NetIQ eDirectory

from Wikipedia, the free encyclopedia
eDirectory

CWorthy3.png
Basic data

developer NetIQ
Current  version 9.2.2
(May 2020)
operating system Platform independent
category Directory service
License Proprietary software
German speaking Yes
Novell eDirectory

NetIQ eDirectory (until 2011 Novell eDirectory , before that NDS = N ovell D irectory S ervices) is a highly scalable and redundant directory service that was introduced by Novell with its Netware 4.x operating system .

Task of the NDS

The Novell Directory Service (NDS) is based on the X.500 directory service and is used to manage users , access rights and network resources . With version NDS 8, it is also referred to as eDirectory. The NDS is the central database of a Novell directory tree . The NDS saves all data available to the system about its users. This includes:

As usual in databases, queries can be defined via this database. The username is only an attribute here. The user is referenced internally via a key.

roll

In addition to the users, the NDS also knows the roles . A role is an object that is very similar to that of a user. It can be used as a substitute for a user at almost all points in the NDS. However, a role has no password and no username. However, the role can then be assigned to a user, which means that the user receives all rights that are associated with this role within the NDS. If the user no longer needs these rights because he has taken on other tasks, all rights that were associated with his previous task can easily be revoked. The role object is often used when it comes to determining, for example, a department administrator who has maximum rights to all printers and resources in the department and who can reset the passwords of his colleagues. This can be desired in many institutions in order to relieve the central network management. However, it must also be possible to remove these extended powers quickly and cleanly.

groups

The formation of groups is just as possible under Netware as in many other systems; a user can be a member of any number of groups. A group can be assigned rights and resources within the NDS, so that this assignment is then transferred to the members of the group. The permissions of individual users and the groups in which these users are, however, can also contradict one another. This is a wanted feature of the very finely definable rights structure within the NDS. The general order of rights is: The user right breaks role rights, the role right breaks group rights. A group G2 has the right to use a printer P1, a role R3 is explicitly not allowed to use this printer, the user B4 is allowed to use this printer. If the user B4 is now a member of the group G2 and has the role R3, it follows that he can use P1. The ban on using role R3 breaks the permission of group G2, but his user right B4 allows him to do so again.

Metadata

The NDS contains metadata such as authorization structures within the NDS exclusively for the specific instances of the object classes contained in the schema. In contrast to this, however, the NDS does not contain any information from the file system, as both information levels are consistently treated separately. Metadata on folders and files such as permissions, access histories, size, etc. are only located in the file system on the respective volume. Novell's older NDS administration tools such as the Netware Administrator or ConsoleOne suggest a direct connection or transition between NDS and the file system, since the file system and its metadata can be administered in both tools. However, the corresponding interfaces of the file system were simply integrated here. For this reason, there is also the classic option under Netware to authorize NDS objects in the file system and to transfer further information from the NDS to the file system (e.g. for last access, quotas, etc.). This is not possible on other platforms to which the NDS has been ported, such as Windows or Solaris . It was only with the porting of Novell's own file system NSS to Linux that these options were also extended to SuSE Linux in the form of the Novell Open Enterprise Server. Here, too, the metadata is strictly separated as described above.

resources

All printers, servers and other resources that exist within the Netware tree are also managed via the NDS. If other Novell products are used in a network, such as the GroupWise groupware , this is of course also fully integrated into the NDS. There are also modules to integrate products from other manufacturers into the NDS. With NDS for Windows NT it is possible to fully integrate a Windows NT domain into an NDS and thus also to manage the NT servers and workstations via the NDS.

Structure of the NDS

Tree structure

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

Replications

The tree represents the hierarchical mapping of the NDS. The NDS as a database always runs on a specific server within the tree. All other servers must be able to communicate with this server in order to check whether users are authorized to access files or the like. Almost every click of the mouse by a user triggers a change in the NDS. If the NDS only ran on a single server, it would firstly not be redundant and secondly it would be overloaded fairly quickly. The NDS can therefore be replicated to any number of servers . If the NDS is replicated on several servers, it is called an NDS replication ring. There can be different types of replication within such a replication ring.

The master replication

The most important replication is the master replication of the NDS. This replication is the most important because within the transitive replication that Novell uses, its voice counts most. Master replication is also the only replication that can determine a new NDS epoch. The master also has a control function for two essential processes within the NDS: for all partition operations (merge, split, create / delete / change replica) and for the obituary process (move, rename and delete objects). The master acts as a synchronization instance and ensures that all replicas and external references of an object are actually reached. A total loss of the master replication is, however, not a great deal of damage, since within a few moments any other replication of the NDS can be determined to be the new master replication. As long as there is any replication of the NDS that is as complete and up-to-date as possible, the entire system is functional.

Read / write replication

The next level is read / write replication; in normal system operation, they have almost the same function as master replication. Read / write replication can authenticate user requests, it can verify newly created objects, and it can also take on almost every other task within the replication ring, except for declaring a new NDS epoch. The voice of a read / write replication is weaker than the voice of the master replication, but it is also possible that the master replication is overruled by the read / write replication within a transitive replication.

Read replication

The next level is the read replication, which is of no importance in normal system operation. They cannot process requests from users and cannot perform any other tasks within the NDS. Their only right to exist is that they can be promoted to read / write replication or even to master replication in an emergency. The advantage of read replication is that it does not generate any data traffic in the NDS replication ring, since it only reads replication packets but never generates replication packets itself.

The subordinate replication

Subordinate replications, or more correctly: Subordinate References, are created where a server replicates a higher-level partition, but not its children. In this case, the server needs a way to save the references of this child partition, the so-called replica ring. This is done in a subordinate reference, which essentially consists of the replica head, but cannot carry any objects. A subref must never be raised to the master if it also contains another data-bearing replication of the corresponding partition, because it does not contain any objects and would therefore overwrite all other replications with empty databases. If this is a partition in the middle tree level (i.e. there are further child partitions below it), then the continuity of the tree is also destroyed. In general, subordinate references are managed completely automatically and do not have to be touched by the administrator.

Change of replication types

A master, a read / write and a read replication can be changed to a different replication type by the system administrator at any time. The only exception is the master replication, it cannot be changed directly, but by promoting a read / write or a read replication to the new master replication, the old master replication becomes a read / write replication degraded. A change in the type of replication initiated by the system administrator can prevent the master replication from being in place. The old master replication also only gives up its status when the new, the pending master replication, has reached a certain status. If the master replication has been permanently lost due to a system failure , an existing replication is determined as the master, which informs all other replications that it has been promoted.

Partitions

So that the NDS achieves its high scalability, it can be divided into any partitions. The most varied of aspects can come into play. Either because the NDS is also spatially separated: For example, a company with three locations could decide to divide its NDS into four partitions. One ROOT partition and one partition for each of the locations. This would also create four separate replication rings, which can be of great importance for the utilization of the dedicated lines between the locations. In addition, failure of a leased line would not cause too much of a problem, since three of the four replication rings are completely independent of the leased lines. And only the ROOT replication ring runs over all locations, this ring would then be disrupted in its replication, but this does not pose too much of a problem as long as a new fourth company location is not opened during this time. In each replication ring there is again a master replication, which is the most important replication for this ring. However, it may also be necessary to partition the NDS when it has reached a certain size. In such a case, partitioning can increase the performance of the NDS, since user inquiries are now much more targeted within the system. In addition, the individual replication cycles in the replication rings are accelerated.

Partition policies

Many Novell system administrators recommend that each replication ring should contain at least two to four replications. Increasing the number of replications to more than five to six replicas will result in performance disadvantages because the replication cycles in affected rings are increased. The number of objects in a partition is also decisive for the performance of a partition; if there are more than 2,500 objects, many recommend another partition.

Further development of the NDS

The NDS 6

Version 6 of the NDS was introduced with Netware 4.11; it replaced its previous versions. However, attention was paid to compatibility, so that although it is possible to work with different NDS versions on the individual servers, this is not recommended.

The NDS 7

The new version of the NDS was introduced with Novell Netware 5.0. NDS 7 is backwards compatible with NDS 6, so servers with both versions can coexist in a replication ring. The new functions of the NDS 7, e.g. B. transitive replication, however, can only be used if only NDS 7 servers are involved in a replication ring, otherwise the old directional replication variant is used. With the NDS 7, the possibility came for the first time to use the NDS via Lightweight Directory Access Protocol (LDAP).

The NDS 8 - eDirectory

The NDS 8 was introduced with Netware 5.1. It is not fully compatible with NDS 7, but both NDS versions can be used for migration purposes. The NDS enables the use of LDAP v3 to query the NDS.

The eDirectory emerged from the NDS, it is a symbiosis of LDAP and NDS. Netware 5, Windows NT / 2000, Linux / Unix and Solaris are available as operating systems. Existing standards such as LDAP, DNS, XML, XSL, ODBC, JDBC and ADS are supported. The eDirectory consists of the Directory System Agent (DSA), the directory server and the directory clients . Access is via LDAP or the Novell Directory Access Protocol (NDAP). Different levels describe the architecture of the directory service.

literature

  • Jeffrey F. Hughes: Effective eDirectory design and proactive analysis. Learning Design, Scottsdale, AZ. 2001, ISBN 0-9717420-0-6 .
  • David Johnson, James E Gaskin, Daniel Cheung, Ed Tittel: Novell Netware 5.X to 6 upgrade. Que Certification, Indianapolis, Ind. 2003, ISBN 0-7686-6105-6 , p. 150 ff. ( Books.google.de )
  • Taito Radtke: Synchronization of directory services using the example of Novell NDS and Microsoft ADS. 2004. ( informatik.haw-hamburg.de PDF)
  • Jeffrey Harris: Novell eDirectory management. In: Novell Netware 6.5 administrator's handbook. Novell Press, Indianapolis, Ind. 2004, ISBN 0-7897-2984-9 .
  • Peter Kuo, Jim Henderson: Novell's guide to troubleshooting eDirectory. New Riders, Indianapolis, Ind. 2005, ISBN 0-7686-6590-6 .
  • Rick Killpack: eDirectory Field Guide. Rick Killpack, Berkeley, CA 2006, ISBN 1-59059-553-X .

Web links

Individual evidence

  1. ^ EDirectory . NetIQ. Retrieved June 10, 2020.
  2. ↑ NetIQ Adds Identity, Security and Selected Data Center Products from Novell to Portfolio; new executive leadership team. novell.com, accessed November 29, 2015 .
  3. ↑ a b Novell eDirectory. elektronik-kompendium.de, accessed on November 29, 2015 .
  4. ↑ Nds2. hs-fulda.de, accessed on November 29, 2015 .
  5. ↑ Access rights in the Novell network. (No longer available online.) University of Passau, archived from the original on December 8, 2015 ; accessed on November 29, 2015 .
  6. ^ Sander van Vugt: Pro novell open enterprise server. Apress, Berkley, CA. 2005, ISBN 1-4302-0043-X .
  7. ^ Novell Documentation. In: novell.com. Retrieved November 29, 2015 .
  8. ^ Novell Documentation. In: novell.com. Retrieved November 29, 2015 .