[RADIATOR] Issues with AuthbyNTLM (LONG)
Heikki Vatiainen
hvn at archred.com
Wed Sep 22 14:57:26 CDT 2010
On 09/22/2010 07:23 PM, Smith, Todd wrote:
> I have just purchased Radiator to replace some elderly Steel-Belted
> RADIUS and I am still in test mode but after looking at the
> documentation and testing a single client; I am still having
> problems with an endless loop of authentication requests.
The trace file looks similar to what I run into recently. I was going to
test e.g. Ubuntu 10.04 for a more complete report, but I think now is
the good enough time to write about the problem and the solution I had
instead of waiting any longer.
Luckily I was able to solve the problem, please read more.
> My environment is a Ubuntu 10.04.1 LTS server fully patched running
> the latest version of Samba from the Ubuntu distribution. The Samba
> services are configured as a member server to a Windows 2003 Active
> Directory and klist successfully authenticated a username and
> password and ntlm_auth reports OK after a successful username and
> password. Radiator was downloaded as the tarball and was installed
> into a /usr/src source directory.
We had a working Debian 4.0 (etch) installation that was handling
authentication about the same as described above. The usual case was
Windows doing PEAP.
Since 4.0 is not supported anymore, it was upgraded to 5.0 and
everything else worked as it should (plain password authentication etc.)
but PEAP broke. The trace looked similar: ntlm_auth indicated success
and the authentication almost finished.
After looking for help, I found out that others had also seen the problem:
http://lists.freeradius.org/pipermail/freeradius-users/2009-February/msg00289.html
The problem seems to be that ntlm_auth that comes with Debian 5.0 samba
package does not return correct values. There is more about this towards
the end where the trace file is.
The fix was to downgrade winbind and samba-common packages to Debian 4.0
packages.
In other words we have the following samba related packages from 4.0
installed on 5.0:
ii samba-common 3.0.24-6etch10 Samba
common files used by both the server a
ii winbind 3.0.24-6etch10 service
to resolve user and group informatio
A bit more about this solution: only samba-common and winbind were
needed. The samba package itself is not installed since smbd and nmbd
daemons are not needed for ntlm_auth to work.
% dpkg -s samba
Package: samba
Status: deinstall ok config-files
Samba in Debian 5.0 is 3.4.5 so the fix was in effect to downgrade from
3.4 series to 3.0 series. You may be able to fix your problem by
uninstalling samba packages, not using purge because winbind needs
samba's configuration file. and installing the latest samba-common and
winbind from Ubuntu 8.04 branch. I have not tried the downgrade with
Ubuntu, but it helped with Debian.
I just did a quick check to various Debian and Ubuntu versions and it
looks like:
- Debian 4.0 has samba 3.0.24
- Debian 5.0 has samba 3.2.5
- Ubuntu 8.04 has samba 3.0.28a
- Unbutu 10.04 has samba 3.4.7
>From the above I have also used Ubuntu 8.04 successfully doing ntlm_auth.
There is more about ntlm_auth below near the end of included trace.
What I wrote above may be unrelated to Todd's problem but it looks quite
similar to that I saw. Have the other list members seen something like
this? It would be good to get this potential Samba bug fixed and it
would help if it could be better confirmed.
> 1) A clear description of the problem
>
> Client does not complete the authentication process even though the
> Accept message seems to indicate a successful authentication. The
> client then attempts to reauthenticate and the loop doesn't end.
>
> 2) Copy of the Radiator configuration file (no secrets)
[cut]
> 3) A trace 4 debug from Radiator showing what is happening
[cut until almost the end]
> Wed Sep 22 12:05:59 2010: DEBUG: EAP PEAP inner authentication request for anonymous
> Wed Sep 22 12:05:59 2010: DEBUG: PEAP Tunnelled request Packet dump:
> Code: Access-Request
> Identifier: UNDEF
> Authentic: <232><180><135>ho<23><1><169><169><10><215>4<199><184><149>I
> Attributes:
> EAP-Message = <2><8><0>C<26><2><8><0>B1Wh<5>^<141><175><213><249><149><254>Wn"<180><27>U<0><0><0><0><0><0><0><0><218><235><166><31><10><133><229>AFD<<226><221><135><189>b<229>q<163><11><248>-"<4><0>CAMC\tssmith
> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> NAS-IP-Address = 10.2.96.19
> NAS-Identifier = "Dover Standalone (Thick) AP"
> NAS-Port = 16973824
> Calling-Station-Id = "00-13-ce-69-43-2c"
> User-Name = "anonymous"
>
> Wed Sep 22 12:05:59 2010: DEBUG: Handling request with Handler '', Identifier ''
> Wed Sep 22 12:05:59 2010: DEBUG: Deleting session for anonymous, 10.2.96.19, 16973824
> Wed Sep 22 12:05:59 2010: DEBUG: Handling with Radius::AuthNTLM:
> Wed Sep 22 12:05:59 2010: DEBUG: Handling with EAP: code 2, 8, 67, 26
> Wed Sep 22 12:05:59 2010: DEBUG: Response type 26
> Wed Sep 22 12:05:59 2010: DEBUG: Radius::AuthNTLM looks for match with CAMC\tssmith [anonymous]
> Wed Sep 22 12:05:59 2010: DEBUG: Radius::AuthNTLM ACCEPT: : CAMC\tssmith [anonymous]
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute Request-User-Session-Key: Yes
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute Request-LanMan-Session-Key: Yes
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute LANMAN-Challenge: 179b1eda2032ef41
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute NT-Response: daeba61f0a85e54146443ce2dd87bd62e571a30bf82d2204
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute NT-Domain:: Q0FNQw==
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute Username:: dHNzbWl0aA==
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: Authenticated: Yes
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: LANMAN-Session-Key: 55FC5F8DFAA3A58D
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: User-Session-Key: B48DFF252D4FAB7CBEA3207E1A5C51BE
Everything looks good so far. ntlm_auth gets a success back from the
Windows server and also the User-Session-Key it requested.
If I have understood correctly the User-Session-Key should be a MD4 hash
of NTHash the the Windows server stores. In other words
md4(md4(asciitounicde(password))) which with plain 7bit ascii is simply
md4(md4(password))
The broken ntlm_auth does not return this double hash of password, but
instead of some other value. This value causes incorrect "authenticator
response" to be calculated and makes the client think that the server
does not know the real password hash. In other words the server
authentication to the client fails.
What happens is that client ends the authentication and no reply is ever
received until a new try is initiated by the client. Just like below,
the last message is the message to the client.
Looking at Radiator goodies directory, the simplest method to generated
User-Session-Key from a known password is this:
% perl goodies/nthash.pl password
{nthash}8846F7EAEE8FB117AD06BDD830B7586C
% perl goodies/nthash.pl 8846F7EAEE8FB117AD06BDD830B7586C
{nthash}0204D0612AF59BDABC236E5195648836
The hex string 0204D0612AF59BDABC236E5195648836 is the User-Session-Key
for the password 'password'.
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: .
> Wed Sep 22 12:05:59 2010: DEBUG: EAP result: 3, EAP MSCHAP V2 Challenge: Success
> Wed Sep 22 12:05:59 2010: DEBUG: AuthBy NTLM result: CHALLENGE, EAP MSCHAP V2 Challenge: Success
> Wed Sep 22 12:05:59 2010: DEBUG: Access challenged for anonymous: EAP MSCHAP V2 Challenge: Success
> Wed Sep 22 12:05:59 2010: DEBUG: Returned PEAP tunnelled packet dump:
> Code: Access-Challenge
> Identifier: UNDEF
> Authentic: <232><180><135>ho<23><1><169><169><10><215>4<199><184><149>I
> Attributes:
> EAP-Message = <1><9><0>=<26><3><8><0>8S=AD59BE8E0A96165332AEEBF926A4002E20868CDB M=success
> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>
> Wed Sep 22 12:05:59 2010: DEBUG: EAP result: 3, EAP PEAP inner authentication redispatched to a Handler
> Wed Sep 22 12:05:59 2010: DEBUG: AuthBy NTLM result: CHALLENGE, EAP PEAP inner authentication redispatched to a Handler
> Wed Sep 22 12:05:59 2010: DEBUG: Access challenged for CAMC\tssmith: EAP PEAP inner authentication redispatched to a Handler
> Wed Sep 22 12:05:59 2010: DEBUG: Packet dump:
> *** Sending to 10.2.96.19 port 1111 ....
> Code: Access-Challenge
> Identifier: 45
> Authentic: <155><216><173><221>2<245><196><238><211>w\<24><174>m<245>3
> Attributes:
> EAP-Message = <1><9><0>T<25><0><23><3><1><0>I<10><160><227><173><198>N<190>HO<14><186><171><197><251>Z<154><195>g<232><147><254>#<238><129>7x^6'S\<134>A`qL<203><253><14><28>p<190><232>%M<224>w<148><215><176><170>UW<22><193><168>6<147><25><249><255><7><3><137><22><192><193><190>M<202><236><153>[
> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>
> ^C
--
Heikki Vatiainen, Arch Red Oy
+358 44 087 6547
More information about the radiator
mailing list