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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
