[rabbitmq-discuss] Client certificate based authentication over SSL

Fri Mar 28 16:19:50 GMT 2014

Simon,
Mate,
1)    About the AD anonymous bind, we will check the ldap log for the bind and search results
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.
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.
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).
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.
Once we fixed the paths in our config and removed the user, it worked like a charm.
Infact we went ahead and secured our management portal using certificates.

Thanks a lot for your help mate. I’’ll try and blog as much as I can (and remember) to help someone save time.
We are onto clustering and availability now. Hope that goes well. Thanks again.
Regards,
Vinay

> On 28 Mar 2014, at 11:55, Simon MacMullen <simon at rabbitmq.com> wrote:
> 
>> On 28/03/14 11:46, Primary wrote:
>> Thank you for your response.
>> We have made a bit of a progress but are still struggling with a few things. Can you please give us some pointers:
> 
> Sure.
> 
>> 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:
>> {handandshake_error,starting,0,
>>     {exit,
>>         {error,operationsError},
>>         'connection.start_ok',
> 
> "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.
> 
>> 2) We used a {username, password} tuple to bind to the AD. Though
>> this is not an ideal approach, we were able to bind to AD and
>> authorise our certificate user. Isn't there a way to use the
>> certificate itself to bind to AD rather giving a username, password
>> in clear text?
> 
> I don't think so. While some LDAP servers support authentication via client certificate, the RabbitMQ LDAP plugin doesn't.
> 
> 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.
> 
> 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.
> 
>> 3) Once this was done we had to then "create the certificate user
>> with no password" in RabbitMQ admin and grant access to the virtual
>> host via the admin. We want to get away with this i.e. having to
>> maintain users outside the AD. Is there no way we can achieve this
>> without having to create a user in RabbitMQ admin?
> 
> You don't need to create users in RabbitMQ's internal database, no.
> 
> 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.
> 
>> 4) This last bit is related to authorising access to the user. We are
>> able to write, read and create queues if our resource access query is
>> {constant, true}. To grant access based on AD groups we changed the
>> query to
> 
>> {permission, write,
>> {for, [{resource, queue, {constant, true}},
>>        {resource, exchange, {in_group, "cn=<Group Name>,ou=XXX,ou=Exchange,ou=Distribution Lists,dc=domain,dc=com"}}]}}
>> 
>> However this does not work. The group does exist and the certificate
>> user is a member of that group. We even tried giving a full group path
>> without any success.
> 
> Well, that's for exchanges not queues, right?
> 
>> Following is an extract from our log:
>> 
>> LDAP network traffic: search reply = {ok,
>>                                      {'LDAPMessage',2,
>>                                                      {searchResDone,           {'LDAPResult',noSuchObject,"DC=domain,DC=com",
>> [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,
>> 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],
> 
> That's the LDAP server returning noSuchObject. Are you absolutely sure you got the group DN right?
> 
> Cheers, Simon
> 
> -- 
> Simon MacMullen
> RabbitMQ, Pivotal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140328/db6f2567/attachment.html>