Bug 680 - Winbindd and idmap backend without LDAP instead local files.
Winbindd and idmap backend without LDAP instead local files.
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: winbind
3.0.0
All other
: P3 normal
: 3.0.1
Assigned To: Gerald (Jerry) Carter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-24 11:33 UTC by Eric Horst
Modified: 2005-08-24 10:22 UTC (History)
0 users

See Also:


Attachments
allow winbindd to match SIDs to local user and groups (30.12 KB, patch)
2003-11-04 09:01 UTC, Gerald (Jerry) Carter
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Horst 2003-10-24 11:33:31 UTC
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.
Comment 1 Gerald (Jerry) Carter 2003-10-29 14:36:49 UTC
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.
Comment 2 Eric Horst 2003-10-29 15:15:49 UTC
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?

 
Comment 3 Gerald (Jerry) Carter 2003-10-31 06:07:28 UTC
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.
Comment 4 Gerald (Jerry) Carter 2003-11-04 09:01:38 UTC
Created attachment 235 [details]
allow winbindd to match SIDs to local user and groups
Comment 5 Gerald (Jerry) Carter 2003-11-04 09:08:55 UTC
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.
Comment 6 Gerald (Jerry) Carter 2003-11-07 06:34:22 UTC
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.
Comment 7 Eric Horst 2003-11-07 11:39:55 UTC
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.
Comment 8 Gerald (Jerry) Carter 2005-08-24 10:22:07 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.