[rabbitmq-discuss] Debugging AD

[Ben Hood]

On Wed, Nov 30, 2011 at 4:44 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Hi Simon,
>
> So after spinning the underlying LDAP driver on it's own, I was able
> to establish what combination of input parameters was going to work
> with AD:
>
> 1> {_, C} = eldap:open(["172.20.3.21"],[]).
> 2> eldap:simple_bind(C,
> "ben.hood at ACMEDOMAIN","DB/nUcPk?DdF<eCjp?erzpbi[g"BdJL.w;pFrT>tg at KnbCDsi").
> ok
>
> So this boils down to putting
>
> {user_dn_pattern,       "${username}@ACMEDOMAIN"},

I've managed to test for group membership in AD using after applying this patch:

iff -r 99212b40d834 src/rabbit_auth_backend_ldap.erl
--- a/src/rabbit_auth_backend_ldap.erl	Wed Nov 09 10:20:24 2011 +0000
+++ b/src/rabbit_auth_backend_ldap.erl	Thu Dec 01 17:03:48 2011 +0000
@@ -119,7 +119,7 @@
     object_exists(DNPattern, Filter, Args, LDAP);

 evaluate({in_group, DNPattern}, Args, #user{impl = UserDN}, LDAP) ->
-    Filter = eldap:'and'([eldap:equalityMatch("objectClass", "groupOfNames"),
+    Filter = eldap:'and'([eldap:equalityMatch("objectClass", "group"),
                           eldap:equalityMatch("member",      UserDN)]),
     object_exists(DNPattern, Filter, Args, LDAP);

However, I think I may have run into a brick wall with the bind with AD.

$ ldapsearch -h 172.20.3..21 -w 'xxx' -b "dc=acme,dc=com" -D
"ACMEDOMAIN\\ben.hood"

will return a whole subtree of results, but for an in_group query to work, e.g.

{resource_access_query,
     {for, [
        {permission, configure, {in_group, "CN=Rabbit
Admins,DC=acme,DC=com" } },
        {permission, configure, {constant, false} }
     ]}
   },

the original bind request will have had to returned the full user DN,
not a list of results.

To get AD to return a single user DN, you can do the following:

$ ldapsearch -h 172.20.3..21 -w 'xxx' -b "dc=acme,dc=com" -D
"ACMEDOMAIN\\ben.hood" '(sAMAccountName=ben.hood)' dn

But with AFAICT with eldap this would require the bind to be followed
by a subsequent query by attribute, like the example in the LDAP
driver shows: https://github.com/etnt/eldap/blob/master/doc/README.example

So I would love to be corrected, but I can't see how AD authentication
can work without post-processing the initial bind call. Has anybody
else had any success with AD where authentication for the bind is
required?

Cheers,

Ben