Best Practice NTFS Permissions – AGDLP Myth

There is no "best practice"!

Thomas Gomell

The administration of authorizations (ACL / ACE) in the Windows file server world is complex. The main reason it is so complicated is that there is no common database. The file server and the authorized accounts come from the same world, but there is no central directory in Windows (as under Novell) that brings together the information from ACEs and accounts. (How nice was the time with Novell 😉

There are technical and regulatory requirements that the administrators have forced to find solutions (workarounds) in order to meet them.

Problems / challenges / aspects in the administration of ACL with NTFS file system

1. Reporting / traceability -> groups don't really help
   How do you find out where a group / user is authorized in the file system if you don't have a tool that can read this information from a database.
   Somebody came up with a clever idea and created groups that contain the directory name in the name and also the right that is represented by the group. Actually a smart idea. Unfortunately, the only disadvantage is that the groups are not automatically updated or deleted if the path is changed or directories are even deleted. After a certain time, this leads to considerable discrepancies with the ACTUAL in the system. So this approach doesn't really work.
2. Speed ​​setting permissions -> use group wherever you can!
   This is a legitimate reason to use groups for permissions. These are entered once in an ACL. If the authorized accounts change, only the members of the group in the AD are adjusted. This is quick and takes effect immediately after the affected accounts log on to the computer again.
3. Kerberos Tokensize/Tokencount -> Be careful with groups!
   There are environments in which the same accounts have to repeatedly access identical directories.
   For example, if a company works very heavily in projects (directories) that are highly standardized.
   \ Project 1 <- access for project management
   -> \ Carpenter <- Access for all carpenters
   -> \ Purchasing <- Access for all buyers
   -> \ xxx <- Access for role X
   
   In these cases Kerberos token problems can quickly arise if you have hundreds of such directories and you would work with authorization groups. The Kerberos token count is strictly limited to a maximum of 1015 group memberships. These can be achieved very quickly in such constellations. Users can then no longer log on to their computers.

Combinations of roles and authorization groups

What does AGDLP stand for:

• A: User or computer account account),
• G: Global group,
• DL: Domain local group,
• P: authorization permission; e.g. entry in ACL).

In order to better show the different combinations, I would like to translate this. The AGDLP becomes an A-RG-BG-P

• A: User or computer account account),
• RG: Role group (contains all user accounts from a specific unit or with a specific functional role in the company)
• BG: Authorization group (domains local / global / universal)
• P: authorization permission; e.g. entry in ACL).

The different methods for granting permissions

modus	Account	RG	BG	P	Use
Org mode	X	X	X	X	in directories named like a department; Members become automatically managed by IAM.
Project mode	X	X		X	very many identical constellations. individual BG would blow up the token. Management is taken over by the owner (project manager).
Exchange Mode	X	(X)		X	Directories are only used for a short time, but they are given proper rights. But then z. B. deleted after a few days. Groups don't make sense.
Process mode	X		X	X	The players in the process are usually distributed across organizational units. The use of roles is not effective.

The search for the corrective - role groups yes or no?

The main question in this game is the following:
"Who makes sure that something goes away again? Who is the corrective?".

That is why you have to give a lot of thought. There, always goes somehow. But no user will put IT under pressure and threaten the boss to have his rights withdrawn. (Laughter)

There are two options for this real challenge.

1. Automatic management of authorizations via roles
   This method is the first choice if the roles are controlled by a reliable body. For example, a leading HR system specifies the membership of people in organizational units and the members of roles (groups) are automatically and correctly maintained via an interface or an IAM system.
   Corrective -> HR system
2. Management of authorizations via owner
   If there is no automatism to benefit from, the task has to be entrusted to a person who has a relationship and an interest in the data and correct permissions. This person is assigned the role of "owner" and takes on the management of the authorization on their own responsibility using suitable tools.

Practice has shown that a degree of utilization of 40% - 60% is achieved. The trend is clearly towards more flexibility and comprehensive data exchange. This is mainly due to the self-service of migRaven.24 / 7 supported.

Optimal depth of granted authorizations

This question arises again and again. In the past, explicit authorizations also had to be granted at lower levels on request. Over the years this practice has raised a number of problems that need not be mentioned here.

Structure itself is usually the root of the problem. It is always best to find the objects that are relevant in a directory and not have to search for them in a structure. This saves time and costs. But unfortunately the reality is different. Many directory trees often contain several thousand files per employee. Just as the number of objects has grown in recent years, this will also happen in the coming years. You have to leave this spiral -> migRaven Data retention offers the right solution here

The optimum is when you only need authorizations on the first level. But this can only be achieved if structures are broken up. You have to look carefully why you need permissions at lower levels at all. This is usually the case if you have directories that are designed according to an organizational chart and then contain process, project or exchange directories. It becomes very easy if you build up basic structures that allow a clean separation from the start. In order to break up the existing structures, should

1. all obsolete data / authorizations are identified and eliminated
2. Project, process and exchange directories are separated
3. remaining directory structures can be made flatter
4. ensure that it is lived that way.

Build an optimal directory structure

Organization or team directories: Based on the organization chart, but not structured like that. All units should be parallel on the first level! It is essential to activate ABE so that the user only sees the directories to which he is authorized. Advantages: The authorizations can be administered fully automatically with a clean design and use of an IAM system.

Process, project directories: record all projects or processes directly. These are managed by the owner directly via self-service from migRaven.

Exchange directories: Will be flat by migRaven.24 / 7 Self Service created and managed by the owner. We recommend that these directories be deleted automatically after a short time. E.g. after 7 days. Users are always directly authorized. Administration can be done directly via migRaven.24 / 7.

Public folder: A special feature in this case is that many users can read the information, but only a few can manage the data.

Application directories: Software applications read or write data in these directories. Many directories could not be renamed in the last few years because the dependencies were too high and no one dared.

In all constellations, it is important to ensure that data has to leave the structures again. File servers must not be used like swollen dead ends. Rather, it is a tube from which the oldest data emerges at the end when it is no longer used.

Consequence

You often hear that there is ONE best practice for assigning authorizations or structures. I cannot confirm that from many years of experience. There are always very different requirements and you then have to look for the best solution for the requirement. Up until now, each of our customers had their own requirements, most of which ended in very specific solutions. Let one of our partners advise you.