[rabbitmq-discuss] RabbitMQ 2.8.7 + LDAP + other_bind

[Marc Villacorta]

Thank you,

Now I realized the other_bind option is not what I want.
Jenkins LDAP has this 'Manager DN' to establish the initial bind.
Then they look up the username using a 'User search filter'.
I am not sure either about the user password. I don't see it in the network
traces thus, I think the application validates the password somehow.

Cheers, Marc

On Wed, Oct 10, 2012 at 6:22 PM, Simon MacMullen <simon at rabbitmq.com> wrote:

> Hi!
>
> The other_bind option is only used for authorisation queries - i.e. the
> queries we make *after* authenticating a user, to determine what rights
> they have.
>
> The user's provided username and password are used to bind to LDAP for
> authentication.
>
> I'm not sure how authentication could work any other way - I guess we
> could try to look up username and password, but I assume any sensible LDAP
> server will not store passwords in plain text anyway.
>
> Cheers, Simon
>
>
> On 10/10/12 15:28, Marc wrote:
>
>> Hello all!
>>
>> For authentication I need to bind to a Microsoft Active Directory.
>>
>> Let's say my bind user is '/uxxx/' with password '/pxxx/'.
>> Let's say the user I try to authenticate is '/uyyy/' with password
>> '/pyyy/'.
>>
>> I use the /other_bind
>> <http://hg.rabbitmq.com/**rabbitmq-auth-backend-ldap/**
>> file/d76afaf44415/README#l100<http://hg.rabbitmq.com/rabbitmq-auth-backend-ldap/file/d76afaf44415/README#l100>
>> >**/
>> configuration option in order to bind with user '/uxxx/'.
>>
>>
>> Like this:
>>
>>          { rabbit, [{auth_backends, [rabbit_auth_backend_ldap]}]},
>>
>>          { rabbitmq_auth_backend_ldap, [
>>
>>              {servers, ["myldapserver"]},
>>
>>              {other_bind, {"uxxx", "pxxx"}},
>>
>>              {dn_lookup_base, "DC=my,DC=domain,DC=com"},
>>
>>              {dn_lookup_attribute, "AccountName"},
>>
>>              {user_dn_pattern,
>>     "CN=${username},OU=users,OU=**mycompany,DC=my,DC=domain,DC=**com"},
>>
>>              {log,true}
>>
>>          ]}
>>
>>
>> but when I try to login with user '/uyyy/' I get this in my logs:
>>
>>
>>     =INFO REPORT==== 10-Oct-2012::16:21:04 ===
>>
>>     LDAP backend: connecting to ["myldapserver"]
>>
>>
>>     =INFO REPORT==== 10-Oct-2012::16:21:04 ===
>>
>>     LDAP backend: bind request = {'BindRequest',3,
>>
>>
>>       "CN=uyyy,OU=users,OU=**mycompany,DC=my,DC=domain,DC=**com",
>>
>>                                       {simple,<<"pyyy">>}}
>>
>>
>>     =INFO REPORT==== 10-Oct-2012::16:21:04 ===
>>
>>     LDAP backend: bind reply = {ok,
>>
>>                                  {'LDAPMessage',1,
>>
>>                                   {bindResponse,
>>
>>                                    {'BindResponse',**
>> invalidCredentials,[],
>>
>>
>>       [56,48,48,57,48,51,48,56,58,**32,76,100,97,112,
>>
>>
>>     69,114,114,58,32,68,83,73,68,**45,48,67,48,57,
>>
>>
>>     48,51,65,57,44,32,99,111,109,**109,101,110,116,
>>
>>
>>     58,32,65,99,99,101,112,116,83,**101,99,117,114,
>>
>>
>>     105,116,121,67,111,110,116,**101,120,116,32,101,
>>
>>
>>     114,114,111,114,44,32,100,97,**116,97,32,53,50,
>>
>>                                      101,44,32,118,49,100,98,48,0],
>>
>>                                     asn1_NOVALUE,asn1_NOVALUE}},
>>
>>                                   asn1_NOVALUE}}
>>
>>
>> I understand the bind request is being forged with the wrong user.
>> Could that be a bug in the LDAP plugin?
>>
>>
>> ______________________________**_________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
>> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>>
>>
>
> --
> Simon MacMullen
> RabbitMQ, VMware
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121011/88a55100/attachment.htm>