Table of Contents
In order to access authorization endpoints in lower directories, the authorized users require list rights. Two types of groups can be used for this purpose: special list groups on the one hand and the authorization groups that are created for the authorization endpoint on the other.
Here is to be shown how both types of groups interact and that their advantages and disadvantages are balanced when they are used together.
1. The use of list and authorization groups for the allocation of list rights
1.1. Why list rights?
1.2. List rights
- Browse folders / execute files
- List folder / read data
- Read attibute
- Read extended attributes
- Read permissions
1.3. Two group types for the allocation of list rights
In other articles it has already been pointed out that for the allocation of list rights
- List groups and
- Rights groups
can be used. This raises questions such as:
- "Can I only use list groups?" Or
- "Can I only use authorization groups for the allocation of list rights?" Or
- "Can I use authorization groups above and list groups below?" And
- "To what level can list groups be used and from which authorization groups?"
The following simplified example should illustrate this.
For simplicity, we assume permission endpoints in the 7 plane. We also set a value for the average number of subdirectories per directory. We assume that in the 7. Level explicit rights are assigned to all of these directories. Finally, we need an average value for the number of authorization groups per authorization endpoint (BEP).
We note that each directory has 2 subdirectories.
In the 7.plane, each directory has an explicit permission group. These are the authorization endpoints (BEP).
To answer the question of where list groups are appropriate and where authorization groups, the question is best negated:
Where are list groups or permission groups unsuitable?
The example numbers answer that clearly:
- In the lower levels, many list groups burden the Kerberos token for the authorized users.
- In the upper levels, many permission groups burden the ACL and slow access to the directory.
And all the more, the larger the assumed values are.
2. Comparison of both procedures
2.1. List groups
List groups are created additionally, per group a group.
For each list group, the Kerberos token increases by 8 or 40 bytes, depending on the group type. If the size of the Kerberos token exceeds a specific server-dependent value, it is no longer possible for the affected user to log in.
In our example, the number of list groups doubles from level to level. From level 4 or 5, the number of list groups can already be considerable. In these levels, list groups should no longer be used. If you experience problems with the Kerberos token, the border between list and permission groups should be moved upwards.
2.2. Authorization groups with list rights
These groups are not created additionally. The groups created for the authorization endpoint (BEP) are reused. It is important to emphasize that these authorization groups are only authorized with list rights for the directories to be traversed.
Any group authorized in any way occupies an entry in the access control list (ACL) of the directory. In our example, the number of permission groups per directory doubles from level to level, but starting from the bottom. In the top level, all underlying authorization groups with list rights are authorized, which can be very many. If you want to see this directory, Windows must check if you have the right to do so. Windows compares the contents of your login token with the ACL entries of that directory. The more entries in the ACL, the longer it takes for the content of the directory to be displayed to the user.
Authorization groups have a suffix that corresponds to the right to the authorization endpoint. You should not let that irritate you. In the higher directories where this group is used as a list group, of course, it has the same suffix as the BEP, but listing rights, this is a bit confusing.
In the upper levels, therefore, no authorization groups should be authorized directly to the directories. For this, a list group should be used, which occupies only one ACL entry. The authorization groups are nested in this list group.
Thus list groups and authorization groups with list rights form a perfect complement to each other. The boundary between the two must be determined according to your circumstances. One universal rule can not be called.
The example shows which parameters cause the problems and should therefore be avoided:
- the number of subdirectories with explicit rights,
- The number of authorization groups per authorization endpoint in subdirectories