S 2.237 Planning of partitioning and replication in Novell eDirectory

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, Head of IT

As a scalable directory service, eDirectory offers the ability to divide parts of the directory database into partitions and to distribute them across different eDirectory servers. This reduces the average access times, since the search will only span a special partition and not the entire directory tree under some circumstances. In addition, partitioning increases the reliability, since only the partitions located on the server will be affected and not the entire directory database if one server fails. Furthermore, partitioning allows distribution of the data according to a previously performed classification scheme among correspondingly secure servers.

When planning the partitions, it is necessary to take into consideration the partition rules defined by the eDirectory.

Figure: Planning eDirectory partitioning

In turn, partitions may contain sub-partitions, which were created according to the rules specified. Partitions can be used to either perform different operations, e.g. generating, merging, moving, or cancelling one of the mentioned operations.

In addition to the mechanism of partitioning the directory tree, eDirectory also offers the ability to replicate parts of the directory tree on other eDirectory servers. In the terminology of eDirectory this is referred to as replicas. Each partition contains a so-called master replica. These form the centre of the respective partition. The creation of new sub-partitions or new replicas of the current partition depends on the availability of the master replica server. There are different options for replicating the directory data to other servers:

• Read/write replica: Read/write replicas of a partition may be accessed just like the master replica itself. In particular, the data can be modified in a read/write replica. The information is exchanged automatically between the individual replicas. If the server the master replica is stored on fails permanently, a read/write replica may be configured to be the master replica.
• Read-only replica: These replicas only receive synchronisation updates from other replicas. Clients are not capable of changing the content of a read-only replica.
• Filtered read/write replica: Only a part of an eDirectory partition is replicated to these servers. The selection of the replicated content can be performed both at the level of the object classes and at the level of individual attributes. The content of this replica may be changed by clients. If the information is changed, the content is synchronised automatically with the other replicas.
• Filtered read-only replica: This type of replica only contains a selection of the entire partition that may not be changed by clients in addition. The same options apply to the selection of the content to be replicated as to the filtered read/write replicas.

The types of replicas described above are set up and configured manually. The replication itself is automatic. Another type of replication includes the subordinate reference replicas. However, these are created and administrated by the eDirectory system itself. They only contain branch addresses, so as to be able to efficiently resolve object names across partition borders (so-called tree walking).

When planning the partitions, the following aspects should be taken into consideration:

• Consideration of the protection requirements: The information to be stored in the directory should be classified according to its protection requirements. The objects should then be distributed among correspondingly secure servers based on this classification. In doing so, it must be ensured that the content of the security container is stored to a sufficiently secured server in particular, since this is sensitive information. For example, the security container stores the key management objects and the security policies.
• Required availability of the directory service: A sufficient number of replicas of the directory data must be created on eDirectory servers to improve load distribution.
• Distribution of the administrative tasks: In order for a separation of roles regarding the administrative tasks to go hand in hand with the separation of the data storage, the administrative tasks should be distributed between individual partitions.
• Compliance with the eDirectory rules for partitioning. The most important rules in this case include the following:
  • Every partition begins hierarchically with a single container object.
  • The partition must be a coherent subtree of the eDirectory tree.
  • Different partitions should not overlap.
  • The name of the partition must be the fully qualified distinguished name (FQDN) of the root object of the partition.
• The exact contexts of the servers containing partitions/replicas. If the structure is too flat, this results in a greater internal effort for replication. Furthermore, individual servers not available at a given time will result in corresponding status messages on all other eDirectory servers contained in this replication ring.

The following items must be taken into consideration when planning the replicas:

• The specifications regarding the number of replicas to be generated must be derived from the availability and reliability requirements placed on the directory service.
• The load distribution planning is based on the required system performance.
• It must be decided whether additional security can be gained by defining filters for replicas.
  
  The additional security provided comes particularly in the form of the ability to separate the data storage according to the data classification specified in advance. This allows for implementing the basic principle of only allowing an eDirectory server to store the data that it actually "needs" (and/or which the users or applications accessing the data actually need).
  
  However, this additional security may remain inefficient in the event of inconsiderate configuration. The system performance may be a potential disadvantage. If the data sought for is not available and/or cannot be found on an eDirectory server because it is being hidden by corresponding filter rules, the search for the data will continue in the background (provided that this is permitted). Therefore, a filter rule configuration that does not meet the actual needs may have adverse effects on the performance of the system.
  
  Example: An eDirectory server is located in the intranet of an organisation and only a share of the directory data stored there must also be made available on the internet. One possible solution is to install an additional eDirectory server in the demilitarised zone (DMZ) between intranet and Internet containing a filtered replica only containing the information actually needed on the internet.

• The data storage must be planned. Here, it must be planned with the highest possible level of detail which data must be available to whom and from where. For example, filtered replicas can be used for implementing the specifications.

Review questions:

• Has the information stored in the eDirectory directory been classified according to its protection requirements?
• Have the specifications regarding the number of replicas to be generated been derived from the availability and reliability requirements placed on the directory service?
• Planning the data storage: Is there a plan with the highest possible level of detail as to which data must be available to whom and from where?