(Version from August 18.08.2020, XNUMX, author: Thomas Gomell t.gomell (at)migRaven. Com)

Introduction

We have this document as Introduction to Authorization Designed on Microsoft Windows File Servers, It explains which authorizations are available, how to assign them and what preliminary considerations are necessary.

Permissions regulate access to the directories and files, which is why it is important to handle their assignment with great care. If the allowances are given too loosely, everyone may be able to access the employment contracts of all employees or other confidential data. However, placing them too restrictively makes it difficult to work because employees may not be able to access data relevant to them in order to process them.

The most important thing is to make the allocation of rights as transparent as possible, otherwise it will be almost impossible to administer the NTFS rights.
The lack of overview is also from our experience a major cause of the problems that result from granting the authorization. Remedy here well adapted authorization concepts and special toolsthat go far beyond the capabilities of Microsoft on-board resources.

A VERY IMPORTANT note at the beginning:

There always goes - never goes away 😉

The most important thing is to think about how something will go away. Somehow, there is always a right to "go there" and when the user moves into the IT department with his tent to express his will. However, the same situation is unimaginable when it comes to revoking permissions.

Because if you use the following procedure to manage the permissions, then you will quickly get many permission groups on the filer.

That is why it is important to think about the daily processes in addition to the pure technical award. These are not the content of this article.

If questions remain unanswered, you can also contact me directly.

But let's start with the basics:

1. Overview - General file server permissions

Authorizations are necessary on every file server so that only those users can access documents who should. There are different ways to do this. First of all, there are the share authorizations, which should be made as open as possible (e.g. authenticated users -> full access) in order to ultimately restrict access via the NTFS authorizations (authorizations in the file system). When assigning authorizations, make sure that you keep them as flat as possible (up to the 5th directory level from share) so that the system remains manageable and the Kerberos token (logon token, explained in more detail below) is not too large becomes. Care should also be taken to set as few different authorizations as possible. This means that you create directories that the entire department can "read and execute" and only those users who actually need it are "changed".

Please note!

When reinstalling a file server, it is recommended to first remove the "creator and owner" or at least to adapt. Because this "dummy user" causes the person who creates a document to become the owner and has full access rights to these files / folders. In this case, the creator could also grant or deny permissions, with the result that administrators or the backup user can no longer access files or entire directories.

As mentioned above, you should also entitle the shares. Here it is not recommended to authorize "Everyone" by default, but to limit the whole thing to "Authenticated Users" or even better "Domain Users" or departmental groups. Here is also recommended that not - as usual in the past - full access is granted, but only "change" rights. This prevents the owners of a directory from changing their rights.

You should also ensure that the shares are created in such a way that, if possible, no shares are created within another share. Nesting the shares would mean that you might suddenly get access rights at a lower level, but these are not visible further up in the share -> transparency. The shares are therefore chosen in such a way that they can prevent access -> Because if a share is only accessible to one department or its AD group, other users cannot access it in the first place.

The Kerberos token-size problem

The Kerberos token is used to authenticate to Windows servers and includes not only the SID but also the group memberships. It is limited in size and has been adapted in size over the years and across several Windows versions. However, if a user is in too many groups and the maximum size of the token is exceeded, users will not be able to log in to their system. This should also be taken into account when assigning permissions and groups.

Local groups (40bytes) occupy more memory than global (8byte) or universal (8bytes in their own domain, 40byte in a foreign domain), the latter two are calculated in the MS formula with one-fifth the size of the local groups. Global and universal occupy the same memory. The difference is that global groups can only include user accounts or other global groups belonging to their own domain. In universal groups, on the other hand, user accounts or global groups of all domains to which a trust relationship exists can be included. If they are universal groups from another domain, they consume as much memory as domain local groups.

The Kerberos token count problem

The Kerberos token can contain a maximum of 1024 SIDs. So each user can be a member of a maximum of 1024 groups. This quickly becomes a problem, especially for domain migrations, when the number of SIDs doubles due to the SID history. If I was only a member of 500 groups (which can be reached quickly), I migrated to 1000 after the migration. Up to this size, it still works. You can create 16 more groups and then it's over!

2. ABE (Access Based Enumeration)

Another point to mention is the ABE. Access-based enumeration, abbreviated to ABE, translates to "access-based listing" or rather "entitlement-based listing". In the Windows Explorer, only the directories and files for which the user has access rights are listed to the user. All other folders and files are hidden. The ABE can be activated from Windows 2008 servers by selecting in the server manager under "Sharing and memory management" the appropriate share, there with a right-click to call the properties, in the first tab (Sharing) click "Advanced" and then "Access-based Activate enumeration ".

ABE is a feature that has always been part of the Novell Filesystem standard.

The ABE is extremely important. If it was necessary to build very deep directory structures without ABE, so that the users can find a certain structure over which they can retrieve the data, it is possible with ABE to build extremely flat directory structures. Each user now sees only the directories to which he is actually entitled.

Here is an example of a highly structured directory tree:

Suggestion: The same directory tree but in flat with ABE.

Result by ABE

The members of Team 1 see only the directory "Team 1" and the team leader still sees the "Team 1 ladder" directory. And then you can ask yourself if it is actually flat enough. Maybe you should also top up the content of "Team 1".

Why is this done? Because it is beneficial for the users! Why should they only fight through many levels, even if they could come directly.

Of course, this is just a simplistic example, but it shows the possibilities very nicely. In addition to the activation of ABE described below, the clean authorization of list rights on the directories is especially important. The right one Structure can be found in article 7.

Figure 2: Activation of ABE under 2012 Server

If a DFS is still used at the same time, it is important to activate the ABE on this page. Every hook works only in its area! However, the entry in the DFS must be made manually.

3. NTFS permissions - what is there, what do they do?

The NTFS authorizations are the authorizations that start in the file system and regulate user access there. There are several NTFS permissions to allow or deny access. The following authorizations are available:

• Read - Read files, view file attributes, owners and permissions.
• Tender - Overwrite files, modify file attributes, view file owners, and permissions.
• Read and execute - Execute applications and all actions that allow the "Read" permission.
• Change - Modify and delete files, execute actions that allow the permissions "Write", "Read and Execute".
• full access - Change permissions, take ownership, perform actions that allow all other NTFS folder permissions.

It's often assumed that you need Full Control permission to create, open, edit, and delete folders and files. That's wrong. All you need is the right to change. "Change" contains everything that a normal user needs to work. The right "full access" gives the user the right to change or assign permissions, which in a company should be reserved for the administrators in order to avoid a chaos in the assignment of authorizations. Explanation: Through a full access right for users, access can also be denied, which unfortunately also occurs in practice and is particularly problematic if, for example, the administrator or the backup user is affected. In addition, there are the following extended permissions.

Figure 2: Available standard rights

Figure 3: Advanced Permissions

• full access - Grants the user or group all permissions to a resource.
• Browse Folder / Execute File - Browse Folders allows or denies folder browsing to access other files or folders, even if the user does not have permissions to the folder being searched. “Run file” allows or denies the ability to run executable files (application files).
• List folder / read data - "List folders" only applies to folders, allows or denies the display of file and subfolder names within a folder. "Read data" only applies to files, allows or denies the display of the file contents.
• Read attributes - allows or denies the display of the file or folder attributes set by the NTFS.
• Read extended attributes - Allows or denies the display of file or folder attributes set by programs. Extended attributes are defined by programs and can differ from program to program.
• Create files / write data - The Create Files permission applies to folders only, and grants or denies the user the right to create files in each folder. The Write Data permission applies only to files and grants or denies the user the right to modify a file and overwrite its contents.
• Create folder / attach data - The Create Folder permission applies only to folders and grants or denies the user the right to create folders in each folder. The Append Data permission applies only to files and grants or denies the user the right to make changes to the end of a file, but not to modify, delete, or overwrite existing content.
• Write attributes - Allow or deny the modification of the file or folder attributes set by NTFS.
• Extended Attributes Write - allows or denies the modification of the extended file or folder attributes. Extended attributes are defined by programs and may differ from program to program.
• Delete subfolders and files - Allow and deny deletion of subfolders or files in a folder - even if the subfolder or file is not deleted
• Delete - allows or denies the deletion of files and folders
• Read permissions - allows the user to read the permissions assigned to a file or folder
• Change permissions - allows the user to change the permissions assigned to a file or folder (without Full Control permission)
• Take ownership - Permit or deny ownership of files and folders. The owner of a file can always change the permissions on a file or folder, regardless of the permissions set on the file or folder

However, just like denying permissions, you should only use the special permissions in special cases. A refusal is not necessary under normal circumstances, because with a sophisticated directory structure the users have access only where they need it. If you are tempted to deny access to a directory to a user or group, you should think about breaking the inheritance and re-assigning the permissions for that particular directory.

4. Assigning NTFS permissions to a share or share

A share is like a garden door enclosing a house with its own locking system. There you can set the right, that you even get into the garden. The NTFS rights are then the individual doors in the building, which in turn are provided with locks. Here it is recommended to work with differentiated rights. For example, administrators get "Full Control" and Domain Users or Authenticated Users get "Change." Restricting permissions for specific user groups is particularly important because: It's possible that you have more rights at the NTFS level than you would like. Figuratively speaking, the door on NTFS is wider than in the share. But if you want to go through the garden gate, it is too narrow and you can not get through it. This is especially important in the following point.

When a user creates a directory, it automatically becomes the "owner" of the folder at the NTFS level, giving it equal privilege to that folder. It is the right to change permissions for this folder. But that's not what you want in most cases. If a user attempts to change the rights, that would allow the NTFS right, but the "modify" rights on the share would prevent this. This trick saves you annoying changes.

5. The allocation of NTFS permissions in the file system

As mentioned earlier, you should make the permissions as "flat" as possible to allow for some transparency. You can assign the permissions to both folders and files, which makes a file system arbitrarily complex. Authorizations are generally granted by AD groups (Active Directory groups), so that they can be administrated centrally.

Assignment to folders or files?

Assigning permissions down to file level is not recommended, considering the complexity of the file system. So, as far as possible, you should only assign permissions to folders, because when assigning permissions to files, the entire file system may become so unmanageable that it will not be administrable at the end.

The AG / UGP principle - groups or direct authorization?

Permissions "should" in a single domain structure should always be assigned according to the AGGP or AGP principle. Other variants become necessary when multiple domains are linked or in the forest. Above all, AGGP ensures that the security tokens do not grow too much. At the same time, one should not listen too much to often outdated information from books, but follow his own mind.

• A = Account
• G / U = Global Domain Group / Universal Domain Group -> the users are clustered here; e.g. all employees in purchasing
• G = Global group -> this is used to assign authorizations in the file system; eg a group for the “Change” right with the name: “DL_V1_V2_V3_md”; "Md" then stands for modify; this group accepts either the global group or, in exceptional cases, individual users.
• P = Permission

You should get used to creating a group in the AD (Active Directory) for each authorization, eg "change directory_XY_change" or "directory_AB_read", which is also only used for this authorization, which considerably simplifies the assignment of authorizations.

As most of the time - except when setting up the folder - you work through groups from the AD, the assignment of permissions is faster and you can also get an overview of permissions if you look at the members of the G group. Now there should only be those who have permissions. Unfortunately, this is a deceptive assumption, since you can never be so sure under Microsoft who is actually eligible. Unfortunately, Microsoft is extremely intransparent at this point. Here we recommend the use of third-party tools for the effective presentation of permissions.

NOTE: Unfortunately, there is still a strong interpretation of the AGGP principle from NT time. So here's the hint for using the Global Domain Group. This should actually be a group for clustering the users according to a task area or organization chart (eg purchasing). In the past, local domains were often doubled: DL_V1_md became G_V1_md. This only leads to a doubling of the groups and has no practical use according to Microsoft's own statement.

You should NEVER authorize a user directly to a folder, as this also loses transparency and if the user is deleted and the authorization is not removed, only the SIDs of the users remain in the directory (dead SIDs). In addition, setting the permissions takes an unnecessarily long time. In addition (;-)) too many entries (ACE) in the ACL cause access to be slowed down. Theoretically, there can be around 1820 ACEs in an ACL - but this is not practical. More than 20 makes access slow: http://support.microsoft.com/kb/166348

Figure 4: "Dead SIDs"

However, what is recommended is the creation of AD groups (eg department or project groups) that are to be authorized for multiple directories in order not to have to add all users individually to the corresponding authorization groups each time. Need to know principle: Only as many authorizations should be allocated as the employee actually needs for his work.

6. Inheritance of access rights

The Inheritance of permissions means that the permissions of a folder, as set there, are also transferred to lower levels. Of course, this does not exclude adding additional permissions at a lower level. It can also be achieved by a meaningful use of the inheritance that a Kerberos token is not overly large. You should set the permissions in the top level so that you can pass them on well down. It is best to only have minimum permissions (LIST) on root and then extend the permissions.
Breaking up the inheritance is very bad style, which is why you should do it only in very rare exceptional cases. Through clean planning and possibly an adaptation of the File structure you get it out, you can get along without interruption.

Figure 5: How set privileges look like

Figure 6: How inherited permissions look like

7. Setting list permissions

List permissions are permissions that are granted to allow users to browse through the directories. If a user joins the share, he also wants to be able to "click through" to the directory that is relevant for him. But if you look in the 4. Level sets a permission, he can not do that necessarily. For this, assign the right "list folder" to the directories above only for this folder:

Figure 7: allocate list rights

There are several things to remember about setting the list rights:

1. How many directories with changed permissions do I have below the share and the subsequent levels?
2. What is the group affiliation with the users? (Are the users already in many different groups?)

On the basis of these events one must decide in which levels list groups are created and in which levels the authorization groups are used for the list rights.

Best practice with a maximum authorization assignment up to 5. Directory level is when you use list groups in the first and second directory levels and in the 3. and 4. Level uses the permission groups.

Figure 8: Directory Levels

If, for example, only the authorization groups are used, it should be noted here that a large number of groups appear in the authorizations at the highest levels, which greatly reduce the clarity. Conversely, the group affiliation of users is greatly increased, if you only use list groups.

Note: The list group assignment must be adapted individually to each file system and AD.

8. So how do you do it?

1. Find out how big the Kerberos token is or in how many groups the users are already members.
2. Find out how many directories with changed permissions are needed.
3. Decide how to set the list rights.
4. Put the basic permissions in the first level and this down inherit.
5. Set the different permissions in the lower levels (from top to bottom) and pass them back down.
6. Set list groups or list permissions.

Conclusion & recommendations

In smaller environments, the permissions can be granted by hand, in larger this is no longer feasible to implement, as a complex authorization structure inevitably ends in an unmanageable chaos. If you maintain the authorization structures with Excel spreadsheets and the like, they will, according to experience, always deviate from the actual structure, as it is often forgotten to document a quick change.

• In larger environments, it is essential Authorization toolse which assign and document the authorizations.
• In addition, major restructuring should already be in advance a uniform concept for granting authorizations be worked out.
• Experience shows that migrations to new systems can be used very well for a clean re-allocation of permissions. The file server tool migRaven exactly depicts this process