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 _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
