multiple Autz-Type

[wekz <fbl.list@gmail.com>]

Hello everybody. I'll tell you what i wanna do and the problem i get so you could either fix my configuration or give me some new ideas. 

First, I´m using freeradius 1.1.1 + ldap. 

What I have is this: I have three radius working in different placement of one organization, these radius authorize against three subtrees of the ldap. When a user is not found they do proxy to another radius. This work quite well. 


What I want: I want to have another radius ( only one ) to acct as a backup of these servers ( for configuring my ciscos with two servers ). This radius has the complete tree but it must look in each subtree depending on the NAS-IP, not in the whole ldap. If the user is not found in the corresponding subtree it must do proxy to the central radius.

I don't know if I have explain it correctly, if I haven't just tell me ( I'm not an english speaker )

For this configuration I've defined three ldaps in radiusd.conf:
module{
    ldap ldap1{
    }
    ldap ldap2{
    }
    ldap ldap3{
    }
}
...
authorize{
...
     autztype customer1{
                redundant {
                        group {
                                ldap1 {
                                        notfound = return
                                        fail = return
                                }
                                files
                                mschap
                                eap
                                notfound = 1
                                fail = 1
                        }
                        files
                }
        }
       Autz-Type customer2{
           [ similar configuration as above ]
       }
       Autz-Type customer3{
           [ similar configuration as above ]
       }
}


My hints file:

DEFAULT NAS-IP-Address == "192.168.51.220"
        Autz-Type := customer1
DEFAULT NAS-IP-Address == "192.168.51.221"
        Autz-Type := customer2
DEFAULT NAS-IP-Address == "192.168.51.222"
        Autz-Type := customer3



Users:
DEFAULT Proxy-to-realm := wickwar_central



The problem is that it doesn't execute any of Autz-Type sections.

The logs:
rad_recv: Access-Request packet from host 192.168.51.221:1645, id=200, length=160
        User-Name = "cadiz"
        Framed-MTU = 1400
        Called-Station-Id = "
0011.9215.c490"
        Calling-Station-Id = "0004.238d.4b0e"
        Cisco-AVPair = "ssid=perfil_tipo_a"
        Service-Type = Login-User
        Message-Authenticator = 0x27c966f01f1de90c836066e2a019c553
        EAP-Message = 0x0202000a01636164697a
        NAS-Port-Type = Wireless-802.11
        Cisco-NAS-Port = "395"
        NAS-Port = 395
        NAS-IP-Address = 
192.168.51.221
        NAS-Identifier = "ap"
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
  hints: Matched DEFAULT at 59
  modcall[authorize]: module "preprocess" returns ok for request 1
    rlm_realm: No '/' in User-Name = "cadiz", looking up realm NULL
    rlm_realm: No such realm "NULL"
  modcall[authorize]: module "ntdomain" returns noop for request 1
radius_xlat:  '/opt/radius_LOCAL/var/log/radius/radacct/192.168.51.221/auth-detail-20060605'
rlm_detail: /opt/radius_LOCAL/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /opt/radius_LOCAL/var/log/radius/radacct/192.168.51.221/auth-detail-20060605
  modcall[authorize]: module "auth_log" returns ok for request 1
modcall: leaving 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: [cadiz/<no User-Password attribute>] (from client ap port 395 cli 
0004.238d.4b0e)
Delaying request 1 for 1 seconds
Finished request 1
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 200 to 192.168.51.221 port 1645
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 1 ID 200 with timestamp 44840b82
Nothing to do.  Sleeping until we see a request.








If anyone could give my a hand. I would be grateful. 
Thanks.