Discussed on Samba list and suggested by jht@samba.org that if this was a show- stopper to submit it. The easiest way to describe is the way it was in email: > I think I understand at least a part of Anton's issue. It's one that I've > been thinking about as we deploy Samba 3.0. We never really thought much > about ACLs until now and have never run winbindd. The problem boils down > to this: We currently have a group of seven Samba/NFS file servers which > are members of a Windows domain. The Windows usernames and group names > are synchronized. The numeric UIDs and GIDs are uniform across all of > them by virtue of the fact that they have a common /etc/passwd. We want > to jump on the ACL bandwagon and do things right using winbindd. > However, in a distributed environment the official way of mapping SIDs to > UIDs consistently across the servers involves an 'idmap backend'. All of > the idmap backends involve ldap. It is frustrating that I have to > introduce the overhead of deploying an LDAP server and populate it with > UID mappings even though the file servers already have an /etc/passwd > which has enough information to map numeric Unix UIDs consistently. > > I know idmap'ing was a hot topic during development so you have probably > already considered all of this. At the time, watching the discussion I > didn't follow it all but now starting to consider deployment the issues > are becoming clearer. > Hopefully the above is clear. I'm not sure the proper solution but perhaps it's simply an idmap backend that uses /etc/passwd as it's table. Maybe you've already got that code laying around.
you don't have to run winbindd. There's an implicit mapping between windows domain user names and names in /etc/passwd. If winbindd can't be contacted (i.e. getpwnam(domain\user) fails), smbd will lookup the getpwnam(user). There was one bug post 3.0.0 that caused this to fail for users in trusted realms using kerberos tickets to authenticate to the Samba domain member. So the question is did someone tell you that you had to run winbindd? If so they were wrong. If you have tried not running winbindd and things don't work right then i'll need more details to work on the bug because it should work.
I realize that running winbindd is not required. However, we'd like to show accurate security info and begin to use ACLs. As I understand it, in order to have the security info for a file and directory say "DOMAIN\user" instead of "LOCALSERVER\user" or to use groups and users in the windows domain we need to run winbindd. We need the mapping function of winbind. Is this incorrect? If we do in fact have to run winbind then my issue is that I don't want to have to also run an LDAP server to do the idmap'ing. All the info required for idmap is in /etc/passwd. I got the feeling that John Terpstra got the essence of this when we exchanged email. Maybe he can state it clearer (if he remembers the issue.) On a tangent maybe how Samba does this is fundamentally backward. It seems not quite right if you have a Samba server be a member of a domain, authenticate as a domain user and yet have file ACLs say SERVER\user. Maybe in security=ads or security=domain it should always assume DOMAIN\user?
ok. I understand now. I had intended to fix this prior to 3.0.0 but couldn't get to it in time. I'll go back and look at it again.
Created attachment 235 [details] allow winbindd to match SIDs to local user and groups
Here's a patch against the latest SAMBA_3_0 cvs tree. It patches cleanly against 3.0.0 as well (cd samba/source; patch -p0 < winbindd_uid2sid.patch) The general idea is that on members of samba domains you set 'winbindd trusted domains only = yes' to force winbindd create a sid<->uid/gid mapping based on the result of getpwuid/getgrgid. The 2 requirements are * You must create group mappings on the Samba PDC for all groups that you care about in ACLs. * the passwd & group lines in /etc/nsswitch.conf must list 'files' before the NSS service winbind I now see DOMAIN\foo instead of SERVER\foo on members of my Samba 3.0 domain. Users/Groups in trusted domains are still assigned a uid/gid as needed. This patch does change the behavior of the ldap backend for winbindd idmap store but I don't think there are any consequences. Please let me know if this works for you. Thanks.
I think this patch is ok and I want to get it into 3.0.1pre2 for testing. So I'm checking it in and marking this as fixed.
Yes, sorry for the delay in giving you feedback. It works just great so far and has the desired effect. Thanks for getting this patched up.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.