|
|||
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 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) Planning the Directory Information Tree (DIT) Planning the LDAP Security Model Planning Client Profiles and Default Attribute Values for LDAP Planning the LDAP Data Population 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 Part V Active Directory Naming Service 17. Setting Up Solaris Active Directory Clients A. Solaris 10 Software Updates to DNS, NIS, and LDAP |
Planning the LDAP Network ModelFor 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. |
||
|