[Samba] UNIX vs. AD group permissions

[David Pullman]

We've just built a RHEL 5 ES server to test the issues we've been having 
with group permissions since 3.0.23 (re: 3.0.23d UNIX vs. AD group 
permissions) and we found we have the same issue with the Redhat built 
rpm of version 3.0.23c.

The following is the ldap and winbind portion of our smb.conf, the same 
as used on our current Solaris production servers:

    # ldap settings
    ldap admin dn = cn=ldapmaster,dc=mel,dc=nist,dc=gov
    idmap backend = ldap:ldap://ldap1.mel.nist.gov
    ldap idmap suffix = ou=Idmap
    ldap suffix = dc=mel,dc=nist,dc=gov

    idmap uid = 16777216-33554431
    idmap gid = 16777216-33554431
    template shell = /bin/false
    winbind use default domain = no
    winbind trusted domains only = yes

We don't allocate uids or gids with this setup, only map the sids so 
that a user can work with ACLs on the Windows workstations.  (The NIS 
uids and gids are handed out from a superior database to ensure common 
account ids across labs with no common authentication system.)

We have all usernames manually the same in NIS and in AD, and we don't 
have any groups in AD.  The UNIX file system permissions have always 
worked before 3.0.23, specifically if you are a member of a group in NIS 
then you can access the files and directories on the SAMBA server from a 
Windows AD workstation.

Since 3.0.23, if winbind is running, the SAMBA server will get a list of 
groups from AD and not from NIS.  If winbind is not running, it gets the 
list of groups from NIS.  We don't maintain groups in AD, so any shared 
directories will not allow group members.

I think I've checked all of the release notes and the updated man pages 
and while there are lots of changes in the 3.0.23 to 3.0.25 versions, I 
can't find anything that indicates this should be happening.  I'd be 
glad to create level 10 logs to show what's happening (as I did in the 
previous posts and the bugzilla entry 4348).

If anyone has any suggestions I'd greatly appreciate it.  We're still 
running 3.0.14 and can't update production until we can sort this out.

--
David Pullman