Paul, Looks like the Ambari 2.2.1 LDAP selection logic is fouled up as you noted. I was able to pull in the group memberships from Windows AD using these ambari.properties file values (only relevant properties shown): authentication.ldap.baseDn=ou=myorgunit,ou=mydomain,ou=com {masked to protect security} authentication.ldap.dnAttribute=distinguishedName authentication.ldap.groupMembershipAttr=member authentication.ldap.groupNamingAttr=cn {Note that for Windows AD/Server 2008 R2, group attributes: cn, name and sAMAccountName all contain the same value which is the group name so either of these three values should work} authentication.ldap.groupObjectClass=group {also can be top} authentication.ldap.userObjectClass=user {also can be top;person;organizationalPerson} authentication.ldap.usernameAttribute=sAMAccountName While the membership information now pulls in from Windows AD to Ambari 2.2.1 using "ambari-server sync-ldap --all" with the groupNamingAttr=cn and groupMembershipAttr=member, Ambari is now pulling in ALL AD users who are members of the AD group. Because my baseDn=ou=myorgunit,ou=mydomain,ou=com, I should only be pulling the subset of AD group members who are actually contained in the "myorgunit" organizational unit (OU), not ALL AD group members in the host domain. (Changed the groupNamingAttr=cn from =sAMAccountName for Ambari 2.1.1 and it works as expected i.e. doesn't bring in any additional users, but maintains group membership as before. ) ... View more