[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