| Many of the techniques discussed in the previous section apply to multiple-object manipulation as well as to single-object manipulation. As with single-object manipulation, use of standardized programs in multiple-object manipulation to create scripts for utilities such as UImport, ICE, and JRBImprt can be a tremendous time saver. In the extreme case of a university environment ”where you may be creating thousands of users each term ”there really is no other approach to mass management than using batch tools. In this type of environment, the ability to manipulate data is the key. Suppose you receive a list of students from the university administration or the enrollment department. You need to be able to extract the information from the data provided in order to create user objects with standardized names and information. With a project of this scale, standardization is the key to success. The logical starting place for standardization is the user account names. This is particularly important if you have multiple systems where you want to use the same login identifier for the users. You need to take into consideration several factors when coming up with a standardized naming convention: -
Standardizing the maximum login name length on all systems -
Resolving naming clashes -
Identifying multiple accounts for the same user -
Updating multiple objects The following sections talk about each of these in a little more detail. Standardizing the Maximum Login Name Length Unlike other systems, NDS and eDirectory allow for a fairly long name length: The login ID has a maximum distinguished name (DN) length of 256 characters . This means the username and all contexts back to the [Root] context must be fewer than 256 characters. This should be more than adequate for any environment; if it is not adequate for your environment, you need to rethink your naming conventions. However, in some systems, you or another department might use login names that have different limitations. The AS/400 platform running OS/400, for example, has a maximum login name length of only nine characters. Many Unix/Linux limit you to eight characters. In situations where you want to use the same login ID across platforms ”even if the user information is not shared ”you want to keep the maximum login name lengths in mind for all operating system platforms concerned . NOTE When considering what sort of maximum login name length should be used, remember that in NDS , the username the user typically needs to know is his or her object's common name ( CN ). Thus, if you create the user ID HendersJ in a Unix environment, the DN for that username may end up being something like HendersJ.East.XYZCorp ; the CN portion of the full DN is the part that should match between platforms.
Resolving Naming Clashes The next challenge in multiple-object management is to determine a way to handle name clashes. A naming clash occurs when the following occur: For example, suppose you opt for an eight-character naming convention that uses up to the first seven characters of the last name and the first initial. This would result in the name Jim Henderson generating the login name HendersJ. The name John Henderson, however, would also result in the login name HendersJ. Resolving this type of name clash ahead of time in your naming convention ”particularly if you're using an automated system ”can be difficult. Some companies using this naming convention have opted to use the first six characters of the last name and the first and middle initials . If no middle initial is present, they replace the initial with an uncommon letter ”say the letter X. So, Jim Henderson would now become HenderJS, and John Henderson might become HenderJX. If your organization is small enough, this sort of change in the convention might be sufficient. For larger environments ”such as the university environment described earlier in this chapter ”the naming scheme just described might not be sufficient. You may want to use some other unique identifier in conjunction with part of the user's name ”for example, the user's initials and the last four digits of his or her student number; thus, John Henderson's login ID could end up being JXH1234. In an environment where thousands of users are being created at a time, you do not want to tie the user's name to an arbitrary value. Such a value could be referred to as an "instance number" ”the first user being JXH01, the second being JXH02, and so on. Automating the creation of accounts in this manner can become quite complex fairly quickly, depending on the type of constraints you face. The idea is to use the data provided to create a unique key to be used as the user login name. In smaller environments, it may be sufficient to use first name and last initial or the user's first name or nickname. Choosing a way to resolve name clashes very much depends on your environment and the politics involved. Whatever method you choose to handle it, you should always keep in mind that you may run into a clash, so you should decide ahead of time how you want to handle it. Identifying Multiple Accounts for the Same User Chapter 15, "Effectively Setting Up eDirectory Security," discusses the need to keep administrative accounts separate from non-administrative accounts. Administrative accounts, by their very nature, have the capability to make changes that you may not want to a network during normal operation. For example, an administrative user might be able to make changes to default templates used by the Microsoft Office product suite or, worse , could accidentally delete part of a critical application. The best solution to this is to create a separate non-administrative account for each user who has administrative authority. That way, these users can perform normal operational tasks such as preparing status reports and project plans by using the non-administrative account, without any risk to the software installations. Their administrative IDs should be used only for administrative tasks, such as creating users. This also gives you the ability to restrict a user's rights if he or she leaves your information systems department (or at least leaves the role where he or she performed administrative tasks). You can simply disable the administrative account and modify the user's non-administrative account to fit his or her new job role. TIP One added benefit of having separate IDs for system administration is accountability. If everyone shares the same administrator account, it may be difficult to determine who used the ID last and changed your VP's password.
Using a separate non-administrative account for each user who has administrative authority works very well if the administrative staff has more than one computer to work on. Administrative accounts should be named such that they are easy to identify at a glance ”possibly as obviously as using a user's regular user ID with a special modifier to show the administrative account. Such an identifier could be something obvious, such as the suffix _ Admin (making John Henderson's administrative account JXH1234_Admin ), but something a little subtler might be called for if your environment is likely to have people attempting to hack into the system. Making the administrative accounts easy for anyone to identify removes a barrier to someone attempting to break into your system. One variation of using a suffix on the account is to use a different middle initial ”say Q ”for the user. Searching for administrative accounts that are logged in then becomes a simple matter of searching for all accounts with a middle initial Q . One other variation is to create two non-admin users and two admin users (other than Admin) and scatter them throughout the tree. This might seem like overkill, but if someone either tries to hack the tree or mistakenly creates a destructive policy with ZENworks, for instance, you always have at least one admin and one non-admin user that you can call on to copy a profile from or to log in without using a script, in order to bypass any issues. NOTE Consider keeping at least one hidden admin-type user hidden by placing an Inherited Rights Filter on it. That way, should someone nose around your tree, the person will not be able to come across the administrative username without some efforts. Refer to the section "Protecting Administrative Accounts" in Chapter 15 for more information.
Updating Multiple Objects ConsoleOne (and NetWare Administrator, too) has the capability to perform modifications on multiple User objects; the newer versions of ConsoleOne can also modify multiple non-user objects. To use this feature, you select multiple user objects while holding down the Ctrl key. Then you select either Object, Properties of Multiple Objects (it is called Details of Multiple Users in NetWare Administrator) or right-click the selected objects and then select Properties of Multiple Objects from the context menu. This brings up the dialog box shown in Figure 14.2. Figure 14.2. Viewing password restriction details about multiple users. 
As you can see in Figure 14.2, the dialog box looks nearly identical to the dialog box for a single-object modification. The primary difference is that in this case, you have the ability to set the values for multiple users or to leave values alone. TIP You can use the Search function in ConsoleOne or NetWare Administrator to locate the desired User objects in a tree and then use the Properties of Multiple Objects function to view or change that user's settings. For example, to check the password restriction settings on all Sales users (which are located in different containers in a tree), you can start at the [Root] of the tree, select the Search Subtree option, and search for users whose Department attribute has the value Sales. Then from the resulting search window, you can highlight all these users and select Properties of Multiple Objects.
This particular method of changing multiple users is easy to use, but it can also create problems if it is not used properly. For example, if you change user group memberships on a large scale, the result is that the user group membership lists are the same, rather than just having the desired group memberships being added. A better approach in this case is to add multiple users to the group from the group perspective or to use UImport, ICE, or JRBImprt to make this type of mass change. | 