Hello,

I just upgraded a machine from the 0.9.3 Debian package to 1.0.0.
Everything seemed to work smoothly, but upon closer inspection it
started to give login failures for _some_ accounts. I've been unable
to determine what causes this, as other accounts in the same realm
kept on working fine. Another 0.9.3 server using the same configs
continues to work fine. 
I did a quick check of the few config files that changed between
those two versions and recreated the appropriate 1.0.0 proxy.conf
and radius.conf files with the local setting here, but no joy.

So I did the freerad -X dance, results below. Note that the 
users file is a massive Cistron type file (compat=cistron is 
set and with -x or -X you can see it doing a nice conversion dance).
That file is 14MB and yes, a better solution (LDAP) is in the works
but the pace of that project is snail like and out of my control.

Note that both replaced passwords are 8 chars long, nothing special...

First a working example: 
---
Ready to process requests.
rad_recv: Access-Request packet from host 127.0.0.1:32787, id=1, length=76
        User-Name = "[EMAIL PROTECTED]"
        User-Password = "somepass"
        NAS-IP-Address = 255.255.255.255
        NAS-Port = 22
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
  modcall[authorize]: module "preprocess" returns ok for request 0
  modcall[authorize]: module "chap" returns noop for request 0
  modcall[authorize]: module "mschap" returns noop for request 0
    rlm_realm: Looking up realm "airh.vips.gol.com" for User-Name = "[EMAIL PROTECTED]"
    rlm_realm: Found realm "airh.vips.gol.com"
    rlm_realm: Proxying request from user hidden1 to realm airh.vips.gol.com
    rlm_realm: Adding Realm = "airh.vips.gol.com"
    rlm_realm: Authentication realm is LOCAL.
  modcall[authorize]: module "suffix" returns noop for request 0
  rlm_eap: No EAP-Message, not doing EAP
  modcall[authorize]: module "eap" returns noop for request 0
    users: Matched [EMAIL PROTECTED] at 198024
  modcall[authorize]: module "files" returns ok for request 0
modcall: group authorize returns ok for request 0
  rad_check_password:  Found Auth-Type Local
auth: type Local
auth: user supplied User-Password matches local User-Password
Login OK: [EMAIL PROTECTED]/somepass] (from client localhost port 22)
Sending Access-Accept of id 1 to 127.0.0.1:32787
        Service-Type = Framed-User
        Framed-IP-Netmask = 255.255.255.255
        Framed-IP-Address = 255.255.255.254
        Framed-Protocol = PPP
Finished request 0
---


And now the broken one. The record for that user is in the same users
file as the previous one, of course.
---
rad_recv: Access-Request packet from host 127.0.0.1:32787, id=233, length=78
        User-Name = "[EMAIL PROTECTED]"
        User-Password = "somepass"
        NAS-IP-Address = 255.255.255.255
        NAS-Port = 22
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
  modcall[authorize]: module "preprocess" returns ok for request 1
  modcall[authorize]: module "chap" returns noop for request 1
  modcall[authorize]: module "mschap" returns noop for request 1
    rlm_realm: Looking up realm "airh.vips.gol.com" for User-Name = "[EMAIL PROTECTED]"
    rlm_realm: Found realm "airh.vips.gol.com"
    rlm_realm: Proxying request from user hidden2 to realm airh.vips.gol.com
    rlm_realm: Adding Realm = "airh.vips.gol.com"
    rlm_realm: Authentication realm is LOCAL.
  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
radius_xlat:  'v2004-09-01-17.30.00.000000cRb8C'
  modcall[authorize]: module "files" returns notfound for request 1
modcall: group authorize returns ok for request 1
auth: No authenticate method (Auth-Type) configuration found for the request: 
Rejecting the user
auth: Failed to validate the user.
Login incorrect: [EMAIL PROTECTED]/somepass] (from client localhost port 22)
Delaying request 1 for 1 seconds
Finished request 1
---

So what the heck does:

radius_xlat:  'v2004-09-01-17.30.00.000000cRb8C'

tell me and how do I fix this???

Thanks a lot for any input,

Christian Balzer
-- 
Christian Balzer        Network/Systems Engineer                NOC
[EMAIL PROTECTED]       Global OnLine Japan/Fusion Network Services
http://www.gol.com/


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to