This chapter discusses the high-level planning you should do before beginning the server and client setup and installation processes.This chapter covers the following topics.LDAP Planning Overview Planning the LDAP Network Model Planning the Directory Information Tree (DIT) LDAP and Replica Servers Planning the LDAP Security Model Planning Client Profiles and Default Attribute Values for LDAP Planning the LDAP Data Population The LDAP client profile is a collection of configuration information an LDAP client uses to access LDAP naming services information about the supporting LDAP server. This chapter discusses the planning of the various aspects of the LDAP naming services. These include the network model, the directory information tree, the security model, the default values of the various profile attributes, and finally, the preparation for data population. For availability and performance considerations, each subnet of the company-wide network should have its own LDAP server to service all the LDAP clients in the subnet. Only one of the servers needs to be a master LDAP server. The rest could all be replicas of the master server.To plan for the network configuration, consider how many servers are available, how a client would be able to get to the servers, and in what order the servers should be accessed. If there is one per subnet, you could use the defaultServerList attribute to list all the servers and have the LDAP client sort and manipulate the access order. If the servers need to be accessed in a certain order due to speed or data management reasons, you should use the preferredServerList attribute to define the fixed order of accessing the servers. Note that you might not want to put the master server on either of these lists to reduce the load on the master server.In addition, you might find three more attributes worth consideration when planning for the server and network configuration. The bindTimeLimit attribute can be used to set the time-out value for a TCP connect request. The searchTimeLimit attribute can be used to set the time-out value for an LDAP search operation. The profileTTL attribute can be used to control how often the LDAP client should download its profile from the servers. For a slow or unstable network, the bindTimeLimit and searchTimeLimit attributes might need a larger value than the defaults. For early stage testing of the deployment, you might want to reduce the value of the profileTTL attribute to have the clients pick up the frequent changes made to the profile stored in the LDAP servers. LDAP naming services have a default directory information tree (DIT) and an associated default schema. For example, the ou=people container contains the user account, password, and shadow information. The ou=hosts container contains information about systems in the network. Each entry in the ou=people container would be of objectclass posixAccount and shadowAccount.The default DIT is a well designed directory structure and is based on open standards. It should be sufficient for most of naming service needs, and is recommended to be used without changes. If you choose to use the default DIT, the only thing you need to decide is from which node (base DN) in the directory tree the naming services information will be searched for a given domain. This node is specified with the defaultSearchBase attribute. Additionally, you might want to set the defaultSearchScope attribute to tell the clients the scope of search a naming service lookup should perform. Is it just searching one level under the DN (one), or the entire subtree under the DN (sub)?There are times, however, that more flexibility is needed for the LDAP naming service to either work with an existing DIT or handle a more complicated DIT with naming service data scattered around the directory tree. For example, user account entries may exist in different part of the tree. The serviceSearchDescriptor, attributeMap, and objectclassMap attributes in the client profile are designed to handle these situations.A service search descriptor can be used to override the default search base, search scope, and search filter for a particular service. See Service Search Descriptors (SSDs) and Schema Mapping.The AttributeMap and ObjectclassMap attributes provide a way for schema mapping. They make it possible for the LDAP naming services to work with an existing DIT. You can map the posixAccount object class to an existing object class, myAccount, for example. You can map an attribute in the posixAccount object class to an attribute in the myAccount object class.Multiple LDAP servers can serve one DIT. For example, some subtrees of the DIT reside on other LDAP servers. In this case, an LDAP server may refer the LDAP client to a different server for the naming data it knows about but is not in its own database. If you plan such a DIT configuration, you should set the clients' profile attribute followReferrals to indicate to the LDAP naming service to follow server referrals to continue naming service lookups. However, it is best to have all naming data for a given domain reside on a single directory server, if at all possible.Referrals can be useful if you want to have clients access read-only replicas most of the time and follow referrals to a read/write master server only when necessary. In this way, the master server does not get overloaded with requests that could be handled by replicas. To make best use of LDAP, you should have a single LDAP entry for each logical entry. For example, for a user you can have not only company white-page information, but also Solaris account information, and possibly application-specific data. Since posixAccount and shadowAccount are auxiliary object classes, they can be added to any entry in the directory. This will require careful planning, setup, and administration. See the Sun Java System Directory Server (formerly Sun ONE Directory Server) documentation for information about how to choose an appropriate directory suffix. There are three different strategies to employ when setting up replica servers.Single-master replication Floating-master replication Multi-master replication Single-masterWith single-master replication, only one master server for any given partition or non-partitioned network holds writable copies of directory entries. Any replica servers have read-only copies of the directory entries. While both replicas and masters can perform searches, compares, and bind operations, only the master server can perform write operations.The potential disadvantage to the single-master replication strategy is that the master server is a single point of failure. If the master server goes down, none of the replicas can process write operations.Floating-masterThe floating-master strategy is similar to the single-master strategy in that there is only one master server with write capabilities at any given time for a given partitioned or non-partitioned network. However, when implementing the floating-master strategy, when the master server goes down, a replica is automatically transformed into a master server by way of an algorithm.One potential disadvantage to the floating-master replication strategy is that if your network becomes partitioned and replicas on either side of the partition become masters, the process of reconciling the new masters can be very complicated if the network is rejoined.Multi-masterWith multi-master replication, there are multiple master servers with their own read-write copies of the directory entry data. While the multi-master strategy eliminates the problem of having a single point of failure, update conflicts can occur between servers. In other words, if an entry's attribute is modified around the same time on two masters, an update conflict resolution policy, such as “last writer wins,” must be in place.For information about how to set up replica servers, refer to the Administration Guide for the version of Sun Java System Directory Server that you are using. To plan for the security model, you should first consider what identity the LDAP client should be using to talk to the LDAP server. For example, you must decide if you want an enterprise-wide single sign-on solution, with no passwords being sent over the wire, or the wire encryption of data and the ability to access control data results from the directory server on a per-user basis. You must also decide whether you want strong authentication to protect the user password flow across the wire, and/or if you need to encrypt the session between the LDAP client and the LDAP server to protect the LDAP data transmitted.The credentialLevel and authenticationMethod attributes in the profile are used for this. There are four possible credential levels for credentialLevel: anonymous, proxy, proxy anonymous and self. See LDAP Naming Services Security Model for a detailed discussion of LDAP naming service security concepts.&pamldapnote;If you enable pam_krb5 and Kerberos as an enterprise-wide single sign on solution, you can design a system whereby login passwords are only needed once at the start of a session. See System Administration Guide: Security Services for further details. If you enable Kerberos you will generally also need to enable DNS. See the chapters on DNS in this manual for further details. The main decisions you need to make when planning your security model are the following.Will you use Kerberos and per-user authentication? What credential level and authentication methods will LDAP clients use? Will you use TLS? Do you need to be backward compatible with NIS or NIS+? In other words, will clients use pam_unix or pam_ldap? What will the servers' passwordStorageScheme attribute settings be? How will you set up the Access Control Information?For more information about ACIs, consult the Administration Guide for the version of Sun Java System Directory Server that you are using. By going through the previous planning steps (network model, DIT, and security model), you should have some idea of the values for the following profile attributes.cn defaultServerList preferredServerList bindTimeLimit searchTimeLimit profileTTL defaultSearchBase defaultSearchScope serviceSearchDescriptor attributeMap objectclassMap followReferrals credentialLevel authenticationMethod serviceCredentialLevel serviceAuthenticationMethod Of the preceding attributes, only cn, defaultServerList, and defaultSearchBase are required. They have no default values. The rest are optional, and some have default values.See Chapter 12, Setting Up LDAP Clients (Tasks) for more information about setting up LDAP clients. data populationTo populate the LDAP server with data, after the LDAP server has been configured with the proper DIT and schema. Use the new ldapaddent tool. This tool will create entries in LDAP containers from their corresponding /etc files. It can be used to populate data into the containers for the following types of data: aliases, auto_*, bootparams, ethers, group, hosts (including IPv6 addresses), netgroup, netmasks, networks, passwd, shadow, protocols, publickey, rpc, and services.By default, ldapaddent reads from the standard input and adds this data to the LDAP container associated with the database specified on the command line. But an input file from which data should be read can be specified using the -f option.Because the entries are stored in the directory based on the client's configuration, the client must be configured to use the LDAP naming services.For better performance, load the databases in this order:passwd database followed by shadow database networks database followed by netmasks database bootparams database followed by ethers database Note that when adding automounter entries, the database name is in the form of auto_* (for example, auto_home).If you have /etc files from different hosts to add to the LDAP server, you can either merge all of them into the same /etc file and then use ldapaddent on one host to add the files, or perform ldapaddent on the different hosts one by one, with the expectation that each host is already configured as a LDAP client.If your naming service data is already in an NIS server, and you want to move the data to the LDAP server for LDAP naming services, use the ypcat (or niscat) command to dump the NIS map into files. Then, run ldapaddent against these files to add the data to the LDAP server.ldapaddent can only be run on an LDAP client. The following procedure assumes that the tables are to be extracted from a yp client.Make sure that Sun Java System Directory Server was set up using idsconfig. On a client machine, become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Make the machine an LDAP client.# ldapclient init a profileName=new a domainName=west.example.com \ 192.168.0.1 Populate the server with data.# ldapaddent D “cn=directory manager” f /etc/hosts hostsYou will be prompted for a password.In this example, ldapaddent will use the authentication method that has been configured in the profile new. Selecting simple will cause the password to be sent in the clear. For more information, refer to the ldapaddent1M man page.