subject:"Re\: can't connect to my ldap server"

Re: can't connect to my ldap server

2021-11-15 Thread Emmanuel Lécharny





On 15/11/2021 22:05, Meissa Sakho wrote:
Emmanuel, Given that it's a bug, are you going to fill a jira 
although there is a workaround?


I have already filled a JIRA, and I'm working on a fix 
(https://issues.apache.org/jira/browse/DIRAPI-380)





Le lun. 15 nov. 2021 à 21:30, Meissa Sakho > a écrit :


I've tried your hint and it works.
The question is: Why do we have such regression?
In the older version, it worked as defined in my first post and as
described in this article
https://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#


Le lun. 15 nov. 2021 à 17:52, Emmanuel Lécharny mailto:elecha...@gmail.com>> a écrit :

Hi Meissa,

I can confirm this is a buig the the Apache Directory server. the
comparison of the RDN does not work properly when providing a
RDN like
"cn=Meissa Sakho+uid=msakho".

The added entry has this normalized DN:

0.9.2342.19200300.100.1.1= msakho +2.5.4.3= meissa  sakho
,0.9.2342.19200300.100.1.25= example
,0.9.2342.19200300.100.1.25= com

while the Bind dn is normalized this way :

2.5.4.3= meissa  sakho +0.9.2342.19200300.100.1.1= msakho
,0.9.2342.19200300.100.1.25= example
,0.9.2342.19200300.100.1.25= com

As you can see, the two values are inverted (cn+uid in one case,
and
uid+cn in the other case). That should not be the case.

This is the rreason why it fails.

Funny enough, would you try to login using "uid=msakho+cn=Meissa
SAKHO,ou=users,dc=example,dc=com", it would work...

On 15/11/2021 05:16, Emmanuel Lécharny wrote:
 > 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: msa...@redhat.com 
>
 >> 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://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#



 >>

>

 >>
 >>
 >>
 >>
 >>
 >> Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny
mailto:elecha...@gmail.com>
 >> >> 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:

Re: can't connect to my ldap server

2021-11-15 Thread Meissa Sakho

Emmanuel, Given that it's a bug, are you going to fill a jira
although there is a workaround?

Le lun. 15 nov. 2021 à 21:30, Meissa Sakho  a écrit :

> I've tried your hint and it works.
> The question is: Why do we have such regression?
> In the older version, it worked as defined in my first post and as
> described in this article
> https://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#
>
> Le lun. 15 nov. 2021 à 17:52, Emmanuel Lécharny  a
> écrit :
>
>> Hi Meissa,
>>
>> I can confirm this is a buig the the Apache Directory server. the
>> comparison of the RDN does not work properly when providing a RDN like
>> "cn=Meissa Sakho+uid=msakho".
>>
>> The added entry has this normalized DN:
>>
>> 0.9.2342.19200300.100.1.1= msakho +2.5.4.3= meissa  sakho
>> ,0.9.2342.19200300.100.1.25= example ,0.9.2342.19200300.100.1.25= com
>>
>> while the Bind dn is normalized this way :
>>
>> 2.5.4.3= meissa  sakho +0.9.2342.19200300.100.1.1= msakho
>> ,0.9.2342.19200300.100.1.25= example ,0.9.2342.19200300.100.1.25= com
>>
>> As you can see, the two values are inverted (cn+uid in one case, and
>> uid+cn in the other case). That should not be the case.
>>
>> This is the rreason why it fails.
>>
>> Funny enough, would you try to login using "uid=msakho+cn=Meissa
>> SAKHO,ou=users,dc=example,dc=com", it would work...
>>
>> On 15/11/2021 05:16, Emmanuel Lécharny wrote:
>> > 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: msa...@redhat.com 
>> >> 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://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#
>> >> <
>> https://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#>
>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny > >> > 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
>> >>  >

Re: can't connect to my ldap server

2021-11-15 Thread Meissa Sakho

I've tried your hint and it works.
The question is: Why do we have such regression?
In the older version, it worked as defined in my first post and as
described in this article
https://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#

Le lun. 15 nov. 2021 à 17:52, Emmanuel Lécharny  a
écrit :

> Hi Meissa,
>
> I can confirm this is a buig the the Apache Directory server. the
> comparison of the RDN does not work properly when providing a RDN like
> "cn=Meissa Sakho+uid=msakho".
>
> The added entry has this normalized DN:
>
> 0.9.2342.19200300.100.1.1= msakho +2.5.4.3= meissa  sakho
> ,0.9.2342.19200300.100.1.25= example ,0.9.2342.19200300.100.1.25= com
>
> while the Bind dn is normalized this way :
>
> 2.5.4.3= meissa  sakho +0.9.2342.19200300.100.1.1= msakho
> ,0.9.2342.19200300.100.1.25= example ,0.9.2342.19200300.100.1.25= com
>
> As you can see, the two values are inverted (cn+uid in one case, and
> uid+cn in the other case). That should not be the case.
>
> This is the rreason why it fails.
>
> Funny enough, would you try to login using "uid=msakho+cn=Meissa
> SAKHO,ou=users,dc=example,dc=com", it would work...
>
> On 15/11/2021 05:16, Emmanuel Lécharny wrote:
> > 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: msa...@redhat.com 
> >> 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://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#
> >> <
> https://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#>
>
> >>
> >>
> >>
> >>
> >>
> >> Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny  >> > 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:

Re: can't connect to my ldap server

2021-11-15 Thread Emmanuel Lécharny


Hi Meissa,

I can confirm this is a buig the the Apache Directory server. the 
comparison of the RDN does not work properly when providing a RDN like 
"cn=Meissa Sakho+uid=msakho".


The added entry has this normalized DN:

0.9.2342.19200300.100.1.1= msakho +2.5.4.3= meissa  sakho 
,0.9.2342.19200300.100.1.25= example ,0.9.2342.19200300.100.1.25= com


while the Bind dn is normalized this way :

2.5.4.3= meissa  sakho +0.9.2342.19200300.100.1.1= msakho 
,0.9.2342.19200300.100.1.25= example ,0.9.2342.19200300.100.1.25= com


As you can see, the two values are inverted (cn+uid in one case, and 
uid+cn in the other case). That should not be the case.


This is the rreason why it fails.

Funny enough, would you try to login using "uid=msakho+cn=Meissa 
SAKHO,ou=users,dc=example,dc=com", it would work...


On 15/11/2021 05:16, Emmanuel Lécharny wrote:

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: msa...@redhat.com 
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://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console# 
 






Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny > 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
    mailto:elecha...@gmail.com>
 > >> a 
écrit :

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

 >

Re: can't connect to my ldap server

2021-11-15 Thread Emmanuel Lécharny

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"

"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: msa...@redhat.com
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=DwIDaQ=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0=Pa2DB88IW_s2TyLfktHtWA=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c=Dn5z0Fep2ece_GfHn192tX9s8ttmCOPevpID9LHt6hI=

Re: can't connect to my ldap server

2021-11-15 Thread Donald Lohr

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.

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

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.

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: msa...@redhat.com 
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=DwIDaQ=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0=Pa2DB88IW_s2TyLfktHtWA=18v0l4oU4DKQ7FmlB99aAPZBhJ_vU0z6nRnh1dS2_8c=Dn5z0Fep2ece_GfHn192tX9s8ttmCOPevpID9LHt6hI= 

Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny mailto:elecha...@gmail.com>> 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::

Re: can't connect to my ldap server

2021-11-14 Thread Emmanuel Lécharny


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: msa...@redhat.com 
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://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console# 






Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny > 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
mailto:elecha...@gmail.com>
 > >> 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
 >      >

Re: can't connect to my ldap server

2021-11-14 Thread Meissa Sakho

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=comobjectClass:
organizationalPersonobjectClass: personobjectClass:
inetOrgPersonobjectClass: topcn: meissa sakhosn: sakhotitle:
cn=Administrator,ou=Groups,dc=example,dc=comuid: msakhouserpassword: 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: msa...@redhat.com
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://developers.redhat.com/blog/2018/09/21/setup-ldap-auth-amq-console#




Le sam. 13 nov. 2021 à 19:51, Emmanuel Lécharny  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  > > 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
> >  >
> >

Re: can't connect to my ldap server

2021-11-13 Thread Emmanuel Lécharny


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 > 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
emmanuel.lecha...@busit.com 
https://www.busit.com/ 

-
To unsubscribe, e-mail: users-unsubscr...@directory.apache.org

For additional commands, e-mail: users-h...@directory.apache.org

Re: can't connect to my ldap server

2021-11-11 Thread Meissa Sakho

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=comobjectClass:
organizationalPersonobjectClass: personobjectClass:
inetOrgPersonobjectClass: topcn: meissa sakhosn: sakhotitle:
cn=Administrator,ou=Groups,dc=example,dc=comuid: msakhouserpassword: meissa*

Thanks

Le ven. 12 nov. 2021 à 04:03, Emmanuel Lécharny  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
> emmanuel.lecha...@busit.com https://www.busit.com/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@directory.apache.org
> For additional commands, e-mail: users-h...@directory.apache.org
>
>

Re: can't connect to my ldap server

2021-11-11 Thread Emmanuel Lécharny


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
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@directory.apache.org
For additional commands, e-mail: users-h...@directory.apache.org

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

Re: can't connect to my ldap server

11 matches

Site Navigation

Mail list logo

Footer information