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
Hi,
your LDAP configuration doesn‘t look right to me.
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.
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
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/646d3405-ea2e-4ba2-900c-5f6d55490e2fn%40googlegroups.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!
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/806e9e44-0aff-4ca7-bc80-31a3cac1a051n%40googlegroups.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.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/65a73832-edf7-4492-b9d6-4fe5d27e4c74n%40googlegroups.com.