|
have been
running FreeRadius at our installation for some time to
authenticate user access to routers. We recently introduced a number of Radius servers for various parts of the network and started using Realms. Also introduced a raddb/users group called "readonly" which gets read only service attributes passed back to NAS which limits the users functionality. We now find that if a username is sent with a suffixed Realm then the users group ("readonly") is bypassed and the DEFAULT group is used. Is there a reference to how I can have a suffix realm observed that still uses the "readonly" DEFAULT entry in the raddb/users file. Attached is a logon with the same user without and with a suffixed realm. raddb/users entry are: DEFAULT Group == "readonly", Auth-Type := System Login-Service = Telnet, Cisco-AVPair = "shell:priv-lvl=1", ERX-Cli-Initial-Access-Level= "5", ........ DEFAULT Auth-Type := System Login-Service = Telnet, Cisco-AVPair = "shell:priv-lvl=15", Service-Type = 6 raddb/realms entry are: # Realm Remote server [:port] Options #---------------- --------------------- ------- rdn LOCAL rad_recv: Access-Request packet from host 144.133.144.100:50000, id=59, length=83 User-Password = "......................................." User-Name = "bhd3" Acct-Session-Id = "erx :0002097211" Service-Type = Administrative-User NAS-IP-Address = 144.133.144.100 NAS-Identifier = "P_Router" modcall: entering group authorize modcall[authorize]: module "suffix" returns ok HASH: user bhd3 found in hashtable bucket 93085 HASH: matched user bhd3 in group readonly users: Matched DEFAULT at 7 modcall[authorize]: module "files" returns ok modcall: group authorize returns ok rad_check_password: Found Auth-Type System auth: type "System" modcall: entering group authenticate HASH: user bhd3 found in hashtable bucket 93085 modcall[authenticate]: module "unix" returns ok modcall: group authenticate returns ok Sending Access-Accept of id 59 to 144.133.144.100:50000 Login-Service = Telnet Cisco-AVPair = "shell:priv-lvl=1" ERX-Cli-Initial-Access-Level = "5" Finished request 6 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 6 ID 59 with timestamp 405d3194 Nothing to do. Sleeping until we see a request. Second use with @realm rad_recv: Access-Request packet from host 144.133.144.100:50000, id=60, length=87 User-Password = "...................................." User-Name = "[EMAIL PROTECTED]" Acct-Session-Id = "erx :0002097212" Service-Type = Administrative-User NAS-IP-Address = 144.133.144.100 NAS-Identifier = "P_Router" modcall: entering group authorize modcall[authorize]: module "suffix" returns ok users: Matched DEFAULT at 65 modcall[authorize]: module "files" returns ok modcall: group authorize returns ok rad_check_password: Found Auth-Type System auth: type "System" modcall: entering group authenticate HASH: user bhd3 found in hashtable bucket 93085 modcall[authenticate]: module "unix" returns ok modcall: group authenticate returns ok Sending Access-Accept of id 60 to 144.133.144.100:50000 Login-Service = Telnet Cisco-AVPair = "shell:priv-lvl=15" Service-Type = Administrative-User Finished request 7 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 7 ID 60 with timestamp 405d31a8 Nothing to do. Sleeping until we see a request. |
- Re: Precedence of Realms and Groups in raddb/users Bernie Dolan
