S 4.157 Setting of access authorisations to Novell eDirectory

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The eDirectory directory service normally stores large volumes of sensitive corporate and user data. It is therefore essential that this information is only accessible to expressly authorised applications, users, and administrators. For this, it is necessary to consistently and strictly implement a previously drawn up security policy that contains the rules regarding the access authorisations (see S 2.238 Specification of security guidelines for Novell eDirectory).

With eDirectory, the rights are assigned using access control lists (ACLs). Access authorisations can be assigned at the object level as well as at the attribute level. The following object rights (and/or privileges) are available: browse, create, delete, rename, and supervisor. Attribute rights include: compare, read, add or delete self, write, supervisor, and inheritance control. Rights can only be assigned 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.

Figure: Rights assignment in Novell eDirectory

Access authorisations are assigned expressly by so-called trustee assignments. The additional objects allowed to access a given target object are entered in this, i.e. that are trustees of this target object. The other way around, it is also possible to adopt the perspective of an accessing object and see which target objects this 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 objects can be controlled by configuring so-called masks or inherited rights filters (IRF). This way, the inheritance of access authorisations can be limited. Since the self privilege may be used to change one's own attribute values, it is critical from a security perspective and should also be controlled with the help of a filter.

Figure: Assigning rights

When a directory tree is partitioned, there is initially a gap in the chain of inheritance, which is closed automatically, though, by appending an inherited ACL.

Another option for granting access authorisations to eDirectory objects includes the assignment of a so-called security equivalence of an object to another object. This way, it can be defined that object X at least disposes of the same access options as object Y. All trustees of object Y will thereby automatically become trustees of object X.

Figure: Configuring group memberships

The rights which actually apply when attempting to gain access are referred to as the effective rights, i.e. the access authorisations resulting from the rights assigned 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 administrator may use the management console ConsoleOne in order to have the currently applicable effective rights to individual objects displayed.

An important aspect when assigning rights in the eDirectory includes the configuration of the users and the user group (organisational roles). 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 (organisational roles) and to make these configurations more consistent.

eDirectory allows both role-based and function-based administration. For this, so-called RBS objects (role-based service) and then RBS job objects, as well as RBS function objects are defined. This requires an extension of the directory service's scheme. With the help of the RBS function objects, the tasks are defined that may be performed by the members of an assigned user group (administrator group). This way, the delegation of administration tasks is also allowed.

In the event of a possible merger of two or more eDirectory trees into one overall tree, the effective rights resulting from this must be checked. This also must be taken into consideration when moving the partitions within an eDirectory tree. It is also necessary to check the access authorisations and to change them accordingly, if necessary, for example after a Windows NT domain has been moved to an eDirectory tree via migration.

Review questions:

• Is the eDirectory security policy implemented consistently and strictly regarding the rules for the access authorisations?
• Are templates used for configuring users and user groups (organisational roles)?