JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Naming and Directory Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


Part I About Naming and Directory Services

1.  Naming and Directory Services (Overview)

2.  Name Service Switch (Overview)

3.  Managing DNS (Tasks)

4.  Setting Up Oracle Solaris Active Directory Clients (Tasks)

Part II NIS Setup and Administration

5.  Network Information Service (Overview)

6.  Setting Up and Configuring NIS (Tasks)

7.  Administering NIS (Tasks)

8.  NIS Troubleshooting

Part III LDAP Naming Services

9.  Introduction to LDAP Naming Services (Overview)

10.  Planning Requirements for LDAP Naming Services (Tasks)

LDAP Planning Overview

Planning the LDAP Network Model

Planning the Directory Information Tree

Multiple Directory Servers

Data Sharing With Other Applications

Choosing the Directory Suffix

LDAP and Replica Servers

Planning the LDAP Security Model

Planning Client Profiles and Default Attribute Values for LDAP

Planning the LDAP Data Population

How to Populate a Server With host Entries by Using the ldapaddent Command

11.  Setting Up Oracle Directory Server Enterprise Edition With LDAP Clients (Tasks)

12.  Setting Up LDAP Clients (Tasks)

13.  LDAP Troubleshooting (Reference)

14.  LDAP Naming Service (Reference)

15.  Transitioning From NIS to LDAP (Tasks)



Planning the LDAP Network Model

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. defaultServerList treats all servers in the list equally, while servers in the preferredServerList are in priority order, where the first server in the list is the best server to use. The major difference being that when the preferredServerList is used available server with the highest priority is used over another available server with a lower priority. In the event that a server with higher priority becomes available, the client machine will disconnect from the server of lower priority. When a defaultServerList is used, all servers have equal priority, and one server coming online will not replace an existing server. Both lists may be used in a configuration. 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.