Stupid /etc/hosts problems with service principal names

Richard Sharpe realrichardsharpe at
Wed Apr 18 19:04:02 MDT 2012

On Wed, Apr 18, 2012 at 5:37 PM, Andrew Bartlett <abartlet at> 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?

> Which client is honouring the incorrect value (old Samba versions
> would)?

Well, the traces I have suggest that at least W2K03 uses the bad
principal name and submit it to the KDC, getting back Principal Not
Found. I will have to look again at the details but they are at work.
I can probably post parts of a capture I have.

In one case, someone seems to have defined a locally known principal
name as well (on a Windows client) that matched the bogus principal
name, and that caused authentication to not work at all. The client
just kept asking for credentials. The ticket that was generated was
bad, it seems.

Richard Sharpe

More information about the samba-technical mailing list