samba - Jan 2007 - 3.0.23d UNIX vs. AD group permissions

We have what may be a very, very bad situation here and I'm hoping 
someone may be able to point out either where I'm misinterpreting this 
or where I missed the memo.

We're testing 3.0.23d so we can upgrade from 3.0.14a.  Our servers are 
all currently Solaris 9, and we build samba from source with MIT krb5 
and openldap libraries.  We have used security = ads since 3.0 after 
having used security = domain with nt4.0 for many years in the 2.2 era.

We also have winbindd running, but only with idmap to an ldap directory 
to map uids to sids.  All usernames are in NIS and the identical 
usernames are in AD, as they were in NT before.  We share all 
directories to both NFS and CIFS clients, with posix acls on the file 
server.  This has worked for years.  We only pursued the winbindd 
feature for idmapping to provide the users with the ability to add a 
name to an acl in Windows.  Currently on 3.0.14a this works fine.

We do not have unix groups, as populated in NIS group, in the AD.  We do 
not use winbind for any authentication.

When we started testing 3.0.23d we found that the primary group of a 
user seemed to be honored for access to a file or directory, but the 
secondary groups were not.  On our test server I cranked up idmap and 
auth logging.  Then we added some group names to AD; this was after I 
asked Gerry at the LISA conference about the issue I was seeing.

In the log snip below the server is getting a bunch of sids for my 
login.  Everyone of these is only the groups that are enumerated on AD, 
specifically with my name in the group.  Also, in trying to access 
folders on a share, only the groups listed will allow permission; if I 
have a group on a directory that I'm a member of in UNIX but not in AD I 
can't access the folder.  ****This is different than it used to be****

[2007/01/11 11:08:40, 10] auth/auth_util.c:(454)
   NT user token of user S-1-5-21-1214440339-839522115-1708537768-1623
   contains 9 SIDs
   SID[  0]: S-1-5-21-1214440339-839522115-1708537768-1623
   SID[  1]: S-1-5-21-1214440339-839522115-1708537768-6843
   SID[  2]: S-1-1-0
   SID[  3]: S-1-5-2
   SID[  4]: S-1-5-11
   SID[  5]: S-1-5-21-1214440339-839522115-1708537768-2254
   SID[  6]: S-1-5-21-1214440339-839522115-1708537768-513
   SID[  7]: S-1-5-21-1214440339-839522115-1708537768-2270
   SID[  8]: S-1-5-32-545
   SE_PRIV  0x0 0x0 0x0 0x0

[root@chrome boogie]$ wbinfo -s 
S-1-5-21-1214440339-839522115-1708537768-6280
MELAD\tac 2
[root@chrome boogie]$ wbinfo -s 
S-1-5-21-1214440339-839522115-1708537768-2270
MELAD\melsa 2
[root@chrome boogie]$ wbinfo -s 
S-1-5-21-1214440339-839522115-1708537768-2254
MELAD\MELSAApps 2
[root@chrome boogie]$ wbinfo -s 
S-1-5-21-1214440339-839522115-1708537768-6843
MELAD\wwwmel 2

Taking this a step farther:  we added a UNIX group to AD and put my name 
in it.  I am not a member of this group in UNIX.  In the snip below that 
sid is now included in my user token.

[2007/01/11 11:34:53, 10] auth/auth_util.c:(454)
   NT user token of user S-1-5-21-1214440339-839522115-1708537768-1623
   contains 11 SIDs
   SID[  0]: S-1-5-21-1214440339-839522115-1708537768-1623
   SID[  1]: S-1-5-21-1214440339-839522115-1708537768-6843
   SID[  2]: S-1-1-0
   SID[  3]: S-1-5-2
   SID[  4]: S-1-5-11
   SID[  5]: S-1-5-21-1214440339-839522115-1708537768-2254
   SID[  6]: S-1-5-21-1214440339-839522115-1708537768-513
   SID[  7]: S-1-5-21-1214440339-839522115-1708537768-6279
   SID[  8]: S-1-5-21-1214440339-839522115-1708537768-2270
   SID[  9]: S-1-5-21-1214440339-839522115-1708537768-6280
   SID[ 10]: S-1-5-32-545
   SE_PRIV  0x0 0x0 0x0 0x0

With this token I was able to create files and directories in a 
directory that had this new group.  I'm not the owner of the directory, 
or a member of the group, and other has only r-x. ****Even though I am 
not permitted to do this in UNIX****

[root@chrome testing]$ ls -al .
total 8
drwxrwsr-x   4 carolyn  adacs        512 Jan 11 11:35 .
drwxr-xr-x   8 root     sys          512 Jan  5 13:37 ..
drwxr-sr-x   2 dpullman adacs        512 Jan 11 11:35 New Folder
[root@chrome testing]$ groups dpullman
melsaunx wwwmel melsa gss gssreq office root sensor lp melsapw sa 
webgroup admin tac

Isn't there a statement somewhere that samba will honor the UNIX 
permissions?  How am I able to write in a directory that I do not have 
access to according to the UNIX permissions?

Is it the intention of the samba development that all UNIX groups will 
have to not only be listed in AD, but also populated?

Thanks very much.

-- 
David Pullman
Systems Administrator
Manufacturing Engineering Laboratory
National Institute of Standards & Technology
Mail Stop 8203
100 Bureau Drive
Gaithersburg, MD 20899-8260
Tel: (301) 975-5385
Fax: (301) 926-3842
E-mail: david.pullman@nist.gov

In some subsequent testing it seems to be in winbind: by commenting out 
the ldap, idmap, and winbind params in smb.conf and not starting 
winbindd, the authorization is as expected:

When I access the share, I get the slew of groups  that I belong to in 
UNIX mapped to the S-1-22 sid:
[2007/01/11 18:59:56, 10] auth/auth_util.c:(454)
   NT user token of user S-1-22-1-19122
   contains 18 SIDs
   SID[  0]: S-1-22-1-19122
   SID[  1]: S-1-22-2-4228
   SID[  2]: S-1-1-0
   SID[  3]: S-1-5-2
   SID[  4]: S-1-5-11
   SID[  5]: S-1-22-2-3001
   SID[  6]: S-1-22-2-4227
   SID[  7]: S-1-22-2-4031
   SID[  8]: S-1-22-2-4128
   SID[  9]: S-1-22-2-4023
   SID[ 10]: S-1-22-2-0
   SID[ 11]: S-1-22-2-19029
   SID[ 12]: S-1-22-2-8
   SID[ 13]: S-1-22-2-4229
   SID[ 14]: S-1-22-2-304
   SID[ 15]: S-1-22-2-400
   SID[ 16]: S-1-22-2-80
   SID[ 17]: S-1-22-2-4260
   SE_PRIV  0x0 0x0 0x0 0x0

And with the UNIX group that I'm not a member in place on the directory, 
I cannot create files or directories.  If I change the group to one of 
my secondary directories, I have rwx as expected.

Of course, without winbind and idmapping, the Windows ACL shows "Unix 
User" and "Unix Group" for domain on the entries, and of course
there is
no ability to add to the ACL, as we are currently doing in 3.0.14ap 
(attempting to add a username):
[2007/01/11 19:15:29, 0] smbd/posix_acls.c:(1399)
   create_canon_ace_lists: unable to map SID 
S-1-5-21-1214440339-839522115-1708537768-1219 to uid or gid.

Is the authorization issue I've outlined with winbind and idmap running 
a bug, or a misconfiguration, or is the functionality not supported 
where Samba is going?  It seems like the old days of "Samba is a file 
server" is going by the wayside in the pursuit of AD/Domain Controller 
functionality.  I have to admit that I don't follow all the mailing 
lists topics as closely as I would like; we're spread too thin.  So as I 
said, if I missed the memo, please let me know :)

--David

Posted bug for this as I do think it is a serious issue:

https://bugzilla.samba.org/show_bug.cgi?id=4348

            Summary: UNIX groups not honoured for access to filesystem
            Product: Samba 3.0
            Version: 3.0.23d
           Platform: Sparc
         OS/Version: Solaris
             Status: NEW
           Severity: major
           Priority: P3
          Component: winbind
         AssignedTo: samba-bugs@samba.org
         ReportedBy: dpullman@nist.gov
          QAContact: samba-qa@samba.org

Posted bug for this as I do think it is a serious issue:

https://bugzilla.samba.org/show_bug.cgi?id=4348

            Summary: UNIX groups not honoured for access to filesystem
            Product: Samba 3.0
            Version: 3.0.23d
           Platform: Sparc
         OS/Version: Solaris
             Status: NEW
           Severity: major
           Priority: P3
          Component: winbind
         AssignedTo: samba-bugs@samba.org
         ReportedBy: dpullman@nist.gov
          QAContact: samba-qa@samba.org

-- 
David Pullman
Systems Administrator
Manufacturing Engineering Laboratory
National Institute of Standards & Technology
Mail Stop 8203
100 Bureau Drive
Gaithersburg, MD 20899-8260
Tel: (301) 975-5385
Fax: (301) 926-3842
E-mail: david.pullman@nist.gov