Issue 283: ActiveDirectory LDAP Support
Status:  Released
Owner:
Closed:  Oct 2012
Project Member Reported by m.bn...@gmail.com, Sep 28, 2009
Right now Gerrit seems incapable of searching for group members because of
the way the queries are structured versus what ActiveDirectory accepts.

LdapRealm.java is most likely the problem.

A query such as:
$ ldapsearch -x -h ldap.ad.xxx.com -D ldapuser@ad.xxx.com -w readonly
"(CN=Newnam, Anthony)" memberOf

Will return all of the groups that I am in, whereas:
$ ldapsearch -x -LLL -h ldap.ad.xxx.com -D ldapuser@ad.xxx.com -w readonly
-b "dc=ad,dc=xxx,dc=com" -s sub "(&(objectClass=group)(member=*N*))"

Will give no data (any value beside * for member acts the same).

More discussion:
http://groups.google.com/group/repo-discuss/browse_frm/thread/ebe2598b87cf1eb8#
Sep 28, 2009
Project Member #1 m.bn...@gmail.com
I'm going to fix this today probably, if you would like to assign it to me.

Is there a good way to test changes to parts of Gerrit without rebuilding the .war
and restarting jetty?
Sep 28, 2009
#2 sop+code@google.com
> Is there a good way to test changes to parts of Gerrit without rebuilding the .war
> and restarting jetty?

No.  If you are using Eclipse you might be able to get the hosted mode debugging
to work, which typically saves quite a bit on the rebuild time and allows you to
debug the code.  But sometimes, all you can do is rebuild the war and retest on
a real servlet container.
Status: Accepted
Owner: m.bnovc
Sep 28, 2009
#3 sop+code@google.com
Also see  issue 271  which talks about trying to get recursive group membership
reported from ActiveDirectory so nested groups work as expected.
Sep 29, 2009
Project Member #4 m.bn...@gmail.com
It would appear that you also can not search by "dn" in AD.

The patch I submitted finds if a user in a group if you put the dn in because that is
what memberOf returns, but if you put the cn in, it won't find them.

I'm not sure of a good way to handle this, especially one that supports recursive
group lookups. I could store the DN and CN in the account_groups table, so when I get
the memberOf list back, I can lookup the AccountGroup by DN.
Sep 29, 2009
#5 shawn.pe...@gmail.com
To search by "dn" in any LDAP server you actually need to do:

  ctx.getAttributes("CN=Some Group, OU=Groups, DC=example, DC=com")

Where ctx is the DirContext handle you already have open.  So you can still pull back
the group's attributes without needing to store the DN in Gerrit.


Oct 1, 2009
Project Member #6 m.bn...@gmail.com
What's the reason for "groupNeedsAccount" and account* member variables being
parametrized strings instead of normal strings? It seems like you just add "${}"
around them and then get the name back out.

Do you have any ideas on how to support recursive groups this way? The only way I
know is to do something like:
while (parent group exists) {
if (!ldapGroup(curr group)) {
curr group = parent of current; (via getting memberOf from a query on that group)
}
}
not very efficient, though.
Oct 1, 2009
#7 sop+code@google.com
The account* variables are parameterized strings so you can say things like

  accountFullName = ${givenName} ${sn}

to concatenate two fields from LDAP into one string for Gerrit.  Some organizations
set the displayName in LDAP to "${sn}, ${givenName}" which looks horrible in the UI
in Gerrit.  So being able to flip the order around to the more western style of name
is preferred by some users.

Recursive group support is ugly.  Basically you just have to code a recursive method
which loops through groups and collects them together:

  Set<String> groupsFor(Set<String> inputGroups) {
    Set<Group> out = new Set<Group>();
    for(String g : inputGroups) {
      out.add(g);
      out.addAll(groupsFor(ctx.getAttributes(name).getAttribute("memberOf")))
    }
    return out;
  }
Oct 6, 2009
#8 sop+code@google.com
Fixed by I3196a8e9f5c08dedccd05d2de10c55042933e427
Status: Fixed
Labels: FixedIn-2.0.24
Oct 21, 2012
#9 sop@google.com
(No comment was entered for this change.)
Status: Released
Blocking: -gerrit:271