[rabbitmq-discuss] rabbit_auth_backend_ldap connect failed

[SAG - Jonathan Andrés]

Thank you very much!

Now I can see the logs of the LDAP Plugin. But I think this directive is not working:

	{other_bind, {"UserXXX", "PassXXX"}},

Because I can´t see the UserXXX in the LDAP's log. This is the LDAP log when I use Apache (you can see that the UserXXX appears in the BIND dn):
----------------
[22/Aug/2013:10:22:36 +0200] conn=743 op=-1 msgId=-1 - fd=42 slot=42 LDAP connection from 194.224.33.245:54587 to 194.224.33.177
[22/Aug/2013:10:22:36 +0200] conn=743 op=0 msgId=1 - BIND dn=" UserXXX " method=128 version=3
[22/Aug/2013:10:22:36 +0200] conn=743 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn=" UserXXX "
[22/Aug/2013:10:22:36 +0200] conn=743 op=1 msgId=2 - SRCH base="c=es" scope=2 filter="(&(userCertificate=*)(uid=DSISOFT2))" attrs="uid"
[22/Aug/2013:10:22:36 +0200] conn=743 op=1 msgId=2 - RESULT err=0 tag=101 nentries=1 etime=0
---------------

But this is the same log when I use RabbitMQ (the UserXXX doesn't appear):
---------------
[22/Aug/2013:10:15:34 +0200] conn=740 op=-1 msgId=-1 - fd=51 slot=51 LDAP connection from 194.224.33.245:54555 to 194.224.33.177
[22/Aug/2013:10:15:34 +0200] conn=740 op=0 msgId=1 - BIND dn="uid=DSISOFT2,ou=om,o=mycompany,c=ES" method=128 version=3
[22/Aug/2013:10:15:34 +0200] conn=740 op=0 msgId=1 - RESULT err=48 tag=97 nentries=0 etime=0
[22/Aug/2013:10:15:34 +0200] conn=740 op=1 msgId=0 - RESULT err=80 tag=120 nentries=0 etime=0
[22/Aug/2013:10:15:34 +0200] conn=740 op=-1 msgId=-1 - closing from 194.224.33.245:54555 - A1 - Client aborted connection -
[22/Aug/2013:10:15:34 +0200] conn=740 op=-1 msgId=-1 - closed.
---------------

I have tried with {other_bind, "anon"}, but doesn't work.

This is the RabbitMQ log:
--------------------------------------------------
=INFO REPORT==== 22-Aug-2013::10:15:34 ===
accepting AMQP connection <0.342.0> (194.224.33.160:47393 -> 194.224.33.245:5671)

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
LDAP CHECK: login for DSISOFT2

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
        LDAP filling template "uid=${username},ou=om,o=mycompany,c=ES" with
            [{username,<<"DSISOFT2">>}]

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
        LDAP template result: "uid=DSISOFT2,ou=om,o=mycompany,c=ES"

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
    LDAP connecting to servers: ["194.224.33.177"]

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
    LDAP network traffic: bind request = {'BindRequest',3,
                                          "uid=DSISOFT2,ou=om,o=mycompany,c=ES",
                                          {simple,<<"guest">>}}

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
    LDAP network traffic: bind reply = {ok,
                                        {'LDAPMessage',1,
                                         {bindResponse,
                                          {'BindResponse',
                                           inappropriateAuthentication,[],[],
                                           asn1_NOVALUE,asn1_NOVALUE}},
                                         asn1_NOVALUE}}

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
    LDAP bind error: uid=DSISOFT2,ou=om,o=mycompany,c=ES inappropriateAuthentication

=INFO REPORT==== 22-Aug-2013::10:15:34 ===
LDAP DECISION: login for DSISOFT2: {error,inappropriateAuthentication}
--------------------------------------------------

And I have another question: Once the producer and the consumer are authenticated, can the consumer know who sent the message?

Thank you, thank you again!





-----Mensaje original-----
De: Matthias Radestock [mailto:matthias at rabbitmq.com] 
Enviado el: miércoles, 21 de agosto de 2013 15:32
Para: SAG - Jonathan Andrés
CC: Discussions about RabbitMQ
Asunto: Re: [rabbitmq-discuss] rabbit_auth_backend_ldap connect failed

On 21/08/13 13:21, SAG - Jonathan Andrés wrote:
> Today I have installed the last version of RabbitMQ (3.1.5), but I 
> have the same problem (I had the 3.1.4 version before).

Found the problem:

> {rabbit_auth_backend_ldap,

should be rabbitmq_auth_backend_ldap.

Terribly sorry about that; we really should have spotted this earlier.

Matthias.