Allocation of list rights

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?

For Windows servers, the problem is that a user who has rights to subdirectories (at lower levels) has problems finding these directories. Without ABE he sees all the directories, but does not recognize to which he has rights, and certainly not at lower levels.
With ABE ("access-based listing" or better "authorization-controlled listing") he sees from his current location only the subdirectories to which he has rights. If he has rights under it, the directory to be traversed will not be displayed. The path is blocked.
The directories to be traversed, to which the users do not actually have any rights, will be given list rights to the users.

1.2. List rights

List permissions are permissions that are granted to allow users to browse through the directories.
List rights include the rights:
  • Browse folders / execute files
  • List folder / read data
  • Read attibute
  • Read extended attributes
  • Read permissions
They comply with the Read & Execute rights but with the restriction: only for this folder, List rights are not inherited.

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.

1.4. Beispiel

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).

Levels below
the share
number of
Directories
List groups
per level
Rights groups
per directory
Level 1: 2 2 64
Level 2: 4 4 32
Level 3: 8 8 16
Level 4: 16 16 8
Level 5: 32 32 4
Level 6: 64 64 2
Level7, BEP: 128 1

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.

Problem:

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.

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

Permanent link to this post: https://help.migraven.com/vergabe-von-listrechten/