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
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
