S 4.309 Setting up access authorisations for directory services
Initiation responsibility: IT Security Officer, Head of IT
Implementation responsibility: Administrator
A directory service generally stores large amounts of information requiring protection, for example user data, for an organisation. It is therefore essential that this information is only accessible to expressly authorised applications, users, and administrators. It is necessary to consistently and strictly implement a security policy (created in advance) that contains the rules regarding the access authorisations (see S 2.405 Drawing up a security policy for the use of directory services).
The rights are generally assigned using access control lists (ACLs). Access authorisations can be assigned at the object level as well as at the attribute level. Rights can only be assigned using ACLs in the positive sense, i.e. they can only grant access explicitly. An access list cannot be used to explicitly define which users should be prohibited access.
Access authorisations are assigned explicitly to the owner of the rights. The additional objects a given target object is allowed to access are entered when assigning the rights in this case. It is therefore also possible to determine which target objects a given object is allowed to access.
Access authorisations are inherited according to the tree hierarchy of the directory service. However, this initially only applies to the object rights and the attribute rights are only inherited when this has been configured explicitly. The automatic inheritance of access authorisations by the child objects from the parent object can be controlled in the configuration using masks or filters. Since a user can use the "Self" right to change his/her own attribute values, the use of this right is critical from a security perspective and should be controlled with the help of a filter.
When a directory tree is partitioned, there is initially a gap in the chain of inheritance. This gap is closed automatically, though, by appending an inherent ACL.
The rights that actually apply when attempting to gain access are referred to as the effective rights, i.e. the access authorisations resulting from the rights granted according to the mechanisms mentioned above. The effective rights are calculated dynamically for each access and are stored in the cache of the server. The administrators should be able to display the currently valid effective rights to individual objects using a management console and should check a subset of these rights at regular intervals.
An important aspect when assigning rights in the directory service is the configuration of the user and group accounts. Defining suitable user and administrator groups makes it easier to design the rights assignment more transparently.
This is recommendable, since a highly complex administration will generally increase the risk of misconfigurations. Templates should be used to simplify the configuration of the users and user groups and to make these configurations more consistent.
Directory services allow both role-based and function-based administration. If these administrative roles are not defined yet, then the schema of the directory service will need to be extended. Administrative tasks can be delegated so that they can be performed by members of a specific user group (the group of administrators). This is how the delegation of administration tasks is carried out.
If two or more directory service trees will be combined into one overall tree, then the effective rights resulting after combining the trees must be checked. This also needs to be taken into account when moving the partitions within a directory service tree. It is also necessary to check the access authorisations and change them accordingly, if necessary, for example after a Windows domain has been moved to an eDirectory tree via migration.
Review questions:
- Were the access rights of the user group and administrator group configured according to the security policy created for this purpose?
- Are samples of the effective rights which are actually valid for the target objects checked at regular intervals?
- Are the administrator roles and the delegation of administration rights configured consistently?