Table of Contents
1. Need for list permissions
As a rule, access rights to NTFS file servers are lower than to the 1. Assign directory level. But once that is the case, you have to make sure that the user can also browse through the file system to the appropriate directory. There are different possibilities with different effects.
2. Variants of the allocation of list rights
For browsing through the directory system can migRaven build flexible list permissions. There are basically two options available:
- Authorization groups are created for the list authorizations that, for example, include the "Change" authorization groups from the lower levels.
- In the directories under the list groups up to the explicitly authorized folder (authorization point = BEP), the authorization groups (of the BEP) are used for the assignment of the list authorizations.
The optimal way is the combination of both possibilities. He should be 1. not be used in too low levels, because otherwise the account comes in too many groups. But it must not be waived in position one, otherwise there are too many entries in the ACLs of the upper directories. An ACL can hold a maximum of 1800 ACEs. Too many ACL entries make accessing the directories slow.
3. List permissions - the technical structure
The allocation of the list permissions should follow certain guidelines. On the one hand, the rule applies here that authorizations are only granted via groups, never directly (see: Direct permissions). In addition, the effectiveness of the permission should be limited to the appropriate folder. This is achieved by setting "Only this folder" to "Apply to":
Rights of a list group: corresponds to read-execute-right, but applied "Only to this folder"
4. List permissions in migRaven
You can specify where you create list groups or where you reuse the authorization groups of the authorization end point (BEP).
Automatic creation of list groups in the marked area (level 1 to 3 unterm Share). Below this, authorization groups (of the BEP) with list rights are automatically created up to the authorization point.
You can configure the values via the slider. The blue bar determines from which level and up to which level migRaven created separate list groups. Between 0 = Share and the left end of the blue bar will be from migRaven No list authorization established. From the right end of the bar to the explicit permission in the level you configured, the explicit permission groups are used to assign the list permissions.
- Level 0: No list rights are created.
- 1. to 3. Level: List authorization groups are generated which include the authorization groups (eg for Read and Modify) of the authorization endpoints.
- under the 3. Level: The authorization groups (eg for Read or Modify) of the authorization endpoint are reused, but only with list rights. Somewhat irritating is that these groups have suffixes like m, mx, or w, but only have list privileges above the BEP.
- For both types of groups: the rights are only applied to this folder. This means that at least one list group must be created for each level.
5. Effects on the example of a Modify right in the 7. level
To say it in advance: So deep rights are not recommended. In our projects, however, we repeatedly see access rights of this kind, often with historically grown legal structures. So, what's wrong with the Modify right in 7? Level?
- the account will be in one go in 4 groups member: a group for Modify, 3 groups for List -> increase the TokenSize
- setting permissions is very fast on 1-3 levels because only changes are made in the AD (group membership)
- Setting the access rights from level 4 takes a long time, depending on the number of files
- the number of ACEs in the ACL in the 1-3 levels is low: good for the perceived performance on access; more than 20 - 30 are noticeable
- the number of ACEs from level 4 may exceed the recommended number
It can with migRaven into the 10. Level automatically list permissions are established. The method is chosen so that it always cleans itself. Therefore, if a user is removed from a specific permission group for "modify", then the list permission is removed at the same time. If a complete authorization group for "Change" is deleted, the case 4, 5 and 6 remains in this case orphaned SID back. The list permissions of the levels 1-3 are completely clean.
It is important to think about the above points before setting up or redesigning the list permissions, and to weigh the individual effects against each other. Basically, it is advisable to work with flat authorization structures because it significantly reduces the complexity of the problem, not only in the allocation of list permissions. However, you can with an authorization management software (eg 8MAN Enterprise) also confidently fulfill requests that require differentiated permissions and thus quickly deeper than the 3. or 4. Level of a directory tree.
Talk to us if you have any questions about this topic!
- Step by step - The guide to 8MAN and collaboration migRaven
- Video Recommendation: Best Practice NTFS Permissions - The Great Webinar Record!
Please comment on this amount with own experiences / opinions.