Stupid /etc/hosts problems with service principal names

[Richard Sharpe]

On 4/18/12, Andrew Bartlett <abartlet at samba.org> wrote:
> 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?
>
> Clients should use cifs/hostname where hostname is the name it was asked
> to connect to.  This avoids some man-in-the-middle attacks, and is an
> important security feature.
>
>> > 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.
>
> Could it be that the client was connecting to one name, that was in DNS
> or netbios, but was no the name registered with our KDC as a
> servicePrincipalName and not the name we joined as?
>
> Netbios aliases would do this in particular, if not also registered as a
> servicePrincipalName.

The problem as initially reported was that Windows clients could not
connect to the Samba-based box (Samba 3.5.6) with the hostname but
could connect via IP address.

The Samba box was actually giving out the correct SPN for that node in
the domain that it was in, say server1.sub-dom.forest1.somecom.local,
however, somewhere along the line someone had used the setspn command
on a W2K08 box and had created a local SPN for server1 that translated
to server1.forest1.somecom.local. This caused the KDC to say unknown
principal, and the client fell back to NTLMSSP and all worked.

However, in the process of finding and fixing the problem I stumbled
over the case where the hosts file was causing Samba to give out the
wrong SPN. (There was also other issues, like DDNS updates failing and
DHCP issues ...)

In all cases, people were using the hostname short-form wich matches
the NetBIOS name in most cases.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)