Hi everyone,
I'm new to the ldap stuff, therefore sorry if this is a silly question. My openldap (slapd) version is 2.4.28. To manage openldap I'm using phpldapadmin. I'm using a third party software which relies on ldap to manage users.
I've added a test user to ldap via phpldapadmin. The 3rd party software tries to modify/add an object via the following bind:
slapd[19030]: conn=1435 fd=18 ACCEPT from IP=X.X.X.X:35541 (IP=0.0.0.0:389) slapd[19030]: conn=1435 op=0 BIND dn="cn=admin,dc=dmp,dc=..." method=128 slapd[19030]: conn=1435 op=0 BIND dn="cn=admin,dc=dmp,dc=..." mech=SIMPLE ssf=0 slapd[19030]: conn=1435 op=0 RESULT tag=97 err=0 text= slapd[19030]: conn=1435 op=1 MOD dn="uid=test1003,ou=users,dc=dmp,dc=..." slapd[19030]: conn=1435 op=1 MOD attr=objectclass slapd[19030]: conn=1435 op=1 RESULT tag=103 err=32 text= slapd[19030]: conn=1435 fd=18 closed (connection lost)
This fails because it tries to accomplish this by using dn="uid=...", but as shown in phpldapadmin the dn is cn=Test Testuser,ou=users,dc=dmp,dc=... Therefore the distinguished name for dn="uid=...,ou=users,dc=dmp,dc=..." doesn't exist (the user has a uid of course). Therefore my question is, is there a possibility to change / to configure openldap to use / allow the uid instead of the cn? Or did I something wrong? So far I couldn't find any information about this. Any help is welcome and I would really appreciate this :)
Best regards and have a nice weekend! Dennis Wehrle
Am Fri, 30 Jan 2015 18:36:29 +0100 schrieb Dennis openldap@wehrle.it:
Hi everyone,
I'm new to the ldap stuff, therefore sorry if this is a silly question. My openldap (slapd) version is 2.4.28. To manage openldap I'm using phpldapadmin. I'm using a third party software which relies on ldap to manage users.
I've added a test user to ldap via phpldapadmin. The 3rd party software tries to modify/add an object via the following bind:
slapd[19030]: conn=1435 fd=18 ACCEPT from IP=X.X.X.X:35541 (IP=0.0.0.0:389) slapd[19030]: conn=1435 op=0 BIND dn="cn=admin,dc=dmp,dc=..." method=128 slapd[19030]: conn=1435 op=0 BIND dn="cn=admin,dc=dmp,dc=..." mech=SIMPLE ssf=0 slapd[19030]: conn=1435 op=0 RESULT tag=97 err=0 text= slapd[19030]: conn=1435 op=1 MOD dn="uid=test1003,ou=users,dc=dmp,dc=..." slapd[19030]: conn=1435 op=1 MOD attr=objectclass slapd[19030]: conn=1435 op=1 RESULT tag=103 err=32 text= slapd[19030]: conn=1435 fd=18 closed (connection lost)
This fails because it tries to accomplish this by using dn="uid=...", but as shown in phpldapadmin the dn is cn=Test Testuser,ou=users,dc=dmp,dc=... Therefore the distinguished name for dn="uid=...,ou=users,dc=dmp,dc=..." doesn't exist (the user has a uid of course). Therefore my question is, is there a possibility to change / to configure openldap to use / allow the uid instead of the cn? Or did I something wrong? So far I couldn't find any information about this. Any help is welcome and I would really appreciate this :)
You are free in designing a directory information tree, so a DN uid=someID,ou=users,.. is valid, you may read http://www.openldap.org/doc/admin24/
-Dieter
On Fri, Jan 30, 2015 at 06:36:29PM +0100, Dennis wrote:
This fails because it tries to accomplish this by using dn="uid=...", but as shown in phpldapadmin the dn is cn=Test Testuser,ou=users,dc=dmp,dc=... Therefore the distinguished name for dn="uid=...,ou=users,dc=dmp,dc=..." doesn't exist (the user has a uid of course). Therefore my question is, is there a possibility to change / to configure openldap to use / allow the uid instead of the cn?
You can use any locally-unique attribute value in a DN, but each entry can only have one DN. So: you can change your DIT design to use "uid=...,ou=users,dc=dmp,dc=..." if you want to, but then anything that is assuming the existing DN structure wil break!
In this case I would say that your management application is at fault. It should not be assuming that it can make a DN by tacking the UID value onto a fixed suffix. If all it knows is the UID then it should first search for the entry using the UID in the search filter. The search result will include the DN of any entry that is found, so it is then easy to work on that entry.
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Dennis -
Dieter Klünter