problem matching realms - for local auth not proxy
Hi Using freeradius2.1.3 for seperate Auth and Acct servers in DSL/PPPoE n/w. Using CHAP auth only and lookup via dbm file with users.txt fallback. Can successfully authenticate/authorise against specific user profiles in users dbm/txt but problems when trying to match realms. Have users dbm/txt file with list of DEFAULT realm=xxx followed by users profiles. realm matches simply returns L2TP tunnel profiles for these realms (no fallthru). No realm match (null or other domains not in proxy.conf) will do lookup and return specific user profiles (i.e matching userxx Cleartext-Password := "xxxx"). Debug shows the rlm_realms module logging error: [suffix] Looking up realm "dslip" for User-Name = "jean@dslip" [suffix] No such realm "dslip" We are not proxying to remote servers but do local auth on matching realms. Am I missing some step/module which imports the proxy.conf file - or the order of modules in authorise{} This issue occurs regardless dbm or files based lookup and in realms module.If I remove proxy.conf radius does not complain. Ive looked in maillist for similiar problems. Some reference to include suffix in preacct module but ours is Auth server only. I have spent some time testing and read man pages, searching related etc before resorting to first my first query to this maillist. Any help appreciated SeamusB Setup ---------- [1] Test users file with single record - a default realm : DEFAULT Realm == "dslip", Auth-Type := Accept Tunnel-Type:1 = L2TP, Tunnel-Medium-Type:1 = IP, Tunnel-Server-Endpoint:1 = "xxx.xxx.xxx.xxx", Tunnel-Client-Auth-Id:1 = "yyy", Tunnel-Password:1 = "yyy", Tunnel-Assignment-Id:1 = "dslip", Tunnel_Algorithm = 2, Tunnel_Domain = 1 Added to dbm file: /usr/local/freeradius/bin/rlm_dbm_cat -f /usr/local/freeradius/etc/raddb/users DEFAULT Realm == "dslip", Auth-Type := Accept Tunnel-Type:1 = L2TP, Tunnel-Medium-Type:1 = IPv4, Tunnel-Server-Endpoint:1 = "159.134.191.145", Tunnel-Client-Auth-Id:1 = "dslip", Tunnel-Password:1 = "unlock", Tunnel-Assignment-Id:1 = "dslip", Tunnel_Algorithm = 2, Tunnel_Domain = 1 freeradiusdsldev00# [2] proxy.conf has realm added as below and permissions 644 for radius/radadmin realm dslip { type = radius authhost = LOCAL accthost = LOCAL nostrip } [3] radiusd.conf includes reference to realm module and includes in authorise {} section. Also not including policy.conf which denies realms by default. modules { .. realm suffix { format = suffix delimiter = "@" ignore_default = no ignore_null = no } } authorize { preprocess suffix chap group { dbm { ok = return reject = return notfound = return fail = 1 } files { ok = return reject = return notfound = return fail = return } } } [4] Radiusd -X output client freeradiusdsldev00 { require_message_authenticator = no secret = "testing123" shortname = "freeradiusdsldev00" } radiusd: #### Loading Realms and Home Servers #### radiusd: #### Instantiating modules #### radiusd: #### Loading Virtual Servers #### modules { Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_chap Module: Instantiating chap Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_preprocess Module: Instantiating preprocess preprocess { huntgroups = "/usr/local/freeradius/etc/raddb/huntgroups" hints = "/usr/local/freeradius/etc/raddb/hints" with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no with_alvarion_vsa_hack = no } Module: Linked to module rlm_realm Module: Instantiating suffix realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } Module: Linked to module rlm_dbm Module: Instantiating dbm dbm { usersfile = "/usr/local/freeradius/etc/raddb/users" byclid_length = 4 } Module: Linked to module rlm_files Module: Instantiating files files { usersfile = "/usr/local/freeradius/etc/raddb/users.txt" compat = "no" byclid_length = 4 } } radiusd: #### Opening IP addresses and Ports #### bind_address = * WARNING: The directive 'bind_adress' is deprecated, and will be removed in future versions of FreeRADIUS. Please edit the configuration files to use the directive 'listen'. Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on proxy address * port 1814 Ready to process requests. [5] Test when using radclient with test username jean@dslip which should match the realm in proxy.conf and default profile in users.db. Server debug log: rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx port 35210, id=168, length=201 User-Name = "jean@dslip" Acct-Session-Id = "5511534626" CHAP-Password = 0xa812b2813543dd45b1434328ea423c83e4 Service-Type = Framed-User Framed-Protocol = PPP +- entering group authorize {...} ++[preprocess] returns ok [suffix] Looking up realm "dslip" for User-Name = "jean@dslip" [suffix] No such realm "dslip" ++[suffix] returns noop [chap] Setting 'Auth-Type := CHAP' ++[chap] returns ok ++- entering group {...} rlm_dbm: try open database file: /usr/local/freeradius/etc/raddb/users rlm_dbm: Call parse_user: sm_parse_user.c: check for loops Add jean@dslip to user list rlm_dbm: User <jean@dslip> not found in database Remove jean@dslip from user list sm_parse_user.c: check for loops Add DEFAULT to user list sm_parse_user: start parsing: user: DEFAULT parse buffer: <<Realm == "dslip", Auth-Type := Accept>> rlm_dbm: recod parsed process pattern rlm_dbm: patern not matched, reply skiped Remove DEFAULT from user list +++[dbm] returns notfound ++- group returns notfound Found Auth-Type = CHAP +- entering group CHAP {...} [chap] login attempt by "jean@dslip" with CHAP password [chap] Cleartext-Password is required for authentication ++[chap] returns invalid Failed to authenticate the user. Login incorrect (rlm_chap: Clear text password not available): [jean@dslip/<CHAP-Password>] (from client freeradiusdsldev00 port 3525263410 cli :xxxxxx) Sending Access-Reject of id 168 to xxx.xxx.xxx.xxx port 35210 Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 168 with timestamp +5 Ready to process requests.
Seamus Bridgeman wrote:
Using freeradius2.1.3 for seperate Auth and Acct servers in DSL/PPPoE n/w. Using CHAP auth only and lookup via dbm file with users.txt fallback. Can successfully authenticate/authorise against specific user profiles in users dbm/txt but problems when trying to match realms.
Why are you using the DBM files?
We are not proxying to remote servers but do local auth on matching realms. Am I missing some step/module which imports the proxy.conf file - or the order of modules in authorise{} This issue occurs regardless dbm or files based lookup and in realms module.
No. The default configuration loads the proxy.conf file.
If I remove proxy.conf radius does not complain.
Because it's not required in all configurations.
Added to dbm file: /usr/local/freeradius/bin/rlm_dbm_cat -f
Don't use rlm_dbm. Just use the normal "users" file. It works, and it's fast.
[3] radiusd.conf includes reference to realm module and includes in authorise {} section. Also not including policy.conf which denies realms by default.
No, it doesn't. As the comments in that file should make clear, those are SAMPLE policies. They aren't used until you tell the server to use them.
authorize { ... }
Great. You've completely butchered the "authorize" section, and removed all references to the "realms" module. Can you explain WHY you did this? What documentation led you to conclude that deleting the majority of that section was a good idea? The recommendation here is simple: DO NOT BUTCHER THE DEFAULT INSTALL The default installation WORKS. If you had simple added a realm, and added entries in the "users" file... it would have WORKED. Instead, you spent a great deal of effort editing the configuration, breaking it, and then trying to debug it. Almost all of that work was wasted. The default installation works. Don't butcher it. Read "man radiusd" for instructions on how to edit the configuration without breaking it. Alan DeKok.
Fair enough Alan. Reprimand warranted and accepted. We removed proxy settings but naturally need this to match realms in proxy.conf which solved our problem Take your point on controlled iterative changes to default settings in radiusd.conf and not butchering! Just getting familiar with changes post 2.0.0 (virtual servers with authorise{} etc ). We have a need to use dbm file given our volumes and migration from current dbm based Radius. thanks again for help/advice. 2009/4/1 Alan DeKok <aland@deployingradius.com>
Seamus Bridgeman wrote:
Using freeradius2.1.3 for seperate Auth and Acct servers in DSL/PPPoE n/w. Using CHAP auth only and lookup via dbm file with users.txt fallback. Can successfully authenticate/authorise against specific user profiles in users dbm/txt but problems when trying to match realms.
Why are you using the DBM files?
We are not proxying to remote servers but do local auth on matching realms. Am I missing some step/module which imports the proxy.conf file - or the order of modules in authorise{} This issue occurs regardless dbm or files based lookup and in realms module.
No. The default configuration loads the proxy.conf file.
If I remove proxy.conf radius does not complain.
Because it's not required in all configurations.
Added to dbm file: /usr/local/freeradius/bin/rlm_dbm_cat -f
Don't use rlm_dbm. Just use the normal "users" file. It works, and it's fast.
[3] radiusd.conf includes reference to realm module and includes in authorise {} section. Also not including policy.conf which denies realms by default.
No, it doesn't. As the comments in that file should make clear, those are SAMPLE policies. They aren't used until you tell the server to use them.
authorize { ... }
Great. You've completely butchered the "authorize" section, and removed all references to the "realms" module.
Can you explain WHY you did this? What documentation led you to conclude that deleting the majority of that section was a good idea?
The recommendation here is simple:
DO NOT BUTCHER THE DEFAULT INSTALL
The default installation WORKS. If you had simple added a realm, and added entries in the "users" file... it would have WORKED.
Instead, you spent a great deal of effort editing the configuration, breaking it, and then trying to debug it. Almost all of that work was wasted.
The default installation works. Don't butcher it. Read "man radiusd" for instructions on how to edit the configuration without breaking it.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Seamus Bridgeman wrote:
We have a need to use dbm file given our volumes and migration from current dbm based Radius.
In 2.x, the "users" file is put into an internal hash. So it's just as fast (if not faster) than DBM files. I've tested it reading 10's of 1000's of entries in the "users" file in less than a second. So unless you have 100's of 1000's of entries in the "users" file, the DBM overhead is unnecessary. Alan DeKok.
participants (2)
-
Alan DeKok -
Seamus Bridgeman