[Samba] winbind rfc2307 mapping not "correct"

[simo]

CCed samba technical as this is a development/bug issue.

On Thu, 2006-08-03 at 09:55 -0400, Neal A. Lucier wrote:
> 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.

As jerry like to put it out, the rfc2307 mapping in AD is a mess :-)

> 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.)

I agree with this point, we should really use the gidNumber specified
and not try to map the windows user primary group, as that's what most
admins would like to do.
One of the reasons is that many may not have any chance of convincing
the Windows Administrators to change the users primary group and yet for
these admins it may make no reasons to have Domain Users as their users
primary group (exp. when you have to migrate existing NIS domains or
passwd files).

> 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.

I do  not agree on this. Because this would completely decouple the
group membership management, making it completely incompatible between
Windows and Samba. For any other Linux application it would work, not
for Samba IMO.
But I see that perhaps an option to use either method may make sense.
something like:
winbind nss info = rfc2307  vs  winbind nss info = rfc2307-memberUid

> 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.)

Not really MS just added all the rfc2307 attributes but, as the proposed
rfc2307bis make the usage of memberUid optional and proposes to use
uniqueMember (which is equivalent to member for the scope of our
discussion), they prefer the usage of member.

> 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.

exactly, that's why it is much more difficult to use memberUid on samba,
not really what you would like to do.

> 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.

welcome to one very difficult problem to solve, which can't be solved
without breaking some eggs on the road :)

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org