[tech] Active Directory group attributes

Felix von Perger frekk at ucc.asn.au
Tue Jan 1 14:48:08 AWST 2019


Hi tech,

Following some investigation this morning into determining group 
memberships via LDAP (which is used by memberdb), I came across a few 
bits of information which could be useful to help standardise our AD 
configuration a bit more.

Some background: we are using the RFC2307 LDAP schema extensions which 
define the uidNumber and gidNumber attributes on user objects 
(representing the POSIX user id and primary group id respectively) and 
the gidNumber attribute on group objects (representing the POSIX group 
id). Groups typically have multiple values for the member attribute for 
each of their member user/group objects, and each of those will then 
have a corresponding memberOf attribute for each parent group.

Each AD user has an LDAP attribute primaryGroupID which is used to 
determine the primary group in a Windows environment, and takes an 
integer value representing a group RID (which is just the last section 
of the Windows SUID associated with a group object, see here 
<https://lists.samba.org/archive/samba/2014-October/186252.html>). For 
example, with a primary group of wheel (SUID 
S-1-5-21-3342141748-1574249315-1264630062-*512*), primaryGroupID would 
be set to 512. The fact that for some groups (such as wheel) the POSIX 
gid is the same as the value of primaryGroupID should be treated as a 
coincidence.
An interesting quirk is that any group that is referenced in a user 
object by the primaryGroupID attribute will *not* have the corresponding 
member and memberOf attributes (and changing the primary group in LDAP 
will either add/remove these attributes to both the user and group 
objects as necessary), however for all purposes that user is considered 
to be a member of that group. This makes group queries quite hard 
because you can't rely on simply reading the list of member values for a 
particular group.

It seems like the primaryGroupID was created for compatibility with Mac 
/ POSIX clients (see here 
<https://support.microsoft.com/en-au/help/2379276/information-about-active-directory-and-posix-primary-group-settings-on> 
for an official explanation, and here 
<https://serverfault.com/questions/518608/purpose-of-primary-group>) but 
since we are using RFC2307 this should probably be superseded by the 
gidNumber attribute on user objects (which is respected by most of our 
running systems). However, older versions of Samba/winbind < 4.6.0 will 
ignore this and determine the primary POSIX group based on the value of 
primaryGroupID (see here 
<https://wiki.samba.org/index.php/Idmap_config_ad#The_RFC2307_and_template_Mode_Options>), 
but winbind >= 4.6.0 can be configured to use the gidNumber attribute by 
setting idmap config UCCDOMAYNE:unix_primary_group = yes. In some cases, 
this can cause inconsistent behaviour across machines when gidNumber and 
primaryGroupID get out of sync (note that they should not necessarily 
have the same numeric value, since they refer to completely different 
things).

My suggestion is thus to set all users' primaryGroupID to 513 (the 
default for AD (see here 
<https://lists.samba.org/archive/samba/2016-March/198545.html> and here 
<https://lists.samba.org/archive/samba/2016-March/198549.html>, which 
refers to the gumby group [Domain Users]) and only use gidNumber for 
UNIX primary groups. This would mean upgrading winbind to >= 4.6.0 where 
possible or replacing it with sssd (using configuration adapted from the 
new AD wiki page 
<https://wiki.ucc.asn.au/NewActiveDirectory/LinuxClients>) to resolve 
the inconsistent behaviour and to make querying AD groups over LDAP more 
straightforward.

Happy new year!

Felix von Perger [FVP]
UCC President & Wheel Member

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20190101/f9ee86ac/attachment.htm 


More information about the tech mailing list