Novell eDirectory

Novell eDirectory (formerly NDS (Novell Directory Services ) ) is a highly scalable and redundant directory service, which was introduced by Novell NetWare 4.x with its operating system.

• 2.1 Tree structure
• 2.2 replications 2.2.1 The master replication
• 2.2.2 The Read-/Write-Replikation
• 2.2.3 The Read - replication
• 2.2.4 The Subordinate Replication
• 2.2.5 Change of types of replication

• 2.3.1 Partition Guidelines

• 3.1 The NDS 6
• 3.2 The NDS 7
• 3.3 The NDS 8
• 3.4 The eDirectory

The object of the NDS

The NDS is the central database of a Novell directory tree. The NDS stores all the present system data on its users. These include:

• Username,
• Password
• Authorization within the system
• Data for last login
• Associated printer
• And other data

About this dataset, as usual in databases, queries can be defined. However, the user is in this case only one attribute. Internally, the user is referenced by a key.

Roll

Apart from the users knows the NDS nor the roles. A role is an object that is very similar to that of a user. It can be used at almost all points of the NDS as a substitution of a user. However, a role has no password and a user name. The role can be assigned to a user but then, thus the user gets all the rights that are connected within the NDS with this role. If the user these rights no longer need because he has taken on other tasks, so it can all the rights that were connected to his previous task to be taken easily again. The rolling object is often used when it comes, for example, to determine a department administrator, the maximum has rights to all printers and the department's resources and can reset the passwords of his colleagues. This may be desirable in many institutions to relieve the central network management. However, these extended powers must also quickly remove and clean again. It can not be that one to create a department administrator at x points set permissions and afterwards to remove as many places these rights must again, therefore, the role pleased in many NetWare environments quite popular.

Groups

The formation of groups is possible, as in many other systems including NetWare, while a user can be a member of any number of groups. One group can be assigned within the NDS rights and resources so that this assignment then passes each to the members of the group. The permissions of individual users and groups, where these users, but can conflict with each other. This is an intended feature of the very fine- definable rights structure within the NDS. The general rights order is: The user right breaks right role, the role of law breaking group law. A group G2 has the right to use a printer P1, a role R3 may not use this printer explicitly, the user B4 may use this printer. If the user B4 now a member of the group G2 and has the role R3 it follows that he must use P1. Although the ban on use of roller R3 breaks the permission of the group G2, but its user right B4 allows him again ..

Metadata

The NDS contains metadata such as authorization structures within the NDS exclusively to the concrete instances of the object classes contained in the schema. In contrast, however, the NDS does not contain any information from the file system, as both levels of information are consistently treated separately. Metadata to folders and files, such as permissions, access history, size, etc. are all located in the file system on each volume. Although older Novell NDS management tools such as the NetWare Administrator or ConsoleOne suggest a direct link or transition between NDS and File System, as can be in two tools to administer the file system and its metadata. However, here the corresponding interfaces of the file system were easily integrated. For this reason, there are classic only under NetWare, the possibility of NDS objects to entitle the file system and to take on additional information from the NDS in the file system (eg for load access, quotas, etc.). On other platforms, the NDS has been ported, such as Windows or Solaris, this is not possible. Only with the port of Novell 's NSS file system on Linux, these possibilities were also extended to SuSE Linux in the form of Novell Open Enterprise Server. Here again there is a strict separation of metadata as described above.

Resources

Likewise, all printers, servers and other resources that exist within the NetWare tree, managed by the NDS. Be used in a network or other Novell products, such as groupware GroupWise, then this is of course also fully integrated into the NDS. There are also modules to products of other manufacturers in the NDS to integrate. So it is possible with NDS for Windows NT to fully integrate a Windows NT domain to a NDS and thus about the NDS mitzuverwalten the NT servers and workstations.

Structure of the NDS

Tree

The NDS provides a distributed hierarchical tree-view The top object is always an NDS object [ ROOT ]. All other objects are located under the root object. A freshly installed NDS therefore contains only the object [ ROOT ], at least one container, the ADMIN user, a server object and at least one volume object. The user ADMIN is in this new NDS trustee of the object [ ROOT ] and has to this object Supervisor rights. Since all the rights, if they are not explicitly revised, always inherit from a higher object on all downstream objects, the user has ADMIN, through this a rights definition, maximum access rights to every object in the entire NDS.

Replications

The NDS is as already mentioned a highly scalable, redundant, relational database. The tree represents the hierarchical picture of the NDS represents the NDS database always runs on a particular server within the tree. All other servers must be able to communicate with this server to check whether users are authorized to access or similar files. Almost every click a user thus triggers a change in the NDS. If the NDS would be running on a single server, it would not be redundant, first and second overloaded pretty quickly. The NDS can therefore be replicated to any number of servers. If the NDS replicated on multiple servers, it is called an NDS replication ring. Within such a replication ring there may be different types of replications.

The master replication

The most important replication is the master replication of the NDS. This replication is therefore the most important since, her voice counts most within the transitive replication that uses Novell. The master replication is also the only replication that can determine a new NDS era. The master continues to have a control function in two essential processes within the NDS: all partition operations (merge, split, create / delete / change replica ) (move, rename, and delete objects ) and the Obituary Process. The master acts here as a synchronization instance and ensures that all replicas and External References an object will be achieved. However, a total loss of the master replication is no great harm, because within moments each other replication of the NDS can be determined for the new master replication. As long as there is any, but as complete as possible and current, replication of the NDS, the entire system is functional.

The Read-/Write-Replikation

The next level are the Read-/Write-Replikationen, they have the normal system operation almost the same function as the master replication. A Read-/Write-Replikation can authenticate user requests, they can verify newly created objects, and otherwise take on almost any task in the replication ring, except for the declaration of a new NDS era. The voice of a Read-/Write-Replikation is weaker than the voice of the master replication, but it is also possible that within a transitive replication, the master replication is overruled by the Read-/Write-Replikationen.

The Read - replication

The next stage represent the Read Replicas, they have no meaning in the normal system operation. You can not process requests from users and otherwise perform any tasks within the NDS. Their only raison d'être is that it can be carried in a Read-/Write-Replikation or even in the master replication in an emergency. The advantage of a read- replication is that it does not generate any traffic in NDS replication ring, because it only reads replication packets but never produced even replication packets.

The Subordinate Replication

Subordinate replications, or rather Subordinate References are created there, where a server does have a replication of a parent partition, but not their children. In this case, the server needs a way to store the references of child partition, the so-called replica ring. This is done in a Subordinate Reference, the exact basically consists of the replica head, but can not wear objects. A subref must never be raised to the master if there is another, supporting data, including replication of the corresponding partition because it contains just objects of any kind and therefore all other replications would overwrite with empty databases. If this is a partition in the middle level of the tree (ie including even attach other child partitions ), then the continuity of the tree is destroyed. Generally Subordinate References are fully managed automatically and must not be touched by the administrator

Change of types of replication

A master, a Read-/Write- and a read- replication can be changed by the system administrator at any time in a different type of replication. The only exception is the master replication is, it can not be changed directly, but through the promotion of a Read-/Write- or a read- replication to the new master replication, the old master replication in a Read-/Write-Replikation degraded. Through triggered by the system administrator replication mode change can not happen that no master replication longer exists. The old master replication is also her status on only when the new, the Pending master replication, achieved a certain status has. If the master replication gone permanently lost due to a system failure, so there is a replication is determined to master that tells her promotion to all other replicas.

Partitions

Thus the NDS reaches its high scalability, it can be divided into any partitions. It can thereby a variety of aspects come into play. Either because the NDS is also spatially separated: A company with three locations could, for example, decide to divide their NDS into four partitions. A ROOT partition and one partition each for each of the sites. It would thus also arise four separate replication rings, which may be for the utilization of leased lines between sites of great importance. In addition, a failure of a leased line would not draw too many problems by itself, since three of the four replication rings are completely independent of the leased lines. And only the ROOT replication ring extends over all sites, this ring would be true in its replication disturbed, but this is also not too many problems as long as would be opened at this time, no new fourth company site. In each ring, there is again a replication master replication, which is the single most important for replication that ring. It may also be necessary to partition the NDS when it has reached a certain size, can be achieved by partitioning in such a case, the performance of the NDS be increased since the user requests now be much more targeted Gerichter within the system. In addition, the single replication cycles are accelerated in the replication rings.

Partition Guidelines

Many recommend Novell system administrator that each replication ring should contain at least two to four replications, an increase in the number of replication over five to six replications brings then again performance penalty because the replication cycles are increased in affected rings. The number of objects in a partition is critical to the performance of a partition, at more than 2,500 objects from many another partition recommended.

Further development of the NDS

The NDS 6

The version 6 of the NDS was introduced with NetWare 4.11, they took over from their previous versions. However, it was taken to a compatibility so that it is possible, on each server to work with different versions of NDS, but this can not be recommended.

The NDS 7

The new version of NDS was introduced with Novell NetWare 5.0. The NDS 7 is backward compatible with the NDS 6 server with both versions can thus coexist in a replication ring. The new features of the NDS 7, such as the transitive replication, however can only be used if only NDS 7 server participate in a replication ring, otherwise the old directional replication variant is used. With the NDS 7 first came to the possibility to use the NDS via LDAP.

The NDS 8

The NDS 8 was introduced with NetWare 5.1. It is not fully compatible with NDS 7, but a transition operation of both NDS versions is possible for migration purposes. NDS enables the use of LDAP v3 to query the NDS.

The eDirectory

The Novell eDirectory is the result of the NDS, there is a symbiosis between LDAP and NDS.