Set Windows NTFS permissions optimally
We have conceptualized this document as introduction in the allocation of authorization on the Microsoft Windows File servers. It is illustrated which permissions are there, how one assigns them and which are the considerations of notes in addition to that. Permissions regulate the access to the directories and files, therefore it is important to manage their allocation thoroughly. If the permissions are allocated very casually, everyone can get hold of the work contracts of all employees or other confidential data under circumstances. However if they allocated too restrictively, the work becomes difficult, where probably the employees cannot get hold of the relevant data for themselves, in order to revise it.
In addition to this it is also sensible to use special groups for the permissions, which one should possibly not misuse for other purposes. But most important is, to form the rights allocation as transparent as possible, because otherwise it is almost impossible to administrate the NTFS-rights. From our experience the missing overview is also a basic cause of the problems, which arise with the authorization allocation. Well customized authorization concepts and specialized tools, provide a remedy here, which further back out the possibilities of the Microsoft shelf medium. Of course first we dedicate it to the basis:
1. Overview – general File server- permissions
Permissions are necessary for every file server, so that the user can get hold of the documents, which it also should. There are different variants, to make it possible. Firstly it is the share-permissions, which one should however form as open as possible (z. B. authenticated user -> full access), in order to finally restrict the access to the NTFS- permissions (permissions in the file system). During the allocation of permissions it is to be taken care of that, that one keeps it as even as possible (maximum till the fifth directory level from share), so that the system still remains assessable and the Cerberus token (registration token, explained more precisely further down) does not become too big. Also it should be taken care of to set as little different permission as possible. That means, that one creates directories, on which he gets the whole department “read and run” and only those users get “change”, who actually need it.
At the time of new installation of a file server it is recommended to firstly remove the “creator and owner” or at least to adjust with them. Because this “Dummy-User” ensures, that the one, who creates a document, also becomes the owner and receives complete access rights of these files/folders. In this case the creator could also assign permissions or decline with the result, which the administrators or the backup-user cannot get hold of anymore files or whole directories.
As already stated above, one should also authorize the shares. Here it is not advisable, to authorize “every person” as standard, instead to restrict the whole thing on “authenticated user” or yet better “domain-user” or the department groups. Here it is also recommended, that complete access will not be assigned as commonly as earlier, instead only “Change-rights”. This prevents, that the owner of a directory can change its rights.
One should also ensure to create the shares in this manner, that possibly no shares occur within other shares. An interlacing of shares would result in, that one probably suddenly gets access rights in a deeper level, which are not evident further above in the share -> transparency. Therefore one chooses the shares like this, that as a consequence one can already prevent an access. -> Because when a share is accessible only for a department or its AD-group, other users cannot get hold of it in the first place.
The Cerberus token problem
The Cerberus-token acts as an authentication on Windows-servers and also includes the group affiliations along with the SID. It is restricted in size and adjusted in the course of years and over different Windows-versions. However if a user is a member of many groups and the maximum size of the token is exceeded, the users cannot register on their systems anymore. That is also to be taken care of during the allocation of the permissions and groups.
Local groups (40 byte) seize more memory than global (8 byte) or universal (8 byte in the own domains, 40 byte in a foreign domain), with the MS formula both latter ones are authorized with a fifth part of the size of the local groups. Global and universal ones seize the same memory. The difference is, that the global groups can acquire only the user accounts or other global groups, which belong to own domain. On the contrary, in the universal group user accounts or global groups of all domains can be acquired, which ensures a position of trust. If it is about universal groups of another domain, then they seize the same memory as the domain local groups.
2. ABE (Access Based Enumeration)
As a further point the ABE is to be mentioned. Access-based enumeration, abbreviated as ABE, translated means, “access based listing” or better “random authorization listings”. In the Windows-Explorer only those directories and files are listed for the user, for which he also has access rights. All other folders and files are shielded. One can activate the ABE from Windows 2008 servers, in which one chooses the appropriate share under “share- and memory management” in the server manager, there he recalls the qualities with a right click, clicks on “enhanced” in the first tab and then chooses “activate access based enumeration”.
Illustration 1: activation of the ABE
3. NTFS-permissions – which are there, what do they cause?
The NTFS permissions are the permissions, which are to be set in the file system and there they adjust the access of the users. There are different NTFS permissions, in order to allow them or decline them. The following permissions are to be chosen:
Illustration 2: available standard rights
- Reading – reading of files, notifications of file attributions, owners and authorizations.
- Writing – overwriting of files, change of file attributions, notifications of file owners and authorizations.
- Reading and implementation – implementation of applications and all actions, which allows the authorization “reading”.
- Changing – changing and deleting of files, implementation of actions, which allows the authorization “writing” and “reading and implementation”.
- Full access – changing of authorizations, ownership transfer, implementation of actions, which allows all the remaining NTFS – folder authorizations.
Often it is to be presumed, that one also needs the permission “full access” for creation, opening, processing and deleting of folders and files. This is false. The right “change” will be needed. “Change” contains all that, what a normal user needs for working. The right “full access” gives the user the right to change or to assign authorizations, what should remain reserved in a firm, in order to prevent a chaos in the allocation of authorization. For explanation: Through a full access right for users the access can still be declined, what unfortunately also occurs in the practice and is especially problematic, if for e.g. the administrator or the back-up user is involved. In addition to that there are the following enhanced permissions:
Illustration 3: enhanced permissions
- Full access – grants all permissions for a resource to the user or the groups.
- Browse folders/ implement files – “browse folders” grants or declines the browsing of folders, in order to get hold of the other files or folders – even then, if the user owns no permissions for the browsed folder. “File implementation” grants or declines the ability for implementation of feasible files (application files).
- List folders/read data – “List folders” is valid only for folders, grants or declines the display of files- and subfolder names within a folder. “Data reading” is only valid for files, grants or declines the display of the file content.
- To read attribute – grants or declines the display of the file- or folder attribute, which is determined by NTFS.
- To read enhanced attribute – grants or declines the display of files- or folder attribute, which is determined by the programs. Enhanced attributes are defined through the programs and can differentiate from program to program.
- Create files/ write data – The authorization “create files” is valid only for folders and grants or declines the user the right to change a file and to overwrite its content.
- Create folders/ attach data – the authorization “create folder” is valid only for folders and grants or declines the user the right to create a folder in the respective folder. The authorization “attach data” is valid only for files and grants or declines the user the right to carry out changes at the end of a file, however not to change, to delete or to overwrite existing contents.
- To write attributions – grants or declines the change of the files- or folder attributions, which are fixed by the NTFS.
- To write enhanced attributions – grants or declines the change of the enhanced file- or folder attributions. Enhanced attributions are defined through programs and can be differentiate from program to program.
- Deleting subfolder and files – grants and declines the deleting of subfolders or files in one folder – even then, when the authorization „deleting“ was granted for the involved subfolder or a respective file.
- Deleting – grants or declines the deleting of files and folders
- To read permissions – it makes it possible for the user the reading of a file or a folder to assigned authorizations
- Change of authorizations – it makes it possible for the user to change a file or a folder of the allocated authorizations (without authorization “full access”)
- Transfer owner rights – grants or declines the transfer of the owner rights for files or folders. The owner of a file can always change the authorizations for a data or a folder, independent of the files or the folders of the determined authorizations.
However one should use the special authorizations exactly like the refusal of authorizations, only in special cases. A refusal is not necessary under normal circumstances, because with a thoroughly thought over directory structure the user only has access there, where they need him. If there is a temptation to decline a directory access to a user or group, one should think about it to break the inheritance and allocate the authorizations for this special directory again.
Based on the 8MAN technology 8MAN Visor collects all information of the integrated target system regularly and consolidates these in its databank. On the basis of this evaluation of single authorization cases and audits of whole authorization structure can be followed. Queries and requirements of revision, data owner and economy checks can be done like this. All changes are documented revision secured and with that are 100% comprehensible. Details…
4. The allocation of NTFS-permissions on a share
A share is to be understood like a garden door, which embraces a house with an own closure system. There one can set the right that one first of all comes in the garden. The NTFS-rights are then the single doors in the building, which are again provided with locks. Here it is advisable to work with differenced rights. For e.g. administrators get “full access” and domain users or authenticated users get “change”. The restriction of the rights for specific user groups is especially important, because: It is possible, that one has more rights on the NTFS level than wished for. Figuratively said, the door over NTFS is broader than in the share. But if one wants to now get through the garden door, it is too narrow and one does not come through. This is important in the following point.
When a user creates a directory, he automatically changes from NTFS- level to the “owner” of the folders and through that at the same time gets enhanced authorizations on this folder. It is namely the right to just be able to change the permissions for this folder. But one does not exactly want that in most of cases. When a user tries to change the rights, the NTFS-right allows it, but the “change” rights on the share would prevent these. Through this trick one saves the troublesome changes.
5. The allocation of NTFS-permissions in the file system
As mentioned at the beginning, one should form the permissions as “evenly” as possible, in order to make a specific transparency possible. One can allocate the authorizations on the folder as well as on the files, whereby a file system can become randomly complex. The allocation of the authorizations takes place in the rule through AD-groups (active directory groups), so that they can be centrally administered.
Allocation on folder or on data?
The allocation of the authorizations except on the file level is not recommended, if one observes the complexities of the file systems. So one should allocate the authorizations on the folder as far as possible, because under these circumstances during the allocation of authorizations the whole file system becomes so incomprehensible, that at the end it is not administrable.
The A-G/U-G-P Concept – groups or direct administrative rights?
Rights in a single domain structure “should” always be assigned according to the A-G-G-P or A-G-P concept. Other variants are necessary only when many domains are connected or are available in the Forrest. A-G-G-P mainly ensures that the security-token does not accrues strongly. One should also not rely often on old information out of books, rather follow their own reason.
- A = Account
- G/U = Global domain groups/ universal domain groups -> here all the users are advesperated; for instance all staff of sales.
- G = Global groups -> this is used for the assignment of administrative rights in File system; for instance to change the right of a group with the name “DL_V1_V2_V3_md”, here “md” stands for modify; this group then either incorporates the global group or in exceptional case individual users.
- P = Permission
One should get used to creating a group in AD (Active Directory) every time administrative rights are assigned, for ex. “Index_XY_change” or “Index_AB_read”, which is also used for these rights, which in turn simplifies the rights allocation.
As one now predominantly – besides during the installation of a folder – works from AD through groups, the assignment of rights is a lot quicker and moreover one gets an overview about the assigned rights when one sees the members of the G-group. Now there are only those people supposed to be in the group, who have any rights. This however is a deceiving assumption, as one can never be too sure in Microsoft about who actually has got the rights. Microsoft is unfortunately in such cases extremely non-transparent. Here we suggest the usage of third party tools for an effective representation of rights.
ADVICE: Unfortunately an interpretation of the A-G-G-P concept from the NT times still strongly persists. So once again we advise the usage of global domain groups. As a matter of fact there should be a group for clusters of users in one specific assignment area or organization chart (for ex. Sales). In the past the domains of local groups were often doubled: DL_V1_md turned to G_V1_md. This however just leads to the doubling of groups and has, according to Microsoft, no practical use.
One should, therefore, NEVER give user direct rights to a folder, as the transparency also suffers in this process and while deleting the user and the default, to remove the rights, only the SID´s of the user remain in the index (dead SIDs). Moreover the implementation of rights also takes a long time and the many entries (;)) (ACE) in the ACL lead to a slowdown in access. Theoretically around 1820 ACEs can be part of an ACL – which is however not practical. More than 20 slows down the access: http://support.microsoft.com/kb/166348
Image 4: „dead SIDs“
Recommended is the creation of AD-groups (for ex. Departmental- or project groups), who should be assigned rights to several indexes, so as to avoid adding all users individually every time in the respective rights groups. Need to know-concept: only those rights should be assigned every time, which the staff actually needs for their work.
6. Inheritance of access rights
The inheritance of rights means, that the rights of a folder, as set, can be transferred to other lower levels. This naturally does not exclude the option of adding extra rights to a further lower level. Furthermore through a sensible application of inheritance the possibility of an excessively big Kerberos-token can be avoided. For this one needs to set the higher level of rights in such a manner that they can be thoroughly inherited to the lower levels. Best option is to have only limited permissions (LIST) on the root and then to expand the permissions. To disrupt inheritance is a totally bad option and this should therefore be undertaken only in very exceptional cases. One can completely carry on without disruption through neat planning and eventually through adaptation of file structure.
Image 5: the set rights looks like this
Image 6: the inherited rights look like this
7. The setup of list rights
List rights are those rights, which are assigned so as to allow the users browsing through the indexes. If a user enters into Share, then he wants to click to the indexes relevant to him. If one however sets the rights only in the 4th level, then this would impede the user’s access. In this regard one assigns the respective indexes with the right, “list folder” only for the specified folder:
Image 7: Assigning list rights
By deciding the list rights following things should be considered:
- How many indexes with changed rights do I have within the Share and the consecutive levels?
- How the user´s group membership looks? (are the user´s already present in different groups?)
With reference to such factors one has to decide, in which level can one create list groups and in which levels can one use rights groups for list rights.
With reference to such factors one has to decide, in which level can one create list groups and in which levels can one use rights groups for list rights.
Image 8: Index levels
As far as, for instance, one only uses the rights groups then it should be noted that, in the upper levels numerous groups within the rights appear, which reduce clarity. An Implication of this is the increased group membership of the users, if one only uses the list groups.
Notice: the list group assignment must be individually adapted for every file system and AD.
8. How does one then proceed?
- Find out, how big the Kerberos-token is i.e. in how many groups the users are already members?
- Find out, how many indexes with changed rights are needed?
- Come to decision, how the list rights should/must be set.
- Set the basic rights in the first level and let these be inherited in the lower levels.
- Set the deviating rights in the lower levels (from up to down) and let them be inherited further down.
- Setting up of list groups i.e. list rights
⇒ How should one administer their rights?
Surely not with the tools available with Microsoft!
There are simply a lot of settings to be undertaken and to be removed. As pointed in the previous points, a lot of individual steps are to be taken so that the rights correspond to the current requirements. Now imagine the effort it takes to maintain these structures consistent over the time, for instance, when an index is renamed or groups become unnecessary or the index structure changes. Every time one need to make changes due to some point or the other, which furthermore are dependent on other aspects and this eventually leads to a lot of efforts.
For this reason, to make things simple and to avoid the aforementioned problems, 8MAN enterprise has been developed. The rights management-suite functions in a highly efficient manner and brings comfort in the whole administration, maintains consistency across structures and makes every single change through its automatic documentation understandable.
Conclusion & Suggestions
In small spaces rights could be personally assigned, whereas in large settings this does not function in a coherent manner, as a complex rights structure inevitably ends up in chaos with no clarity whatsoever. If one maintains the rights structures with Excel-tables, then these would according to experience always deviate from the actual structure, as a quickly undertaken change is seldom documented.
- In large settings it is therefore vital, to implement tools for allocation of authorizations, which assign and document rights.
- By large shuffling one should moreover already work out a consistent concept for the allocation of authorizations
- According to experience migration in new systems can be used well for a neat re-assignment of rights. The file server-tool migRaven represents exactly this process.