<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi tech,</p>
<p>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.</p>
<p>Some background: we are using the RFC2307 LDAP schema extensions
which define the <tt>uidNumber</tt> and <tt>gidNumber</tt>
attributes on user objects (representing the POSIX user id and
primary group id respectively) and the <tt>gidNumber</tt>
attribute on group objects (representing the POSIX group id).
Groups typically have multiple values for the <tt>member</tt>
attribute for each of their member user/group objects, and each of
those will then have a corresponding <tt>memberOf</tt> attribute
for each parent group.<br>
</p>
<p>Each AD user has an LDAP attribute <tt>primaryGroupID</tt> 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 <a moz-do-not-send="true"
href="https://lists.samba.org/archive/samba/2014-October/186252.html">here</a>).
For example, with a primary group of wheel (SUID <tt>S-1-5-21-3342141748-1574249315-1264630062-</tt><tt><b>512</b></tt>),
<tt>primaryGroupID</tt> would be set to 512. The fact that for
some groups (such as wheel) the POSIX gid is the same as the value
of <tt>primaryGroupID</tt> should be treated as a coincidence.<br>
An interesting quirk is that any group that is referenced in a
user object by the <tt>primaryGroupID</tt> attribute will <b>not</b>
have the corresponding <tt>member</tt> and <tt>memberOf</tt>
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 <tt>member</tt>
values for a particular group.</p>
<p>It seems like the <tt>primaryGroupID</tt> was created for
compatibility with Mac / POSIX clients (see <a
moz-do-not-send="true"
href="https://support.microsoft.com/en-au/help/2379276/information-about-active-directory-and-posix-primary-group-settings-on">here</a>
for an official explanation, and <a moz-do-not-send="true"
href="https://serverfault.com/questions/518608/purpose-of-primary-group">here</a>)
but since we are using RFC2307 this should probably be superseded
by the <tt>gidNumber</tt> 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 <tt>primaryGroupID</tt>
(see <a moz-do-not-send="true"
href="https://wiki.samba.org/index.php/Idmap_config_ad#The_RFC2307_and_template_Mode_Options">here</a>),
but winbind >= 4.6.0 can be configured to use the <tt>gidNumber</tt>
attribute by setting <tt>idmap config
UCCDOMAYNE:unix_primary_group = yes</tt>. In some cases, this
can cause inconsistent behaviour across machines when <tt>gidNumber</tt>
and <tt>primaryGroupID</tt> get out of sync (note that they
should not necessarily have the same numeric value, since they
refer to completely different things).</p>
<p>My suggestion is thus to set all users' <tt>primaryGroupID</tt>
to 513 (the default for AD (see <a moz-do-not-send="true"
href="https://lists.samba.org/archive/samba/2016-March/198545.html">here</a>
and <a moz-do-not-send="true"
href="https://lists.samba.org/archive/samba/2016-March/198549.html">here</a>,
which refers to the <tt>gumby</tt> group [Domain Users]) and only
use <tt>gidNumber </tt>for UNIX primary groups. This would mean
upgrading <tt>winbind</tt> to >= 4.6.0 where possible or
replacing it with <tt>sssd</tt> (using configuration adapted from
<a moz-do-not-send="true"
href="https://wiki.ucc.asn.au/NewActiveDirectory/LinuxClients">the
new AD wiki page</a>) to resolve the inconsistent behaviour and
to make querying AD groups over LDAP more straightforward.</p>
<p>Happy new year!</p>
<p>Felix von Perger [FVP]<br>
UCC President & Wheel Member<br>
</p>
</body>
</html>