Discussed on Samba list and suggested by firstname.lastname@example.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
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
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.