4 Migrating Entries to Oracle Internet Directory

This chapter contains the following topics:

4.1 Migrating Entries

Before migrating entries from NIS, files, or another LDAP directory, perform the following tasks:

  • Tune your Oracle Internet Directory database.

    See Also:

  • Take a cold backup of the Oracle Internet Directory database in case you need to restore it.

  • Ensure that, in the event that Oracle Internet Directory becomes unavailable, the administrator will still be able to log in as root. Specifically:

    • Keep a local root account in your /etc/passwd and /etc/shadow files.

    • Do not modify the passwd or shadow precedence in nsswitch.conf. The configuration script sets them to:

      passwd: files ldap
      shadow: files ldap
      
  • Ensure that the default password hashing algorithm in your environment is DES or MD5 crypt. If it is not, change it. Then require all users to modify their passwords, so that passwords are stored in a format supported by Oracle Internet Directory.

Before you load LDIF files into Oracle Internet Directory, you can check the files for schema and data consistency violations using the check feature of the bulkload tool. The syntax is:

$ORACLE_HOME/ldap/bin/bulkload connect=oid-db check=true file=ldif_file

Note:

Exercise security precautions in your handling of files that contain sensitive information.

This section contains the following topics:

4.1.1 Migrating from NIS to Oracle Internet Directory

Migrate entries as follows.

4.1.1.1 AIX 5.3

If you did not migrate all your entries to LDAP before running the client configuration script, proceed as described in the AIX 5.3 section of "Configuring Oracle Authentication Services for Operating Systems on the Client".

4.1.1.2 Other Platforms

The steps for migrating entries from NIS to Oracle Internet Directory are as follows:

  1. Run the LDAP migration scripts, described in "Get NIS Migration Tools", on your NIS master files. This will generate LDIF files containing the entries.

  2. For compatibility with a variety of clients, as well as with the system-config-users tool, ensure that the entries include all the required attributes shown in the following example. (Substitute the user's password for password.)

    dn: uid=jueno,ou=People,dc=us,dc=example,dc=com
    uid: jueno
    homedirectory: /home/jueno
    loginshell: /bin/tcsh
    uidnumber: 506
    gidnumber: 506
    cn: juri ueno
    objectclass: posixAccount
    objectclass: shadowAccount
    objectclass: account
    objectclass: top
    userpassword: password
    shadowwarning: -1
    shadowmax: 99999
    shadowlastchange: 13916
    shadowexpire: -1
    shadowmin: 0
    shadowinactive: -1
    gecos: jueno
    

    The shadowAccount objectclass and attributes are typically missing in user entries migrated from an HP-UX server.

  3. Use the ldapadd client tool shipped with Oracle Internet Directory to load the LDIF entries into Oracle Internet Directory. Use a command line of the form:

    ldapadd -p port -h host -D binddn -q -v -f ldif_file
    

Note:

  • If you are using the same naming context created during installation, these scripts will generate parts of the DIT (Directory Information Tree) that already exist. This will cause ldapadd failures because you are attempting to add an existing entry. You can avoid these failures by specifying the -c option to continue upon encountering such errors.

  • The binddn you use must be the directory administrator DN so that you have the proper privileges when performing these additions.

4.1.2 Migrating from Operating System Files to Oracle Internet Directory

Migrating from operating system files is basically the same as migrating from NIS, except that you might have different versions of your configuration files on different machines. If you have multiple versions, run the migration scripts on each version and combine the LDIF files. You must resolve conflicts manually, using a text editor. Each user must have a unique user name and UID, and each group must have a unique group name and GID.

4.1.3 Migrating from Another LDAP Directory to Oracle Internet Directory

You can migrate entries from a third-party, LDAP-compliant directory to Oracle Internet Directory.

Note:

This section describes how to do a one-time migration of data from an LDAP-compliant source directory to Oracle Internet Directory. If you are planning to set up ongoing synchronization between a source directory and Oracle Internet Directory by using Oracle Directory Integration Platform, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

Migration of entries from a third-party source directory to Oracle Internet Directory occurs in two phases: schema migration and data migration.

4.1.3.1 Schema Migration

The steps for migrating schema are as follows:

  1. Analyze the schema difference between the directories by running the schemasync tool. The syntax is:

    $ORACLE_HOME/bin/schemasync -srchost srchost -srcport srcport -srcdn binddn \
                                -srcpwd bindpwd -dsthost oidhost -dstport oidport \
                                -dstdn oiddn -dstpwd oidpwd
    

    where srchost and srcport are the connection details of the source directory and srcdn and srcpwd are the credentials to connect to the source directory.

    See Also:

    The command reference for schemasync in the Oracle Directory Integration Platform Tools chapter of the Oracle Fusion Middleware Reference for Oracle Identity Management.

    The command produces four output files that list differences between the source directory and Oracle Internet Directory schema. They are:

    • $ORACLE_HOME/ldap/odi/log/attributetypes.log–difference in the schema definition of the common attributes between the source directory and Oracle Internet Directory.

    • $ORACLE_HOME/ldap/odi/log/objectclasss.log–difference in the schema definition of the common object classes between the source directory and Oracle Internet Directory

    • $ORACLE_HOME/ldap/odi/data/attributetypes.ldif–attributes that are available only in the source directory and not in Oracle Internet Directory.

    • $ORACLE_HOME/ldap/odi/data/objectclasses.ldif–object classes that are available only in the source directory and not in Oracle Internet Directory.

  2. If necessary, extend the schema elements in Oracle Internet Directory.

    1. Based on the analyses in Step 1, determine what new schema elements you must load onto Oracle Internet Directory. Modify the files attributetypes.ldif and objectclasses.ldif (from step) 1 to have only the attributes and object classes that you must load. Name the modified files modified_attributetypes.ldif and modified_objectclasses.ldif.

      For example, assume that the objectclass of the user entry in the third-party directory is inetorgperson, organizationalperson, person, srcuser and the objectclass of user entry in Oracle Internet Directory is inetorgperson,organizationalperson, person, orcluser. In Step 1, if the objectclass definitions of inetorgperson, organizationalperson, and person are different between Oracle Internet Directory and the third-party directory, the difference will be written to the objectclasses.log files. After looking at the file, you might decide to make the required changes in the objectclass definitions of Oracle Internet Directory. Since srcuser is a third-party directory specific objectclass, the objectclass definition will be in the objectclasses.ldif file. Modify the objectclass.ldif file to contain the objectclass definition and rename it modified_objectclasses.ldif. Modify the attributes.ldif file to contain the definitions of the attributes required for the objectclasses in objectclasses.ldif.

    2. Upload the required schema using the ldapmodify command as follows:

      ldapmodify -h oidhost -p oidport -D 'cn=orcladmin' -q \
                 -f modified_attributetypes.ldif 
      ldapmodify -h oidhost -p oidport -D 'cn=orcladmin' -q \
                 -f modified_objectclasses.ldif
      

4.1.3.2 Data Migration

Migration of data is more complicated because you must include some entries and exclude others. Even in the entries that are included, you might want to include only specific attributes. In general, user and group are migrated. The attributes representing access control definitions, password policy-related attributes, and other operational attributes such as createtimestamp, modifytimestamp, creatorsname, modifiersname, entrydn, numsubordinates, parentid, entryid, and nsuniqueid are excluded. You might want to include userpassword as an attribute to be migrated. Do so only if both the directories support the same kind of encryption or hashing techniques.

You can get the exact data to be migrated by filtering the data either while exporting it from the source directory (Step 1) or as a separate step (Step 2).

  1. Export the data from the source directory into LDIF file format, using the appropriate LDAP tool on your system, and analyze it. See the documentation for your directory server to determine what command to use. If you filter and export only the required LDAP entries with only the required attributes during the export operation, proceed to Step 3. Otherwise, filter it in Step 2.

  2. If you did not filter out the entries and attributes not to be migrated in Step 1, remove them in this step by using syncProfileBootstrap.

    The syncProfileBootstrap tool filters the entries based on the configuration and also supports mapping and transformation of attributes. You specify the configuration of filtering, mapping and transformation in the mapfile. Sample mapfiles are provided in Appendix C.

    1. If you are migrating entries other than user and group from source directories, update the mapfile accordingly.

    2. Make a copy of the sample file $ORACLE_HOME/ldap/odi/samples/migrate.properties and name it migrate.properties.

      See Also:

      The command reference for syncProfileBootstrap in the Oracle Directory Integration Platform Tools chapter of the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform for documentation of the parameters used in the properties file.
    3. In the properties file, you must specify the name of the LDIF file containing the entries to be migrated as source file and a name for the file that is to be generated by syncProfileBootstrap as the destination file name. The containers to be included/excluded and the attributes to be included/excluded are specified in the mapfile parameter of the properties file. Note: This mapfile can be used only for migration purposes and is not supported for synchronization. A sample properties file is shown in Appendix B.

    4. Generate a new LDIF file in the format required by Oracle Internet Directory by running the command:

      syncProfileBootstrap -file testmigrate.properties 
      
  3. Optionally, you can use an Oracle Internet Directory plug-in to augment entries. See "Setting up a Plug-in to Augment Active Directory Entries for Linux Authentication". This method has been shown to work for iPlanet (Sun Java System Directory Server) 5.2 as well as Active Directory.

  4. Get the filtered LDIF file resulting from Step 1 or Step2 and use either $ORACLE_HOME/bin/ldapadd or $ORACLE_HOME/ldap/bin/bulkload to add the data to Oracle Internet Directory. If you have more than a few thousand entries, use bulkload in preference to ldapadd.

    1. The syntax for ldapadd is:

      ldapadd -h oidhost -p oidport -d oiddn -q -f ldif_file
      

      If you use ldapadd, once the data is successfully added, update the Oracle Internet Directory database statistics using $ORACLE_HOME/ldap/admin/oidstats.sql. Log in to the Oracle Internet Directory database as the ODS database user and execute this SQL script.

      See Also:

      The oidstats.sql command reference in the Oracle Internet Directory Database Tools chapter of the Oracle Fusion Middleware Reference for Oracle Identity Management.
    2. If you decide to use bulkload, then proceed to Step 5

  5. Bulk load LDIF data into Oracle Internet Directory. In the following steps, the file /home/jdoe/migrationdata.ldif is the filtered LDIF file.

    1. Stop all Oracle Internet Directory processes by executing the command:

      $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OID
      
    2. Take a cold backup of the database if you have not done so already.

    3. Use bulkload to check for schema errors, duplicate entries and other errors and to generate intermediate files for a subsequent data load. The syntax is:

      $ORACLE_HOME/ldap/bin/bulkload connect=oid-db check=true generate=true file=/home/jdoe/migrationdata.ldif
      

      When you specify both check and generate options, bulkload checks the entries for schema compliance and duplicates and generates the intermediate files that are used during the load phase in the $ORACLE_HOME/ldap/load directory.

      If there are any check-related errors, bulkload reports them on the screen. The tool logs entries in $ORACLE_HOME/ldap/log/duplicateDN.log and logs schema-related violations in $ORACLE_HOME/ldap/log/bulkload.log. It writes entries that have errors to $ORACLE_HOME/ldap/load/badentry.ldif.

      If bulkload detects any errors in the entries, you might have to fix the entries or schema or both in Oracle Internet Directory. After you fix the problems, re-run the bulkload command. Repeat this until there are no errors or the errors reported are acceptable. For example, if you encounter some schema check error for a small number of entries, you can choose to ldapadd them from badentry.ldif later by fixing the entries or schema in Oracle Internet Directory.

      When you use the check and generate options, bulkload generates the intermediate files for entries that had no check-related errors. The generate occurs even if there are erroneous entries. For example, if the LDIF file has 100 entries and 10 entries have check errors, bulkload generates the intermediate files for 90 good entries.

    4. Use bulkload to load the data, recreate all indexes and generate db statistics. Execute the command:

      $ORACLE_HOME/ldap/bin/bulkload connect=oid-db load=true file=/home/jdoe/migrationdata.ldif
      

      This command accomplishes three things: loading data from $ORACLE_HOME/ldap/load directory into the database using SQL*Loader, creating indexes, and generating database statistics.

      If it detects an error, bulkload indicates the error on the screen. If it reports an error during loading of data, you must restore the database from the backup taken in Step b and then repeat the bulkload load=true command. If bulkload reports an error during indexing, use the following command to recreate all indexes:

      bulkload connect=oid-db index=true
      

      If bulkload reports an error during database statistics generation, you can use the following command to generate the statistics:

      $ORACLE_HOME/ldap/admin/oidstats.sql
      
    5. Start all Oracle Internet Directory processes by executing the command:

      $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OID
      

4.2 Setting Access Control on User Entry Attributes

To protect sensitive user attributes from unauthorized modification, set an access control item. Type:

ldapmodify -h oidhost -p oidport -D 'cn=orcladmin' -q -f aci.ldif

where aci.ldif looks like this:

dn:
changetype: modify
add: orclaci
orclaci: access to attr=(uidnumber,gidnumber,homedirectory,uid)
 by group="cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext"
 (search,read,write,compare) by group="cn=directoryadmingroup,cn=oracle internet
 directory" (search,read,write,compare) by * (search,compare,nowrite,nocompare) 

4.3 Using Custom Attributes in Oracle Internet Directory

You can search for an attribute in Oracle Internet Directory only if the attribute is indexed. By default, standard attributes of the user and group entries are indexed. If you use a custom attribute, you can index it by using the catalog command. For example, if you migrate automount data to be used by automount programs such as amd or autofs, index the automountKey attribute by using the catalog command, as follows:

catalog connect="connect_str" add="TRUE" attribute="automountKey" 

Note:

If you attempt to perform a search with a non-indexed attribute specified as a required attribute, the server will return a "Function not implemented. DSA unwilling to perform" error. See "Create and Index New Custom Attributes (Optional)".

Some attributes, such as uid and user name, must be unique. Oracle Internet Directory will enforce uniqueness if you create a uniqueness constraint for that attribute. For more information see the chapter "Attribute Uniqueness in the Directory" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

Note:

The attribute uniqueness feature works on indexed attributes only.

4.4 Migrating SUDO

You can migrate entries from /etc/sudoers into Oracle Internet Directory using the sudo package you downloaded from:

http://www.gratisoft.us/sudo

This sudo package includes sudo software and the scripts to convert sudo data to LDAP data (LDIF). Read the documentation included in the package before you begin the migration process.

Note:

After migrating sudo, run some security tests to ensure that your sudo policy is being enforced correctly.

4.4.1 Migrating SUDO Entries to Oracle Internet Directory on the Server

To move the contents of your sudoers file to Oracle Internet Directory, perform these steps:

  1. Add a Sudoers container to Oracle Internet Directory using the command:

    ldapadd -h oid_hostname -p port -D cn=orcladmin \
            -q -f sudocontainer.ldif
    

    where sudocontainer.ldif looks like this:

    dn:ou=Sudoers,dc=us,dc=example,dc=com
    objectclass:top
    objectclass:organizationUnit
    ou=sudoers
    
  2. Using the /etc/sudoers file from your existing sudo client, generate an LDIF file by running the conversion script supplied with the sudo package you downloaded. Follow the instructions at the download site. Please see the sudo package documentation for known limitations.

  3. View the resulting LDIF file in a text editor and correct any obvious errors.

  4. Add the contents of the ldif file to Oracle Internet Directory by using the command:

    ldapadd -h oid_hostname -p port -D cn=orcladmin \
            -q -f sudoers.ldif
    

    where sudoers.ldif is the file generated from your /etc/sudoers file.

    If ldapadd encounters an error, it will stop and report the error. Correct the error and repeat the command until it runs successfully and adds all the entries.

Once you have migrated your sudo entries to Oracle Internet Directory, you must use LDAP tools to modify them. See the documentation in the downloaded sudo package for information about LDAP browsers you can use for editing sudo entries.

4.4.2 Configuring a Client to Use LDAP for SUDO Information

On most client operating systems, you can configure sudo with the native LDAP and SSL libraries for that operating system. On a few operating systems, you must use OpenLDAP and OpenSSL.

When you configure sudo, the make install step will install a new copy of /etc/ldap.conf. If you already have an ldap.conf file, you must make a copy before you configure sudo or the file will be overwritten. Once you have performed a make install, copy that file back to /etc/ldap.conf.

4.4.2.1 SuSE 10 Client

  1. Download, build, and install the OpenLDAP and OpenSSL packages.

  2. If you already have the file /etc/ldap.conf, make a copy. For example

    cp /etc/ldap.conf /etc/ldap.conf.save
    
  3. In the directory where you downloaded the sudo package, build sudo by typing the following commands:

    ./configure --with-ldap-type=openldap --with-pam --enable-ssl
    make all
    make compile
    make install
    
  4. If you made a copy of your ldap.conf file, copy it back to its original name. For example:

    cp /etc/ldap.conf.save /etc/ldap.conf
    
  5. If there is no libpam.so link, make one by typing:

    cd /usr/lib
    ln -s libpam.so.0 libpam.so
    
  6. Edit /etc/pam.d/sudo. Add the following line above the first auth line:

    auth     sufficient     /lib/security/pam_ldap.so debug
    
  7. Modify /etc/ldap.conf so that sudoers_base points to the base sudoers container. For example:

    sudoers_base  ou=Sudoers,dc=us,dc=example,dc=com
    

    If you want to configure ssl for sudo you must specify startTLS in ldap.conf since the current sudo implement does not support SSL only. For example:

    ssl startTLS
    

4.4.2.2 Solaris 9, Solaris 10, HP-UX 11.23 or AIX 5.3 Client

On these operating systems, the native LDAP client does not support StartTLS. If you plan to use sudo with SSL, download, build, and install the OpenLDAP and OpenSSL packages and build sudo as described for SuSE 10 clients. Once you have completed those steps, add the following lines to/etc/ldap.conf to specify the target LDAP host and port and the SSL certificate authority certificate path and certificate filename:

host ldap_host
port ldap_port
tls_cacertdir  /etc/ca_certs_dir
tls_cacertfile  /etc/ca_cert_file

If you plan to use sudo in non-SSL mode only, build it using the native LDAP client libraries, as described for other clients.

4.4.2.3 AIX 5.3 Client

To build sudo with LDAP enabled on AIX 5.3, proceed as follows, where base_dir is the directory where you install openssl, openldap, and sudo.

  1. Set environment variables.

    export CFLAGS="-I$base_dir/include -I/usr/include" \ 
    export CPPFLAGS="-I$base_dir/include -I/usr/include" \ 
    export LDFLAGS="-L$base_dir/lib -L/usr/lib" 
    export CC=/usr/local/bin/gcc 
    
  2. Build openssl.

    cd $build_dir/openssl-0.9.8g 
    ./Configure aix-cc shared threads -D_REENTRANT --prefix=$base_dir 
    make 
    make install 
    
  3. Build openldap

    cd $build_dir/openldap-2.3.39 
    ./configure \ 
    --prefix=$base_dir \ 
    --enable-slapd=no \ 
    --enable-bdb=no \ 
    --enable-static=no \ 
    --enable-shared=yes 
    
  4. Edit the Makefile, adding the TLS_LIBS parameter, as follows:

    TLS_LIBS = -lssl -lcrypto -lldap 
    
  5. Run make.

    make depend MKDEP=$PWD/build/mkdep.aix 
    make 
    

    If you encounter errors when you run make, update this parameter in the Makefile and try again:

    LUTIL_LIBS=$(LDAP_LIBDIR)/libldap/.libs/libldap.a 
    
  6. After make completes successfully, type:

    make install 
    
  7. Build sudo

    cd $build_dir/sudo1.6.9p15 
    ./configure [--with-pam | --with-aixauth] --with-ldap=$base_dir/lib --with-prefix=$base_dir 
    make 
    make install 
    

    If you encounter linking errors, determine which objects are missing from the link lines in your Makefile, add those objects, then try again.

4.4.2.4 Other Clients

  1. If the sudo binary you are using was not built using the --with-ldap option, then rebuild the sudo command using the --with-ldap option, as described in the documentation in the downloaded sudo package. Before rebuilding sudo, save a copy of /etc/ldap.conf to a different name. Be sure to check the documentation and the README files for other options you might need to use. For example, you might have to specify your library and header location or a different configuration file if they are non-standard. You might also have to modify the Makefile by adding an -lldif flag to SUDO_LIBS if you are using an SDK other than OpenLDAP. Once you have rebuilt sudo, copy your saved ldap.conf file back to its original name.

  2. Modify /etc/ldap.conf so that sudoers_base points to the base sudoers container you created in Server Step 1. For example:

    sudoers_base  ou=Sudoers,dc=us,dc=example,dc=com
    

    If you want to configure SSL for sudo you must specify startTLS in ldap.conf because the current sudo implementation does not support SSL only. For example:

    ssl startTLS
    

    Optionally, enable sudo debugging by adding the following line to /etc/ldap.conf:

    Sudoers_debug 2
    
  3. Prevent sudo from using the /etc/sudoers file by adding the ignore_local_sudoers suboption to the sudoers defaults. You do this by running this command:

     ldapmodify -h oid_hostname -p port -D cn=orcladmin \
            -q -f ignore_local_sudoers.ldif 
    

    where ignore_local_sudoers.ldif looks like this:

    dn:cn=defaults, ou=Sudoers, dc=us, dc=example, dc=com
    changetype:modify
    add: sudooption
    sudooption: ignore_local_sudoers
    

4.4.3 Reconfiguring a Client to Use /etc/sudoers

If you have configured a client computer to use LDAP for sudo, you can reconfigure it to use the sudoers file again by commenting out the line that begins with sudoers_base in /etc/ldap.conf.

4.5 Setting Access Control on SUDO Attributes

To protect sensitive sudo attributes from unauthorized modification, set an access control item. Type:

ldapmodify -h oidhost -p oidport -D 'cn=orcladmin' -q -f aci.ldif

where aci.ldif looks like this:

dn: 
changetype: modify 
add: orclaci 
orclaci: access to 
 attr=(sudoUser,sudoHost,sudoCommand,sudoRunAs,sudoOption,sudoRole) 
 by group="cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext" 
 (search,read,write,compare) by group="cn=directoryadmingroup,cn=oracle 
 internet directory" (search,read,write,compare) by * (none)