Table of Contents
1. Need for list permissions
As a rule, access rights on NTFS file servers are not assigned below the 1st directory level. But as soon as this is the case, you have to ensure that the user can also browse through the file system to the corresponding directory. There are different options 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. But it should not be used in levels that are too low, otherwise the account will become part of too many groups. At the same time, you must not forego position one, because 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 that permissions are only granted through 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 rights, but applied "Only to this folder"
4. List permissions in migRaven
One can set where to create list groups or where to reuse the authorization endpoint (BEP) authorization groups.
Automatic creation of list groups in the designated area (levels 1 to 3 under the share). Authorization groups (of the BEP) with list rights up to the authorization endpoint are automatically created underneath.
You can configure the values via the slider. The blue bar determines from and 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 becomes a member of 4 different groups in one fell swoop: One group for Modify, 3 groups for List -> increasing the TokenSize
- The setting of permissions is very fast on the 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 levels 1-3 is low: good for the perceived performance during 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.
6. Fazit
It is important to think about the points mentioned before setting up or redesigning the list authorizations and to weigh the individual effects against each other. In principle, it is advisable to work with flat authorization structures because it significantly reduces the complexity of the problem, not only when assigning list authorizations. However, with authorization management software, you can also confidently fulfill requests that require differentiated authorizations and thus quickly go deeper than the 3rd or 4th level of a directory tree.
Talk to us if you have any questions about this topic!
- Step by step - the instructions for the cooperation between 8MAN and migRaven
- Video recommendation: Best Practice NTFS Permissions - The Great Webinar Recording!
Please comment on this amount with own experiences / opinions.