RSS
 |
|
by Tom Zeller
Designing Novell Directory Services
User Objects: Collected or Distributed? This leads to a discussion of user objects. There are several advantages to having a single large container for user objects, but only under certain circumstances. The conditions for centralization of users are all users are centrally created and managed, no bindery services are required for user logins and slow network links are not a concern. In such a situation, centralization of users offers a simpler model. For instance, if everyone in the corporation has a fully qualified name of .username.users.corporationname, a user can easily grant rights to another user by knowing only his or her user name and not the user object's exact location within the hierarchy. This model also facilitates the automation of account creation and elimination and the setting of user attributes. Another advantage is the ease of report generation on user accounts-s uch as a report on the number of users, a list of disabled accounts or a list of accounts that haven't logged in for six months. However, this approach requires the assignment of unique user names for all users (arguably, a good approach anyway). If the above conditions are not the situation, however, you might find it beneficial to disperse the user objects throughout the hierarchy.
Also, if user objects are to be maintained by individual departments, then having the user objects under departmental containers makes the most sense. A departmental administrator can be given an account with control over a departmental container, giving him or her complete management control of objects within that container and without jeopardizing the security of objects in the rest of the tree. This model allows for the coexistence of user objects with the same user name such as .jones.users.sales and .jones.users.marketing, if that is deemed desirable. Another reason to have user objects distributed is if bindery services will be required on some servers. To deliver bindery services, a server m ust have a read-write replica of a partition that includes the objects that are to be represented as bindery objects. This represents a severe drawback to the centralized user model. It means replicating a rather large partition and turns peripheral departmental servers into key NDS infrastructure servers, as problems in any server in the replica ring for the users container could create problems for all users. Fortunately, as more software has become NDS-aware, there are fewer situations that require bindery services than two years ago. Most notably, the Windows95 and NT clients are now NDS-aware, at least for logins. Novell also provides an NDS client for the Macintosh, but I haven't found a single Mac user who enjoys using it. Most NetWare Loadable Modules (NLMs), such as metering and backup software, are now also NDS-aware. If you have older software that requires bindery services, you should consider upgrading to a current version or migrating to another product to avoid use of bindery services In a very large organization with central administration, standardizing departmental subdivisions might be beneficial. For a smaller NDS environment, or one near the leaf end of a larger NDS tree, the decision on NDS structure is probably less important. If local departmental members are the administrators, it is probably best to let them create a substructure that makes the most sense to them.
A very small department with 50 or fewer objects might simply place all these objects in its departmental container. With more than 50 objects, however, it is probably better to have subcontainers for servers and volumes, users and printer objects. This lets individual objects of a given type be located more quickly.
Print This Page
 E-mail this URL |
User Login Under NDS: 1) User requests login. 2) If server 1 doesn't hold user object, server walks tree to find a server that does. 3) Server 2 tells server 1 it doesn't hold the object, but to try server 2's parent. 4) Server 3, the parent, knows server 4 holds the user object, and directs server 1 to pass that information to the user. 6) Server 1 tells client to talk to server 4. 7 and 8) Workstation requests and receives login from server 4.
