My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 423: ActiveDirectory group querys cannot be anonymous
7 people starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  ----


Sign in to add a comment
 
Reported by jeffreys...@gmail.com, Feb 1, 2010
Default installation requires anonymous LDAP access or an admin account.
There is no option to attempt to fast bind using the user's supplied
username and password.
Feb 1, 2010
#1 sop@google.com
When auth.type is LDAP gerrit does a simple bind with the user's
supplied username/password to authenticate them.  IIRC it also
uses that initial connection to read back the user's group membership.

However, if the ldap cache entry for that user expires while the user
session is still valid, Gerrit uses anonymous access or an admin account
(configured by ldap.username, ldap.password) to login and refresh the
group listing for that user.  It does this to bypass asking the user
for their credentials again.

So we're basically already doing what you ask when auth.type = LDAP.
Could you elaborate further?
Feb 1, 2010
#2 jeffreys...@gmail.com
Maybe I'm not understanding the directions then. We're using Active Directory and
ldaps and with all the settings I've tried I cannot get gerrit to authenticate with
ldap. Using ldapsearch we can only query account information with a query like this:

ldapsearch -x -LLL -H ldaps://adserver -D jelevesque@company.com -b dc=company,dc=com
-W "(sAMAccountName=*auto*)"

So for my gerrit.config I used this:

[auth]
        type = LDAP
[ldap]
        server = ldaps://adserver
        accountBase = cn=Users,dc=company,dc=com
        sslVerify = false

Is it not working because of the @company.com piece in the username? The reason I
assumed fast bind was not being used because the documentation says when username and
password are not supplied it attempts an anonymous connection. Is this the same as
the -x option for ldapsearch?
Feb 1, 2010
#3 sop@google.com
You're right.  Gerrit is broken when auth.type = LDAP and the
server is Active Directory.

I think you need the following as your configuration:

  [auth]
    type = LDAP
  [ldap]
    server = ldaps://adserver
    accountBase = cn=Users,dc=company,dc=com
    sslVerify = false
    accountPattern = (&(objectClass=user)(userPrincipalName=${username}))

Unfortunately the default under Active Directory is:

  accountPattern = (&(objectClass=user)(sAMAccountName=${username}))

as this was created for auth.type = HTTP_LDAP, where ${username} was the
local username only.  When auth.type = LDAP, ${username} is the entire
name, including domain.  So you're right, its the @company.com part that
is confusing things here.

Please try adding the ldap.accountPattern with userPrincipalName and let
me know if that solves the problem.  If so, I'll adjust the default in
for Gerrit 2.1.2.
Summary: auth.type LDAP uses wrong username on Active Directory
Status: Accepted
Labels: -Type-Feature Type-Bug Milestone-2.1.2
Feb 1, 2010
#4 jeffreys...@gmail.com
Even with those settings I'm still not able to authenticate. Is there anyway to
enable debugging so we can see what the LDAP query is that's being sent?
Feb 1, 2010
#5 sop@google.com
Not really, no, there aren't enough debugging settings.  :-(

IIRC the ldapsearch would be:

  ldapsearch -x -W -D $username -H ldaps://adserver \
    -b cn=Users,dc=company,dc=com \
    '(&(objectClass=user)(userPrincipalName=${username}))'

where ${username} is the value typed into the Username box in the
dialog that Gerrit presents when you click Sign-in.

E.g. if you enter "jeff@company.com" in the username box:

  ldapsearch -x -W -D jeff@company.com -H ldaps://adserver \
    -b cn=Users,dc=company,dc=com \
    '(&(objectClass=user)(userPrincipalName=jeff@company.com))'

You might have to hack the LdapQuery and/or LdapRealm classeses
and recompile from source to get any debugging into the login.
Feb 21, 2010
#6 sop@google.com
Changes I8ec3adc36ae3f2363d344521d02755a2b385db0b and
Ic62dccfc48283d9b4f7f27c86c8a404c4c05d3b2 were merged to
support better ActiveDirectory integration.

What's still broken here is we can't query for group membership
of other user accounts that haven't recently logged in.  This is
going to cause problems with evaluating whether or not a change
can be merged as we can't determine if a user was actually able
to do a +2 vote.
Status: Started
Mar 2, 2010
#7 sop@google.com
Slipped to 2.1.3.  I want to get 2.1.2 out.
Labels: Milestone-2.1.3
Mar 2, 2010
#8 sop@google.com
(No comment was entered for this change.)
Labels: -Milestone-2.1.2
Apr 26, 2010
#9 sop@google.com
(No comment was entered for this change.)
Labels: -Milestone-2.1.3
Jun 15, 2010
#10 sop@google.com
Changed summary to better reflect what the remaining
parts of the issue is about.
Summary: ActiveDirectory group querys cannot be anonymous
Status: Accepted
Jul 23, 2010
#11 sop@google.com
Work on this is stalled.  See https://review.source.android.com/13585
Sign in to add a comment

Powered by Google Project Hosting