Migration Planning

The LDAP migration planning process consists of several tasks :

• Collecting data

• Analyzing the data

• Resolving conflicts

• Consolidating the data

• Choosing migration tools

This section provides tips on how to accomplish these steps.

Collecting Data and Resolving Conflicts

Identifying all sources of naming service data is one of the first steps you should perform. You should also identify what the authoritative source for the data is. The most obvious place to start is with your NIS and NIS+ databases. Other areas include:

• Electronic messaging system

• LDAP directory supporting web-based applications

• Lotus Notes/Domino

• Human Resource Database

If your enterprise is running multiple NIS/NIS+ domains, which is likely, you need to determine if all the domains use the same maps or if the maps vary among different domains. You also need to identify any custom NIS maps that you might be deploying. The following is a list of standard NIS/NIS+ maps, or databases, followed by descriptions of potential data consolidation issues to look out for.

• passwd and shadow

• group

• hosts

• ipnodes

• ethers

• bootparams

• netgroup

• networks

• netmasks

• aliases

• services

• protocol

• rpc

• publickey

• automount

• user_attr

• audit_user

• auth_attr

• exec_attr

• prof_attr

passwd and shadow Databases

The passwd and associated shadow database are arguably the most important and most used by the Solaris OE. The entry in this map has seven fields, each separated by colons, as shown in the example and described in TABLE 2-1.

Example passwd entry:

 tb250:SnLaPR6XvcJV6:1250:10:Tom Bialaski, Enterprise  Engineer:/home/tb250:/bin/csh 

Table 2-1. passwd and shadow Database Fields

Field	Description
login_name	A string composed of no more than eight alpha-numeric characters . The string is used as an index to locate a user 's password. The login process searches the naming database until a match is found. There is nothing inherent in NIS or NIS+ to enforce login name uniqueness. The pwck command can be used to check for duplicates.
password	The password is actually obtained from the shadow database which contains one-for-one entries corresponding to the passwd database. In the shadow database the password is stored in UNIX crypt format, which is a one-way hash. Although the clear text password cannot be easily be determined, the hash string can be copied to another passwd database and used in the authentication process.
uid	A numeric value used in the Solaris OE authorization process. While the number should be unique within the namespace, there is nothing inherent to prevent duplicate uid numbers from being assigned. If duplicates exist, the first one found is used. When merging multiple NIS/NIS+ domains, you should verify that everyone has a unique uid . Most enterprises probably have already done this. However, merging databases from different companies can be problematical.
gid	A numeric value used to identify the user's primary group. Secondary groups are specified in the groups database. The gid is not expected to be unique and is usually assigned a name in the groups database. Like the uid , the gid is used for assigning and granting access rights. Issues with consolidated group membership information are discussed in the group database section.
gecos	Contains a free-form text field used to store descriptive information about a user. The information in the gecos field is used by some messaging applications to display the user's full name and title. Modern LDAP-based messaging systems provide several attributes for storing this information, which diminishes the importance of the gecos field. Because there are no guidelines for how to store data in this field, the format of the information varies widely between enterprises. Migrating this information to LDAP generally requires custom scripts.
home_directory	Specifies the directory where users are placed after a successful login. The directory specified here is usually an automount point. The common convention is to use the user login as the home directory name. Therefore, the same issues with login names apply here. Consolidation of automount tables is another issue which is discussed in the automount database section.
user_shell	Specifies the preferred shell to invoke after a successful login. Because there are no dependencies on the value of this field, there is no impact with consolidation.

group Database

The group database is used to either assign a name to a group, for example, staff::10: , or to assign secondary groups to a user. A numeric identifier called the gid is assigned to each group. By default, GID numbers 1-10, 12, and 14 are used by the Solaris OE. Group numbers should not be greater than 60000 (60001 and 60002 are reserved for nobody and noaccess ). It is recommended that the GID for normal users be no less than 100. This is because some applications, such as PC NetLink, use group numbers under 100.

Group names and GID numbers have a high potential for collision when merging naming services because group names tend to be generic and GID numbers are usually assigned sequentially, starting from a boundary like 101 or 1001. There is also nothing inherent in NIS or NIS+ to prevent duplicate group names or undefined users being added to groups. The grpchk command can be used to check for these conditions. Sorting out group conflicts can represent the most challenging activity when consolidating naming service data.

The following is an example of what a group entry looks like:

 lab:*:261:csdemo,carlab,waldo,adele,pj23592,riggs,ktegan,ann, vella 

hosts Database

The hosts database contains host names, host name aliases, and their associated IP address. While this information can also be stored in DNS, the Solaris OE sysidtool programs may make use of NIS or NIS+ to automatically configure Solaris OE systems. Host information is sometimes kept in both DNS and NIS/NIS+ databases so non-NIS/NIS+ clients can access the information. Most enterprises have already grappled with consolidating host names when they set up DNS. However, there might not be a one-to-one mapping between DNS domains and the LDAP namespace. For example, the U.S. might be split into east, central, and west DNS subdomains, but only have a single LDAP domain. This means there is a potential for host name conflicts when they are consolidated.

Systems that have multiple network interfaces, called multi-homed systems, have different LDAP representations than systems with single network interfaces. You will need to identify multi- homed systems, so they can be properly migrated .

ipnodes Database

This database is used to support Internet Protocol version 6 (IPv6). Because this protocol is relatively new and not widely adopted, there will be few consolidation problems. The issues here are the same with the hosts database, but might not apply to your environment.

ethers Database

The ethers database is used to map an Ethernet address to a host name and IP address. With most TCP/IP operations, this step is not necessary because the system sending or receiving a TCP/IP packet will already know its IP address and host name. However, to perform an automated installation using Solaris JumpStart software, the client does not have this knowledge, and must find out this information by broadcasting its MAC address. If JumpStart technology is used extensively throughout your enterprise, the ethers database may be quite large. The ethers database contains host names, so the same consolidation considerations apply as for the hosts database.

bootparams Database

The bootparams database is used to support Solaris OE JumpStart technology, network booting, and diskless client services. The entries it contains may reference NFS mount points by host name. If entries in the hosts database were modified to resolve conflicts, these entries need to be examined.

netgroup Database

The netgroup database is used to restrict access to network resources. The entries in the netgroup database include a domain name and, optionally , user names. If you have multiple domains that need to be collapsed into a single domain, the entries here need to be updated to reflect the new domain name.

networks Database

The networks database defines a name for a particular network number. It is referenced by some Solaris OE utilities like the netstat utility to display a meaningful name instead of just a number. Consolidation should have little effect unless there are name conflicts.

netmasks Database

The netmasks database defines a subnet mask for a particular network. It is referenced by ifconfig(1m) when configuring network interfaces. Because this information may be supplied through the JumpStart sysidfg file, it might not be used in your enterprise. If it is, consolidation should not be a problem because each entry would most likely be unique.

aliases Database

The aliases database is used to store email aliases used by the Sendmail facility. If you are not using Sendmail to forward messages, you do not have to worry about this database. If you are, then consolidation of NIS domains may have an impact. In most cases the same aliases database would be used throughout the enterprise, so consolidation would not be an issue. The /usr/lib/sendmail -OCheckAliases can be run to validate aliases before rebuilding the aliases database.

services Database

The services database is used to determine which port number a particular network service uses. For standard services with well known port numbers, consolidation is not an issue. However, for homegrown services, or services from different vendors , the potential for conflict exists.

protocol Database

The protocol database is used to map a protocol name to a protocol number. Because protocol names and numbers are industry standards, consolidation of this database should not be an issue.

rpc Database

The rpc database is used to map remote procedure calls (RPCs) to port numbers. If different parts of an enterprise developed their own unregistered RPC-based applications autonomously, it is likely there will be some conflicts here.

publickey Database

The publickey database is used to store public or secret keys typically used by secure RPC applications. If users' keys are being stored, you could have the same issues as with login names.

automount Database

The automount database actually consists of several databases. There is a top-level database called auto_master which contains a list of all other automount databases. Most organizations will have many automount databases defined. The potential for conflict is high, because common names such as auto.tools are used. Re-organizing your automount structure requires a fair amount of planning.

Role-Based Access Control (RBAC) Databases

To support new security features in the Solaris 8 OE, five new databases were introduced:

• user_attr

• audit_user

• auth_attr

• exec_attr

• prof_attr

If these are widely used in your enterprise, there is a possible conflict with user_auth because user names are stored here.

User-Defined (Custom) NIS Maps

The NIS and NIS+ naming services can be extended by creating your own NIS maps or NIS+ tables to hold data specific to your enterprise. To access this data, applications that use the Solaris OE naming service API are written. These applications generally communicate directly to the name service and not to the name service switch (the nsswitch.conf file).

There is a generic object class for specifying generic NIS maps in LDAP. However, unless your application consults the name service switch, converting it will not buy you much. Redesigning your application to access LDAP directories directly probably makes the most sense.

Establishing Unique IDs

Politically, one of the toughest migration decisions to make is establishing an enterprise-wide naming convention for assigning unique identifiers to all users. Employees who have worked for a growing company for a long time, or for a small company that has been absorbed, may be reluctant to change their simple login ID. For example, there may be a tom@east , tom@central , and tom@west . Obviously, at least two user IDs will have to change.

Choosing NIS/NIS+ Migration Tools

Once you have identified all your naming service data sources and resolved any conflicts, the next step is to decide what deployment approach works best for you. The two options are:

• Convert your clients to Secured LDAP Clients, eliminating NIS and NIS+

• Keep running NIS and NIS+ client, but use LDAP as a back-end store

With the first option, you can take advantage of the security features of the Secured LDAP Client, and you can use password storage schemes other than UNIX crypt. You can also take advantage of client failover and features such as Service Search Descriptors (SSDs). These features are explained in Chapter 4 "Deploying Solaris OE LDAP Naming Services."

The second option has the advantage of not having to modify client software. It also allows you to begin a migration including clients running earlier Solaris OE versions than Solaris 8 OE. The downside is that you still have the limitations of NIS and NIS+ and passwords are required to be stored in UNIX crypt. Descriptions of migration tools can be found in Chapter 5 "Migrating Legacy Data to LDAP" and in Chapter 10 "Emerging Directory Technologies."

It should be noted that the LDAP migration tools discussed in this book are designed to aid in the transition and not meant to be a permanent replacement for NIS and NIS+. If your clients support the Secured LDAP Client, you are encouraged to deploy it rather than the migration tools.