I've got, well think I have, radius to accept all logins no matter what password they send. However some users still cannot login, its around 10 users out of 200. I'll show details for one user that can login ok and one user that can't. I'm guessing it's something the end user is doing because they all come in via the same NAS and have exactly the same radius entry. If I can get around this by just accepting anything that would be ideal, since our realm is the only radius logins that are sent to us. Here is a user that can't login: ## Thu Mar 2 09:59:03 2006 : Auth: Login incorrect (rlm_chap: Clear text password not available): [user22@dsl.realm.com/<CHAP-Password>] (from client l2tp port 510) ## Here is someone that did authenticate ok: ## Thu Mar 2 09:55:26 2006 : Auth: Login OK: [user3@dsl.realm.com/<CHAP-Password>] (from client l2tp port 492) ## My users file has: ## DEFAULT Auth-Type = Accept ## And the entries for both users above are identical apart from the username and IP assignment: ## user3@dsl.realm.com Auth-Type := Accept Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 192.168.0.1, Framed-Netmask = 255.255.255.255, Framed-Compression = Van-Jacobsen-TCP-IP, user22@dsl.realm.com Auth-Type := Accept Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 192.168.0.2, Framed-Netmask = 255.255.255.255, Framed-Compression = Van-Jacobsen-TCP-IP, ## Here is some radius debug first for the user that can't login: ## rad_recv: Access-Request packet from host 10.0.0.2:1645, id=46, length=98 Framed-Protocol = PPP User-Name = " user22@dsl.realm.com" CHAP-Password = 0x01295999be562b2eab944deb9647c5a664 NAS-Port-Type = Virtual NAS-Port = 563 Service-Type = Framed-User NAS-IP-Address = 10.0.0.2 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 rlm_chap: Setting 'Auth-Type := CHAP' modcall[authorize]: module "chap" returns ok for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: Looking up realm "dsl.realm.com" for User-Name = " user22@dsl.realm.com" rlm_realm: No such realm "dsl.realm.com" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 1 users: Matched DEFAULT at 152 modcall[authorize]: module "files" returns ok for request 1 modcall: group authorize returns ok for request 1 rad_check_password: Found Auth-Type CHAP auth: type "CHAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 1 rlm_chap: login attempt by " user22@dsl.realm.com" with CHAP password rlm_chap: Could not find clear text password for user user22@dsl.realm.com modcall[authenticate]: module "chap" returns invalid for request 1 modcall: group Auth-Type returns invalid for request 1 auth: Failed to validate the user. Login incorrect (rlm_chap: Clear text password not available): [ user22@dsl.realm.com/<CHAP-Password>] (from client l2tp port 563) ## And a user that can login: ## rad_recv: Access-Request packet from host 10.0.0.2:1645, id=200, length=97 Framed-Protocol = PPP User-Name = "user3@dsl.realm.com" CHAP-Password = 0x012d51dff5b1bda7f6a370e79ff84e0dcf NAS-Port-Type = Virtual NAS-Port = 717 Service-Type = Framed-User NAS-IP-Address = 10.0.0.2 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 modcall[authorize]: module "preprocess" returns ok for request 2 rlm_chap: Setting 'Auth-Type := CHAP' modcall[authorize]: module "chap" returns ok for request 2 modcall[authorize]: module "mschap" returns noop for request 2 rlm_realm: Looking up realm "dsl.realm.com" for User-Name = "user3@dsl.realm.com" rlm_realm: No such realm "dsl.realm.com" modcall[authorize]: module "suffix" returns noop for request 2 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 2 users: Matched DEFAULT at 152 users: Matched user3@dsl.realm.com at 243 modcall[authorize]: module "files" returns ok for request 2 modcall: group authorize returns ok for request 2 rad_check_password: Found Auth-Type Accept rad_check_password: Auth-Type = Accept, accepting the user Login OK: [user3@dsl.realm.com/<CHAP-Password>] (from client l2tp port 717) Sending Access-Accept of id 200 to 10.0.0.2:1645 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = 192.168.0.2 Framed-IP-Netmask = 255.255.255.255 Framed-Compression = Van-Jacobson-TCP-IP Finished request 2 ## I can see that it seems user33 is sending a blank white space before his username, but I don't see that this would make a difference since I'm accepting everything anyway. And from the command line I can use "radtest" and send blank spaces and it works fine. Although I do see that the user would not get assigned his IP address. But first I'd like to ensure everyone can authenticate. Any idea? Thanks in advance Tony
So I put DEFAULT Auth-Type := Accept Everyone will be authenticated?? If that is so will the other attributes against the username in the users file still be applied, such as IP address, if that user is in the file? Tony -----Original Message----- From: freeradius-users-bounces+tony=games-master.co.uk@lists.freeradius.org [mailto:freeradius-users-bounces+tony=games-master.co.uk@lists.freeradius.or g] On Behalf Of Alan DeKok Sent: 02 March 2006 18:52 To: FreeRadius users mailing list Subject: Re: some users not authenticating "Tony Spencer" <tony@games-master.co.uk> wrote:
DEFAULT Auth-Type = Accept
Read "man users". This means "accept, unless another module has already set Auth-Type". Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Friday 03 March 2006 03:18, Tony Spencer wrote:
So I put
DEFAULT Auth-Type := Accept
Everyone will be authenticated?? If that is so will the other attributes against the username in the users file still be applied, such as IP address, if that user is in the file?
Tony
That is the correct syntax to override any previous Auth-Type. And yes, attributes in the users file should still be sent with the reply packet. Kevin Bonner
participants (3)
-
Alan DeKok -
Kevin Bonner -
Tony Spencer