Copies of emails sent to samba-general: 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. 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 :)
I believe am experiencing the same problem. Hardware: x86 (Intel Xeon) Samba version: 3.0.25b-1.el5_1.4 OS: Linux (Centos 5) I have successfully configured Samba to use Winbind to authenticate users against our AD domain. However, we've noticed the same behavior described above. winbind_use_default_domain is set to "yes" We use the shorter username in all circumstances however I believe Windows is passing the fully qualified user name (ie. DOMAIN\\username) when connecting from remote. We're not mapping any users or groups. None of the user accounts we're dealing with are local unix accounts; they all come from the domain. How I reproduce the problem: Create any local unix group (I'll use "group1"), add a user from the domain to it (I'll use "user1". We do have winbind_use_default_domain set to true so we've been adding the username alone to the /etc/group file. Grant group rwx to a directory or file (one that is shared on the network) for the group1 group, make sure the user you're going to attempt to use the file from does NOT own the file (in my case, "user1" must only be a member of the group that has privileges to it but may not own the file: if "user1" owns the file, things work as expected). If logged into ssh, "user1" can read/write to the file in question without problems. When attempting to access the file from my windows system via the share, the same user will NOT have read/write access. If the group in question is a domain group (for example "domain users" instead of "group1"), the shares behave as expected. Another thing I noticed: output of: # groups MYDOMAIN+user1 does not match the output of: # groups user1 I too am interested if this is the intended behavior or if something broken. My inclination is to suggest that it's broken as the share does not behave in the same manner as the same user account logged in to a shell and furthermore, MYDOMAIN+user1 and user1 should be members same groups: they're technically the same user.
users get their group memberships assigned by AD and the unix group membersips are not being asked. This is by design. A hack that currently works is to trick Samba by mapping the incoming user to "another" user which triggers a different, less accurate code path. set "username map script = /bin/echo" if you really want to use group memberships from nss. But this is not a recommended thing to do generally...