Hello,
I'm trying to enable unique overlay to enforce uniqueness of uid and mail attributes with no luck. My server is debian 7 based with packaged slapd (2.4.31]. Here's the config for the unique overlay :
DN: cn=module{1},cn=config objectClass: olcModuleList objectClass: olcConfig objectClass: top cn: module{1} olcModuleLoad: {0}memberof olcModuleLoad: {1}refint olcModuleLoad: {2}unique olcModulePath: /usr/lib/ldap
DN: olcOverlay={4}unique,olcDatabase={1}hdb,cn=config objectClass: olcUniqueConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {4}unique olcUniqueURI: ldap:///?mail?sub olcUniqueURI: ldap:///?uid?sub
assuming the configuration is good, I've tried to create 2 entries : uid=test,ou=people,dc=mydomain,dc=com and uid=test2,ou=people,dc=mydomain,dc=com with the same mail : test@mydomain.com => created without error.
change mail to test2@mydomain.com on entry uid=test2,ou=people,dc=mydomain,dc=com works going back to test@mydomain.com => no error
The first time, I've used the main administrative account. So I created a sub administrator account, changed the ACLs, fine. Deleted the two entries, recreated the two entries with the same mail without error.
I've tried to put slapd in debug mode, the only ting I've noticed is :
51f7df1e >>> dnPrettyNormal: <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e <<< dnPrettyNormal: <uid=test2,ou=people,dc=mydomain,dc=com>, <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e ==> unique_modify <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e *unique_modify: administrative bypass, skipping* 51f7df1e bdb_dn2entry("uid=test2,ou=people,dc=mydomain,dc=com") 51f7df1e bdb_entry_get: rc=0
If someone has a clue...
Rgds
Philippe MARASSE wrote:
I'm trying to enable unique overlay to enforce uniqueness of uid and mailattributes with no luck. [..] The first time, I've used the main administrative account. So I created a sub administrator account, changed the ACLs, fine. Deleted the two entries, recreated the two entries with the same mail without error.
I've tried to put slapd in debug mode, the only ting I've noticed is :
51f7df1e >>> dnPrettyNormal: <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e <<< dnPrettyNormal: <uid=test2,ou=people,dc=mydomain,dc=com>, <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e ==> unique_modify <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e *unique_modify: administrative bypass, skipping* 51f7df1e bdb_dn2entry("uid=test2,ou=people,dc=mydomain,dc=com") 51f7df1e bdb_entry_get: rc=0
If someone has a clue...
It's a bit unclear what you're really doing. There are/were some bugs in slapo-unique but not sure whether you're hitting them without seeing *exactly* how you perform the client operations.
Maybe you could try to provide the LDIF input data and commands you're using. Which client? Which options?
AFAICS in the source the bypass message is only written to log in case of ManageDSAIT control being used during ldapadd/ldapmodify. You should really understand what's the effect of LDAPv3 extended controls before using them.
Ciao, Michael.
Thanks for your answer,
Le 30/07/2013 18:55, Michael Ströder a écrit :
Philippe MARASSE wrote:
I'm trying to enable unique overlay to enforce uniqueness of uid and mailattributes with no luck. [..] The first time, I've used the main administrative account. So I created a sub administrator account, changed the ACLs, fine. Deleted the two entries, recreated the two entries with the same mail without error.
I've tried to put slapd in debug mode, the only ting I've noticed is :
51f7df1e >>> dnPrettyNormal: <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e <<< dnPrettyNormal: <uid=test2,ou=people,dc=mydomain,dc=com>, <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e ==> unique_modify <uid=test2,ou=people,dc=mydomain,dc=com> 51f7df1e *unique_modify: administrative bypass, skipping* 51f7df1e bdb_dn2entry("uid=test2,ou=people,dc=mydomain,dc=com") 51f7df1e bdb_entry_get: rc=0
If someone has a clue...
It's a bit unclear what you're really doing. There are/were some bugs in slapo-unique but not sure whether you're hitting them without seeing *exactly* how you perform the client operations.
I've tested : - adding an entry with non-unique mail attribute - modifying an entry to make mail non unique
Maybe you could try to provide the LDIF input data and commands you're using. Which client?
jxplorer
Which options?
A good question indeed ! I'm using jxplorer from stock install without customization.
AFAICS in the source the bypass message is only written to log in case of ManageDSAIT control being used during ldapadd/ldapmodify. You should really understand what's the effect of LDAPv3 extended controls before using them.
Hmmm, interesting, if ManageDSAIT option is used, I'm not yet aware of that. I'll track jxplorer behavior today.
May should I test with another ldap tool ?
Many thanks. Rgds.
Philippe MARASSE wrote:
Le 30/07/2013 18:55, Michael Ströder a écrit :
Which client?
jxplorer
Which options?
A good question indeed ! I'm using jxplorer from stock install without customization.
AFAICS in the source the bypass message is only written to log in case of ManageDSAIT control being used during ldapadd/ldapmodify. You should really understand what's the effect of LDAPv3 extended controls before using them.
Hmmm, interesting, if ManageDSAIT option is used, I'm not yet aware of that. I'll track jxplorer behavior today.
I vaguely remember JNDI using the ManageDSAIT control by default.
May should I test with another ldap tool ?
When reporting something here which you suspect to be a bug please try to reproduce it with OpenLDAP's command-line tools (ldapadd, ldapmodify, etc.).
Interactive UI tools are mainly a matter of taste. Being the author of web2ldap I'm biased anyway.
Ciao, Michael.
Le 31/07/2013 09:48, Michael Ströder a écrit :
Philippe MARASSE wrote:
Le 30/07/2013 18:55, Michael Ströder a écrit :
Which client?
jxplorer
Which options?
A good question indeed ! I'm using jxplorer from stock install without customization.
AFAICS in the source the bypass message is only written to log in case of ManageDSAIT control being used during ldapadd/ldapmodify. You should really understand what's the effect of LDAPv3 extended controls before using them.
Hmmm, interesting, if ManageDSAIT option is used, I'm not yet aware of that. I'll track jxplorer behavior today.
I vaguely remember JNDI using the ManageDSAIT control by default.
It seems to be true... I've watched modify queries done by jxplorer : all of these have ManageDSAIT control enabled. After a little googling, it seems that the ManageDSAIT control is related to how JNDI is told to handle referrals. with Ldap browser, another java tool, ManageDSAIT is not enabled by default.
May should I test with another ldap tool ?
When reporting something here which you suspect to be a bug please try to reproduce it with OpenLDAP's command-line tools (ldapadd, ldapmodify, etc.).
I took some time to write LDIF : with ldapadd/ldapmodify, I do have as expected : Constraint violation (19), additional info: some attributes not unique, great :-).
Interactive UI tools are mainly a matter of taste. Being the author of web2ldap I'm biased anyway.
Thank you.
Rgds.
Philippe MARASSE wrote:
Le 31/07/2013 09:48, Michael Ströder a écrit :
I vaguely remember JNDI using the ManageDSAIT control by default.
It seems to be true... I've watched modify queries done by jxplorer : all of these have ManageDSAIT control enabled. After a little googling, it seems that
the ManageDSAIT control is related to how JNDI is told to handle referrals. with Ldap browser, another java tool, ManageDSAIT is not enabled by default.
Well, it seems JNDI is not really capable of handling referrals / search continuations. And using this control is JNDI's work-around to suppress them.
Ciao, Michael.
--On Wednesday, July 31, 2013 8:26 PM +0200 Michael Ströder michael@stroeder.com wrote:
Philippe MARASSE wrote:
Le 31/07/2013 09:48, Michael Ströder a écrit :
I vaguely remember JNDI using the ManageDSAIT control by default.
It seems to be true... I've watched modify queries done by jxplorer : all of these have ManageDSAIT control enabled. After a little googling, it seems that
the ManageDSAIT control is related to how JNDI is told to handle referrals. with Ldap browser, another java tool, ManageDSAIT is not enabled by default.
Well, it seems JNDI is not really capable of handling referrals / search continuations. And using this control is JNDI's work-around to suppress them.
JNDI should just be avoided.
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Le 31/07/2013 20:46, Quanah Gibson-Mount a écrit :
--On Wednesday, July 31, 2013 8:26 PM +0200 Michael Ströder michael@stroeder.com wrote:
Philippe MARASSE wrote:
Le 31/07/2013 09:48, Michael Ströder a écrit :
I vaguely remember JNDI using the ManageDSAIT control by default.
It seems to be true... I've watched modify queries done by jxplorer : all of these have ManageDSAIT control enabled. After a little googling, it seems that
the ManageDSAIT control is related to how JNDI is told to handle referrals. with Ldap browser, another java tool, ManageDSAIT is not enabled by default.
Well, it seems JNDI is not really capable of handling referrals / search continuations. And using this control is JNDI's work-around to suppress them.
JNDI should just be avoided.
So I should use ldaptive with another provider instead of Spring LDAP (which relies on JNDI if I'm not mistaken) ?
Rgds.
--On Friday, August 02, 2013 4:46 PM +0200 Philippe MARASSE philippe.marasse@ch-poitiers.fr wrote:
Le 31/07/2013 20:46, Quanah Gibson-Mount a écrit :
--On Wednesday, July 31, 2013 8:26 PM +0200 Michael Ströder michael@stroeder.com wrote:
Philippe MARASSE wrote:
Le 31/07/2013 09:48, Michael Ströder a écrit :
I vaguely remember JNDI using the ManageDSAIT control by default.
It seems to be true... I've watched modify queries done by jxplorer : all of these have ManageDSAIT control enabled. After a little googling, it seems that
the ManageDSAIT control is related to how JNDI is told to handle referrals. with Ldap browser, another java tool, ManageDSAIT is not enabled by default.
Well, it seems JNDI is not really capable of handling referrals / search continuations. And using this control is JNDI's work-around to suppress them.
JNDI should just be avoided.
So I should use ldaptive with another provider instead of Spring LDAP (which relies on JNDI if I'm not mistaken) ?
We use the UnboundID SDK @ Zimbra.
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi,
I am also trying to setup the unique overlay and I must admit:
I can't belive what I am reading right now! Can somebody enlighten me, please?
As far as I understand the unique overlay should prevent clients to accidently or willfully set two attributes with the same name. Now I find a switch in it that can be used by any client to disable the unique overlay completely!?!
Is there a way to forbid the use of ManageDsaIt to the openldap client that I did not found yet? Otherwise we should reconsider that code, if there is a way to forbid ManageDsaIt it should IMHO be mentioned in the slapo-unique manpage.
Not to use an evil client is no option to me.
regards Hans
--On Tuesday, November 05, 2013 5:42 PM +0100 Hans Freitag zem@fnordpol.de wrote:
Not to use an evil client is no option to me.
Don't give the user manage privileges...
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Hi Quanah,
On Tue, Nov 05, 2013 at 10:07:14AM -0800, Quanah Gibson-Mount wrote:
--On Tuesday, November 05, 2013 5:42 PM +0100 Hans Freitag zem@fnordpol.de wrote:
Not to use an evil client is no option to me.
Don't give the user manage privileges...
My user only has write privileges not manage privileges. The only manage privilege in my setup is the rootdn (by default) which is not used to add entrys.
regards
Hans
--On Tuesday, November 05, 2013 7:52 PM +0100 Hans Freitag zem@fnordpol.de wrote:
Hi Quanah,
On Tue, Nov 05, 2013 at 10:07:14AM -0800, Quanah Gibson-Mount wrote:
--On Tuesday, November 05, 2013 5:42 PM +0100 Hans Freitag zem@fnordpol.de wrote:
Not to use an evil client is no option to me.
Don't give the user manage privileges...
My user only has write privileges not manage privileges. The only manage privilege in my setup is the rootdn (by default) which is not used to add entrys.
Yes, you are correct. manage and manageDSAit are not the same thing. :/
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, November 05, 2013 5:42 PM +0100 Hans Freitag zem@fnordpol.de wrote:
Not to use an evil client is no option to me.
Don't give the user manage privileges...
Doesn't that affect rather the use of Relax Rules control (formerly known as Manage DIT control)?
I think the (ab)use of Manage DSA IT control to circumvent constraint(s) is somewhat historic because at that time in the past [1] was not available yet. This resulted in a control-against-constraint mess.
It should be consequently replaced by applying Relax Rules control including properly checking the manage privilege.
BTW: Still the OID of the Relax Rules control contains this experimental OID *.666.* cruft. Maybe it's the time to proceed with the draft and define a proper OID.
How about discussing this at LDAPcon in Paris? (might also fit in my presentation...)
Ciao, Michael.
openldap-technical@openldap.org
-
Hans Freitag -
Michael Ströder -
Philippe MARASSE -
Quanah Gibson-Mount