<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Simon,<o:p></o:p></span></p><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Mate,<o:p></o:p></span></p><p class="MsoListParagraph" style="text-indent: 0px; margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">1) About the AD anonymous bind, we will check the ldap log for the bind and search results<o:p></o:p></span></p><p class="MsoListParagraph" style="text-indent: 0px; margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">2) You are right about the users certificate being incomplete. Enhancements in 3.3.0 are encouraging as anything is better than a password in clear text.<o:p></o:p></span></p><p class="MsoListParagraph" style="text-indent: 0px; margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">3) and 4) Am combining both the issues as the resolution was the same. We had an in_group query on the v_host query which was incorrect. The log wasn’t clear enough or maybe we were daft to start blaming it on authorisation.<o:p></o:p></span></p><p class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Though we did not have backend_internal in our configuration, creating a “certificate user with no password” and granting the user access to the virtual host seemed to fix the issue (weird).<o:p></o:p></span></p><p class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">However the problem was actually with the AD group path. In our absolute path to the AD group we got the units (OUs) in the wrong order. A quick dsquery on the group name gave us the right AD group absolute path.<o:p></o:p></span></p><p class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Once we fixed the paths in our config and removed the user, it worked like a charm.<o:p></o:p></span></p><p class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Infact we went ahead and secured our management portal using certificates.<o:p></o:p></span></p><p class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);"> </span></p><p class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Thanks a lot for your help mate. I’’ll try and blog as much as I can (and remember) to help someone save time.<o:p></o:p></span></p><p class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt 36pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">We are onto clustering and availability now. Hope that goes well. Thanks again.<o:p></o:p></span></p><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Regards,<o:p></o:p></span></p><p class="MsoNormal" style="margin: 0cm 0cm 0.0001pt;"><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Vinay</span></p></div><div style="-webkit-text-size-adjust: auto;"><br>On 28 Mar 2014, at 11:55, Simon MacMullen <<a href="mailto:simon@rabbitmq.com">simon@rabbitmq.com</a>> wrote:<br><br></div><blockquote type="cite" style="-webkit-text-size-adjust: auto;"><div><span>On 28/03/14 11:46, Primary wrote:</span><br><blockquote type="cite"><span>Thank you for your response.</span><br></blockquote><blockquote type="cite"><span>We have made a bit of a progress but are still struggling with a few things. Can you please give us some pointers:</span><br></blockquote><span></span><br><span>Sure.</span><br><span></span><br><blockquote type="cite"><span>1) We tried using {other_bind, anon} but that still failed even though our AD allows anonymous access. Following is an extract of the log:</span><br></blockquote><blockquote type="cite"><span>{handandshake_error,starting,0,</span><br></blockquote><blockquote type="cite"><span> {exit,</span><br></blockquote><blockquote type="cite"><span> {error,operationsError},</span><br></blockquote><blockquote type="cite"><span> 'connection.start_ok',</span><br></blockquote><span></span><br><span>"operationsError" is coming from the LDAP server. Unfortunately, that's all the detail it's giving out. From a quick google search it sounds like AD can return this error when the user is able to bind but not perform searches.</span><br><span></span><br><blockquote type="cite"><span>2) We used a {username, password} tuple to bind to the AD. Though</span><br></blockquote><blockquote type="cite"><span>this is not an ideal approach, we were able to bind to AD and</span><br></blockquote><blockquote type="cite"><span>authorise our certificate user. Isn't there a way to use the</span><br></blockquote><blockquote type="cite"><span>certificate itself to bind to AD rather giving a username, password</span><br></blockquote><blockquote type="cite"><span>in clear text?</span><br></blockquote><span></span><br><span>I don't think so. While some LDAP servers support authentication via client certificate, the RabbitMQ LDAP plugin doesn't.</span><br><span></span><br><span>In 3.3.0 you will be able to specify a client certificate for the connection to the LDAP server - but only for one certificate for the RabbitMQ server, not passing through the user's certificate.</span><br><span></span><br><span>And of course it's not possible to pass through the user's certificate, since we only have the user's public key, which is not enough to impersonate the user.</span><br><span></span><br><blockquote type="cite"><span>3) Once this was done we had to then "create the certificate user</span><br></blockquote><blockquote type="cite"><span>with no password" in RabbitMQ admin and grant access to the virtual</span><br></blockquote><blockquote type="cite"><span>host via the admin. We want to get away with this i.e. having to</span><br></blockquote><blockquote type="cite"><span>maintain users outside the AD. Is there no way we can achieve this</span><br></blockquote><blockquote type="cite"><span>without having to create a user in RabbitMQ admin?</span><br></blockquote><span></span><br><span>You don't need to create users in RabbitMQ's internal database, no.</span><br><span></span><br><span>Have you perhaps set the auth_backends to [rabbit_auth_backend_ldap, rabbit_auth_backend_internal]? You could be seeing the user failing to authenticate with LDAP and then successfully authenticating with the internal database.</span><br><span></span><br><blockquote type="cite"><span>4) This last bit is related to authorising access to the user. We are</span><br></blockquote><blockquote type="cite"><span>able to write, read and create queues if our resource access query is</span><br></blockquote><blockquote type="cite"><span>{constant, true}. To grant access based on AD groups we changed the</span><br></blockquote><blockquote type="cite"><span>query to</span><br></blockquote><span></span><br><blockquote type="cite"><span>{permission, write,</span><br></blockquote><blockquote type="cite"><span> {for, [{resource, queue, {constant, true}},</span><br></blockquote><blockquote type="cite"><span> {resource, exchange, {in_group, "cn=<Group Name>,ou=XXX,ou=Exchange,ou=Distribution Lists,dc=domain,dc=com"}}]}}</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>However this does not work. The group does exist and the certificate</span><br></blockquote><blockquote type="cite"><span>user is a member of that group. We even tried giving a full group path</span><br></blockquote><blockquote type="cite"><span>without any success.</span><br></blockquote><span></span><br><span>Well, that's for exchanges not queues, right?</span><br><span></span><br><blockquote type="cite"><span>Following is an extract from our log:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>LDAP network traffic: search reply = {ok,</span><br></blockquote><blockquote type="cite"><span> {'LDAPMessage',2,</span><br></blockquote><blockquote type="cite"><span> {searchResDone, {'LDAPResult',noSuchObject,"DC=domain,DC=com",</span><br></blockquote><blockquote type="cite"><span>[48,48,48,48,50,48,56,68,58,32, 78,97,109,101,69,114,114,58,32,68,83,73,68,45,48,51,49,48,48, 50,48,65,44,32,112,114,111,98,108,101,109,32,50,48,48,49,32, 40,78,79,95,79,66,74,69,67,84,41,44,32,100,97,116,97,32,48,44, 32,98,101,115,116,32,109,97,116,</span><br></blockquote><blockquote type="cite"><span>99,104,32,111,102,58,10,9,39,68, 67,61,101,100,102,116,114,97,100,105,110,103,44,68,67,61,99,111,109,39,10,0],</span><br></blockquote><span></span><br><span>That's the LDAP server returning noSuchObject. Are you absolutely sure you got the group DN right?</span><br><span></span><br><span>Cheers, Simon</span><br><span></span><br><span>-- </span><br><span>Simon MacMullen</span><br><span>RabbitMQ, Pivotal</span><br></div></blockquote></body></html>