5.2. About Attribute Uniqueness
The Attribute Uniqueness Plug-in is a preoperation plug-in. This means that the plug-in checks all update operations before the server performs an LDAP operation. The plug-in determines whether the operation applies to an attribute and a suffix that it is configured to monitor.
If an update operation applies to an attribute and suffix monitored by the plug-in and it would cause two entries to have the same attribute value, then the server terminates the operation and returns an
LDAP_CONSTRAINT_VIOLATION error to the client.
Each instance of the Attribute Uniqueness Plug-in performs a check on a single attribute for one or more subtrees. To check uniqueness of several attributes, a separate instance of the plug-in must be created for each attribute to check.
The Attribute Uniqueness Plug-in can operate in specific, user-defined ways:
- It can check every entry in the specified subtrees.For example, if a company,
example.com, hosts the directories forexample_a.comandexample_b.com, when an entry such asuid=jdoe,ou=people,o=example_a,dc=example,dc=comis added, uniqueness needs to be enforced only in theo=example_a,dc=example,dc=comsubtree. This is done by listing the DN of the subtree explicitly in the Attribute Uniqueness Plug-in configuration. - Specify an object class pertaining to an entry in the DN of the updated entry and perform the uniqueness check on all the entries beneath it.This option is useful in hosted environments. For example, when adding an entry such as
uid=jdoe,ou=people,o=example_a,dc=example,dc=com, enforce uniqueness under theo=example_a,dc=example,dc=comsubtree without listing this subtree explicitly in the configuration but, instead, by indicating a marker object class. If the marker object class is set toorganization, the uniqueness check algorithm locates the entry in the DN that has this object class (o=example_a) and performs the check on all entries beneath it.Additionally, it is possible to check uniqueness only if the updated entry includes a specified object class. For example, a check may be performed only if the updated entry includesobjectclass=inetorgperson.
Directory Server provides a default instance of the Attribute Uniqueness Plug-in for the
uid attribute when the Directory Server was first set up. This plug-in instance ensures that values given to the uid attribute are unique in the root suffix (the suffix corresponding to the userRoot database).
This plug-in is disabled by default because it affects the operation of multi-supplier replication.
Attribute Uniqueness Plug-ins do not perform any checking on attribute values when an update is performed as part of a replication operation.
Because all modifications by client applications are performed on the supplier server, the Attribute Uniqueness Plug-in should be enabled on the supplier. It is unnecessary to enable it on the consumer server.
Enabling the Attribute Uniqueness Plug-in on the consumer does not prevent Directory Server from operating correctly but is likely to cause a performance degradation.
In a multi-supplier replication scenario, the suppliers act both as suppliers and consumers of the same replica. Because multi-supplier replication uses a loosely consistent replication model, enabling an Attribute Uniqueness Plug-in on one of the servers is not sufficient to ensure that attribute values will be unique across both supplier servers at any given time. Therefore, enabling an Attribute Uniqueness Plug-in on one server can cause inconsistencies in the data held on each replica.
However, it is possible to use an Attribute Uniqueness Plug-in, providing both of the following conditions are met:
- The attribute on which the uniqueness check is performed is a naming attribute.
- The Attribute Uniqueness Plug-in is enabled on both supplier servers.
When these conditions are met, attribute uniqueness conflicts are reported as naming conflicts at replication time. Naming conflicts require manual resolution.
