The last piece of the puzzle - XP host authentication

[Phil Mayers]

On 04/19/2011 04:41 PM, East, Bill wrote:
>> -----Original Message----- From:
>> freeradius-users-bounces+eastb=pffcu.org at lists.freeradius.org
>> [mailto:freeradius-users-
>> bounces+eastb=pffcu.org at lists.freeradius.org] On Behalf Of Phil
>> Mayers Sent: Tuesday, April 19, 2011 11:15 AM To:
>> freeradius-users at lists.freeradius.org Subject: Re: The last piece
>> of the puzzle - XP host authentication
>>
>> On 19/04/11 14:59, East, Bill wrote:
>>
>>>> Have you made sure that your root cert is present in the right
>>>> stores - remember windows clients have both machine and
>>>> per-user cert stores. Machine auth requires it be in the
>>>> machine store.
>>>
>>> Bah, I should have known that. It's fixed, now.
>>
>> Cool
>>
>>> This looks highly promising.
>>>
>>> I've got the syntax right in mschap now, I think, but the
>>> challenge is still being created strangely (or is it supposed to
>>> look like that?)
>>>
>>> [mschapv2] # Executing group from file
>>> /etc//raddb/sites-enabled/inner-tunnel [mschapv2] +- entering
>>> group MS-CHAP {...} [mschap] Creating challenge hash with
>>> username: host/LP-0010.pffcu.org [mschap] Told to do MS-CHAPv2
>>> for host/LP-0010.pffcu.org with NT-Password [mschap]
>>> expand: %{mschap:User-Name} ->   LP-0010$ [mschap]        expand:
>>> --username=%{%{mschap:User-Name}:-%{User-Name:-None}} ->   --
>> username=LP-0010$
>>> [mschap]  mschap2: ac [mschap] Creating challenge hash with
>>> username: host/LP-0010.pffcu.org [mschap]        expand:
>>> --challenge=%{mschap:Challenge:-00} ->   --
>> challenge=cc01b9d88b911c44
>>> [mschap]        expand: --nt-response=%{mschap:NT-Response:-00}
>>> ->   --nt-
>> response=0a186dec8193bed90f305cabfc6f48f5a3621c58672b98a8
>>
>> This all looks right (I have spent a distressing amount of time
>> looking at MS-CHAP blobs this last week)
>>
>>> Exec-Program output: Logon failure (0xc000006d)
>>> Exec-Program-Wait: plaintext: Logon failure (0xc000006d)
>>
>> ...but obviously this didn't work.
>>
>> What version of Samba do you have? Some (much) older versions
>> didn't permit machine account login via ntlm_auth.
>
> Latest and greatest, 3.5.8.
>
> I'm wondering if this is the "loopback checking" issue from KB896861
> and others. Since the hash is for "host/machinename"... I can modify
> the registry on my domain controller but I'm going to have to wait
> for our maintenance window to restart the damn thing.

I doubt that's it. We don't have that problem with machine auth. But 
maybe it's worth a try.

The other alternative is to do something like:

smbcontrol winbind debug 10

...then have a look in /var/log/samba. The debug logs can be very, very 
chatty but it might give some idea of why the machine account is failing 
to auth.

I guess there's no possibility the machine account password is wrong or 
out-of-sync? There is an entry in your domain for:

samaccountname=LP-0010$

...that's all valid and correct, right?

<rant follows ;o>

In fact the mschap response is calculated and checked against host$, and 
the "real" SAM account name of the machines are host$ - it's never been 
clear to me, given that, why the machines give their EAP-Identity as 
host/name.domain.com. It's a dumb thing to do on a number of levels, not 
least using the machines own (often incorrect) idea of it's DNS name in 
authentication that typically takes place on a link before IP is active....