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.
Thanks,
Neal
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
