[Samba] winbind rfc2307 mapping not "correct"

Neal A. Lucier nlucier at math.purdue.edu
Thu Aug 3 13:55:17 GMT 2006

IMHO the option "winbind nss info = rfc2307" does not fully conform to
the rfc2307 spec to generate user and group data and is thus
"incorrect".  The way it is currently done does solve one issue related 
to group membership mapping, but if I understand the way permissions are 
checked it is a non-issue.

I think it is broken in the following 2 ways:
1. to generate the GID of the user (for the output of 'getent passwd'), 
winbind looks at the ADS attribute, primaryGroupID, instead of the 
rfc2307 attribute, gidNumber.  By using the RID from primaryGroupID a 
2nd lookup must be done to get the gidNumber from the group.  In 
addition if the object specificed by primaryGroupID has not been 
extended to include rfc2307 attributes that user is not listed in the 
output of 'getent passwd' though they may have a valid gidNumber 
specified.  (This is particularily annoying for me as I don't plan on 
mapping "Domain Users" to an equivelant unix group, and all users on 
creation default to a primaryGroupID of 513.)

2. to generate the list of users that are in a group (for the output of 
'getent group', winbind looks at the ADS attribute, 'member', instead of 
the rfc2307 memberUid.  Again, by using the dn from 'member' a 2nd 
lookup must be done to get the uid of each member.

The additional lookups aren't that bad because of the cache; however my 
main concerns are:
a. ADS enforces referential integrity on the attribute primaryGroupID, 
i.e. the user must already be a (windows) member of the group before 
that group can be set as the primary group.  This behaviour is in direct 
contrast to how posix groups work, where setting the gidNumber of a user 
both adds that user to the group and sets that group to be the user's 
primary group.

b. Since MS choose to keep the posix group memberships seperate from 
windows group membership, it's really annoying that samba decided to 
blend the two (especially since the mapping name is 'rfc2307'.)  (I'm 
biased since I already have a complete posix group structure that I'm 
attempting to map into ADS as painlessly as possible.)

There is a problem with samba using memberUid instead of member; on the 
client windows machine the logged in user could possibly not be a 
windows member of a group, and yet be a posix member of a group and thus 
might not have access to files they otherwise should have access to.

In my paticular scenario I think that is a non-issue because:
i. I only have samba servers, no Windows file servers, so at least all 
my file servers will know the correct group information for everyone
ii. by extension of (i.) if access permissions are checked at the server 
and not at the client, the logged in user will still be able to access 
all relevant shares which they have posix group access to

If (ii.) is incorrect then really this whole email is a little moot; 
however, I thought of my objections to which attribute were being 
queried before I thought of the group membership issue on client machines.

I propose that the combination of "idmap_backend = ad" and "winbind nss 
info = rcf2307" be changed to actually look at the rfc2307 group 
attributes instead of the windows group attributes.

I have just started to wrap my mind around the complexities of 
posix<->windows mapping, and I look forward to any response that expand 
my understaning.


More information about the samba mailing list