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
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@samba.org http://samba.org
> -----Original Message----- > From: samba-bounces+bob.gautier=rabobank.com@lists.samba.org > [mailto:samba-bounces+bob.gautier=rabobank.com@lists.samba.org] On Behalf Of Neal A. Lucier> Sent: 03 August 2006 14:55 > To: samba@lists.samba.org > Subject: [Samba] winbind rfc2307 mapping not "correct" > > 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". > ...You make some interesting points, but some (much?) of the existing idmap_ad behaviour makes it fit quite naturally into an (ok, my) existing AD environment. Won't 'idmap backend = ldap' give you the functionality you are asking for? (Especially if you set it up to query the GC?) Bob Gautier _____________________________________________________________ This email (including any attachments to it) is confidential, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this email in error, please advise us immediately and delete it. You are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Although we have taken reasonable precautions to ensure no viruses are present in this email, we cannot accept responsibility for any loss or damage arising from the viruses in this email or attachments. We exclude any liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided in this email or its attachments, unless that information is subsequently confirmed in writing. If this email contains an offer, that should be considered as an invitation to treat. _____________________________________________________________