[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Unique overlay usage with filter


Thanks for your help so far.

In attempting to reproduce my problem with a minimal slapd.conf that I
could post, I am now encountering a slightly different problem related
to the unique overlay.  In particular, I get an LDAP constraint
violation when attempting to add an entry that should be allowed.

Here's my complete slapd.conf:

ucdata-path data
include schema/core.schema
include schema/cosine.schema
include schema/inetorgperson.schema
include schema/nortel.schema
backend bdb
database bdb
overlay unique
unique_uri ldap:///?uid?sub?(sn=e*)
suffix "dc=Nortel,dc=com"
rootdn "cn=Administrator,dc=Nortel,dc=com"
rootpw adminpwd
directory data
index sn eq,sub
index cn eq,sub

Here are the steps to reproduce my current problem (all modifications
are made using the configured rootdn):
1.  Add an entry with uid=a and sn=e.
2.  Add a second entry with uid=a and sn=f.

The second entry is not added.  Instead, OpenLDAP returns error code 19
(constraint violation) with a message of "some attributes are not
unique".  When I comment out the unique_uri line in slapd.conf and
restart slapd, the second entry can be added successfully.

Have I configured something incorrectly?

Kyle Blaney


-----Original Message-----
From: Pierangelo Masarati [mailto:masarati@aero.polimi.it] 
Sent: July 21, 2009 12:52 PM
To: Blaney, Kyle (BVW:9T16)
Cc: openldap-software@openldap.org
Subject: Re: Unique overlay usage with filter

Kyle Blaney wrote:
> I'm using the unique overlay in OpenLDAP 2.4.16 and finding it too 
> easy to violate the uniqueness constraints I have defined.
> For example, if I have the following in my slapd.conf (taken from 
> slapo-unique man page):
> overlay unique
> unique_uri ldap:///?cn?sub?(sn=e*)
> I can violate the uniqueness constraints as follows:
> 1.  Add an entry with cn=a and sn=e.
> 2.  Add a second entry with cn=a and sn=f.
> 3.  Modify the sn of the second entry so that sn=e.
> The attribute modification succeeds but causes a violation of the 
> uniqueness constraints.
> Is there any way to configure OpenLDAP so that the attribute 
> modification fails due to a constraint violation?

How did you configure slapo-unique(5)?  Is it global, or rooted at an
empty DN database?  Note that it requires a rootdn to be configured for
the database it's instantiated for.

According to your configuration, it is not working for a specific
searchbase (the "dn" part of your URI is empty), so it might be that the
identity it is running as does not have enough privileges to see the
attributes it is supposed to constrain when they are across databases.

You should probably post your entire slapd.conf or back-config contents
(make sure you remove sensitive information like passwords).