What I am trying to do:
Simply authenticate and login to a Cisco Cloud Services Platform GUI or CLI via RADIUS with admin-group privilege (or any group).
CSP is standalone, basic config, just the built-in admin super-user present. Reachability to RADIUS server confirmed. No access lists or Firewalls in play.
I've tried with Windows Server 2022 NPS and FreeRADIUS running on Ubuntu with the same results.
The CSP documention does not indicate clearly (at least to me) what RADIUS attributes are required to be sent in the Access-Accept messages in order to properly authenticate a remote user to correct group. For example, the admin-group.
https://www.cisco.com/c/en/us/td/docs/routers/CSP/csp-2100/config/b_Cisco_CSP_Config_Guide_2-9-0.html#id_33411
Cisco CSP-5216
csp# show version
Cisco Cloud Services Platform Software Software, Version 2.9.2 Build:319
TAC Support:
Copyright (c) 2018-2020 by Cisco Systems, Inc
Compiled Thursday 08-December-2022 10:10http://www.cisco.com/tac
-SNIP-
Radius config on the CSP:
show running-config radius-server
radius-server retransmit 1
radius-server timeout 5
radius-server host 192.168.220.12
key 7
shared-secret testing123
auth-port 1812
acct-port 1813
!
csp# ping 192.168.220.12
PING 192.168.220.12 (192.168.220.12) 56(84) bytes of data.
64 bytes from 192.168.220.12: icmp_seq=1 ttl=61 time=11.6 ms
Local user config on the CSP:
csp# show running-config csp-users
csp-users groups group default-vnf-group
type none
!
csp-users users user admin
group superadmin
password <REDACTED>
!
FreeRADIUS version 3.0.26 (Ubuntu)
Users:
root@ubuntu:/# cat /etc/freeradius/3.0/users
testing Cleartext-Password := "password"
Service-Type = Administrative-User,
Class := "admin-group"
-SNIP-
clients.conf: (The CSP)
client new {
ipaddr = 192.168.104.30
secret = testing123
nas_type = cisco
}
Testing logging in as user "testing" and password "password" from the CSP GUI:
Result: Denied, cannot login.
FreeRADIUS logs:
Ready to process requests
(2) Received Access-Request Id 145 from 192.168.104.30:55985 to 192.168.220.12:1812 length 59
(2) User-Name = "testing"
(2) User-Password = "password"
(2) NAS-Port = 0
(2) NAS-IP-Address = 192.168.104.30
(2) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default
(2) authorize {
(2) policy filter_username {
(2) if (&User-Name) {
(2) if (&User-Name) -> TRUE
(2) if (&User-Name) {
(2) if (&User-Name =~ / /) {
(2) if (&User-Name =~ / /) -> FALSE
(2) if (&User-Name =~ /@[^@]*@/ ) {
(2) if (&User-Name =~ /@[^@]*@/ ) -> FALSE
(2) if (&User-Name =~ /\.\./ ) {
(2) if (&User-Name =~ /\.\./ ) -> FALSE
(2) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) {
(2) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE
(2) if (&User-Name =~ /\.$/) {
(2) if (&User-Name =~ /\.$/) -> FALSE
(2) if (&User-Name =~ /@\./) {
(2) if (&User-Name =~ /@\./) -> FALSE
(2) } # if (&User-Name) = notfound
(2) } # policy filter_username = notfound
(2) [preprocess] = ok
(2) [chap] = noop
(2) [mschap] = noop
(2) [digest] = noop
(2) suffix: Checking for suffix after "@"
(2) suffix: No '@' in User-Name = "testing", looking up realm NULL
(2) suffix: No such realm "NULL"
(2) [suffix] = noop
(2) eap: No EAP-Message, not doing EAP
(2) [eap] = noop
(2) files: users: Matched entry testing at line 1
(2) [files] = ok
(2) [expiration] = noop
(2) [logintime] = noop
(2) [pap] = updated
(2) } # authorize = updated
(2) Found Auth-Type = PAP
(2) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(2) Auth-Type PAP {
(2) pap: Login attempt with password
(2) pap: Comparing with "known good" Cleartext-Password
(2) pap: User authenticated successfully
(2) [pap] = ok
(2) } # Auth-Type PAP = ok
(2) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default
(2) post-auth {
(2) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) {
(2) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -> FALSE
(2) update {
(2) No attributes updated for RHS &session-state:
(2) } # update = noop
(2) [exec] = noop
(2) policy remove_reply_message_if_eap {
(2) if (&reply:EAP-Message && &reply:Reply-Message) {
(2) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(2) else {
(2) [noop] = noop
(2) } # else = noop
(2) } # policy remove_reply_message_if_eap = noop
(2) if (EAP-Key-Name && &reply:EAP-Session-Id) {
(2) if (EAP-Key-Name && &reply:EAP-Session-Id) -> FALSE
(2) } # post-auth = noop
(2) Sent Access-Accept Id 145 from 192.168.220.12:1812 to 192.168.104.30:55985 length 57
(2) Service-Type = Administrative-User
(2) Class = 0x61646d696e2d67726f7570
(2) Finished request
Waking up in 4.9 seconds.
(2) Cleaning up request packet ID 145 with timestamp +129 due to cleanup_delay was reached
Ready to process requests
From the above output we see the user was authenticated successfully and Service-Type and Class attributes were sent in the Access-Accept reply.
CSP logs:
csp# show log messages
Nov 2 13:32:17 csp radexternal: rc_avpair_gen: received unknown attribute 80 of length 18: 0x34C7DE97F8BEED36EAA3EE5FA4E1AC57
Nov 2 13:32:17 csp radexternal: REJECT (RC=0)
I believe this "unknown attritbute" is the message-authenticator attribute and is used for validation and integrity purposes. The fact that The RADIUS logs above show successful authentication indicates to me that this isn't a pre-shared key issue. From my research it appears you cannot and would not want to disable message-authentication in FREERADIUS or Microsoft NPS.
How about playing around with Cisco attribute-values?
testing Cleartext-Password := "password"
Service-Type = Administrative-User,
Cisco-AVPair := "shell:priv-lvl=15",
Cisco-AVPair += "shell:roles=admin-group"
CSP GUI login result: Login failed
RADIUS logs: Same as before, authentication successful
(0) Sent Access-Accept Id 44 from 192.168.220.12:1812 to 192.168.104.30:58583 length 100
(0) Service-Type = Administrative-User
(0) Cisco-AVPair = "shell:priv-lvl=15"
(0) Cisco-AVPair = "shell:roles=admin-group"
(0) Finished request
CSP logs:
Nov 2 13:50:06 lon-lab-csp1 radexternal: rc_avpair_gen: received VSA attribute with unknown Vendor-Id 9
Nov 2 13:50:06 lon-lab-csp1 radexternal: REJECT (RC=0)
Now it's complaining about receiving unknown Cisco attributes.
Anyone out there managed to configure this and get it working?
Any help greatly appreciated.
