LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services
| The LDAP migration planning process consists of several tasks :
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:
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 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
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:
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:
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. |