--On Friday, April 12, 2013 5:48 PM +0000 quanah@zimbra.com wrote:

--On Friday, April 12, 2013 5:43 PM +0000 quanah@OpenLDAP.org wrote:

...

Full_Name: Quanah Gibson-Mount Version: RE24 4/12/2013 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.39.181)

Also the following modify succeeds when it should fail:

zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=test zimbraID dn: dc=test,dc=com zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc

zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra dc=example zimbraId dn: dc=example,dc=com zimbraId: 0c18e59d-fdd7-40b2-abff-134b118e6cf9

zimbra@zre-ldap002:~$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra dn: dc=example,dc=com changetype: modify replace: zimbraId zimbraId: 03ccfb88-cbd8-47e5-94e7-0fb1fa60cacc

modifying entry "dc=example,dc=com"

I found it has entirely to do with brand new entries since slapd was last started. unique simply won't enforce on any data added after slapd was started. Restarting slapd results in the correct behavior.

--Quanah

--

Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration