have been
running FreeRadius at our installation for some time toauthenticate user
access to routers.We recently introduced a number of Radius servers for
various parts of thenetwork and started using Realms.Also introduced a
raddb/users group called "readonly" which gets read onlyservice 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 usersgroup ("readonly")
is bypassed and the DEFAULT group is used.Is there a reference to how I can
have a suffix realm observed that stilluses 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
= 6raddb/realms entry are:#
Realm
Remote server
[:port]
Options#
-
---rdn
LOCALrad_recv: Access-Request packet from host 144.133.144.100:5,
id=59,length=83User-Password =
"..."User-Name =
"bhd3"Acct-Session-Id = "erx :0002097211"Service-Type =
Administrative-UserNAS-IP-Address = 144.133.144.100NAS-Identifier =
"P_Router"modcall: entering group authorizemodcall[authorize]: module
"suffix" returns okHASH: user bhd3 found in hashtable bucket 93085HASH:
matched user bhd3 in group readonlyusers: Matched DEFAULT at
7modcall[authorize]: module "files" returns okmodcall: group authorize
returns okrad_check_password: Found Auth-Type Systemauth: type
"System"modcall: entering group authenticateHASH: user bhd3 found in
hashtable bucket 93085modcall[authenticate]: module "unix" returns
okmodcall: group authenticate returns okSending Access-Accept of id 59
to 144.133.144.100:5Login-Service = TelnetCisco-AVPair =
"shell:priv-lvl=1"ERX-Cli-Initial-Access-Level = "5"Finished request
6Going 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 405d3194Nothing to do.
Sleeping until we see a request.Second use with @realmrad_recv:
Access-Request packet from host 144.133.144.100:5,
id=60,length=87User-Password =
""User-Name = "[EMAIL PROTECTED]"Acct-Session-Id = "erx :0002097212"Service-Type =
Administrative-UserNAS-IP-Address = 144.133.144.100NAS-Identifier =
"P_Router"modcall: entering group authorizemodcall[authorize]: module
"suffix" returns okusers: Matched DEFAULT at 65modcall[authorize]:
module "files" returns okmodcall: group authorize returns
okrad_check_password: Found Auth-Type Systemauth: type
"System"modcall: entering group authenticateHASH: user bhd3 found in
hashtable bucket 93085modcall[authenticate]: module "unix" returns
okmodcall: group authenticate returns okSending Access-Accept of id 60
to 144.133.144.100:5Login-Service = TelnetCisco-AVPair =
"shell:priv-lvl=15"Service-Type = Administrative-UserFinished request
7Going 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 405d31a8Nothing to do.
Sleeping until we see a request.
