18.1 Introduction to Managing Attribute Uniqueness Constraint Entries

When you use the LDAP tools, the attribute uniqueness feature prevents duplication of attribute values, both when adding and modifying them. For example, it prevents you from assigning to a new employee an identifier already assigned to another employee. Instead, the directory server terminates the operation and returns an error message.

You can define attribute uniqueness:

Across the entire directory

For example, to ensure that every entry in your directory that includes a mail attribute has a unique value for that attribute, you create an instance of attribute uniqueness associated with mail.

Across one subtree for each attribute

For example, suppose that MyCompany hosts the directories for SubscriberCompany1 and SubscriberCompany2. You can choose to enforce attribute uniqueness in SubscriberCompany1 only.

Across one object class

For example, suppose that ID is an attribute in both the machine object class and the person object class. If attribute uniqueness is enabled, then the directory server prevents you from adding either two machines or two people with the same ID. You can, however, add a machineID attribute that has the same value as an existing personID attribute. Similarly, you can add a personID attribute that has the same value as an existing machineID attribute.

Note:

The LDAP tools support attribute uniqueness. The bulk tools do not.

To implement attribute uniqueness, you create an attribute uniqueness constraint entry in which you provide values for the attributes in Table 18-1.

When you have created the entry and specified the attributes, before it performs an operation, the directory server:

Uses the attribute uniqueness constraint to check all update operations

Determines whether the operation applies to a monitored attribute, subtree, or object class

If an operation applies to a monitored attribute, suffix, or object class, and would cause two entries to have the same attribute value, then the directory server terminates the operation and returns a constraint violation error message to the client.

Note:

The attribute uniqueness feature works on indexed attributes only.

When an attribute uniqueness constraint is present in the Oracle Internet Directory replication environment, be careful about configuring the attribute uniqueness constraints on each server.

Because all modifications by client applications are performed on the supplier server, the attribute uniqueness constraint should be enabled on that server. It is not necessary to enable the attribute uniqueness constraint on the consumer server. Enabling the attribute uniqueness constraint on the consumer server does not prevent the directory server from operating correctly, but it can cause a performance degradation.

Multimaster Replication Scenario

In a multimaster replication scenario, nodes serve as both suppliers and consumers of the same replica. Multimaster replication uses a loosely consistent replication model.

Enabling an attribute uniqueness constraint on one of the servers does not ensure that attribute values are unique across both masters at any given time. Enabling an attribute uniqueness constraint on only one server can cause inconsistencies in the data held on each replica.

The attribute uniqueness constraint must be enabled on both masters. However, there may still be an inconsistent state. For example, in both masters we can successfully modify entries to the same attribute value. However, when the changes are later replicated to the other node, the conflict becomes apparent. You must take this type of conflict resolution into consideration as well, deciding whether conflict resolution should be the replication server's responsibility.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname, orcluniquescope and orcluniqueobjectclass, but different values in orcluniquesubtree, the subtree scopes specified by those attribute uniqueness constraints are checked individually.

For example, refer to Figure 18-1. Suppose that a user defines two attribute uniqueness constraints as follows:

In this example, the attribute uniqueness on employee_id is enforced against all entries under subtree o=sales,c=us,cn=root. Attribute uniqueness on employee_id is also enforced against all entries under o=hr,c=euro,cn=root independent of the entries under the subtree o=sales,c=us,cn=root—that is, the directory server enforces the unique value of the employee_id attribute for employee3 and employee4. Unique employee_id is enforced for employee7 and employee8 as well while employee7 could have the same employee_id as employee4.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname, orcluniquesubtree and orcluniqueobjectclass, but different values in orcluniquescope, the attribute uniqueness constraint with the largest search scope takes effect.

For example, referring to Figure 18-1, suppose that a user defines two attribute uniqueness constraints as follows:

In this example, the attribute uniqueness on employee_id is enforced against all entries under the subtree c=us,cn=root and the entry c=us,cn=root itself. Note that this is the same as if the user had defined only Constraint2.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname, orcluniquesubtree, and orcluniquescope, but different values in orcluniqueobjectclass, then the union of attributes belonging to those object classes is checked.

For example, look at Figure 18-1. Suppose that a user defines two attribute uniqueness constraints as follows:

In this example, the attribute uniqueness on employee_id is enforced against all entries under the subtree c=us,cn=root and the entry c=us,cn=root itself, no matter what object class those entries belong to. Note that Constraint2 specifies no orcluniqueobjectclass attribute, which is the same as specifying all object classes.

When multiple attribute uniqueness constraints have the same values in orcluniqueattrname, but different values in orcluniquesubtree, orcluniquescope, and orcluniqueobjectclass, the entries that belong to the attribute uniqueness scopes of different constraints are checked individually.

For example, referring to Figure 18-1, suppose that a user defines two attribute uniqueness constraints as follows:

The following LDIF file, uniquenessConstraint.ldif, specifies a uniqueness constraint for the orclcommonusernickname attribute:

# Use this LDIF file to set up a uniqueness constraint on the nickname
# attribute within the user search base.
# Before running the script, change the following parameters in the LDIF file.
# <userid_attribute> - Specify the name of the attribute that holds the user
# id. This value should be the same as the orclcommonusernickname attribute
# configured for the realm.# <dn _f_user_serach_base> - Specify the user search base in which the
# uniqueness constraint should be enforced.
#
dn: cn=<userid_attribute> ,cn=unique,cn=common,cn=Products, cn=OracleContext
changetype: add
objectclass: orclUniqueConfig
orcluniqueattrname: <userid _ttribute>
orcluniquesubtree: <dn_of_user_search_base>
orcluniqueenable:1

18.4.2 Creating Attribute Uniqueness Across One Subtree by Using Command-Line Tools

To create an instance of attribute uniqueness across one or more subtrees, specify:

An attribute name for which you want to enforce value uniqueness

Subtree locations under which you want the uniqueness constraint to be enforced

For example, suppose that MyCompany hosts the directories for SubscriberCompany1 and SubscriberCompany2, and you want to enforce the uniqueness of the employee identifier attribute in SubscriberCompany1 only. When you add an entry such as uid=dlin,ou=people,o=SubscriberCompany1,dc=MyCompany, dc=com, you must enforce uniqueness only in the o=SubscriberCompany1,dc=MyCompany,dc=com subtree. Do this by listing the DN of the subtree explicitly in the attribute uniqueness constraint configuration.