samba - Jul 2006 - RE: Q: winbindd, unqualfied users, & name conflicts (a.k.a "Deathto 'winbind use default domain'!")

My opinion:

Local users should always take precedence. 

People should specifically refer to local users as
<SambaHostName>\localuser, if that is the form the SMB client insists on
sending.

Tacking on default domains and/or stripping domains to/from user names
and "trying them out" is playing fast and loose with user identity and
is a breeding ground for potential security holes.

Dave Daugherty


-----Original Message-----
From:
samba-technical-bounces+dave.daugherty=centrify.com@lists.samba.org
[mailto:samba-technical-bounces+dave.daugherty=centrify.com@lists.samba.
org] On Behalf Of simo
Sent: Thursday, July 20, 2006 9:59 AM
To: Gerald (Jerry) Carter
Cc: Volker Lendecke; samba@samba.org; samba-technical@samba.org
Subject: Re: Q: winbindd, unqualfied users, & name conflicts (a.k.a
"Deathto 'winbind use default domain'!")

On Thu, 2006-07-20 at 11:35 -0500, Gerald (Jerry) Carter
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Volker,
> 
> Assume I have a member server named LINUX joined to a
> domain name AD.  Now assume I have a local user named foo
> in my passdb and a user named foo in the domain as well.
> I'm modifying winbindd_util.c:parse_domain_user() to do
> a lookup_name() to try to figure out which domain to prepend
> to the username rather than just assuming its a domain user.
> But this means that we'll always choose the local user
> (due to the order of an isolated search in lookup_name()).
> 
> The main problem is the use default domain abomination
> will confuse local and domain users of the same name and
> possibly return incorrect group membership.
> 
> I am about a 1/2 inch from marking the smb.conf option
> as deprecated and adding similar option to pam_winbind.conf.
> This option just cannot work reliably.
> 
> Do you have any suggestions?
I would just document that local users will always take precendence.

Winbind use default domain is too valuable to be removed imho.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra@samba.org
http://samba.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Daugherty wrote:
> My opinion:
> 
> Local users should always take precedence. 
> 
> People should specifically refer to local users as
> <SambaHostName>\localuser, if that is the form the 
> SMB client insists on sending.
> 
> Tacking on default domains and/or stripping 
> domains to/from user names and "trying them out" is playing
> fast and loose with user identity and
> is a breeding ground for potential security holes.
Dave,

I don't think you fully understand the problem.  We're
talking about Unix shell tools, not SMB clients.  A local
username is always unqualfied when sent by Unix tools like
'id' to query group membership.  A domain user may or may
not be qualfied so how do you know an unqualified domain
user from a normal local user?   For example,

With 'winbind use default domain = no'

$ id
uid=780(jerry) gid=100(users)
groups=16(dialout),33(video),100(users),10001(BUILTIN\users),
10007(SUSE10\developers)

With 'winbind use default domain = yes'

$ id
uid=780(jerry) gid=100(users)
groups=16(dialout),33(video),100(users)

the problem is that when guesing the domain, we assume
the Windows domain name.  Prior to querying group membership,
we do a lookup_name() query to the DC for this name
(DOMAIN\jerry) which fails since it is a local user.
So any local groups are excluded from the getgroups()
return.

*This* ambiguity is why I will be removing the geuss
work from the server code in 3.0.24.





cheers, jerry
====================================================================Samba       
------- http://www.samba.org
Centeris                         -----------  http://www.centeris.com
"What man is a man who does not make the world better?"      --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEv9DpIR7qMdg1EfYRAhMoAJ9mu5FujBGJgheCqD57c5BC4VUQ6ACfU4SA
nKAFtPFGUBQa7CyY0QKrdk4=Yc53
-----END PGP SIGNATURE-----