This question about LDAP: Needs followup in Tasks
primaryGroupID resolution with Windows Active Directory
We have our Foswiki installation configured to successfully use users and groups from our Windows Server 2008 R2 Active Directory LDAP domain. The only problem we're having is how to use the "primary group" as defined by Active Directory.
In AD, the primary group of a user is specified in the user record as primaryGroupID. For the group record, however, the GID is set in the primaryGroupToken attribute.
From our understanding, the group resolution when working with AD should consist of:
- LDAP query for the named group's primaryGroupToken
- LDAP query over all users where the user's primaryGroupID equals the group's primaryGroupToken
- merge in the group's memberOf attribute
Here are our LDAP Group settings (GroupBase is correct, but not included below). All LDAP groups work fine except for "Domain Users". As every LDAP User has their primaryGroupID set to "Domain Users", it would be useful to use this group to authorize any LDAP user (as opposed to local Foswiki users).
$Foswiki::cfg{Ldap}{GroupFilter} = 'objectClass=group';
$Foswiki::cfg{Ldap}{GroupScope} = 'sub';
$Foswiki::cfg{Ldap}{GroupAttribute} = 'sAMAccountName';
$Foswiki::cfg{Ldap}{PrimaryGroupAttribute} = 'primaryGroupID';
$Foswiki::cfg{Ldap}{MemberAttribute} = 'member';
$Foswiki::cfg{Ldap}{InnerGroupAttribute} = 'member';
$Foswiki::cfg{Ldap}{MemberIndirection} = 1;
$Foswiki::cfg{Ldap}{WikiGroupsBackoff} = 1;
$Foswiki::cfg{Ldap}{NormalizeGroupNames} = 0;
$Foswiki::cfg{Ldap}{MapGroups} = 1;
$Foswiki::cfg{Ldap}{RewriteGroups} = {
'^(.*)\\s(.*)$' => '$1$2'
};
$Foswiki::cfg{Ldap}{MergeGroups} = 0;
--
DevinBougie - 13 Mar 2013
In other words,
LdapContrib misses one group for every user. It does not see that users are part of whatever group is defined in AD using the primaryGroupID attribute for that user. This happens regardless of what's configured in Foswiki as the PrimaryGroupAttribute.
http://msdn.microsoft.com/en-us/library/cc220547.aspx
http://msdn.microsoft.com/en-us/library/cc220723.aspx
--
DevinBougie - 14 Mar 2013
Changed this to "Need Followup in Tasks". This does seem to be a bug, but
MichaelDaum would know better.
--
GeorgeClark - 07 Apr 2013
Thanks, George. I've now created
Tasks.Item12669.
--
DevinBougie - 27 Nov 2013
The way AD handles the primary group is more complicated than in the posix case. The primaryGroupId is the relative identifier (RID) of the group object's security identifier (SID). For example,
Domain Users has a SID, S-1-5-21-1921824074-547830868-893353407-1105
the RID is, 1105 (the right-most portion of the SID)
the primaryGroupId for my users is, 1105
The only way I can see to handle this in
LdapContrib is to create a "IsActiveDirectory" checkbox so it will know how to handle these types of differences.
--
ChrisHoefler - 12 Feb 2014
Pardon, my example posted again for readability,
Domain Users has a SID, S-1-5-21-1921824074-547830868-893353407-1105
the RID is, 1105 (the right-most portion of the SID)
the primaryGroupId for my users is, 1105
--
ChrisHoefler - 12 Feb 2014
If you have access to your AD, a workaround is to include posix attributes in your schema. So instead of trying to map the primaryGroupId, you give all of your groups gidNumber attributes.
--
ChrisHoefler - 12 Feb 2014