Stupid /etc/hosts problems with service principal names

[simo]

On Wed, 2012-04-18 at 18:04 -0700, Richard Sharpe wrote: 
> On Wed, Apr 18, 2012 at 5:37 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Wed, 2012-04-18 at 10:02 -0700, Richard Sharpe wrote:
> >> Hi folks,
> >>
> >> I recently saw a problem with Samba giving out what seemed like the
> >> wrong service principal name in the response to a Negotiate Protocol,
> >> but it came down to Samba trying to convert the hostname (short form)
> >> into an FQDN and name_to_fqdn calls gethostbyname, which, because of
> >> /etc/nsswitch, looks in /etc/hosts, and since we had an entry there
> >> that had not been changed after the domain join, came up with the
> >> wrong FQDN ...
> >>
> >> It seems to me that the correct thing here is not to put an entry for
> >> this machine in /etc/hosts (apart from localhost) relating to the
> >> hostname of the member server because it should be using DNS anyway,
> >> and if access to DNS is broken, lots of stuff is not going to work
> >> anyway.
> >>
> >> Any comments? Is this stuff that has been discussed before now?
> >
> > Which version is this?
> 
> Samba 3.5.x
> 
> > However, this is partly why in master we do not generate this principal
> > name in the NegProt, and in 3.6 we do not honour it by default in the
> > client.
> 
> So, how does the client (Windows) find the principal name if we do not
> communicate it?

You cannot trust the server to tell you the principal name, as that
would easily help MITM attacks, by making a user believe they are
connected to server A while they really are connected to server B.
Windows does normal name resolution. If name resolution doesn't yield
the right ticket or doesn't work they try to fall back to NTLM auth.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>