[rabbitmq-discuss] Debugging AD

Fri Dec 2 17:14:30 GMT 2011

On Fri, Dec 2, 2011 at 11:49 AM, Simon MacMullen <simon at rabbitmq.com> wrote:
> So after some off-list discussion, the issue is that AD allows you to bind
> using a short ID rather than a full name - useful in the case where you have
> too many users to stick them in a single OU, but don't want people to have
> to enter their full DN to log in.
>
> But the LDAP plugin assumes that the name you log in as is your full DN
> (after applying user_dn_pattern). So it would be useful to have an optional
> step to go look up the DN after bind.
>
> I'll file a bug.

So it would be cool if this were to land sometime soon. In the
meantime, I have been able to use a workaround of sorts. So by just
letting AD users get the innocuous monitoring role, they can see
everything that is "going on" without be able to do anything like
reading, writing, adding, deleting, binding or purging - it is purely
statistical. All other functions can be executed by users defined in
the internal DB.

Whilst not being as flexible and fully fledged as a full AD solution,
it does add some value right now, because people can use the
management UI as a heads up display, e.g. to see when things get
wedged.

For anybody that is interested, here is the
/etc/rabbitmq/rabbitmq.config I used:

[

 %% Enable SSL support for the Management Web UI
 %% Note that you have to supply the CA cert, the server's cert and
the server's private key yourself

  {rabbitmq_mochiweb,
  [{listeners, [{'*',  [{port,     55670}]},
                {mgmt, [{port,     55672},
                        {ssl,      true},
			{ssl_opts, [{cacertfile, "/path/to/cacert.pem"},
                                    {certfile,   "/path/to/cert.pem"},
                                    {keyfile,    "/path/to/key.pem"}]}
                       ]}
               ]}
  ]},

 %% Enable both the internal user DB and LDAP
 %% Make sure that the internal store has precedence, otherwise
internal users may not be able to use the management UI

 {rabbit, [ {auth_backends, [rabbit_auth_backend_internal,
rabbit_auth_backend_ldap]} ]  },

 %% Configure the connection to AD

 {rabbitmq_auth_backend_ldap,
 [
   %% The main AD server

   {servers,               ["172.20.3.21"]},

   %% This is the user that is logging in using their AD creds.

   {user_dn_pattern,       "${username}@ACMECORP"},

   %% The LDAP plugin in Rabbit 2.7.0 doesn't appear to play as well
as it does with other LDAP implementations,
   %% so the appropriate tickets have been raised at VMWare to get
this fixed for a future version.

   {resource_access_query,
     {for, [ {permission, configure, {constant, false}},
             {permission, read, {constant, false}},
             {permission, write, {constant, false}} ]}
   },

   %% Only allow LDAP users to monitor what is going on

   {tag_queries,           [{monitoring, {constant, true}}]},

   %% Self-explanatory

   {use_ssl,               false},
   {port,                  389},
   {log,                   false} ] }
].