Hi there,
I've followed the docs (and some forums), and made these modifications:
(OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
dn: cn=module,cn=config cn: module objectClass: olcModuleList olcModulePath: /usr/lib/ldap/ olcModuleLoad: unique.la
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueAttribute: uid olcUniqueAttribute: mail olcUniqueAttribute: uidNumber olcUniqueAttribute: sn olcUniqueAttribute: cn
but I still can set the mail attribute as same e-mail address for two different users.
I've tried this config too:
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueUri: ldap:///?uid?sub? olcUniqueUri: ldap:///?mail?sub? olcUniqueUri: ldap:///?uidNumber?sub? olcUniqueUri: ldap:///?sn?sub? olcUniqueUri: ldap:///?cn?sub?
What em'I missing?
Thanks,
a.
On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
I've followed the docs (and some forums), and made these modifications:
(OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
but I still can set the mail attribute as same e-mail address for two different users.
It should just work. Which OpenLDAP version and builds are you using?
Wild guess: Did you also add an eq-index for the unique attributes *and* re-index the DB?
Ciao, Michael.
Michael Ströder wrote:
On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
I've followed the docs (and some forums), and made these modifications:
(OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
but I still can set the mail attribute as same e-mail address for two different users.
It should just work. Which OpenLDAP version and builds are you using?
Wild guess: Did you also add an eq-index for the unique attributes *and* re-index the DB?
(Note - adding an index by LDAPmodify'ing cn=config automatically reindexes the DB...)
Hi there,
On Wed, Aug 08, 2018 at 11:43:56AM +0100, Howard Chu wrote:
Michael Ströder wrote:
On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
I've followed the docs (and some forums), and made these modifications:
(OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
but I still can set the mail attribute as same e-mail address for two different users.
It should just work. Which OpenLDAP version and builds are you using?
Wild guess: Did you also add an eq-index for the unique attributes *and* re-index the DB?
(Note - adding an index by LDAPmodify'ing cn=config automatically reindexes the DB...)
so, I just need to add the index, like
dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcDbIndex - add: olcDbIndex olcDbIndex: objectClass eq - ... existing indexes... - add: olcDbIndex olcDbIndex: mail eq - ... other unique indexes...
?
thanks,
a.
On 8/8/18 12:43 PM, Howard Chu wrote:
Michael Ströder wrote:
On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
I've followed the docs (and some forums), and made these modifications:
(OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
but I still can set the mail attribute as same e-mail address for two different users.
It should just work. Which OpenLDAP version and builds are you using?
Wild guess: Did you also add an eq-index for the unique attributes *and* re-index the DB?
(Note - adding an index by LDAPmodify'ing cn=config automatically reindexes the DB...)
Yes, I know. But I vaguely remember that there were some issues with that in older versions. The original poster did not mention the OpenLDAP builds/version used.
Ciao, Michael.
Michael Ströder wrote:
On 8/8/18 12:43 PM, Howard Chu wrote:
Michael Ströder wrote:
On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
I've followed the docs (and some forums), and made these modifications:
(OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
but I still can set the mail attribute as same e-mail address for two different users.
It should just work. Which OpenLDAP version and builds are you using?
Wild guess: Did you also add an eq-index for the unique attributes *and* re-index the DB?
(Note - adding an index by LDAPmodify'ing cn=config automatically reindexes the DB...)
Yes, I know.
Of course. The note was for Ervin and others' benefit.
Hi Michael,
thanks,
On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
On 8/8/18 11:25 AM, Ervin Hegedüs wrote:
I've followed the docs (and some forums), and made these modifications:
(OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness)
but I still can set the mail attribute as same e-mail address for two different users.
It should just work. Which OpenLDAP version and builds are you using?
2.4.44 (Debian 9 - exactly: 2.4.44+dfsg-5+deb9u1)
Wild guess: Did you also add an eq-index for the unique attributes
no,
(or yes, at my very first try)
*and* re-index the DB?
no. (never)
Now I checked these infos in docs page and manual, but didn't found... In documentation the essential info is that I have to load the overlay, and set the olcUniqueURI(s).
I'll try to do these steps...
thanks again,
a.
Hi Michael,
On Wed, Aug 08, 2018 at 12:51:53PM +0200, Michael Ströder wrote:
On 8/8/18 12:46 PM, Ervin Hegedüs wrote:
On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
*and* re-index the DB?
no. (never)
Please check whether the search (mail=foo@example.com) really returns the existing entries.
# slapindex -n 1 ...
# ... modified the entry's mail to an existing one...
# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w "mail=airween@company.hu" | grep ^mail ldap_initialize( ldaps://dev-ldap-01:636/??base ) Enter LDAP Password: filter: mail=airween@company.hu requesting: All userApplication attributes mail: airween@company.hu mail: airween@company.hu
(there are two entries)
# ... rollback the modification ...
# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w "mail=airween@company.hu" | grep ^mail ldap_initialize( ldaps://dev-ldap-01:636/??base ) Enter LDAP Password: filter: mail=airween@company.hu requesting: All userApplication attributes mail: airween@company.hu
(there is only one entry)
relevant output of 'slapcat -b cn=config':
dn: cn=module{2},cn=config objectClass: olcModuleList cn: module{2} olcModulePath: /usr/lib/ldap/ olcModuleLoad: {0}unique.la structuralObjectClass: olcModuleList
...
dn: olcOverlay={1}unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {1}unique olcUniqueURI: ldap:///?uid?sub? olcUniqueURI: ldap:///?mail?sub? olcUniqueURI: ldap:///?uidNumber?sub? olcUniqueURI: ldap:///?sn?sub? olcUniqueURI: ldap:///?cn?sub? olcUniqueURI: ldaps:///?uid?sub? olcUniqueURI: ldaps:///?mail?sub? olcUniqueURI: ldaps:///?uidNumber?sub? olcUniqueURI: ldaps:///?sn?sub? olcUniqueURI: ldaps:///?cn?sub?
...
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hu ... olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: mail eq olcDbIndex: sn eq
Thanks,
a.
Hi there,
sorry for the reply,
On Wed, Aug 08, 2018 at 01:26:28PM +0200, Ervin Hegedüs wrote:
Hi Michael,
On Wed, Aug 08, 2018 at 12:51:53PM +0200, Michael Ströder wrote:
On 8/8/18 12:46 PM, Ervin Hegedüs wrote:
On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
*and* re-index the DB?
no. (never)
Please check whether the search (mail=foo@example.com) really returns the existing entries.
# slapindex -n 1 ...
# ... modified the entry's mail to an existing one...
# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w "mail=airween@company.hu" | grep ^mail ldap_initialize( ldaps://dev-ldap-01:636/??base ) Enter LDAP Password: filter: mail=airween@company.hu requesting: All userApplication attributes mail: airween@company.hu mail: airween@company.hu
(there are two entries)
# ... rollback the modification ...
# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "admin..." -w "mail=airween@company.hu" | grep ^mail ldap_initialize( ldaps://dev-ldap-01:636/??base ) Enter LDAP Password: filter: mail=airween@company.hu requesting: All userApplication attributes mail: airween@company.hu
(there is only one entry)
relevant output of 'slapcat -b cn=config':
dn: cn=module{2},cn=config objectClass: olcModuleList cn: module{2} olcModulePath: /usr/lib/ldap/ olcModuleLoad: {0}unique.la structuralObjectClass: olcModuleList
...
dn: olcOverlay={1}unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {1}unique olcUniqueURI: ldap:///?uid?sub? olcUniqueURI: ldap:///?mail?sub? olcUniqueURI: ldap:///?uidNumber?sub? olcUniqueURI: ldap:///?sn?sub? olcUniqueURI: ldap:///?cn?sub? olcUniqueURI: ldaps:///?uid?sub? olcUniqueURI: ldaps:///?mail?sub? olcUniqueURI: ldaps:///?uidNumber?sub? olcUniqueURI: ldaps:///?sn?sub? olcUniqueURI: ldaps:///?cn?sub?
...
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hu ... olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: mail eq olcDbIndex: sn eq
any idea?
Thanks,
a.
--On Thursday, August 09, 2018 9:51 AM +0200 Ervin Hegedüs airween@gmail.com wrote:
olcUniqueURI: ldap:///?uid?sub? olcUniqueURI: ldap:///?mail?sub? olcUniqueURI: ldap:///?uidNumber?sub? olcUniqueURI: ldap:///?sn?sub? olcUniqueURI: ldap:///?cn?sub? olcUniqueURI: ldaps:///?uid?sub? olcUniqueURI: ldaps:///?mail?sub? olcUniqueURI: ldaps:///?uidNumber?sub? olcUniqueURI: ldaps:///?sn?sub? olcUniqueURI: ldaps:///?cn?sub?
Using "ldaps://" here is invalid. These are internal searches that don't use the LDAP protocol.
One thing you've not shown in your configurations is whether or not the {1}mdb,cn=config DB has a rootdn configured for that database instance. As noted in the man page, a rootdn is required on the specific database instance for the overlay to function:
" The search is performed using the rootdn of the database, to avoid issues with ACLs preventing the overlay from seeing all of the relevant data. As such, the database must have a rootdn configured."
Additionaly, you haven't noted how you are making the modifications to add the duplicate entries. Again, as noted in the man page:
" Replication and operations with manageDsaIt control are allowed to bypass this enforcement. It is therefore important that all servers accepting writes have this overlay configured in order to maintain uniqueness in a replicated DIT.."
So it is possible the LDAP client you are using to make the modifications is setting the manageDsaIT control.
Warm regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah,
thanks for your reply,
On Wed, Aug 29, 2018 at 09:17:25AM -0700, Quanah Gibson-Mount wrote:
--On Thursday, August 09, 2018 9:51 AM +0200 Ervin Hegedüs airween@gmail.com wrote:
olcUniqueURI: ldap:///?uid?sub? olcUniqueURI: ldap:///?mail?sub? olcUniqueURI: ldap:///?uidNumber?sub? olcUniqueURI: ldap:///?sn?sub? olcUniqueURI: ldap:///?cn?sub?
I've removed these directives:
olcUniqueURI: ldaps:///?uid?sub? olcUniqueURI: ldaps:///?mail?sub? olcUniqueURI: ldaps:///?uidNumber?sub? olcUniqueURI: ldaps:///?sn?sub? olcUniqueURI: ldaps:///?cn?sub?
Using "ldaps://" here is invalid. These are internal searches that don't use the LDAP protocol.
thanks,
One thing you've not shown in your configurations is whether or not the {1}mdb,cn=config DB has a rootdn configured for that database instance. As noted in the man page, a rootdn is required on the specific database instance for the overlay to function:
" The search is performed using the rootdn of the database, to avoid issues with ACLs preventing the overlay from seeing all of the relevant data. As such, the database must have a rootdn configured."
you think about this?
slapcat -b cn=config | less ...
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hu ... olcRootDN: cn=admin,dc=hu ...
Additionaly, you haven't noted how you are making the modifications to add the duplicate entries. Again, as noted in the man page:
" Replication and operations with manageDsaIt control are allowed to bypass this enforcement. It is therefore important that all servers accepting writes have this overlay configured in order to maintain uniqueness in a replicated DIT.."
So it is possible the LDAP client you are using to make the modifications is setting the manageDsaIT control.
I'm using jXplorer, I didn't found any manageDsaIt settings, so I assume that it doesn't support, perhaps I can't bypass the enforcement - but may be I'm wrong.
The unique key constraint still doesn't work.
Thanks again for your help,
a.
--On Thursday, August 30, 2018 10:36 AM +0200 Ervin Hegedüs airween@gmail.com wrote:
I'm using jXplorer, I didn't found any manageDsaIt settings, so I assume that it doesn't support, perhaps I can't bypass the enforcement - but may be I'm wrong.
The unique key constraint still doesn't work.
Start with the command line ldapmodify binary instead. jxplorer does in fact set the manageDSAIT flag on some operations.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Thursday, August 30, 2018 7:31 AM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
--On Thursday, August 30, 2018 10:36 AM +0200 Ervin Hegedüs airween@gmail.com wrote:
I'm using jXplorer, I didn't found any manageDsaIt settings, so I assume that it doesn't support, perhaps I can't bypass the enforcement - but may be I'm wrong.
The unique key constraint still doesn't work.
Start with the command line ldapmodify binary instead. jxplorer does in fact set the manageDSAIT flag on some operations.
In fact, jxplorer causing problems with the unique overlay because it *always* sets manageDSAIT has been discussed in the past:
http://www.openldap.org/lists/openldap-technical/201307/msg00213.html
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi Quanah,
On Thu, Aug 30, 2018 at 06:43:03AM -0700, Quanah Gibson-Mount wrote:
--On Thursday, August 30, 2018 7:31 AM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
--On Thursday, August 30, 2018 10:36 AM +0200 Ervin Hegedüs airween@gmail.com wrote:
I'm using jXplorer, I didn't found any manageDsaIt settings, so I assume that it doesn't support, perhaps I can't bypass the enforcement - but may be I'm wrong.
The unique key constraint still doesn't work.
Start with the command line ldapmodify binary instead. jxplorer does in fact set the manageDSAIT flag on some operations.
In fact, jxplorer causing problems with the unique overlay because it *always* sets manageDSAIT has been discussed in the past:
http://www.openldap.org/lists/openldap-technical/201307/msg00213.html
ah, thanks so much - I'll try the ldapmodify, and will refer.
Thanks,
a.
Hi Quanah,
On Thu, Aug 30, 2018 at 06:31:06AM -0700, Quanah Gibson-Mount wrote:
--On Thursday, August 30, 2018 10:36 AM +0200 Ervin Hegedüs airween@gmail.com wrote:
I'm using jXplorer, I didn't found any manageDsaIt settings, so I assume that it doesn't support, perhaps I can't bypass the enforcement - but may be I'm wrong.
The unique key constraint still doesn't work.
Start with the command line ldapmodify binary instead. jxplorer does in fact set the manageDSAIT flag on some operations.
so, many thanks for your helps, the native ldapmodify works as well:
# ldapmodify -D "..." -w ... -f modify.ldif modifying entry "dn: uid=airween,ou=Users,ou=Administrator,dc=service,dc=customer,dc=hu" ldap_modify: Constraint violation (19) additional info: some attributes not unique
I'll check the PHP and Python API's, what do I need to check to avoid the manageDsaIt.
Thanks for all folks,
a.
Apache Directory Studio works as well as JExplorer and has ManageDsaIT controls. The version you download needs to match the bit-rate of the Java Runtime Environment (32 or 64-bit) you have installed.
http://directory.apache.org/studio/
Jason Trupp Symas Corporation (855) LDAP-GUY
-----Original Message----- From: openldap-technical openldap-technical-bounces@openldap.org On Behalf Of Ervin Hegedüs Sent: Thursday, August 30, 2018 2:36 AM To: Quanah Gibson-Mount quanah@symas.com Cc: Michael Ströder michael@stroeder.com; openldap-technical@openldap.org Subject: Re: Unique overlay confusing
Hi Quanah,
thanks for your reply,
On Wed, Aug 29, 2018 at 09:17:25AM -0700, Quanah Gibson-Mount wrote:
--On Thursday, August 09, 2018 9:51 AM +0200 Ervin Hegedüs airween@gmail.com wrote:
olcUniqueURI: ldap:///?uid?sub? olcUniqueURI: ldap:///?mail?sub? olcUniqueURI: ldap:///?uidNumber?sub? olcUniqueURI: ldap:///?sn?sub? olcUniqueURI: ldap:///?cn?sub?
I've removed these directives:
olcUniqueURI: ldaps:///?uid?sub? olcUniqueURI: ldaps:///?mail?sub? olcUniqueURI: ldaps:///?uidNumber?sub? olcUniqueURI: ldaps:///?sn?sub? olcUniqueURI: ldaps:///?cn?sub?
Using "ldaps://" here is invalid. These are internal searches that don't use the LDAP protocol.
thanks,
One thing you've not shown in your configurations is whether or not the {1}mdb,cn=config DB has a rootdn configured for that database instance. As noted in the man page, a rootdn is required on the specific database instance for the overlay to function:
" The search is performed using the rootdn of the database, to avoid issues with ACLs preventing the overlay from seeing all of the relevant data. As such, the database must have a rootdn configured."
you think about this?
slapcat -b cn=config | less ...
dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hu ... olcRootDN: cn=admin,dc=hu ...
Additionaly, you haven't noted how you are making the modifications to add the duplicate entries. Again, as noted in the man page:
" Replication and operations with manageDsaIt control are allowed to bypass this enforcement. It is therefore important that all servers accepting writes have this overlay configured in order to maintain uniqueness in a replicated DIT.."
So it is possible the LDAP client you are using to make the modifications is setting the manageDsaIT control.
I'm using jXplorer, I didn't found any manageDsaIt settings, so I assume that it doesn't support, perhaps I can't bypass the enforcement - but may be I'm wrong.
The unique key constraint still doesn't work.
Thanks again for your help,
a.
Hi,
sorry for the re-post, but could anybody helps me, how can I fix this problem?
On Wed, Aug 08, 2018 at 12:51:53PM +0200, Michael Ströder wrote:
On 8/8/18 12:46 PM, Ervin Hegedüs wrote:
On Wed, Aug 08, 2018 at 12:36:06PM +0200, Michael Ströder wrote:
*and* re-index the DB?
no. (never)
Please check whether the search (mail=foo@example.com) really returns the existing entries.
# slapcat -b cn=config | grep -i olcdbindex olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: mail eq olcDbIndex: sn eq
# slapcat -b cn=config | grep -i overlay dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig olcOverlay: {0}syncprov dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}syncprov dn: olcOverlay={1}unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig olcOverlay: {1}unique
# ldapsearch -vvv -x -H ldaps://dev-ldap-01:636 -b "dc=hu" -D "UID=_srvcppm,OU=Users,ou=_srv,dc=hu" -W "(mail=airween@company.hu)" ... # airween, Users, Administrator, service.customer.hu dn: uid=airween,ou=Users,ou=Administrator,dc=service,dc=customer,dc=hu uidNumber: 20001 gidNumber: 10000 ... sn: airween mail: airween@company.hu
# dgw_airween, Users, Partner, othercustomer.hu dn: uid=dgw_airween,ou=Users,ou=Partner,dc=othercustomer,dc=hu uidNumber: 11297 gidNumber: 21297 ... sn: dgw_airween mail: airween@company.hu
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
slapindex was finished (before I searched above...):
# service slapd stop # slapindex -F /etc/ldap/slapd.d -n 1 mail sn cn uidNumber uid
WARNING! Runnig as root! There's a fair chance slapd will fail to start. Check file permissions!
# chown -R openldap:openldap /etc/ldap/slapd.d && chown -R openldap:openldap /var/lib/ldap # service slapd start ...
Thanks,
a.
openldap-technical@openldap.org
-
Ervin Hegedüs -
Howard Chu -
Jason Trupp -
Michael Ströder -
Quanah Gibson-Mount