Bug 6766 - 'winbind nss info = rfc2307' breaks 'idmap backend = hash'
'winbind nss info = rfc2307' breaks 'idmap backend = hash'
Product: Samba 3.4
Classification: Unclassified
Component: Winbind
x86 Linux
: P3 normal
: ---
Assigned To: Michael Adam
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2009-09-27 02:10 UTC by Nick (550-5.1.1 The email account that you tried to reach does not exist)
Modified: 2009-11-19 07:04 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Nick (550-5.1.1 The email account that you tried to reach does not exist) 2009-09-27 02:10:19 UTC
Given a user with these attributes in AD:

sAMAccountName: testuser
gidNumber: 100
uidNumber: 1111
loginShell: /bin/csh

And config file:
template shell = /bin/bash
idmap backend = hash
winbind nss info = template

The results are as expected, with uid and gid being generated from a hash (uidNumber and gidNumber being ignored), and the shell being taken from the 'template shell' (loginShell is being ignored):
wbinfo -i testuser

However when "winbind nss info = rfc2307" is set, all of a sudden gidNumber is being used instead of the hashed value:

Unfortunately in our environment we are migrating to a new AD where the uidNumber and gidNumber attributes are broken and cannot currently be used.  The hash plugin is a good workaround for this (yay!).  However we must use the loginShell (which may not be set for all users, so some users will need to get the template shell which seems to be supported), so we also need "winbind nss info = rfc2307".  Unfortunately this causes a mess since it causes the gidNumber attribute to be used when it shouldn't be.

It would be awesome if this could be fixed so that the hashed group id always is used when 'idmap backend = hash'.
Comment 1 Nick (550-5.1.1 The email account that you tried to reach does not exist) 2009-11-14 13:52:39 UTC
After looking through the code a bit I found 2 iterations of the following in winbindd/idmap_ad.c:

if (gid) {
  if ( !ads_pull_uint32(ads, msg, ctx->ad_schema->posix_gidnumber_attr, gid ) )
    *gid = (uint32)-1;

If I replace them with:
if (gid) {
    *gid = (uint32)-1;

Then I get the expected behavior when the idmap backend is not ad.

The problem could probably be fixed by putting an extra conditional to only call ads_pull_uint32 when the idmap backend is ad.  However I'm not familiar with the codebase so there could definitely be a better way.  If any of the developers could give me some pointers on what method would most likely be accepted upstream, I'd be willing to do some code hacking to try and come up with a viable patch.
Comment 2 Michael Adam 2009-11-19 07:03:37 UTC
It actually never occurred to me that one would use
nss info from AD while using a different idmap backend than
the sfu style backends. But well, I guess this request is
very valid. I'll have to investigate the code and see if
the change you suggested is appropriate for all circumstances.