Generally access rights to NTFS-file servers are assigned deeper than the 1st directory level. As soon as this is the case, one must take care of the fact that the user can should also bo able to browse the file system for appropriate directory. Here there are various possibilities with various effects.
2. Variants of assigning list rights
For browsing through the directory system, migRaven can flexibly form list authorizations. In addition to this, two options are fundamentally offered:
- For the list authorizations, own authorization groups are formed, which for example include the “Change” authorization groups from the lower levels.
- 2. In the directories above the explicitly authorized folder, for example the “Change” authorization groups are used for assigning the list authorizations.
The optimal way is the combination from both options. It should however be used in 1st and not up to the lowest level because otherwise the account appears in several groups. But it should not also be dispensed to position one because otherwise too many entries are included in the ACLs of the above directories. An ACL can maximum includes 1800 ACEs. Too many ACL entries make the access to directories slow.
The list authorizations should be assigned as per certain guidelines. On one hand, the rule applies that authorizations are assigned only via groups, and never directly (see: Direct authorizations). Besides effectiveness of the authorization to the appropriate folder is restricted. This is attained by the setting “Only this folder” in case of “Apply to”:
This configuration must be made on each level up to the actual authorization end point.
One can set whether one generates special list authorization groups or one re-uses the authorization groups for “Read” or “Modify” by the authorization end points.
You can configure the values via this slider. The blue bar determines from which level and up to which level does migRaven generate special list groups. No list authorization is formed by migRaven between 0 = Share and the left end of the blue bar. From the right bar up to the explicit authorization in the level configured by you, the explicit authorization groups are used for assigning the list authorizations.
- Level 0: No list rights are created.
- 1st to 3rd level: List authorization groups are generated, which include the authorization groups (for example for read and modify) of the authorization end point.
- Below the 3th level: The authorization groups (for example for Read and Modify) of the authorization end point are reused.
5. Effects for example of a Modify right in the 7th level
Putting it in a nutshell: Strong rights are not recommendable. We always see in our projects access rights of this type, frequently in case of historically grown rights structures. Also what good or bad is in modifying right in the 7th level?
- The account will become a member at one go in 4 groups: a group for Modify, 3 groups for list -> Increase in the token size
- Setting the authorizations on the levels 1-3 very quickly, because only changes come up in AD (group membership)
- Setting the access rights to level 4 takes a long time depending on the number of files
- The number of ACEs in the ACL in the levels 1-3 is low: good for the perceived performance in case of access; more than 20 – 30 can be perceived
- The number of ACEs from level 4 can exceed the recommended number
List authorizations can be automatically formed with migRaven till in the 10th level. The method is selected in such a way that it is always adjusted. If a user is removed from a certain authorization group for “Change”, then the list authorization is cancelled at the same time. If a complete authorization group is deleted for “Change”, then an orphaned SID remains back in the case to be viewed here on the level 5 and 6. The list authorizations of the levels 1-3 are however completely clean.
It is important to be concerned about the mentioned points before structuring and/or re-creating the list authorizations and to balance the individual effects against each other. Fundamentally it is recommended to work with low authorization structures because it clearly reduces the complexity of the problem not only while assigning the list authorizations. Besides one can confidently satisfy all requirements with an authorization management software (for example 8MAN Enterprise) one can demand the differentiated authorizations and thus can reach quickly to the lowest level up to the 3rd or 4th level of a directory tree.
Please feel free to contact aikux if you have questions related to the topic!