| Skip Navigation Links | |
| Exit Print View | |
|
Oracle Fusion Middleware Administration Guide for Oracle Unified Directory 11g Release 1 (11.1.1) |
| 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
Restoring Replicated Directory Servers
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
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
Collective attributes are attributes whose values are shared across a collection of entries. Collective attributes provide similar functionality to the Oracle Directory Server Enterprise Edition Class of Service feature.
Oracle Unified Directory collective attributes are much like virtual attributes but are defined and stored with the user data as LDAP subentries. As part of the user data, collective attributes can be replicated to other servers in the topology.
This section describes the collective attribute implementation in Oracle Unified Directory and explains how to configure collective attributes. The section covers the following topics:
The Oracle Unified Directory implementation of collective attributes is based on RFC 3671 and RFC 3672, with a few specific extensions. These extensions make Oracle Unified Directory collective attributes more transparent for LDAP client applications, and are described in the following sections:
According to RFC 3671, collective attributes must have the COLLECTIVE attribute type, be derived from regular user attributes defined in the schema, and have the c- prefix. For example c-l is a collective attribute for the standard l attribute, and affected user entries have c-l added to them on the fly.
This specification can cause problems for many client applications, which are typically not aware of collective attributes and might need to be modified or extended to handle collective attributes. Oracle Unified Directory therefore removes this restriction and supports the definition of any regular attribute defined in the schema as a collective attribute. This extension is facilitated by adding the required attribute to the related collective attribute subentry and marking the attribute with the collective option.
Because of the way in which collective attributes can be named, a conflict resolution mechanism is provided, for cases where affected user entries already contain related real attributes. Oracle Unified Directory provides the same conflict resolution options for collective attributes as it does for virtual attributes: real-overrides-virtual, virtual-overrides-real, and merge-real-and-virtual.
The default conflict resolution rule is real-overrides-virtual. If an entry already has the same attribute type defined, the explicitly defined attribute takes precedence over the collective attribute. This behavior can be changed for each collective attribute subentry (to virtual-overrides-real or merge-real-and-virtual) by using collectiveConflictBehavior attribute.
The following example dynamically adds the l collective attribute with a value of Paris to each applicable user entry under ou=people. The value of the collective attribute overrides any value for l that is specific to the entry:
dn: cn=People Locale,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Locale
l;collective: Savoie
subtreeSpecification: {base "ou=people", minimum 1}
collectiveConflictBehavior: virtual-overrides-real
In some instances, it might be necessary to avoid having collective attributes in specific user entries. You can add the collectiveExclusions operational attribute to such entries to achieve this behavior. To exclude specific collective attributes, list the attribute names as values of the collectiveExclusions attribute. To exclude all collective attributes, set the value of collectiveExclusions to excludeAllCollectiveAttributes.
The following example excludes the preferredLanguage attribute from being applied to the entry for user.0:
dn: uid=user.0,ou=People,dc=example,dc=com objectclasses and other user attributes collectiveExclusions: preferredLanguage
The following example excludes the c-l attribute from being applied to the entry for user.1:
dn: uid=user.1,ou=People,dc=example,dc=com objectclasses and other user attributes collectiveExclusions: c-l
The following example excludes both the preferredLanguage and c-l attributes from being applied to the entry for user.2:
dn: uid=user.2,ou=People,dc=example,dc=com objectclasses and other user attributes collectiveExclusions: preferredLanguage collectiveExclusions: c-l
The following example excludes all collective attributes from being applied to the entry for user.0:
dn: uid=user.0,ou=People,dc=example,dc=com objectclasses and other user attributes collectiveExclusions: excludeAllCollectiveAttributes
Collective attributes are defined using LDAP subentries within the directory tree where they are applicable. The following examples use a simple tree with multiple user entries.
dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
dn: uid=user.0,ou=People,dc=example,dc=com
dn: uid=user.1,ou=People,dc=example,dc=com
dn: uid=user.2,ou=People,dc=example,dc=com
...
To add a common preferredLanguage attribute for all users, create and add a collective attribute subentry similar to the following:
dn: cn=People Preferred Language,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Preferred Language
preferredLanguage;collective: fr
subtreeSpecification: {base "ou=people", minimum 1}
The preferredLanguage attribute-value pair is dynamically added to all user entries under ou=people, as shown in the following example:
dn: uid=user.0,ou=People,dc=example,dc=com objectclasses and other user attributes preferredLanguage: fr dn: uid=user.1,ou=People,dc=example,dc=com objectclasses and other user attributes preferredLanguage: fr ...
The same procedure applies for collective attribute types. For example, the c-l collective attribute type specifies a locality name for a collection of entries. The following example adds a common c-l collective attribute:
dn: cn=People Locale,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Locale
c-l: Paris
subtreeSpecification: {base "ou=people", minimum 1}
The c-l: Paris attribute is added to applicable entries, as shown in this example:
dn: uid=user.0,ou=People,dc=example,dc=com objectclasses and other user attributes c-l: Paris dn: uid=user.1,ou=People,dc=example,dc=com objectclasses and other user attributes c-l: Paris ...
You can define multiple collective attributes in the subentry of any collective attribute in the following ways:
by adding the collective attribute types to the subentry
by adding regular attribute types with the collective option
by adding a combination of the two
Collective attribute subentries allow for flexible and complex definitions. For information about collective attribute scoping and the subtreeSpecification syntax, see RFC 3671 and RFC 3672.
Make sure that there are no trailing spaces after add. If a space exists after add, the server base-64 encodes the value to represent the space, which can cause problems.
This example uses an input LDIF file named add_collective_attr.ldif.
dn: cn=People Preferred Language,dc=example,dc=com
changetype: add
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Preferred Language
preferredLanguage;collective: fr
subtreeSpecification: {base "ou=people", minimum 1}$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -w password \ -f /usr/local/add_collective_attr.ldif Processing ADD request for cn=People Preferred Language,dc=example,dc=com ADD operation successful for DN cn=People Preferred Language,dc=example,dc=com
You can delete a collective attribute by using either the ldapdelete command or the ldapmodify command. This example uses the ldapmodify command.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -w password dn: cn=People Preferred Language,dc=example,dc=com changetype: delete deleting entry cn=People Preferred Language,dc=example,dc=com
To list the collective attribute subentries that apply to a specific user entry, request the collectiveAttributeSubentries operational attribute for that entry.
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -w password \ -b "uid=user.0,ou=People,dc=example,dc=com" \ "objectclass=*" "collectiveAttributeSubentries" version: 1 dn: uid=user.0,ou=People,dc=example,dc=com collectiveAttributeSubentries: cn=People Preferred Language,dc=example,dc=com
Inherited attributes enable a common set of attributes to be shared by nature of their inheritance. Inherited collective attributes provide flexible scoping mechanisms using the standard subentry subtree specification, and support any attribute type for RDN definition and construction.
The main difference between collective attributes and inherited collective attributes is the source of attribute values:
A collective attribute always derives its value from its definition entry.
An inherited collective attribute can inherit, either directly or indirectly, the collective attribute values from other entities.
The inherited collective attributes functionality is built upon and extends collective attributes. Inherited attributes are defined as a specific type of collective attributes subentry inheritedCollectiveAttributeSubentry. This type is further divided into the following two distinct subtypes :
inheritedFromDNCollectiveAttributeSubentry
inheritedFromRDNCollectiveAttributeSubentry
Each subtype has its own set of configuration attributes. The subtypes cannot be mixed in a single definition, so an inherited attribute definition can only be of one subtype.
Like regular collective attributes, inherited collective attributes are defined using LDAP subentries within the directory tree where they are applicable.
The following examples use a simple tree with multiple user entries.
dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
dn: uid=hpollock,ou=People,dc=example,dc=com
dn: uid=cventer,ou=People,dc=example,dc=com
dn: uid=sdonnelly,ou=People,dc=example,dc=com
...
To add an inherited postalAddress attribute for all users, create and add an inherited collective attribute subentry similar to the following:
dn: cn=indirectCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromDNCollectiveAttributeSubentry
cn: indirectCOS
subtreeSpecification: {base "ou=people"}
inheritFromDNAttribute: manager
inheritAttribute: postalAddress
This subentry specifies that the user entry inherits its postalAddress value from the entry referenced by the manager attribute in the user's entry.
The manager's entry contains the real value for the postalAddress attribute:
dn: uid=dsmith,ou=People,dc=example,dc=com ... objectclasses and other user attributes postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065
Each user entry references the manager entry, and inherits its postalAddress from that entry:
dn: uid=hpollock,ou=People,dc=example,dc=com ... objectclasses and other user attributes manager: uid=dsmith,ou=People,dc=example,dc=com postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065 dn: uid=cventer,ou=People,dc=example,dc=com ... objectclasses and other user attributes manager: uid=dsmith,ou=People,dc=example,dc=com postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065 dn: uid=sdonnelly,ou=People,dc=example,dc=com ... objectclasses and other user attributes manager: uid=dsmith,ou=People,dc=example,dc=com postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065
|