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

Document Information

Preface

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)

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)

NIS-to-LDAP Service Overview

NIS-to-LDAP Tools and the Service Management Facility

NIS-to-LDAP Audience Assumptions

When Not to Use the NIS-to-LDAP Service

Effects of the NIS-to-LDAP Service on Users

NIS-to-LDAP Transition Terminology

NIS-to-LDAP Commands, Files, and Maps

Supported Standard Mappings

Transitioning From NIS to LDAP (Task Map)

Prerequisites for the NIS-to-LDAP Transition

Setting Up the NIS-to-LDAP Service

How to Set Up the N2L Service With Standard Mappings

How to Set Up the N2L Service With Custom or Nonstandard Mappings

Examples of Custom Maps

Example 1-Moving Host Entries

Example 2-Implementing a Custom Map

NIS-to-LDAP Best Practices With Sun Java System Directory Server

Creating Virtual List View Indexes With Sun Java System Directory Server

VLVs for Standard Maps

VLVs for Custom and Nonstandard Maps

Avoiding Server Timeouts With Sun Java System Directory Server

Avoiding Buffer Overruns With Sun Java System Directory Server

NIS-to-LDAP Restrictions

NIS-to-LDAP Troubleshooting

Common LDAP Error Messages

NIS-to-LDAP Issues

Debugging the NISLDAPmapping File

N2L Server Timeout Issue

N2L Lock File Issue

N2L Deadlock Issue

Reverting to NIS

How to Revert to Maps Based on Old Source Files

How to Revert to Maps Based on Current DIT Contents

Part V Active Directory Naming Service

16.  Setting Up Oracle Solaris Active Directory Clients

Glossary

Index

Setting Up the NIS-to-LDAP Service

You can set up the N2L service either by using standard mappings or by using custom mappings, as described in the next two procedures.

As part of the NIS-to -LDAP conversion, you need to run the inityp2l command. This command runs an interactive script for which you must provide configuration information. The following list shows the type of information you need to provide. See the ypserv(1M) man page for explanations of these attributes.


Note - sasl/cram-md5 authentication is not supported by most LDAP servers, including Sun Java System Directory Server.


How to Set Up the N2L Service With Standard Mappings

Use this procedure if you are transitioning the maps listed in Supported Standard Mappings. If you are using custom or nonstandard maps, see How to Set Up the N2L Service With Custom or Nonstandard Mappings.

When the LDAP server has been set up, run the inityp2l script and supply configuration information when prompted. inityp2l sets up the configuration and mapping files for standard and auto.* maps.

  1. Complete the prerequisite steps that are listed in Prerequisites for the NIS-to-LDAP Transition.
  2. Become an administrator on the NIS master server.

    For more information , see How to Obtain Administrative Rights in System Administration Guide: Security Services.

  3. Convert the NIS master server into an N2L server.
    # inityp2l

    Run the inityp2l script on the NIS master server and follow the prompts. See Setting Up the NIS-to-LDAP Service for a list of the information you need to provide.

    See the inityp2l(1M) man page for more details.

  4. Determine if the LDAP Directory Information Tree (DIT) is fully initialized.

    The DIT is fully initialized if it already contains the information necessary to populate all the maps that are listed in the NISLDAPmapping file.

    • If no, continue with Step 5 and skip Step 6.

    • If yes, skip Step 5 and go to Step 6.

  5. Initialize the DIT for the transition from the NIS source files.

    Perform these steps only if the DIT has not been fully initialized.

    1. Make sure that the old NIS maps are up-to-date.
      # cd /var/yp
      # make

      For more information, see the ypmake(1M) man page.

    2. Stop the NIS daemons.
      # svcadm disable network/nis/server:default
    3. Copy the old maps to the DIT, then initialize N2L support for the maps.
      # ypserv -Ir

      Wait for ypserv to exit.


      Tip - The original NIS dbm files are not overwritten. You can recover these files, if needed.


    4. Start the NIS daemons to ensure that they use the new maps.
      # svcadm enable network/nis/server:default

      This completes the set up of the N2L service with standard maps. You do not need to complete Step 6.

  6. Initialize the NIS maps.

    Perform these steps only if the DIT is fully initialized and you skipped Step 5.

    1. Stop the NIS daemons.
      # svcadm disable network/nis/server:default
    2. Initialize the NIS maps from information in the DIT.
      # ypserv -r

      Wait for ypserv to exit.


      Tip - The original NIS dbm files are not overwritten. You can recover these files, if needed.


    3. Start the NIS daemons to ensure that they use the new maps.
      # svcadm enable network/nis/server:default

How to Set Up the N2L Service With Custom or Nonstandard Mappings

Use this procedure if the following circumstances apply:

  1. Complete the prerequisite steps that are listed in Prerequisites for the NIS-to-LDAP Transition.
  2. Become an administrator on the NIS master server.

    For more information , see How to Obtain Administrative Rights in System Administration Guide: Security Services.

    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.

  3. Configure the NIS master server into the N2L server.
    # inityp2l

    Run the inityp2l script on the NIS master server and follow the prompts. See Setting Up the NIS-to-LDAP Service for a list of the information you need to provide.

    See the inityp2l(1M) man page for more details.

  4. Modify the /var/yp/NISLDAPmapping file.

    See Examples of Custom Maps for examples of how to modify the mapping file.

  5. Determine if the LDAP Directory Information Tree (DIT) is fully initialized.

    The DIT is fully initialized if it already contains the information necessary to populate all the maps that are listed in the NISLDAPmapping file.

    • If no, complete Step 6, Step 8, and Step 9.

    • If yes, skip Step 6 and complete Step 7, Step 8, and Step 9.

  6. Initialize the DIT for the transition from the NIS source files.
    1. Make sure that the old NIS maps are up-to-date.
      # cd /var/yp
      # make

      For more information, see the ypmake(1M) man page.

    2. Stop the NIS daemons.
      # svcadm disable network/nis/server:default
    3. Copy the old maps to the DIT, then initialize N2L support for the maps.
      # ypserv -Ir

      Wait for ypserv to exit.


      Tip - The original NIS dbm files are not overwritten. You can recover these files, if needed.


    4. Start the NIS daemons to ensure that they use the new maps.
      # svcadm enable network/nis/server:default
    5. Skip Step 7 and continue with Step 8.
  7. Initialize the NIS maps.

    Perform this step only if the DIT is fully initialized.

    1. Stop the NIS daemons.
      # svcadm disable network/nis/server:default
    2. Initialize the NIS maps from information in the DIT.
      # ypserv -r

      Wait for ypserv to exit.


      Tip - The original NIS dbm files are not overwritten. You can recover these files, if needed.


    3. Start the NIS daemons to ensure that they use the new maps.
      # svcadm enable network/nis/server:default
  8. Verify that the LDAP entries are correct.

    If the entries are not correct, then the entries can not be found by LDAP naming services clients.

    # ldapsearch -h server -s sub -b "ou=servdates, dc=..." \
    "objectclass=servDates"
  9. Verify the contents of the LDAP_ maps.

    The following sample output shows how to use makedm to verify the contents of the hosts.byaddr map.

    # makedbm -u LDAP_servdate.bynumber
    plato: 1/3/2001
    johnson: 2/4/2003,1/3/2001
    yeats: 4/4/2002
    poe: 3/3/2002,3/4/2000

    If the contents are as expected, the transition from NIS to LDAP was successful.

    Note that the original NIS dbm files are not overwritten, so you can always recover those files. See Reverting to NIS for more information.

Examples of Custom Maps

The following two examples show how you might customize maps. Use your preferred text editor to modify the /var/yp/NISLDAPmapping file as needed. For more information about file attributes and syntax, see the NISLDAPmapping(4) man page and the LDAP naming services information in Chapter 9, LDAP Basic Components and Concepts (Overview).

Example 1–Moving Host Entries

This example shows how to move host entries from the default location to another (nonstandard) location in the DIT.

Change the nisLDAPobjectDN attribute in the NISLDAPmapping file to the new base LDAP distinguished name (DN). For this example, the internal structure of the LDAP objects is unchanged, so objectClass entries are unchanged.

Change:

nisLDAPobjectDN hosts: \
                        ou=hosts,?one?, \
                        objectClass=device, \
                        objectClass=ipHost

To:

nisLDAPobjectDN hosts: \
                        ou=newHosts,?one?, \
                        objectClass=device, \
                        objectClass=ipHost

This change causes entries to be mapped under

   dn: ou=newHosts, dom=domain1, dc=sun, dc=com

instead of under

   dn: ou=hosts, dom=domain1, dc=sun, dc=com.

Example 2–Implementing a Custom Map

This example shows how to implement a custom map.

A hypothetical map, servdate.bynumber, contains information about the servicing dates for systems. This map is indexed by the machine's serial number which, in this example, is 123. Each entry consists of the machine owner's name, a colon, and a comma-separated list of service dates, such as John Smith:1/3/2001,4/5/2003.

The old map structure is to be mapped onto LDAP entries of the following form:

dn: number=123,ou=servdates,dc=... \
                 number: 123 \
                 userName: John Smith \
                 date: 1/3/2001 \
                 date: 4/5/2003 \
                  .
                  .
                  .
                 objectClass: servDates

By examining the NISLDAPmapping file, you can see that the mapping closest to the required pattern is group. The custom mappings can be modeled on the group mapping. Since there is only one map, no nisLDAPdatabaseIdMapping attribute is required. The attributes to be added to NISLDAPmapping are the following:

nisLDAPentryTtl servdate.bynumber:1800:5400:3600

nisLDAPnameFields servdate.bynumber: \
                        ("%s:%s", uname, dates)

nisLDAPobjectDN servdate.bynumber: \
                        ou=servdates, ?one? \
                        objectClass=servDates:

nisLDAPattributeFromField servdate.bynumber: \
                        dn=("number=%s,", rf_key), \
                        number=rf_key, \
                        userName=uname, \
                        (date)=(dates, ",")

nisLDAPfieldFromAttribute servdate.bynumber: \
                        rf_key=number, \
                        uname=userName, \
                        dates=("%s,", (date), ",")