Agent Smith wrote:
This was taken from radiusd -X, and then I logged in
with a username,password and domain name too.
Ideally I'd like to make it so that it works either
way but for now I'll settle with ability to login when
the domainname was supplied.
Thanks,
rad_recv: Access-Request packet from host
192.168.3.44:1645, id=139, length=139
User-Name = "UPG\\test"
Framed-MTU = 1400
Called-Station-Id = "0013.8032.40d1"
Calling-Station-Id = "0090.4b1d.86cc"
Service-Type = Login-User
Message-Authenticator =
0x719f121abfb3b27a8746acabe0e1b6c6
EAP-Message = 0x0202000f123d4544566a726176616c
Unless I'm mistaken, the username in the EAP-Message it not just
different but completely different. But anyway...
NAS-Port-Type = Wireless-802.11
NAS-Port = 1527
NAS-IP-Address = 192.168.3.44
NAS-Identifier = "Cisco_AP"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 32
modcall[authorize]: module "preprocess" returns ok
for request 32
rlm_eap: EAP packet type response id 2 length 15
rlm_eap: No EAP Start, assuming it's an on-going EAP
conversation
modcall[authorize]: module "eap" returns updated for
request 32
rlm_realm: No '/' in User-Name = "test", looking
up realm NULL
Ok, FR thinks the username is "test" not UPG\test here. Therefore you've
got ntdomain_hack enabled in preprocess. Turn it off.
You've already stated that ntlm_auth then fails - that's because your
ntlm_auth command line is incorrect. You can fix it a number of ways:
1. set "with_ntdomain_hack = yes" on the mschap module (NOT in preprocess)
2. set the "ntlm_auth" command to (all on one line):
/path/to/ntlm_auth --request-nt-key --username=%{mschap:User-Name}
--challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}
...note the use of the mschap:User-Name which will always strip the
domain\ before doing the chal/resp (and in CVS head turn host/foo into
foo$ as well)
rlm_realm: Found realm "NULL"
rlm_realm: Adding Stripped-User-Name = "test"
rlm_realm: Proxying request from user test to
realm NULL
rlm_realm: Adding Realm = "NULL"
rlm_realm: Authentication realm is LOCAL.
Also, you typically do not want "/" realms, and I seriously doubt you
want them configured like this (matching NULL).
modcall[authorize]: module "suffix" returns noop for
request 32
users: Matched entry DEFAULT at line 1
modcall[authorize]: module "files" returns ok for
request 32
modcall[authorize]: module "etc_smbpasswd" returns
notfound for request 32
modcall: group authorize returns updated for request
32
rad_check_password: Found Auth-Type EAP
auth: type "EAP"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 32
rlm_eap: Identity does not match User-Name, setting
from EAP Identity.
rlm_eap: Failed in handler
modcall[authenticate]: module "eap" returns invalid
for request 32
modcall: group authenticate returns invalid for
request 32
auth: Failed to validate the user.
Delaying request 32 for 1 seconds
Finished request 32
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 139 to 192.168.3.44:1645
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 32 ID 139 with timestamp 441affff
Nothing to do. Sleeping until we see a request.
--- Alan DeKok <[EMAIL PROTECTED]> wrote:
Agent Smith <[EMAIL PROTECTED]> wrote:
When a user connectes, they are presented with a
login
box (username, password and domain name) if they
put a
domain name in the domain field, radius can't
authenticate them and gives that error message.
when
the domain field is left empty, it works fine.
You should be able to use a module before 'eap" to
fix the Username.
I read some posting that talked about how you have
to
turn off ntdomain_hack off and I tried that, it
didn't
gave me that error but then the ntlm_auth failed
saying 'NO SUCH USER' so my guess is that the
user-name has to be exactly same as what gets sent
into EAP message.
If you're using ntlm_auth, you're not using
EAP-TLS. You're using
EAP-PEAP, there's a difference.
And the ntlm_auth program is run *only* inside of
the TLS tunnel,
where there's no certificate, so matching username
to certificate
isn't a problem.
has anyone else ran into this? any ideas on how to
fix
it?
Run the server in debugging mode and post the
results to the list.
Odds are there's a simple way to do what you want.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
