JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)
search filter icon
search icon

Document Information


Part I About Naming and Directory Services

1.  Naming and Directory Services (Overview)

2.  The Name Service Switch (Overview)

Part II DNS Setup and Administration

3.  DNS Setup and Administration (Reference)

Part III NIS Setup and Administration

4.  Network Information Service (NIS) (Overview)

5.  Setting Up and Configuring NIS Service

6.  Administering NIS (Tasks)

7.  NIS Troubleshooting

Part IV LDAP Naming Services Setup and Administration

8.  Introduction to LDAP Naming Services (Overview/Reference)

9.  LDAP Basic Components and Concepts (Overview)

10.  Planning Requirements for LDAP Naming Services (Tasks)

LDAP Planning Overview

Planning the LDAP Network Model

Planning the Directory Information Tree (DIT)

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 Using ldapaddent

11.  Setting Up Sun Java System Directory Server With LDAP Clients (Tasks)

12.  Setting Up LDAP Clients (Tasks)

13.  LDAP Troubleshooting (Reference)

14.  LDAP General Reference (Reference)

15.  Transitioning From NIS to LDAP (Overview/Tasks)

16.  Transitioning From NIS+ to LDAP

A.  Solaris 10 Software Updates to DNS, NIS, and LDAP

Service Management Facility Changes


pam_ldap Changes

Documentation Errors



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. 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.