S 2.236 Planning the use of Novell eDirectory

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Head of IT, Administrator

Basically, there are two operational scenarios for eDirectory:

• the use as management product for resources in a given network or
• the use as (meta) directory service (LDAP server).

When viewed abstractly, the eDirectory forms a hierarchically organised and tree-like, object-based database. It is based on the X.500 directory service standard, and its internal structure and internal design are taken from this standard. However, it is not a X.500-compatible directory service, since the access protocol is based on the proprietary NDAP (Novell Directory Access Protocol).

The tree concept of eDirectory is as follows: servers, users, and further resources are represented in a tree (tree) and they can be administrated by the tree administrator. A tree basically forms an administrative boundary and therefore also limits the effective scope of authorisations.

An eDirectory directory tree consists of different objects. Every object belongs to a distinguished class, e.g. user object or server object, and is composed of different attributes and/or properties according to its class. The various object attributes may adopt different values such as a telephone number or an IP address, for example. The information on the existing object classes, including the attributes contained therein, is stored in the directory scheme. New object classes can be created or existing object classes can be equipped with changed sets of attributes with the help of changes to the scheme definition. Changed schemes are referred to as an extended scheme. eDirectory knows different pre-defined object types:

• Tree object: This object is the root of all eDirectory objects of a directory tree and contains more detailed information about it, e.g. name of the tree. Other objects can be placed below the tree object.
• Container objects: These objects are used to group other objects. By default, the objects Country (C), Organisation (O), and Organisational Unit (OU) are available. An OU object may contain other OU objects, as well as so-called leaf objects (see below).
• Leaf objects: These include server, user, user group, role, printer, printer queue, profile, as well as application objects. Furthermore, alias objects may also be defined to provide a reference to existing objects in other sub-trees.

Figure: Novell eDirectory Tree

An eDirectory tree always contains a distinguished root that has a certain special position: it is determined by the first server that is installed in a tree. This server is used to run the certificate authority (CA) of the tree, which is a prerequisite for integrating additional eDirectory servers into the tree. The CA may be relocated to another eDirectory server later. All additional eDirectory installations must register with the specified eDirectory tree. Here, the exact context, within the framework of which the eDirectory server is integrated into an existing tree, must be specified. Relocating the eDirectory servers at a later point in time is very difficult, and so the server context must be planned in advance.

The first three eDirectory servers of a tree automatically contain a complete replica of the directory data and the following servers do not contain any replicas - unless they are expressly configured to.

After a default installation, there is an initially simple eDirectory structure designed by eDirectory that can be changed in accordance with the plans. If the eDirectory is primarily used for the administration of IT resources, it should be properly taken into consideration when designing the eDirectory tree structure that the structure also needs to be designed based on administrative conditions. If the organisational structure of an organisation is modelled down to the smallest detail instead, this may cause problems regarding the administration.

Moreover, it must be ensured that the selected tree structure is not too flat so that the replication between the eDirectory servers does not have effects on the entire tree. The failure of an individual eDirectory server or the connection of this server to the remainder of the system will otherwise result in error messages generated by all servers integrated into the replication ring.

The possible arrangements of eDirectory objects, i.e. the specification of which object is allowed to contain which other objects, which attributes exist, and which attributes can be used to form objects, are defined by the so-called eDirectory scheme. The scheme specified by eDirectory can be modified, but this is a significant interference with the directory structure that must only be performed upon careful planning.

The eDirectory directory service provides the option of synchronising data in the XML format with other directory services with the help of a synchronisation mechanism. For this, the product DirXML is available as an XML interface. It consists of a core (engine) and different drivers for diverse supported destination systems, e.g. Lotus Notes, SAP R/3, Windows 2000 Active Directory, Netscape (iPlanet), etc. Here, there are two communication channels: on the one hand, there is the so-called publisher channel, which third party directory services may use to inform the eDirectory of changes to their database. On the other hand, there is the subscriber channel, which registered third party directory services may use to obtain information of changes to the eDirectory.

Figure: Publisher Channel

The use of the DirXML interface absolutely requires detailed planning in order to avoid undesired side-effects later on, e.g. endless loops.

The following aspects need to be taken into consideration within the framework of eDirectory planning:

• Which division in organisational, organisational unit, and additional container objects is to be selected?
• Which object classes are needed and which attributes should they have?
• Which users and servers should be compiled in which organisational units?

For each organisation, it must be decided:

• which administrator groups are required,
• which administrative model will be implemented (central or local administration),
• which administrator roles there should be within the tree structure,
• whether or not and to whom the administrative tasks should be delegated,
• which security settings should apply to the different types of servers and user groups,
• which information is allowed to be accessed using the various eDirectory interfaces (e.g. eDirectory clients, LDAP) and by whom.

In general, the planned eDirectory structure must be documented. This contributes significantly to the stability, consistent administration, and therefore to the security of the system. It is recommended to particularly document:

• Which scheme changes are performed? The reasons for the changes should also be documented in this case.
• Which object classes are used in which manner and, in particular, which attributes are used for which content?

The following should be documented for every eDirectory object:

• name and position in the eDirectory tree (e.g. "BerlinOffice", parent object: OU "Offices in Germany"),
• which purpose the object serves,
• which administrative access rights should be assigned for the object and its attributes (e.g. administered completely by "Admin1"),
• how the inheritance of eDirectory rights should be configured, for example by blocking or filtering the rights inherited,
• which security equivalences should exist between objects.

The eDirectory administration and the administrative model used must be planned in any case. The configuration of a role-based administration and the option of delegating administrative tasks are particularly security-critical. Reasonable, clear, and consistent planning may render the security administration using these functionalities more transparent and efficient.

The use of eDirectory includes the operation of a its own, integrated certificate authority (CA). Planning depends on the requirements and particularly on the security policy drawn up in advance here as well.

In summary, the following security-relevant core aspects to be addressed during eDirectory planning result:

• Trees limit the administrative power of administrators and the directory service itself.
• By default, the user Admin is created within the organisation container of the eDirectory tree when installing eDirectory for the first time. This user has the so-called supervisor privilege for the entire tree.

• Administrative delegation is achieved by granting access rights to eDirectory objects and their attributes. The access rights must be distributed according to the administrative model used. Amongst other things, the mechanisms for access rights in eDirectory include inheritance, inheritance control, effective range of access settings, and security equivalence between objects. This may be used to establish very complex authorisation structures that may very quickly become too complex and impossible to administrate so that misconfigurations in the eDirectory may open up security gaps. The authorisation structure used should be as simple as possible for this reason.
• Scheme changes are critical operations and must only be performed by authorised administrators after careful planning.

Finally, it must be pointed out that errors made in the eDirectory planning phase and in the underlying concepts may only be corrected with extensive time and effort after installation is complete.

Review questions:

• Has a detailed context been defined within the directory tree for the planned eDirectory server?
• Has an eDirectory plan been implemented and documented?
• Has the synchronisation of the directory data with additional directory services been planned?
• Are the reasons for the scheme changes documented?
• Has the concept of role-based administration been planned consistently?
• Are scheme changes only performed by authorised administrators upon careful planning?