Assignment of list rights - Windows token count problem

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.

Token Count – Token Size Problems with Kerberos authentication on Windows

Caution: Deep directory structures with explicit permissions will inevitably lead to the Kerberos token count problem. This is the case when a user is effectively a member of more than 1015 groups. The group type is irrelevant. Unlike the token size, which can be expanded via GPO, this is not possible with the token count value!

The problem is fueled again when groups still have entries in the SID history. Each additional SID increases the counter.

That's why it's important to pay close attention to how deep you assign permissions. We recommend placing the right hand as flat as possible. That would actually only be the first level.

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 also only use authorization groups to assign list rights?” Or
• "Can I use authorization groups at the top and list groups at the bottom?" And
• "Up to which level can list groups be used and from which authorization groups?"

This should be clearly illustrated with the following greatly simplified example.

1.4. Example

To simplify matters, we assume authorization endpoints in level 7. We also set a value for the average number of subdirectories per directory. We assume that in the 7th level all these directories are given explicit rights. 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 suitable and where authorization groups, it is best to negate the question:

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.

Problem:

The Kerberos token increases by 8 or 40 bytes for each list group, depending on the group type. If the size of the Kerberos token exceeds a certain server-dependent value, the affected user can no longer log in. This leads to the token count problem.

Conclusion:

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.

Problem:

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.

Conclusion:

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.

2.3. Fazit

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