LDAP bind returned "invalid credentials"

1,846 views
Skip to first unread message

GC

unread,
Mar 26, 2024, 10:45:36 AM3/26/24
to rabbitm...@googlegroups.com
As mentioned in my previous thread (https://groups.google.com/u/1/g/rabbitmq-users/c/ytdX76vye-8), I was finally able to login (although login took around 8-10 secs) using LDAP but when I checked the logs, it kept filling the log file with the following message:
```
2024-03-22 11:33:14.022083+00:00 [warning] <0.906.0> Searching for DN for uid=john.doe,cn=users,cn=accounts,dc=company,dc=com, got back []
```

I'm not too sure but this doesn't look like any lack of permission issue for the bind user because I can use the bind user to search my user's DN
```
$ ldapsearch -D "uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com" -x -H ldaps://ipa.company.com:636 -w somepassword -b "dc=company,dc=com" -LLL '(uid:dn:=john.doe)'
objectClass: top
objectClass: person
...
...
dn: uid=john.doe,cn=users,cn=accounts,dc=company,dc=com
memberOf: cn=platform-admin,cn=groups,cn=accounts,dc=company,dc=com
```

I have tried multiple combinations to fix the issue but didn't get it to work. Here are my latest configs:
```
$ cat rabbitmq.conf
auth_backends.1 = ldap
auth_backends.2 = internal
auth_ldap.port = 636
auth_ldap.use_ssl = true
auth_ldap.ssl_options.verify = verify_none
auth_ldap.servers.1 = ipa.company.com
auth_ldap.dn_lookup_bind.user_dn = uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com
auth_ldap.dn_lookup_bind.password = somepassword
auth_ldap.dn_lookup_base = dc=company,dc=com
# Also tried using uid and sAMAccountName below but same error (HTTP access denied: john.doe) as shown below
auth_ldap.dn_lookup_attribute = distinguishedName
auth_ldap.user_dn_pattern = uid=${username}
auth_ldap.log = network_unsafe
```
```
$ cat advanced.config
[
    {rabbit, [
        {auth_backends, [rabbit_auth_backend_ldap]}
    ]},
    {rabbitmq_auth_backend_ldap, [
        {group_lookup_base, "cn=platform-admin,cn=groups,cn=accounts,dc=company,dc=com"},
        {tag_queries, [
            {administrator,     {in_group, "cn=platform-admin,cn=groups,cn=accounts,dc=company,dc=com", "uniqueMember"}},
            {management,        {constant, true}}
        ]}
      ]}
].
```
With the above config in place, I finally see this error and as expected, I am unable to login. But yes, at least I see that the "got back []" error is not there. That's the only progress I could see.
```
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0> Searching for DN for john.doe, got back [{eldap_entry,
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 "uid=john.doe,cn=users,cn=accounts,dc=company,dc=com",
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 []},
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                {eldap_entry,
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 "uid=john.doe,cn=users,cn=compat,dc=company,dc=com",
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 []},
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                {eldap_entry,
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 "uid=john.doe,cn=users,cn=compat,dc=company,dc=com",
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 []}]
2024-03-26 12:12:09.099034+00:00 [info] <0.980.0>     LDAP connecting to servers: ["ipa.company.com"]
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>     LDAP network traffic: bind request = {'BindRequest',3,"xxxx",
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>                                           {simple,"xxxx"}}
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>     LDAP network traffic: bind reply = {ok,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                         {'LDAPMessage',3,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                          {bindResponse,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                           {'BindResponse',invalidCredentials,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                            [],[],asn1_NOVALUE,asn1_NOVALUE}},
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                          asn1_NOVALUE}}
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>
2024-03-26 12:12:09.677892+00:00 [info] <0.906.0>     LDAP bind returned "invalid credentials": xxxx
2024-03-26 12:12:09.678139+00:00 [info] <0.980.0> LDAP DECISION: login for john.doe: denied
2024-03-26 12:12:09.678297+00:00 [warning] <0.980.0> HTTP access denied: john.doe
```

How can I fix the "invalid credentials" issue now? I will really appreciate any help.

Luke Bakken

unread,
Mar 26, 2024, 3:19:51 PM3/26/24
to rabbitmq-users
Hello,

Thanks for using RabbitMQ and wrangling with LDAP.
 
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0> Searching for DN for john.doe, got back [{eldap_entry,
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 "uid=john.doe,cn=users,cn=accounts,dc=company,dc=com",
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 []},
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                {eldap_entry,
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 "uid=john.doe,cn=users,cn=compat,dc=company,dc=com",
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 []},
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                {eldap_entry,
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 "uid=john.doe,cn=users,cn=compat,dc=company,dc=com",
2024-03-26 12:12:09.098550+00:00 [warning] <0.906.0>                                                 []}]

This is a good sign, because the DN for john.doe was found.
 
2024-03-26 12:12:09.099034+00:00 [info] <0.980.0>     LDAP connecting to servers: ["ipa.company.com"]
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>     LDAP network traffic: bind request = {'BindRequest',3,"xxxx",
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>                                           {simple,"xxxx"}}
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>     LDAP network traffic: bind reply = {ok,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                         {'LDAPMessage',3,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                          {bindResponse,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                           {'BindResponse',invalidCredentials,
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                            [],[],asn1_NOVALUE,asn1_NOVALUE}},
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>                                          asn1_NOVALUE}}
2024-03-26 12:12:09.677413+00:00 [info] <0.981.0>
2024-03-26 12:12:09.677892+00:00 [info] <0.906.0>     LDAP bind returned "invalid credentials": xxxx
2024-03-26 12:12:09.678139+00:00 [info] <0.980.0> LDAP DECISION: login for john.doe: denied
2024-03-26 12:12:09.678297+00:00 [warning] <0.980.0> HTTP access denied: john.doe


"invalid credentials" means the provided credentials aren't valid, i.e. wrong password, or the passed-in DN isn't correct for the LDAP system.

See if you can test that user's credentials using ldapwhoami

Garbageyard

unread,
Mar 27, 2024, 8:32:51 AM3/27/24
to rabbitmq-users
Thanks for the suggestion Luke. The password is correct and I also tried the ldapwhoami.
```
$ ldapwhoami -x -D "uid=john.doe,cn=users,cn=accounts,dc=company,dc=com" -H ldaps://ipa.company.com:636 -W
Enter LDAP Password:
dn: uid=john.doe,cn=users,cn=accounts,dc=company,dc=com
```

One of my colleague mentioned about seeing the same "got back []" message while integrating LDAP for some other application. This is the config that finally worked for him:
```
LDAP_ADDITIONAL_USER_DN = 'cn=users,cn=accounts'
LDAP_ADMIN_DN = 'uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com'
LDAP_BASE_DN = 'dc=company,dc=com'
LDAP_PASSWORD = 'somepassword'

# Simple search
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    '{},{}'.format(LDAP_ADDITIONAL_USER_DN, LDAP_BASE_DN),
    ldap.SCOPE_SUBTREE, '(uid=%(user)s)'
)
```

Is there an equivalent for LDAP_ADDITIONAL_USER_DN in this case?

Luke Bakken

unread,
Mar 27, 2024, 10:54:32 AM3/27/24
to rabbitmq-users
Which DN is being used for this bind request? You have edited it out. I don't remember if the DN is shown here or not.

2024-03-26 12:12:09.099034+00:00 [info] <0.980.0>     LDAP connecting to servers: ["ipa.company.com"]
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>     LDAP network traffic: bind request = {'BindRequest',3,"xxxx",
2024-03-26 12:12:09.099490+00:00 [info] <0.981.0>                                           {simple,"xxxx"}}

Vilius Šumskas

unread,
Mar 27, 2024, 11:26:50 AM3/27/24
to rabbitm...@googlegroups.com

Hi,

 

your LDAP configuration doesn‘t look right to me.

 

  1. “dn_lookup_attribute“ should point to the attribute, which contains just plain username. On MS AD for example it is “userPrincipalName”. In your configuration you are pointing to the DN itself.
  2. Remove “user_dn_pattern“ if you want to use DN lookup instead of fixed DN pattern.
  3. Your search returns multiple DNs per user. I recommend limiting search base, so your searches won‘t return all objects in the directory. This should eliminate those warnings, and the search will also be faster. I assume you are using FreeIPA, so “cn=users,cn=accounts,dc=company,dc=com“ should do the thing (or “cn=accounts,dc=company,dc=com“ if you store users in more sub-containers).

 

And the last optional advice, I recommend removing additional “dn_lookup_bind“ user completely and just do binging under standard user account. Unless your directory doesn‘t allow binding with plain username there is no reason to do it via intermediate user.

 

Hope that helps.

 

--

    Vilius

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CAGDgvc1neVGnrmqmi1y6-nSN6mp5t6%2Bpn5un3LoT8z4KEZonWA%40mail.gmail.com.

Garbageyard

unread,
Mar 28, 2024, 12:52:44 AM3/28/24
to rabbitmq-users
@Luke: I have attached the log containing bind details and response.

@Vilius: Actually, based on the response below, I tried setting dn_lookup_attribute to uid. When that didn't work, I also tried sAMAccountName and distinguishedName. However, i feel it should be uid. Please correct me if I am wrong. May be some other part of the config is incorrect because of which things are not working. 
```
$ ldapsearch -D "uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com" -x -H ldaps://ipa.company.com:636 -w somepassword -b "dc=company,dc=com" -LLL '(uid:dn:=john.doe)'
dn: uid=john.doe,cn=users,cn=compat,dc=company,dc=com
objectClass: posixAccount
objectClass: ipaOverrideTarget
objectClass: top
gecos: John Doe
cn: John Doe
...
uid: john.doe


dn: uid=john.doe,cn=users,cn=compat,dc=company,dc=com
objectClass: posixAccount
objectClass: ipaOverrideTarget
objectClass: top
gecos: John Doe
cn: John Doe
...
uid: john.doe


dn: uid=john.doe,cn=users,cn=accounts,dc=company,dc=com
givenName: John
sn: Doe
uid: john.doe
cn: John Doe
displayName: John Doe
initials: JD
gecos: John Doe
krbPrincipalName: john...@company.COM
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
...
objectClass: ipaobject
...
loginShell: /bin/bash
homeDirectory: /home/john.doe
mail: john...@company.com
krbCanonicalName: john...@company.COM
...
memberOf: ...
memberOf: cn=platform-admin,cn=groups,cn=accounts,dc=company,dc=com
memberOf: cn=engineering,cn=groups,cn=accounts,dc=company,dc=com
memberOf: ...
```
Attaching the latest config based on your suggestion.
rabbit_error.log
rabbit_advanced.confs

Vilius Šumskas

unread,
Mar 28, 2024, 5:41:31 AM3/28/24
to rabbitm...@googlegroups.com

Yes, under FreeIPA it‘s usually uid. I don‘t think sAMAccountName exist anywhere except in MS AD.

 

As for the config, I‘ve meant that you should set „auth_ldap.dn_lookup_base“ not „group_lookup_base“ to „cn=users,cn=accounts,dc=company,dc=com“. As for the groups, I recommend to remove them for now and make sure that authentication works first. Add group lookup and other queries after that.

 

--

    Vilius

Message has been deleted
Message has been deleted

Luke Bakken

unread,
Mar 28, 2024, 11:14:41 AM3/28/24
to rabbitmq-users
2024-03-28 04:19:00.157255+00:00 [info] <0.980.0>     LDAP network traffic: bind request = {'BindRequest',3,"john.doe",
2024-03-28 04:19:00.157255+00:00 [info] <0.980.0>                                           {simple,<<"john-pwd">>}}

john.doe is a different value than what you used in ldapwhoami, which was uid=john.doe,cn=users,cn=accounts,dc=company,dc=com

It feels like whatever LDAP server you're using needs to be configured to accept uid as a credential.

I don't think I will be able to assist you further unless you can provide an LDAP environment where I can see the exact same behavior as you. Right now I feel like I'm guessing.

Vilius Šumskas

unread,
Mar 29, 2024, 3:36:22 AM3/29/24
to rabbitm...@googlegroups.com

You will need to debug this yourself as it is getting out of scope of RabbitMQ. Couple of things comes into my mind:

* DN lookup itself is slow. With RabbitMQ you are doing DN lookup according to the uid provided. Maybe other applications are faster because they are using fixed DN to login?

* Network issues, like misconfigured reverse DNS for example.

* Did you test login without group configuration? Maybe group lookup is misconfigured? Maybe you are hitting recursive group lookup?

 

And, again, unless you really need it, I would suggest to not use intermediate user (uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com) by removing both “dn_lookup_bind” parameters completely. In theory this should not slow down your logins that much but in practice, with current configuration, you are still doing two logins instead of one.

 

--

    Vilius

 

From: rabbitm...@googlegroups.com <rabbitm...@googlegroups.com> On Behalf Of Garbageyard
Sent: Thursday, March 28, 2024 1:12 PM
To: rabbitmq-users <rabbitm...@googlegroups.com>
Subject: Re: [rabbitmq-users] LDAP bind returned "invalid credentials"

 

@Vilius, thank you so much! I actually misunderstood your suggestion.

 

Changing

auth_ldap.dn_lookup_base = dc=company,dc=com
to
auth_ldap.dn_lookup_base = cn=users,cn=accounts,dc=company,dc=com

did the trick. :)

 

After entering my credential, it takes almost anywhere between 10-15 sec to finally login. This is not the case when I login to any other application using LDAP. Any idea how I can fix this?

 

Thanks again!

Garbageyard

unread,
Apr 1, 2024, 2:48:15 AM4/1/24
to rabbitmq-users
@Luke: There was some issue with my last response as it didn't show up in the thread even after few hours so I wasn't sure whether I actually sent it. That resulted in me sending a duplicate response. Sorry for that.

@Vilius, sorry for failing to respond to your query about using intermediate user (uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com). Actually, I did try without it but it immediately failed with error "2024-04-01 06:30:45.606632+00:00 [warning] <0.980.0> HTTP access denied: john.doe"

Also, below are the LDAP configuration sections for Jenkins and Artifactory. As far as I understand, here too we are using uid only, right? Both authenticate quickly (max 2 secs). Jenkins has group filter applied too.
---------------------------------------------
JENKINS:
Server: ldaps://ipa.company.com:636
root DN: dc=company,dc=com
User search base: cn=users,cn=accounts
User search filter: uid={0}
Group search base: cn=groups,cn=accounts
Group membership:
    Search for LDAP groups containing user
    Group membership filter
        (&(objectClass=ipausergroup)(|(cn=platform-admin)(cn=data-engineering)))
Manager DN: uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com
Display Name LDAP attribute: displayname
Email Address LDAP attribute: mail
---------------------------------------------
JFROG Artifactry:
ldaps://ipa.company.com:636/dc=company,dc=com
User DN Pattern: uid={0},cn=users,cn=accounts
Email Attribute: email
Search Filter: sAMAccountName={0}
Search Base: cn=users,cn=accounts
Manager DN: uid=myaccount,cn=sysaccounts,cn=etc,dc=company,dc=com
Manager Password: xxxxx
Sarch Sub-tree: Enabled
---------------------------------------------
How can this Jenkins group filter "(&(objectClass=ipausergroup)(|(cn=platform-admin)(cn=data-engineering)))" be translated to RabbitMQ LDAP group query?

@Vilius, I currently do not have any group_lookup_base configuration in my RabbitMQ configs. Slowness in login is still there.

Also, even after I login, there is this approx. 140 lines of code (attached file) that keeps getting repeated every 2 secs or so. Not sure why this is happening.

rabbitmq_repeating_code.log

Vilius Šumskas

unread,
Apr 1, 2024, 4:03:15 PM4/1/24
to rabbitm...@googlegroups.com

Hi,

 

the logs show that it takes more than 3 seconds to login. Every bind of the two users takes 0.6-0.7 seconds, and another 0.5-0.7 seconds for every 3 lookups happening (DN lookup of the user, and two group lookups). I don‘t know how many objects you have in LDAP directory but for my liking, it‘s too slow. Why slow? You will have to work with your LDAP administrator to debug that. Given almost constant nature of the delay, I would say it’s a network delay issue.

If there is nothing you can do to resolve slow LDAP response times, then https://www.rabbitmq.com/docs/ldap#query-caching could help.

 

I’m not familiar with Jenkins nor Jfrog LDAP authentication flow so I cannot say much. From the looks of it they may be using user DN pattern login flow instead of user DN lookup, but again, your LDAP administrator should help you with this better. If you decide to switch to user DN pattern in RabbitMQ make sure you read https://www.rabbitmq.com/docs/ldap#usernames-and-dns and don’t mix two different configuration.

 

As for the group filter, it’s probably redundant in Jenkins config because you are searching groups container anyway.

Garbageyard

unread,
Apr 2, 2024, 6:21:28 AM4/2/24
to rabbitmq-users
Hi Vilius,

Thanks for the comments. I had seen that section related to DN pattern in the docs earlier but I guess few concepts got cleared in this email chain. I did try using the following DN pattern:
```
auth_ldap.dn_lookup_base = cn=users,cn=accounts,dc=company,dc=com
auth_ldap.user_dn_pattern = ${username}
auth_ldap.dn_lookup_attribute = uid
```
It did work but there was no change in the login time. After I enter the credentials, it took me around 8-10 secs to finally see the RabbitMQ page.

However, your suggestion for caching was great! So fast that it logs me in before I even enter my LDAP password. :)

Thank you, again!

@Luke: Thank you for your help as well.
Reply all
Reply to author
Forward
0 new messages