RE: Freeradius + PEAP + MSCHAPV2 + NTLM_AUTH Question....
Dourty, Brian R. (IATS) [EMAIL PROTECTED] wrote: Ok, but isn't the with_ntdomain_hack =3D yes directive in the raidusd.conf file suppose to correct this behavior? Theoretically, yes. But when you're calling ntlm_auth, the with_ntdomain_hack isn't being used. Why would it? You're passing the exact attributes you want to ntlm_auth. If you don't like the attributes, change them. Why would we need another configuration option to do the same thing? So now my args for ntlm_auth are right, but I think something is up with mschap still. If the arguments to ntlm_auth are right, then it should work. To clarify things here, the --domain and --username arguments are right, but the --challenge argument is incorrect. I'm looking at the code in rlm_mschap.c. I believe this is the code that creates the value for the --challenge argument for ntlm_auth. It is my understanding that this is a hash created with this code: challenge_hash(response-strvalue + 2, chap_challenge-strvalue, user_name-strvalue, buffer); The username being used in this function still contains the DOMAIN! This is what is keeping the auth from working. I've added debug statements to my code. Its using the domain/user. This won't work. When the Challenge or Response message is generated is it still trying to user domain/user as the username? Ask the client, not FreeRADIUS. I can't change the client. I can change freeradius. The client presents freeradius with a domain/username. We all know that is the case. And when you're using ntlm_auth, *you* configure it to use domain\user, or just user. So to answer your question on FreeRADIUS's side, go back and read your configuration. I'm confused on this point. When PEAP identity is set to username my auths work. When the PEAP identity is of the form domain/user MSCHAP fails. Yes. This is the problem. But it has nothing to do with PEAP. You are right, it has nothing to do with PEAP. Freeradius gets what the client gives it. The problem occurs in the mschap module. There's no point trying to configure FreeRADIUS to do the right thing, when you don't even know what the right thing is. Find that out first, and THEN configure the server. I know what the right thing is. In order for the ntlm_auth to return OK all of its arguments have to be right. When a client is setup to send domain/user instead of just user things breakdown in the MSCHAP module. The NTLM_AUTH function takes 4 arguments from freeradius. They are as follows: --domain %{Realm} --username %{Stripped-User-Name} --challenge %{mschap:Challenge:-00} --nt-response %{mschap:NT-Response:-00} The challenge and nt-response are both hashes based in part on the username. The username that freeradius uses when it generates these hashes is the full username, not the stripped username. This is what is causing my problem. Now, the question is how to go about fixing the problem. Brian D. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius + PEAP + MSCHAPV2 + NTLM_AUTH Question....
Dourty, Brian R. (IATS) [EMAIL PROTECTED] wrote: To clarify things here, the --domain and --username arguments are right, but the --challenge argument is incorrect. Ah, OK. The username being used in this function still contains the DOMAIN! This is what is keeping the auth from working. I've added debug statements to my code. Its using the domain/user. This won't work. Then the with_ntdomain_hack should be set... I can't change the client. I can change freeradius. The client presents freeradius with a domain/username. We all know that is the case. Yes, that's a problem. The client is *lying* to FreeRADIUS. The challenge and nt-response are both hashes based in part on the username. The username that freeradius uses when it generates these hashes is the full username, not the stripped username. This is what is causing my problem. Now, the question is how to go about fixing the problem. Theoretically, using with_ntdomain_hack should help. Hmm... the code you pointed out does appear to ignore with_ntdomain_hack. I'll fix that. See tomorrow's CVS snapshot. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius + PEAP + MSCHAPV2 + NTLM_AUTH Question....
I patched the rlm_mschap.c file (attached). I pulled code from rlm_preprocess.c that handles the with_ntdomain_hack and modified it to work. The user_name argument being passed to challenge_hash() function now honors the with_ntdomain_hack but my problem still exists. :-( Back to the drawing board. Brian D. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: Monday, May 03, 2004 1:07 PM To: [EMAIL PROTECTED] Subject: Re: Freeradius + PEAP + MSCHAPV2 + NTLM_AUTH Question Dourty, Brian R. (IATS) [EMAIL PROTECTED] wrote: To clarify things here, the --domain and --username arguments are right, but the --challenge argument is incorrect. Ah, OK. The username being used in this function still contains the DOMAIN! This is what is keeping the auth from working. I've added debug statements to my code. Its using the domain/user. This won't work. Then the with_ntdomain_hack should be set... I can't change the client. I can change freeradius. The client presents freeradius with a domain/username. We all know that is the case. Yes, that's a problem. The client is *lying* to FreeRADIUS. The challenge and nt-response are both hashes based in part on the username. The username that freeradius uses when it generates these hashes is the full username, not the stripped username. This is what is causing my problem. Now, the question is how to go about fixing the problem. Theoretically, using with_ntdomain_hack should help. Hmm... the code you pointed out does appear to ignore with_ntdomain_hack. I'll fix that. See tomorrow's CVS snapshot. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html with_ntdomain_hack.patch Description: with_ntdomain_hack.patch
Re: Freeradius + PEAP + MSCHAPV2 + NTLM_AUTH Question....
Dourty, Brian R. (IATS) [EMAIL PROTECTED] wrote: I patched the rlm_mschap.c file (attached). I pulled code from rlm_preprocess.c that handles the with_ntdomain_hack and modified it to work. Similar code already existed in rlm_mschap.c. The fix was 1 line. The user_name argument being passed to challenge_hash() function now honors the with_ntdomain_hack but my problem still exists. :-( Back to the drawing board. Hmm... you hacked the User-Name attribute, which isn't generally a good idea. Try the CVS snapshot tomorrow, or grab the latest via anonymous cvs. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Freeradius + PEAP + MSCHAPV2 + NTLM_AUTH Question....
Hello all, We are in the process of testing 802.1x authentication for future deployment on campus. Our test setup includes the following: freeradius-snapshot-20040427 running on RHEL 3.0 AS Configured for PEAP with MSCHAPv2 using SAMBA's winbind/ntlm_auth Multiple AD domains (smb.conf points to a Global Catalog Server) Linux/Windows XP/Windows 2K/Mac OS X clients What works: 1. using wbinfo -a domain+user%password I can authenticate as any user in any of our domains. 2. 802.1x auths as long as I don't supply a domain and the user is in the domain that the GC is in. What doesn't work: 1. Supplying domain with login credentials. I've got a realm for each of our domains setup up and I can see the preprocess module doing its job separating domain from username. Then the MSCHAPv2 module kicks in and the call to NTLM_AUTH fails with wrong password. 1. Keeping in mind that user1 in domain1 can auth as long as domain1 isn't supplied why does supplying domain1 cause the auth to fail? 2. What does preprocess do with realm is strips off? I'd like to be able to pass the realm as a --domain option to ntlm_auth. 3. Why does PEAP think the username is still domain/user? I see the following in the logs while running radius -X -A PEAP: Setting User-Name to UMC-USERS\dourtyb PEAP: Adding old state with 17 b0 PEAP: Sending tunneled request Should it be using Stripped-User-Name instead? Thanks, Brian Dourty IAT Services University of Missouri - Columbia - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius + PEAP + MSCHAPV2 + NTLM_AUTH Question....
Dourty, Brian R. (IATS) [EMAIL PROTECTED] wrote: 1. Keeping in mind that user1 in domain1 can auth as long as domain1 isn't supplied why does supplying domain1 cause the auth to fail? Because the MS client does the MS-CHAP calculations using the username without the domain, but supplies the username to the RADIUS server WITH the domain. See the list archives for more explanations. Ok, but isn't the with_ntdomain_hack = yes directive in the raidusd.conf file suppose to correct this behavior? # Windows sends us a username in the form of # DOMAIN\user, but sends the challenge response # based on only the user portion. This hack # corrects for that incorrect behavior. 2. What does preprocess do with realm is strips off? I'd like to be able to pass the realm as a --domain option to ntlm_auth. Read the debug log. It adds it as an attribute. Ah yes, I see that now. New attribute is called Realm so the line in radiusd.conf is now: ntlm_auth = /usr/bin/ntlm_auth --domain=%{Realm} --request-nt-key --username=%{Stripped-User-Name:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00} So now my args for ntlm_auth are right, but I think something is up with mschap still. When the Challenge or Response message is generated is it still trying to user domain/user as the username? 3. Why does PEAP think the username is still domain/user? I see the following in the logs while running radius -X -A PEAP: Setting User-Name to UMC-USERS\dourtyb Because that's the name in the EAP identity packet. Read the debug log, it says this. Should it be using Stripped-User-Name instead? No. I'm confused on this point. When PEAP identity is set to username my auths work. When the PEAP identity is of the form domain/user MSCHAP fails. Am I wrong in thinking that with the correct configuration Freeradius will allow me to have users from all trusted domains use the MSCHAP module for 802.1x auth? Where am I going wrong? Thanks! Brian Dourty IAT Services University of Columbia - Missouri - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html