Re: can't connect to my ldap server

Mon, 15 Nov 2021 08:13:08 -0800 

Hi Donald,

On 15/11/2021 15:43, Donald Lohr wrote:
This may or may not having anything to do with the issue you've reported.  But I have always followed the practice that the cn and uid attributes do not contain any spaces or special or punctuation characters in their value. 


CN and UID may contain any UTF-8 char (and must contain at least one 
UTF-8 char). The values are case insensitive.



Space are 'insignifiant'. If you have multiple contiguous spaces, they 
will be considered as one single space.



Actually, there is a complex processing called normalization, where a 
front and final spaces are added to each value, and where each internal 
space are replaced by exactly two spaces, no matter hwo many spaces 
there are.


For instance, the following elemenst are equivalent:

"cn=Meissa SAKHO"

or

"cn=    Meissa     SAKHO    "

or

"cn=meissa sakho"

They are internally transformed to become:

"cn= meissa  sakho "



Also note that the CN or UID attribute's value can contain any 
punctuation characters, like '=', '+' or whatever. But they must be 
escaped when used in a DN.



I won't go into a lenghtly explaination about those mechanism, just know 
that dealing with all the user cases is one of the most costly, complex 
and tedious part of a LDAP API or Server.







Especially spaces, because some login screen/boxes stop reading after 
the space.


This is a good practice.


Sadly, many applications don't properly handle input, and a lot of what 
the user types in is lost *before* being transmitted to the LDAP server.





Since your dn (dn: cn=Meissa SAKHO,ou=Users,dc=example,dc=com) value 
starts with cn= that means the cn attribute is the naming attribute of 
the dn and it is that attribute that is used when the dn is created and 
is considered to be the user's login-ID.



Well, not exactly. Actually, it's pretty orthogonal. The DN is just a 
path to the entry, the left part of a DN is call a RDN (relative 
Distinguished Name) and it does not mean one can use it to log in. It 
works because there is a userPassword attribute (in teh case of a Simple 
Bind is being used).



The RDN uniquely refers to a single entry under the path given by the 
rest of the DN (ie the DN minus the RDN, aka 
"ou=Users,dc=example,dc=com" in our example)



The BIND operation (which is used to 'log in') is checking that the 
entry associated with the provided DN has a mean to authenticate the 
user.  It may be the presence of a userPaswword, but many other 
possibilty can be used (SASL, delegated authent, Kerberos, certifcate, etc).



That being said, your answer is not totally wrong either. The CN 
attribute *must* be present in the entry as soon as it is present in the 
left part of the DN (the RDN).



In this very case, the 'login-ID' would rather be "cn=Meissa 
SAKHO+uid=msakho" (a combination of two attributes, which must both be 
present)






My practice (in your example) is to set both the cn and the uid to the 
value you've set to the uid attribute (e.g. msakho).



If the uid attribute were the naming attribute, then your dn would be: 
dn: uid=Meissa SAKHO,ou=Users,dc=example,dc=com and then the uid 
attribute would be considered the login-ID.


Don

On 11/14/21 11:16 PM, Emmanuel Lécharny wrote:

CAUTION: This email originated from outside of JMU. Do not click links 
or open attachments unless you recognize the sender and know the 
content is safe.

________________________________

Hi,

Still, the first LDAP entry (with cn: meissa sakho) should work, as CN
is case insensitive.

I'll investigate.

Thanks for the inffo !

On 14/11/2021 18:57, Meissa Sakho wrote:

I'm using the latest version:

Version: 2.0.0.v20210717-M17

I was able to make it work by changing this section:

*dn: cn=Meissa SAKHO+uid=msakho,ou=Users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: top
cn: meissa sakho
sn: sakho
title: cn=Administrator,ou=Groups,dc=example,dc=com
uid: msakho
userpassword: meissa*

*
*

*with this section:*

dn: cn=Meissa SAKHO,ou=Users,dc=example,dc=com
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: top
cn: Meissa SAKHO
description: Capt. Meissa SAKHO, R.N
givenname: Meissa
sn: Sakho
uid: msakho
mail: [email protected] <mailto:[email protected]>
userpassword: meissa*
*


The difference between the two is in the cn.

The first version worked once. I've borrowed it from this article[1]
written by one of my colleagues.

It seems like there are some differences.



[1]=https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_blog_2018_09_21_setup-2Dldap-2Dauth-2Damq-2Dconsole-23&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=Dn5z0Fep2ece_GfHn192tX9s8ttmCOPevpID9LHt6hI&e= 

<https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_blog_2018_09_21_setup-2Dldap-2Dauth-2Damq-2Dconsole-23&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=Dn5z0Fep2ece_GfHn192tX9s8ttmCOPevpID9LHt6hI&e= 
>





Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny <[email protected]
<mailto:[email protected]>> a écrit :

    Thanks.

    Will do a test with the data you've provided.

    Which is the LDAP DS version you are using ?

    On 12/11/2021 08:55, Meissa Sakho wrote:
     > Hi Emmanuel,

     > below is the complete ldif and in bold the corresponding user 
whose

     > password (uid=msakho, password=meissa) is in clear:
     > version: 1
     >
     > dn: dc=example,dc=com
     > objectclass: top
     > objectclass: domain
     > dc: example
     >
     > dn: ou=Groups,dc=example,dc=com
     > objectClass: organizationalUnit
     > objectClass: top
     > ou: Groups
     >
     >
     > dn: ou=Users,dc=example,dc=com
     > objectClass: organizationalUnit
     > objectClass: top
     > ou: Users
     >
     >
     > dn: cn=Administrator,ou=Groups,dc=example,dc=com
     > objectClass: groupOfNames
     > objectClass: top
     > cn: Administrator
     > member: cn=John+sn=Doe+uid=jdoe,ou=Users,dc=example,dc=com
     > member: cn=Elvadas NONO,ou=Users,dc=example,dc=com
     >
     > dn: cn=AMQGroup,ou=Groups,dc=example,dc=com
     > objectClass: groupOfNames
     > objectClass: top
     > cn: AMQGroup
     > member: cn=Elvadas
    Nono+sn=WOGUIA+uid=nelvadas,ou=Users,dc=example,dc=com
     > member: cn=John+sn=Doe+uid=jdoe,ou=Users,dc=example,dc=com
     > member: cn=Meissa+sn=Sakho+uid=msakho,ou=Users,dc=example,dc=com
     >
     > dn: cn=John+sn=Doe+uid=jdoe,ou=Users,dc=example,dc=com
     > objectClass: organizationalPerson
     > objectClass: person
     > objectClass: inetOrgPerson
     > objectClass: top
     > cn: John
     > sn: Doe
     > title: cn=Administrator,ou=Groups,dc=example,dc=com
     > uid: jdoe
     > userPassword: redhat
     >
     >
     > dn: cn=Elvadas NONO+uid=enonowoguia,ou=Users,dc=example,dc=com
     > objectClass: organizationalPerson
     > objectClass: person
     > objectClass: inetOrgPerson
     > objectClass: top
     > cn: elvadas nono
     > sn: Woguia
     > title: cn=Administrator,ou=Groups,dc=example,dc=com
     > uid: enonowoguia
     > userpassword::
e1NTSEF9dlMzVU95V1Bnek9JMUhreG5IV290My9jS0NxZWlGNmlDSlh1SEE9P
     >   Q==
     >
     > *dn: cn=Meissa SAKHO+uid=msakho,ou=Users,dc=example,dc=com
     > objectClass: organizationalPerson
     > objectClass: person
     > objectClass: inetOrgPerson
     > objectClass: top
     > cn: meissa sakho
     > sn: sakho
     > title: cn=Administrator,ou=Groups,dc=example,dc=com
     > uid: msakho
     > userpassword: meissa
     > *
     > *
     > *
     > Thanks
     >
     > Le ven. 12 nov. 2021 à 04:03, Emmanuel Lécharny
    <[email protected] <mailto:[email protected]>

     > <mailto:[email protected] <mailto:[email protected]>>> a 
écrit :

     >
     >     Hi,
     >

     >     can you provide the entry associated to this user (with 
password

     >     redacted, of course)?
     >
     >     Thanks !
     >
     >     On 11/11/2021 18:53, Meissa Sakho wrote:
     >      > Hello everyone,
     >      > I'm trying to connect to my Ldap DS server from ActiveMq .
     >      > The connection setting is configured via a login.config
    file like
     >     below:
     >      > activemq {
     >      >
     >      >
org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule
     >      > required
     >      >       debug=true
     >      > initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
     >      >       connectionURL="ldap://localhost:10389";
     >      > connectionUsername="uid=admin,ou=system"
     >      >       connectionPassword=secret
     >      >       connectionProtocol=s
     >      >       authentication=simple
     >      >       userBase="ou=Users,dc=example,dc=com"
     >      >       userSearchMatching="(uid={0})"
     >      >       userSearchSubtree=true
     >      >       roleBase="ou=Groups,dc=example,dc=com"
     >      >       roleName=cn
     >      >       roleSearchMatching="(member={0})"
     >      >       roleSearchSubtree=false
     >      >       reload=true
     >      >    ;
     >      >
     >      > };
     >      > I've imported a sample ldiff file and double checked that
    every user
     >      > connection is correct.
     >      > When I try to get connected via the ActiveMq admin
    console, I'm
     >     getting a
     >      > login failed error message because of a password that does
    not match.
     >      >
     >      > 2021-11-11 18:38:29,436 DEBUG
     >      >
     >
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
     >     LDAP

     >      > returned a relative name: cn=Meissa 
SAKHO+uid=msakho,ou=Users

     >      >
     >      > 2021-11-11 18:38:29,436 DEBUG
     >      >
     >
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
     >     Using

     >      > DN [cn=Meissa 
SAKHO+uid=msakho,ou=Users,dc=example,dc=com] for

     >     binding.
     >      >
     >      > 2021-11-11 18:38:29,436 DEBUG
     >      >
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
     >      > Binding the user.
     >      >
     >      > 2021-11-11 18:38:29,438 DEBUG
     >      >
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
     >      > Authentication failed for dn=cn=Meissa
     >      > SAKHO+uid=msakho,ou=Users,dc=example,dc=com
     >      >
     >      > WARN  | qtp2029780820-35 | Login failed due to: Password
    does not
     >     match for
     >      > user: msakh
     >      > When I check the password test connection via the DS
    Studio, it
     >     works fine.
     >      > I don't know what's wrong and where.
     >      > Any idea?
     >      >
     >
     >     --

     >     *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 
06200 NICE

     >     T. +33 (0)4 89 97 36 50
     >     P. +33 (0)6 08 33 32 61
     > [email protected] <mailto:[email protected]>
    <mailto:[email protected]
<mailto:[email protected]>>

     > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.busit.com_&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=yb7kN1ISQOYIJPyK7vA1SvBKORzq-YzFAtU4pMuScAo&e= 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.busit.com_&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=yb7kN1ISQOYIJPyK7vA1SvBKORzq-YzFAtU4pMuScAo&e= 
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.busit.com_&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=yb7kN1ISQOYIJPyK7vA1SvBKORzq-YzFAtU4pMuScAo&e= 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.busit.com_&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=yb7kN1ISQOYIJPyK7vA1SvBKORzq-YzFAtU4pMuScAo&e= 
>>

     >
     >
---------------------------------------------------------------------
     >     To unsubscribe, e-mail:
[email protected]
<mailto:[email protected]>
     >     <mailto:[email protected]
<mailto:[email protected]>>
     >     For additional commands, e-mail:
[email protected] <mailto:[email protected]>
     >     <mailto:[email protected]
<mailto:[email protected]>>
     >

    --
    *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
    T. +33 (0)4 89 97 36 50
    P. +33 (0)6 08 33 32 61
[email protected] <mailto:[email protected]>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.busit.com_&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=yb7kN1ISQOYIJPyK7vA1SvBKORzq-YzFAtU4pMuScAo&e= 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.busit.com_&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=yb7kN1ISQOYIJPyK7vA1SvBKORzq-YzFAtU4pMuScAo&e= 
>




--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61

[email protected] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.busit.com_&d=DwIDaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c&s=yb7kN1ISQOYIJPyK7vA1SvBKORzq-YzFAtU4pMuScAo&e= 



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
[email protected] https://www.busit.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]























					Reply via email to