samba - Feb 2011 - Problem with Winbind/Kerberos authentication against AD 2003R2 RFC2307

Samba Team,

I have posted this issue before but it seems to have gotten "lost in the
storm."

I have several Linux servers set up to authenticate users using AD
credentials.
The one server that actually works right is running Samba 3.2.7. The
presence of RFC2307 attributes in the user object, in conjunction with a
UID in the range set in smb.conf determines whether the user enumerates,
and the RFC2307 attributes in the group object and the GID in the range
set in smb.conf  determines whether the group enumerates.   

The appropriately configured users and groups enumerate through both
wbinfo and getent.

When you issue getent passwd, you get the local passwd entries followed
by the AD entries.  The AD users that enumerate with getent passwd show
the UID attribute value from their AD object, the primary GID attribute
value from their AD object, the shell command from the AD object and the
home directory path from their AD object.  All is well with that system.


The other servers are running Samba 3.4.3.  I have also tried Samba
3.5.2 but had even worse luck with that and backrevved to 3.4.3. The
smb.conf are set up similarly to the 3.2.7 server but have differences
dictated by the difference in versions.  I tried many, many different
things to try to get either 3.4.3 or 3.5.2 to enumerate the same way
3.2.7 did.  I could always get a couple of the groups to show up - not
all of them - in a getent group, but getent passwd would never enumerate
the AD users.  Getent passwd <username> however, would enumerate that
one user.  Problem is, it appears to me anyway that unless you can
enumerate the users with getent passwd, you can't assign ACLs to them.
At least I can't find a way.

Researching the problem, I hit upon a workaround that is not a solution,
but does explain what is going on.  I added a value to the GID attribute
of the "Domain Users" AD group, and suddenly, all of my users
enumerated
using getent passwd.  Problem is, they enumerate with all of the RFC2307
attribute values EXCEPT the primary group GID.  That is replaced by the
GID I gave to Domain Users. 

If you issue a getent passwd <username> you still get the RFC2307 GID
for the primary group entry, but that same user in the getent passwd
list has the "Domain Users" GID in the primary group entry.

If the "Domain Users" group is given a GID outside the range for the
domain in smb.conf, it's back to broken.

I need the GID in the RFC2307 gidNumber attribute to be used for the
primary GID, as it did in 3.2.7, as I suspect it's supposed to be given
that it properly assigns that attribute when you specify the user name.

The GID in the users' AD objects is outside the range specified for the
domain set in smb.conf, so that the locally-defined group can exist
without requiring AD, as it's used by system processes.  I need the
primary GID to be that locally-defined GID, not whatever "Domain
Users"
has assigned.

If I change "Domain Users" to be the same GID as the locally-defined
group that must be the primary GID for all users, and must be a specific
GID that's not currently in the UID/GID range assigned in smb.conf for
the domain, then I would have to expand the UID/GID range for the domain
to include that GID, or nobody enumerates properly.

That's another problem.  I am in a multi-domain AD forest.  If I expand
one domain's range to include that GID, that effectively locks out the
other domains in the forest from using that same GID as the primary GID,
which is another reason I need the gidNumber attribute's property to be
*THE* GID used for primary group, for all users of the system that have
that attribute populated, regardless of domain or AD group membership.

Is there a switch or directive or something that is not documented, that
would either turn off the requirement to use "Domain Users" for
enumeration, or at least turn off the forced use of "Domain Users" as
the primary GID, so enumeration goes back to the way it worked pre-3.30
and the users' gidNumber value is the one that's used?  I'm guessing
the
change was made to use "Domain Users" for efficiency's sake,
rather than
spinning through the entire directory looking for users/groups with
rfc2307 attributes, but the way it was done, in my opinion, broke a
basic feature.  (It would have been nice to see the new "domain users"
group requirement show up in the MAN pages for idmap ad, at least, if
there isn't a more appropriate place... That would have saved me a whole
lot of head-scratching and late nights.)

I don't know what the specific components are that do the enumeration,
since I'm not part of your project team, ;) but I suspect that this
particular piece would have to have something to do with nss_winbind.so,
because nss is what getent uses to determine where to look, right?

If nothing else, is there a way to recompile the 3.2.7 nss_winbind.so to
work with 3.4.3?  I really hate being as far behind as 3.4.3 even, much
less being stuck at 3.2.7 for the main production Linux server... But I
need this to work.

I sincerely doubt that this issue is caused by any of my config files,
since I tried probably every possible combination related to winbind,
nss, kerberos, ads, rfc2307, idmap, etc. in trying to figure out what's
going on here, but if you'd like me to post them, I will do so.  It's
possible that I'm missing a new directive related to idmapping - some
other functionality, setting, or whatever, that is in the post-3.0 idmap
component but isn't documented in the 3.4.3 or 3.5.x or other post-3.0
man pages, yet.  

Anyway, besides helping me with this problem, if I might humbly suggest
someone add the new (as of 3.3 anyway) requirement for idmap ad and
enumeration to clearly indicate that in order to enumerate through
getent passwd, the primary group now must be "domain users" and it
must
be in the idmap range for your domain, and if there's a way to turn that
requirement off or to modify the source of the primary GID for a user to
use the rfc2307 gidNumber instead of whatever GID is assigned to "Domain
Users." please also include that, so someone else doesn't have to go
through what I did to get to this point.

Thanks!

Jim.