275598 - [LDAP] Document how to make authentication work with ActiveDirectory 2003

Status: RESOLVED INCOMPLETE

(Bugzilla :: Documentation, enhancement)

Description

[Kevin Benton]

I'm told that the LDAP authentication in BZ 2.19.1 doesn't work with 
ActiveDirectory for a number of reasons.  To test it, I went ahead to set up 
LDAP by configuring the LDAP server, Base DN, and User Verify Class.  When I 
attempted to authenticate, I got no error messages in my Apache logs at all.  
This is a problem at the least.  I want to make sure that failed logings are 
always logged with a reason if possible.  As a result, I am left to conclude 
that BZ doesn't work with AD LDAP without customization.

Comment 1

[Kevin Benton]

FYI - I'm also told that we don't do LDAPS.  That's a severe security issue 
for some networks.

Comment 2

[Max Kanat-Alexander]

I have it working with AD here, but it's on a hacked-up 2.17.1.

Basically, the problems are (as I recall):

(1) No anonymous binds allowed with AD.
(2) For the DN used in authentication, you just use the login name of the user
with @domain on the end. There's no "uid=" or anything.

Comment 3

[Jacob Steenhagen]

I no longer have a server w/AD on it available to me to test this (haven't for
the past year... and that's not likely to change even when I get back to the
States). There's certainly something that has to be done with this bug... either
fix it so that it actually works w/AD's LDAP (I've used perl and Net::LDAP to
auth against AD in the past, so I know it's possible) or document how to set it
up if it veries from a "normal" LDAP setup.

Comment 4

[Chris Hota]

Attachment: Address Book connected to Active Directory 2003, returns users AND computers.

Comment 5

[Chris Hota]

(In reply to comment #2)
*snip*
> (2) For the DN used in authentication, you just use the login name of the user
> with @domain on the end. There's no "uid=" or anything.

You can also use the form "DOMAIN\username" (I prefer this, as it doesn't
confuse users by using something that "looks" like an email address) or the
fully qualified DN of the user from AD (a nightmarish way of doing things,
especially if your users reside in different containers).

Comment 6

[Kevin Benton]

Another additional concern - what if I want to use both LDAP and DB (LDAP first,
then DB)...  Just thinking out loud.  Will try some of the above.

Comment 7

[Chris Hota]

(In reply to comment #4)
> Created an attachment (id=170823) [edit]
> Address Book connected to Active Directory 2003, returns users AND computers.
> 

OK, so I uploaded this screenshot of me doing lookups to our 2003 AD.  The
problem is that, in AD, many things have the "user" objectClass attribute,
including computers and printers and who-knows-what else.

What I normally do (in PHP, other LDAP tools, etc) when I just want to look for
user accounts in AD is use the following LDAP filter:

(&(objectclass=user)(!(objectclass=organizationalunit))(!(objectclass=computer))(!(objectclass=group)))

However, this doesn't work in Mozilla for some reason; it returns the exact same
results as if I hadn't specified a filter at all.  To fix this problem, THE LDAP
"NOT" EXPRESSIONS MUST BE FIRST!  For example, the following query works fine in
Mozilla (this is a reworking of the above query):

(&(!(objectclass=organizationalunit))(!(objectclass=computer))(!(objectclass=group))(objectclass=user))

I don't know whether this is a problem with AD or Thunderbird, but it IS a
problem.  I lean toward classifying it a Thunderbird problem because when I
contact AD with the first filter using other LDAP tools, it works fine.

Comment 8

[Chris Hota]

OK, so I've figured out the LDAP filter that works in my organization.

This returns AD users where the "company" attribute is set to anything other
than NULL, and also returns objects with the objectClass of "contact" as well
(because we have exchange set up in our AD, but don't use it, so this is how we
"inform" ldap searches of distribution lists):

(|(&(company=*)(!(objectclass=computer))(!(objectclass=group))(!(objectclass=organizationalunit))(objectclass=user))(objectclass=contact))

HOWEVER...

A better default filter for AD and AD2003 systems would be:

(email=*)

I'm not sure of the ramifications of this setup, though.  It should work, unless
your printer/ou/coffeepot/etc objects have email addresses.  Your mileage may
vary, etc.  :-|

Comment 9

[Max Kanat-Alexander]

(In reply to comment #8)
> OK, so I've figured out the LDAP filter that works in my organization.

  Chris -- this bug report here is in the "Bugzilla" product, not in
Thunderbird. :-) This is about authenticating Bugzilla accounts against Active
Directory.

  Also, I was only talking about the BindDN, so none the concerns about methods
of finding the user are actually a problem for Bugzilla. There won't be any
query, just a bind.

Comment 10

[Chris Hota]

(In reply to comment #9)
Oh. My. God.

I am so sorry folks!  I could've sword that pesky Product field said 
Thunderbird!  Thanks for pointing that out, Max!!

Well, to throw in my two cents on the Bind DN, we've found out that, for 
authenticating to AD2003 via LDAP, you can specify "cn=username, cn=Users, 
dc=domain, dc=com", "DOMAIN\username", or "[e-mail]".

I hope my ramblings have at least helped someone a little. :P

Sheepishly,

chris.

Comment 11

[Don Seiler]

I've submitted a patch via bug 278735 to fix problems I had with authenticating
against MSAD.  Might be of interest here.

Comment 12

[channy]

It seems that 

1: AD will not return the "dn" on its own.
2: the dn you can get cannot be used for the bind dn.

So the anonymous bind query will not return a proper dn.

I had to change 2 things to make it work: 

change the attrs in the anonymous query to anything e.g. "uid"

Then the user login with the $userDN would not work so I had to change it like this:

    # my $userDN = $mesg->shift_entry->dn;
    my $userDN = "cn=".$username;
 
Now it works.

I've tried reproducing this with ldapsearch and I got the exact same issues.

Comment 13

[Max Kanat-Alexander]

I think we have users who have made this work, yes? I think it's just a documentation issue, at this point.

If anybody tests this, make sure you test it with CVS tip.

Comment 14

[Sean M. Foy]

(In reply to comment #13)
> I think we have users who have made this work, yes? I think it's just a
> documentation issue, at this point.

It worked for me using BZ 2.22 with little trouble.

I do use the LDAPbinddn parameter to authenticate the initial bind. I use the mail (email address) attribute for user logins rather than e.g., sAMAccountName (looks like an NT login) or userPrincipalName (looks like but is not necessarily an email address). That wasn't always possible, but my company recently upgraded its Exchange servers, and the new version extends the AD schema to have a place for email addresses.

Bug 345930 describes some confusion I had about configuring the mapping between BZ users and AD users.

Comment 15

[Gervase Markham [:gerv]]

This bug is not actionable without up-to-date testing, and if that testing found any issues, they should be filed as new bugs.

Gerv