|Oracle® Fusion Middleware Administrator's Guide for Oracle Authentication Services for Operating Systems
11g Release 1 (11.1.1)
Part Number E16454-02
This chapter contains the following topics:
Before migrating entries from NIS, files, or another LDAP directory, perform the following tasks:
Tune your Oracle Internet Directory database.
The basic tuning steps listed in the Oracle Internet Directory chapter of Oracle Fusion Middleware Performance and Tuning Guide.
Oracle Internet Directory Tuning and Configuration, a Quick Reference Guide at
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
Keep a local
root account in your
Do not modify the
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:
Migrate entries as follows.
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".
The steps for migrating entries from NIS to Oracle Internet Directory are as follows:
Run the LDAP migration scripts, described in "Get NIS Migration Tools", on your NIS master files. This will generate LDIF files containing the entries.
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
shadowAccount objectclass and attributes are typically missing in user entries migrated from an HP-UX server.
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
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.
binddn you use must be the directory administrator DN so that you have the proper privileges when performing these additions.
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
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.
The steps for migrating schema are as follows:
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
schemasyncin 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.
If necessary, extend the schema elements in Oracle Internet Directory.
Based on the analyses in Step 1, determine what new schema elements you must load onto Oracle Internet Directory. Modify the files
objectclasses.ldif (from step) 1 to have only the attributes and object classes that you must load. Name the modified files
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
orcluser. In Step 1, if the objectclass definitions of
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
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
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
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).
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.
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 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.
If you are migrating entries other than user and group from source directories, update the mapfile accordingly.
Make a copy of the sample file
$ORACLE_HOME/ldap/odi/samples/migrate.properties and name it
See Also:The command reference for
syncProfileBootstrapin 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.
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.
Generate a new LDIF file in the format required by Oracle Internet Directory by running the command:
syncProfileBootstrap -file testmigrate.properties
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.
Get the filtered LDIF file resulting from Step 1 or Step2 and use either
$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
The syntax for
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.
oidstats.sqlcommand reference in the Oracle Internet Directory Database Tools chapter of the Oracle Fusion Middleware Reference for Oracle Identity Management.
If you decide to use
bulkload, then proceed to Step 5
Bulk load LDIF data into Oracle Internet Directory. In the following steps, the file
/home/jdoe/migrationdata.ldif is the filtered LDIF file.
Stop all Oracle Internet Directory processes by executing the command:
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OID
Take a cold backup of the database if you have not done so already.
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
bulkload checks the entries for schema compliance and duplicates and generates the intermediate files that are used during the load phase in the
If there are any
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
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
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
bulkload generates the intermediate files for 90 good entries.
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
load=true command. If
bulkload reports an error during indexing, use the following command to recreate all indexes:
bulkload connect=oid-db index=true
bulkload reports an error during database statistics generation, you can use the following command to generate the statistics:
Start all Oracle Internet Directory processes by executing the command:
$ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OID
ldapmodify -h oidhost -p oidport -D 'cn=orcladmin' -q -f aci.ldif
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)
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
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.
You can migrate entries from
/etc/sudoers into Oracle Internet Directory using the
sudo package you downloaded from:
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.
sudo, run some security tests to ensure that your
sudopolicy is being enforced correctly.
To move the contents of your
sudoers file to Oracle Internet Directory, perform these steps:
Sudoers container to Oracle Internet Directory using the command:
ldapadd -h oid_hostname -p port -D cn=orcladmin \ -q -f sudocontainer.ldif
sudocontainer.ldif looks like this:
dn:ou=Sudoers,dc=us,dc=example,dc=com objectclass:top objectclass:organizationUnit ou=sudoers
/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.
View the resulting LDIF file in a text editor and correct any obvious errors.
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
sudoers.ldif is the file generated from your
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
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
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
Download, build, and install the OpenLDAP and OpenSSL packages.
If you already have the file
/etc/ldap.conf, make a copy. For example
cp /etc/ldap.conf /etc/ldap.conf.save
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
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
If there is no
libpam.so link, make one by typing:
cd /usr/lib ln -s libpam.so.0 libpam.so
/etc/pam.d/sudo. Add the following line above the first
auth sufficient /lib/security/pam_ldap.so debug
/etc/ldap.conf so that
sudoers_base points to the base sudoers container. For example:
If you want to configure
sudo you must specify
ldap.conf since the current
sudo implement does not support SSL only. For example:
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.
To build sudo with LDAP enabled on AIX 5.3, proceed as follows, where
base_dir is the directory where you install
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
cd $build_dir/openssl-0.9.8g ./Configure aix-cc shared threads -D_REENTRANT --prefix=$base_dir make make install
cd $build_dir/openldap-2.3.39 ./configure \ --prefix=$base_dir \ --enable-slapd=no \ --enable-bdb=no \ --enable-static=no \ --enable-shared=yes
Makefile, adding the TLS_LIBS parameter, as follows:
TLS_LIBS = -lssl -lcrypto -lldap
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:
After make completes successfully, type:
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.
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.
/etc/ldap.conf so that
sudoers_base points to the base sudoers container you created in Server Step 1. For example:
If you want to configure SSL for
sudo you must specify
ldap.conf because the current
sudo implementation does not support SSL only. For example:
sudo debugging by adding the following line to
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
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
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
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)