illumos gate

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.

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

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:

dom="dc=blue,dc=ma,dc=contoso,dc=com" 

 ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN="cn=test,cn=Users,$dom" \
-a proxyPassword=test \
-a defaultSearchBase="$dom" \
-a domainName=blue.ma.contoso.com \
-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 :)