|
|||
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) 11. Setting Up Sun Java System Directory Server With LDAP Clients (Tasks) Configuring Sun Java System Directory Server Using idsconfig Populating the Directory Server Using ldapaddent Populating the Directory Server With Additional Profiles Configuring the Directory Server to Enable Account Management Migrating Your Sun Java System Directory Server 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 |
Using Service Search Descriptors to Modify Client Access to Various ServicesA service search descriptor (SSD) changes the default search request for a given operation in LDAP to a search you define. SSDs are particularly useful if, for example, you have been using LDAP with customized container definitions or another operating system and are now transitional to the latest Solaris release. Using SSDs, you can configure Solaris LDAP naming services without having to change your existing LDAP database and data. Setting Up SSDs Using idsconfigAssume your predecessor at Example, Inc. had configured LDAP, storing users in ou=Users container. You are now upgrading to the latest Solaris release. By definition, Solaris LDAP client assumes that user entries are stored in ou=People container. Thus, when it comes to searching the passwd service, LDAP client will search the ou=people level of the DIT and not find the correct values. One laborious solution to the above problem would be to completely overwrite Example, Inc.'s existing DIT and to rewrite all the exiting applications on Example, Inc.'s network so that they are compatible with the new LDAP naming service. A second, far preferable solution would be to use an SSD that would tell LDAP client to look for user info in an ou=Users container instead the default ou=people container. You would define the necessary SSD during the configuration of the Sun Java System Directory Server using idsconfig. The prompt line appears as follows. Do you wish to setup Service Search Descriptors (y/n/h? y A Add a Service Search Descriptor D Delete a SSD M Modify a SSD P Display all SSD's H Help X Clear all SSD's Q Exit menu Enter menu choice: [Quit] a Enter the service id: passwd Enter the base: service ou=user,dc=west,dc=example,dc=com Enter the scope: one[default] A Add a Service Search Descriptor D Delete a SSD M Modify a SSD P Display all SSD's H Help X Clear all SSD's Q Exit menu Enter menu choice: [Quit] p Current Service Search Descriptors: ================================== Passwd:ou=Users,ou=west,ou=example,ou=com? Hit return to continue. A Add a Service Search Descriptor D Delete a SSD M Modify a SSD P Display all SSD's H Help X Clear all SSD's Q Exit menu Enter menu choice: [Quit] q |
||
|