Feature #10990


Get UNIX group info. from AD/LDAP with partial RFC2307 schema

Added by Gordon Ross about 2 years ago. Updated about 2 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


RFC2307 ( defines the expected fields within LDAP that should be present to allow UNIX systems to use LDAP as a naming service. This is a well documented and accepted RFC for UNIX and Storage vendors alike.

These extensions are typically added into Active Directory by installing IDMU on the Windows DC and are commonly used in the field to facilitate Windows to Unix mapping of users and groups as well as being required to workaround the 16-group NFS limitation as outlined in and NEX-1974.

Certain customer environments may not have fully implemented RFC2307 for historical reasons and instead rely on 3rd party software (Vintela or Centrify) for bridging the gap and allowing UNIX/Linux to use Active Directory to provide User and Group membership.

The end result of this is that certain fields may be missing or named differently or contain different information. For renamed fields this can be worked around by setting the attributemap option to the ldapclient command. Missing fields are far more problematic.

Related issues

Related to illumos gate - Bug #12240: nss_ldap does not properly look up group members by distinguished nameClosed

Actions #1

Updated by Gordon Ross about 2 years ago

  • Description updated (diff)
  • Status changed from New to In Progress
Actions #2

Updated by Gordon Ross about 2 years ago

This case shows us the practical effects of a typical AD setup where a customer continues to use (some of) the RFC-2307 schema after Microsoft ended their official support for their IDMU features.
Note that LDAP (and AD) have always allowed for schema extensions. The Microsoft IDMU extension for AD just made it convenient to manage the RFC-2307 extensions with actions such as:

When adding a new user, automatically setting "uidNumber".
When adding a new group, automatically setting "gidNumber".
When adding/removing a user to/from a group, maintaining the "uidNumber" array in that group.
Without the MS IDMU features, AD adminisrators can and do still use parts of the RFC-2307 schema, but none of those automatic actions in AD happen anymore. The consequence is that, if they want users and groups to have Unix-compatible UID and GID values, they have to fill in those fields manually. (Or they might use a 3rd party product to do that.)

The result is that user objects in AD typically do have a "uidNumber" and "gidNumber" that Unix clients can use. Similary, groups have a "gidNumber", but note: groups typically DO NOT have a "uidNumber" array. That means the only way to determine group membership is to consult the "member" array under the group. That serves the same purpose as the "uidNumber" array would have done, but the members are recorded using their full "distinguished name" (DN) form, not their "uid" (or "samAccountName" in AD).

The implications of all this for our LDAP client are:

When requesting information about a group (including it's list of members, i.e. "getent group somegroup") we can ask for the "memberUid" array, but need to prepared for that array being missing or empty. The remedy is to additionally request the "member" array for the group, and for each member in that array, lookup the "uid" (which in AD is mapped to "samAccountName") and return that to Unix as the name of the member. As an example, given a user with samAccountName="jane.doe" and
DN="CN=Doe\, Jane,OU=Users,DC=contoso,DC=com",
we'll find that DN in the "members" array, lookup the "uid" and get "jane.doe", finally returning that "uid" in the Unix group members list.
When requesting the list of groups in which a given user is a member (i.e. "groups someuser") we can write an LDAP query for a list of groups for which "memberUid=user", but we need to be prepared for that query to have no results. In this case, the remedy is to modify that query to ask for all groups in which either "memberUid=user" OR "member=DN". That means we have to get the user's DN before we can write this query, but that's simple. With that modification in place, we'll get a complete list of groups in which they are a member. In that query result, some groups might not have a "gidNumber", which case we just skip those groups because they're of no interest to a Unix client.
We have a prototype of this design change under test. Initial results look good.

Actions #3

Updated by Gordon Ross about 2 years ago

Testing of this is tricky because one must setup an AD environment with partial schema per. the issue description.
Verified at the customer site. Fix in production since late 2017

Actions #4

Updated by Gordon Ross about 2 years ago

I had forgotten how much the Service Search Descriptors (SSD) substitution complicates all of this.
Here's what the LDAP SSD configuration looks like when your LDAP server is AD:


 ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN="cn=test,cn=Users,$dom" \
-a proxyPassword=test \
-a defaultSearchBase="$dom" \
-a \
-a defaultServerList=$SERVER \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor="passwd:cn=users,${dom}?sub" \
-a serviceSearchDescriptor="group:cn=users,${dom}?sub" 

That means (i.e.) when we query for object class "posixAccount" the query goes out with object class "user".
Oh it's so much fun when what you see (in the code) is not what goes out on the wire :)

Actions #5

Updated by Electric Monk about 2 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit 695ef821379e863d33c30fb148f4ecf87038b246

commit  695ef821379e863d33c30fb148f4ecf87038b246
Author: Gordon Ross <>
Date:   2019-05-30T21:30:45.000Z

    10990 Get UNIX group info. from AD/LDAP with partial RFC2307 schema
    Reviewed by: Matt Barden <>
    Reviewed by: Evan Layton <>
    Reviewed by: Chris Ridd <>
    Approved by: Dan McDonald <>

Actions #6

Updated by Jason King over 1 year ago

  • Related to Bug #12240: nss_ldap does not properly look up group members by distinguished name added

Also available in: Atom PDF