Samba: map untrusted to domain

[Steven Danneman]

Hi Tom,

The short answer is that Windows servers from Windows 2000 and above,
when receiving a username for authentication can place that name into 2
buckets:

1) It is a name known by my primary domain controller.  Either my
primary domain or a domain it trusts.

2) It is a name known by my local SAM (which means the local machine
name if not a DC, and the domain name if the server is a DC).
Authenticate as a local user.

The current Samba code first checks 1), and if it fails, falls back to
2).  Thus your DOS clients when sending (NULL)\joesmith are falling into
the second bucket, because a blank domain name does not equal the
server's primary domain or a trusted domain.

This is how Windows servers work and this is how the Samba code
functions now.

Previous to my patches, smbd would replace an untrusted domain name, or
a NULL domain name, with the primary domain, and then try to
authenticate that name against the DC.  This, while not matching Windows
behavior, seems to be the behavior you're expecting and want in your
setup.  That's why the "map untrusted to domain" parameter exists, to
allow you to revert to the previous non-Windows behavior.

-Steven

> -----Original Message-----
> From: Thomas Sailer [mailto:t.sailer at alumni.ethz.ch]
> Sent: Monday, January 04, 2010 12:14 PM
> To: Steven Danneman
> Subject: RE: Samba: map untrusted to domain
> 
> Hello Steven,
> 
> thank you very much for your quick reply!
> 
> I've seen the commit comment of your first patch. While it's certainly
> a
> good thing to bring samba's behaviour closer to windows', I thought
> there was some deeper reason that wasn't mentioned.
> 
> > Though, in the original change, I missed the NULL/empty domain case.
> This is now fixed in 3.4.3 for sure:
> > commit fbca26923915a70031f561b198cfe2cc0d9c3aa6
> 
> I'm confused now. This commit seems to be also in 3.4.2, what I'm
> using.
> Still, I need to set map untrusted to domain = yes, otherwise the
empty
> domain name gets mapped to the machine name...
> 
> Thanks,
> Tom