Skip Navigation Links | |
Exit Print View | |
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
1. Starting and Stopping the Server
2. Configuring the Server Instance
3. Configuring the Proxy Components
4. Configuring Security Between Clients and Servers
5. Configuring Security Between the Proxy and the Data Source
6. Managing Oracle Unified Directory With Oracle Directory Services Manager
Populating a Stand-Alone Directory Server With Data
Importing Data Using import-ldif
To Import Data in Offline Mode
To Replace Existing Data During an Offline Import
To Append Imported Data to Existing Data
To Import Fractional Files by Using Filters
To Include or Exclude Attributes During Import
To Import a Compressed LDIF File
To Record Rejected or Skipped Entries During Import
To Import Data From a MakeLDIF Template
To Run an Import in Online Mode
Exporting Data Using export-ldif
To Export Part of a Back End by Using Filters
To Include or Exclude Attributes During Export
To Export to LDIF and Then Compress the File
To Run an Export in Online Mode
Creating MakeLDIF Template Files
Attribute Value Reference Tags
Tuning the JVM and Java Arguments
Overview of the Backup and Restore Process
To Back Up All Back Ends with Encryption and Signed Hashes
To Perform an Incremental Backup on All Back Ends
To Back Up a Specific Back End
To Perform an Incremental Backup on a Specific Back End
To Schedule a Backup as a Task
Backing Up the Server Configuration
Backing Up for Disaster Recovery
To Back Up the Directory Server For Disaster Recovery
Backing up and Restoring Data Using File System Snapshots
To Take a ZFS Snapshot On a Dedicated Backup Server
To Restore a Directory Server From a ZFS Snapshot
To Restore a Back End From Incremental Backups
To Schedule a Restore as a Task
To Restore the Configuration File
To Restore a Directory Server During Disaster Recovery
Overview of the ldapsearch Command
ldapsearch Location and Format
Specifying Filter Types and Operators
Using UTF-8 Encoding in Search Filters
Using Special Characters in Search Filters
To Search for Specific User Attributes
To Perform a Search With Base Scope
To Perform a Search With One-Level Scope
To Perform a Search With Subtree Scope
To Return Attribute Names Only
To Return User Attributes Only
To Search For Specific Object Classes
To Return a Count of All Entries in the Directory
To Perform a Search With a Compound Filter
To Perform a Search Using a Filter File
To Limit the Number of Entries Returned in a Search
Searching Data With Oracle Directory Services Manager
Using Advanced Search Features
Searching for Special Entries and Attributes
To Search for Operational Attributes
To Search the Configuration Entry
To Search the Monitoring Entry
To Search Over SSL With Blind Trust
To Search Over SSL Using a Trust Store
To Search Over SSL With No Trust Store
To Search Over SSL Using a Keystore
To Search Using SASL With DIGEST-MD5 Client Authentication
To Search Using SASL With the GSSAPI Mechanism
To Search Using SASL With the PLAIN Mechanism
To View the Available Controls
To Search Using the Account Usability Request Control
To Search Using the Authorization Identity Request Control
To Search Using the Get Effective Rights Control
To Search Using the LDAP Assertion Control
To Search Using the LDAP Subentry Control
To Search Using the Manage DSA IT Control
To Search Using the Matched Values Filter Control
To Search Using the Password Policy Control
To Search Using the Persistent Search Control
To Search Using the Proxied Authorization Control
To Search Using the Server-Side Sort Control
To Search Using the Simple Paged Results Control
Searching Using the Virtual List View Control
To Search Using the Virtual List View Control
To Search Using Virtual List View With a Specific Target
To Search Using Virtual List View With a Known Total
Searching in Verbose Mode and With a Properties File
To Search Using a Properties File
Searching Internationalized Entries
Adding, Modifying, and Deleting Directory Data
To Add an Entry Using the --defaultAdd Option With ldapmodify
To Add Entries Using an LDIF Update Statement With ldapmodify
To Add an Attribute to an Entry
To Add an International Attribute
To Modify an Attribute With Before and After Snapshots
To Delete an Entry With ldapmodify
To Delete an Entry With ldapdelete
To Delete Multiple Entries by Using a DN File
Configuring Indexes on the Local DB Back End
To Create a New Local DB Index
To Enable or Disable Compact Encoding
To Enable or Disable Entry Compression
Ensuring Attribute Value Uniqueness
Overview of the Unique Attribute Plug-In
Configuring the Unique Attribute Plug-In Using dsconfig
To Ensure Uniqueness of the Value of the uid Attribute
To Ensure Uniqueness of the Value of Any Other Attribute
Replication and the Unique Attribute Plug-In
Configuring Virtual Attributes
To List the Existing Virtual Attributes
To Create a New Virtual Attribute
To Enable or Disable a Virtual Attribute
To Display the Configuration of a Virtual Attribute
To Change the Configuration of a Virtual Attribute
Extensions to the Collective Attributes Standard
Collective Attributes and Conflict Resolution
Excluding Collective Attributes From Specific Entries
Configuring Collective Attributes
To Create a New Collective Attribute
To Delete a Collective Attribute
To List the Collective Attributes That Apply to an Entry
Inherited Collective Attributes
Specifying Inherited Collective Attributes
Managing Data With Oracle Directory Services Manager
View the Attributes of an Entry
Add an Entry Based on an Existing Entry
Delete an Entry and its Subtree
10. Managing Users and Groups With dsconfig
11. Managing Password Policies
Oracle Unified Directory provides an extensible framework that supports a variety of repository types. The directory server uses the Berkeley DB Java Edition (JE) as its primary back end. The JE back end provides some advantages over other databases as it provides a high-performance, scalable transactional B-tree database with full support for ACID semantics for small to very large data sets. It can also store its entries in encoded form and provide indexes for fast, efficient data retrieval.
This section covers the following topics:
To maintain the directory data on the JE back end, the directory server provides efficient backup and restore utilities that support full and incremental backups. A full backup saves the directory data files in the environment as a compressed archive file. An incremental backup saves and compresses just those files that have been written since the previous backup, together with a list of names of files that are unchanged since the previous backup. The directory server stores its backup information in a backup back end for easy restores.
Directory server backups also can be made on the local disks or on remote disks, for example, on network-attached storage (NAS). If you run a backup locally, you should then copy and store the backup on a different machine or file system for security purposes.
Before you start backing up and restoring data, consider the following:
You must design a workable backup and restore strategy for your directory services system. For example, you can run an incremental backup daily and perform a full backup at least once a week. Test your backup process and your ability to restore regularly. For data restores, many companies restore a directory server from a replicated server, which ensures that the most update copy of the directory data is used. Backup tapes are still needed if the directory data is damaged (for example, missing entries) and the corrupted data has been replicated to other servers.
Ensure that you have a disaster recovery plan in place. Disaster recovery is necessary when catastrophic events, data corruption, or data tampering occurs. Companies devise their own plans or out source the work to third party specialists. See Backing Up for Disaster Recovery for more information.
Ensure that you have a place to store your back ups. Store the archived data, configuration directory, schema subdirectory, and installation directory used for your server together in a single location. All these items are required when you restore the server.
The directory server provides an efficient command-line utility (backup) to back up databases. The backup command can be run immediately or scheduled as a task. If the backup is scheduled, the command contacts the server over SSL, using the administration connector, and registers a backup task. If no connection options are specified, the command runs immediately.
The following procedures show the use of the backup command in various backup scenarios.
You can back up all back ends end by using the --backUpAll option.
The following command is run on a standalone directory server and specifies that all databases should be backed up, compresses the backup file, and saves the file to a specified location.
$ backup --backUpAll --compress --backupDirectory /tmp/backup
The backup directory contains subdirectories for each back end:
$ ls /tmp/backup ./ ../ config/ schema/ tasks/ userRoot/
The backup utility writes the backup to the specified directory and creates a backup.info file that provides details about the backup. The directory server assigns a backup ID based on the current date and time. To create your own ID, use the --backupID option:
$ ls /tmp/backup/config ./ backup.info ../ config-backup-20070827153501Z
The backup.info file contains detailed information about the current backup.
$ more /tmp/backup/config/backup.info backend_dn=ds-cfg-backend-id=config,cn=Backends,cn=config backup_id=20070827153501Z backup_date=20070827153511Z incremental=false compressed=true encrypted=false property.archive_file=config-backup-20070827153501Z
The backup utility provides encryption and signed hash support for secure backups. The use of the encryption and signed hash options requires a connection to an online server instance, so the appropriate connection options must be specified.
The following command backs up all back ends, compresses them, generates a hash, signs the hash, and encrypts the data.
$ backup -h localhost -p 4444 -D "cn=directory manager" -w password --backUpAll -X \ --compress --hash --signHash --encrypt --backupID 123 --backupDirectory /tmp/backup
Incremental backups save only those changes that have occurred since the last backup (full or incremental). The main advantage of an incremental backup is the faster time to back up a system when compared to that of full backups. The disadvantage of an incremental backup is that each incremental backup must be restored, which requires more time and care than that of a full restore.
$ backup --backUpAll --incremental --compress --backupDirectory /tmp/backup
You can back up a single back end by using the --backendID option, which specifies the back end to save.
Note - If you back up a single back end and replication is configured, any changes made to that back end are stored in the change log on the replication server. When you restore that back end, the replication server detects that the back end is not up to date and replays the changes made after the backup. This behavior occurs even if there is only one directory server in the replicated topology, because the changes are stored on the replication server.
If you do not want this behavior, back up all back ends in a replicated environment. This ensures that the data, and the replication server are backed up. In this case when a restore is done, the directory server and the replication server are restored to their state before the back up, and no memory of subsequent changes remains.
$ list-backends Backend ID Base DN -------------- ----------------- adminRoot cn=admin data ads-truststore cn=trust-store backup cn=backups config cn=config monitor cn=monitor schema cn=schema tasks cn=tasks userRoot dc=example,dc=com
For example, to back up the userRoot back end, run the following command:
$ backup --backendID userRoot --backupDirectory /tmp/backup
$ list-backends Backend ID Base DN -------------- ----------------- adminRoot cn=admin data ads-truststore cn=trust-store backup cn=backups config cn=config monitor cn=monitor schema cn=schema tasks cn=tasks userRoot dc=example,dc=com
$ backup --incremental --backendID userRoot --backupDirectory /tmp/backup
The directory server provides a task back end for processing administrative tasks, such as backups and restores. You can specify the start time for a backup or restore by using the -t or --start option. If one of these options is provided, the utility exits immediately after scheduling the task. To schedule a task for immediate execution and have the utility exit immediately after scheduling the task, specify 0 as the value for the start time. If the -t or --start option is omitted, the utility schedules the task for immediate execution and tracks the task's progress, printing log messages as they are available and exiting when the task has completed.
Access to the task back end is provided over SSL via the administration connector. If you schedule the backup as a task, you must therefore specify how the SSL certificate will be trusted. This example schedules a backup for execution at a future time. The -X option specifies that all certificates presented by the server are trusted. For more information, see Managing Administration Traffic to the Server.
$ backup --port 4444 --bindDN "cn=Directory Manager" --bindPassword password -X \ --backUpAll --backupDirectory /tmp/backups --start 20080601121500 \ --completionNotify admin@example.com --errorNotify admin@example.com
$ manage-tasks --port 4444 --bindDN "cn=Directory Manager" --bindPassword password -X \ --info 2008040210324704 --no-prompt
All configuration settings for a directory server instance are stored in the config.ldif file, which is located in the config directory. The directory server automatically saves the config.ldif file to ensure that changes are properly accounted for in the configuration. The file is saved at two specific times:
At startup. If the current configuration does not match the archived configuration, the server saves the config.ldif file.
At modification time. Whenever a directory administrator makes changes to the configuration by using the dsconfig utility with the server online, the directory server saves the config.ldif file prior to the change.
You can access archived configuration files from the install-dir/config/archived-configs directory. This directory lists each saved configuration file, compresses it as a .gz file, and saves the configuration as config-timestamp.gz. For example, you can see archived config.ldif files as follows:
$ ls config/archived-configs 09/02/2007 03:43 PM 9,045 config-20070819055359Z.gz
Directory and system administrators should have a disaster recovery plan in place in the event of a natural, human-induced, or catastrophic disaster. If your directory service is distributed over multiple individual servers, back up all the servers individually or back up all the directory data from a central location.
Alternatively, consider replication as a backup and restore strategy. Replication provides faster restores and more update data from another replicated server. For more information, see Restoring Replicated Directory Servers.
$ backup --backUpAll --backupDirectory /tmp/backup
Make sure that the schema subdirectory is present within the install-dir/config directory.
All items are required when restoring the server.
For certain deployments, file system snapshot technologies offer a viable alternative to the traditional backup. On Solaris systems, ZFS enables file system snapshots that are space efficient, very quick to create, and portable between systems. By dedicating a Directory Server per data center, or two if your entire service runs in one data center, you deploy an effective, redundant solution for restoring data as part of your disaster recovery plan.
$ dsconfig -h host -p 4444 -D "cn=Directory Manager" -w password -X -n \ set-global-configuration-prop --set writability-mode:internal-only
When you restore a server from the snapshot of the read-only replica, the restored server accepts only replication traffic until you enable writability, after the server has caught up with other replicas in the topology.
For example, if the Directory Server files are stored in the file system corresponding to zpool/DS_FS, the command is:
$ zfs snapshot zpool/DS_FS@{todays_date}
$ zfs send zpool/DS_FS@{today_date} > /backups/DS_FS.{today_date}.zfs
Do not keep snapshots longer than the replication purge delay, because when you restore from a snapshot, the replication mechanism has to be able to replay all the missing changes on the replica.
Create a ZFS file system to access the backup pool, using /backups as the mount point.
$ dd if=/backups/DS_FS.{date_to_restore}.zfs bs=32k | zfs receive -F zpool/DS_FS
$ dsconfig -h restored-host -p 4444 -D "cn=Directory Manager" -w password -X -n \ set-global-configuration-prop --set writability-mode:enabled
You can restore data by using the restore utility. The restore utility allows you to restore only one back end at a time. The directory server must be stopped prior to a restore, unless you are scheduling a restore task, or you are restoring data that has been signed or hashed.
$ restore --listBackups --backupDirectory backup/userRoot Backup ID: 20080827153501Z Backup Date: 27/Aug/2008:10:35:11 -0500 Is Incremental: false Is Compressed: true Is Encrypted: false Has Unsigned Hash: false Has Signed Hash: false Dependent Upon: none
$ restore --backupDirectory backup/userRoot
Typically, system administrators run a weekly full backup with daily incremental backups. Be aware that it takes longer to restore your system from incremental backups.
Each back end must be restored individually.
Restore each incremental backup starting from the last full backup.
The directory server provides a task back end for processing administrative tasks, such as backups and restores. You can specify the start time for a restore by using the -t or --start option. If one of these options is provided, the utility exits immediately after scheduling the task. To schedule a task for immediate execution and have the utility exit immediately after scheduling the task, specify 0 as the value for the start time. If the -t or --start option is omitted, the utility schedules the task for immediate execution and tracks the task's progress, printing log messages as they are available and exiting when the task has completed.
Access to the task back end is provided over SSL, using the administration connector. If you schedule the restore as a task, you must therefore specify how the SSL certificate will be trusted.
The following command restores the userRoot back end at a scheduled start time by using the --start option. The restore sends a completion and error notification to admin@example.com. The -X option specifies that all certificates presented by the server are trusted.
$ restore -p 4444 -D "cn=Directory Manager" -w password -X \ -d /backup/userRoot --start 20080125121500 --completionNotify admin@example.com \ --errorNotify admin@example.com
For more information, see Configuring Commands As Tasks.
You might need to restore the configuration file to transfer the configuration to another server, for disaster recovery purposes, or for other events. In general, if a server is online, the current configuration file is equivalent to the latest archived configuration file. However, you can choose to restore the config.ldif file from a previous date.
$ ls install-dir/config/archived-configs ./ ../ config-20070817192057Z.gz config-20070827153200Z.gz config-20070817192052Z.gz config-20070827153214Z-2.gz
$ cp config-20070817182052Z install-dir/config/config.ldif
The config.ldif file should reside in this directory. The saved schema subdirectory should be located in install-dir/config/schema.
Performing binary restores in replicated environments requires special care depending on your replicated topology. If possible, update your back end by using the replication mechanisms in your system instead of restoring it from a backup. Replication has distinct advantages over traditional tape backups. Data restores are much faster than tape restores, and the data is more up to date. However, tapes are still needed in the event that the replicated data is corrupt and has been propagated to other servers.
When restoring a replicated server, ensure that the configuration file install-dir/config/config.ldif is the same as when the backup was made. Restore the config.ldif file prior to restoring the server back ends.
You cannot restore an old backup to a master server because it might be out of date. Rather allow the replication mechanism to bring a master up to date with the other master servers by setting that master to read-only. When the master has been synchronized, you can reset it to read-write.
If you need to restore a replicated server, reinitialize the server from one of the other replicated servers by importing an LDIF file.
For very large databases (millions of entries), make a binary copy of one server and restore it on the other replicated server.
If you have a fairly recent backup (one that is not older than the maximum age of the change log contents on any of the other replicated servers), you can use that version to restore your data. When the old backup is restored, the other servers will update that server with recent updates made since the backup was saved.
If you run regular backups, the backup files might start to consume too much disk space. You must remove the old backup files manually to create space for new ones.
When you delete backup files manually, make sure that you do not break any dependencies between backup sets.
For example, to list the backups in the default backup directory, run the following command:
UNIX: $ ls install-dir/bak backup-userRoot-20090929184101Z backup-userRoot-20091029184509Z backup.info backup.info.save WINDOWS: C:\> dir install-dir\bak backup-userRoot-20090929184101Z backup-userRoot-20091029184509Z backup.info backup.info.save
For example, to remove the oldest backup of the userRoot database in the preceding step, run the following command:
UNIX: $ rm install-dir/bak/backup-userRoot-20090929184101Z WINDOWS C:\> del install-dir\bak\backup-userRoot-20090929184101Z
You can display the contents of the backup.info, as follows (on UNIX systems):
$ more install-dir/bak/backup.info backend_dn=ds-cfg-backend-id=userRoot,cn=Backends,cn=config backup_id=20090929184101Z backup_date=20090929184104Z incremental=false compressed=false encrypted=false property.last_logfile_name=00000000.jdb property.last_logfile_size=160773 property.archive_file=backup-userRoot-20090929184101Z backup_id=20091029184509Z backup_date=20091029184512Z incremental=false compressed=false encrypted=false property.last_logfile_name=00000000.jdb property.last_logfile_size=160773 property.archive_file=backup-userRoot-20091029184509Z
For Windows systems, use an appropriate text editor.