[rabbitmq-discuss] Client certificate based authentication over SSL

Fri Mar 28 11:55:00 GMT 2014

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