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