Hey everyone, I've been tasked with setting up Okta to handle RADIUS authentication for some older Cisco switches and firewalls we have. Our goal is to finally move away from local admin accounts and use our Okta directory.
I found the official docs, but they felt a bit high-level for our specific legacy gear. I wanted to share my step-by-step process and see if anyone has gone through something similar or can spot where I might have gone wrong.
First, I set up the Okta Network Zone. This part was straightforward in the Okta Admin panel under **Security > Network Zones**. I added our corporate public IP range.
Then, I moved to the RADIUS app integration (**Applications > Applications > Create App Integration > RADIUS**). The configuration looked like this:
```
Client IP Address: [Our RADIUS server's public IP]
Client Shared Secret: [Generated a strong secret here]
Network Zone: [Selected the zone I created]
```
The tricky part was mapping the Okta user attributes to RADIUS reply items. Our network gear expects a specific `Filter-Id` value to assign the right admin privilege level. In the **Attribute Mappings** section of the RADIUS app, I set it up like this:
* Okta `user.profile.role` (a custom attribute we have) → RADIUS `Filter-Id`
On the legacy gear side (Cisco IOS), the config looks something like this:
```
aaa new-model
aaa group server radius okta_radius
server [Okta provided RADIUS server IP] auth-port 1812 acct-port 1813
key [The shared secret from Okta]
aaa authentication login default group okta_radius local
```
I've got it working... kind of. Authentication succeeds, but the privilege level isn't being applied correctly—everyone gets the same basic access. I'm guessing the `Filter-Id` value isn't being passed in the correct format, or maybe the attribute needs to be in a different RADIUS vendor-specific attribute (VSA).
Has anyone else dealt with mapping Okta groups or attributes to Cisco privilege levels via RADIUS? Is there a better way to structure the attribute mapping to make the gear understand the admin role?
The attribute mapping step you mentioned is where I've seen most setups get stuck. Did you have to create a custom attribute in Okta for the privilege level, or were you able to map from an existing one like department?
I'm planning a similar project for some old Aruba gear and this part worries me.
Hold on, you're trusting a public IP in your Network Zone for RADIUS? I hope your "corporate public IP range" is a VPN or a dedicated jump box. If that RADIUS traffic is crossing the open internet, even with a shared secret, you're just begging for a headache. The cost of a small private link or even a VPS just for this would be less than the coffee you'd drink while dealing with a brute-force attempt.
On the attribute mapping, I had to create a custom attribute for `cisco-avpair`. The `Filter-Id` is a start, but with the real legacy gear, you often need to send the full AV pair string. It looks like you got cut off, but I'd double-check the exact syntax the Cisco boxes expect - sometimes it's `shell:priv-lvl=15` in the reply item. Getting it wrong just gives you a successful auth but a user stuck in privilege level 1.
pay for what you use, not what you reserve
> you're trusting a public IP in your Network Zone for RADIUS
This. The shared secret is just an obfuscation layer, not encryption. If that traffic is hitting a public IP, you're serving your auth traffic on a platter for offline analysis. The legacy gear probably only supports PAP, too. Good luck with that.
—EB
Yeah, that `Filter-Id` mapping is the make-or-break part. For our old ASAs, we actually had to map two attributes to get full admin: `Filter-Id` set to a value like `Admin` AND a `cisco-avpair` reply item with `shell:priv-lvl=15`. The gear would ignore one without the other.
If you're pulling from an Okta group membership, you can use an expression like `user.isMemberOfGroupName("Network-Admins") ? "Admin" : "User"` in the mapping. Saved us from creating a custom attribute. Might be worth a shot if your groups are already set up.
Curious, did your switches accept the connection from Okta's public IP range immediately, or did you have to tweak any timeout settings on the Cisco side? We hit a few session timeout mismatches.
Data is the new oil - but it's usually crude.
Oh, the attribute mapping part is exactly where I got stuck reading the docs! I'm looking at doing this for some old Avaya gear soon, and the privilege level mapping is my biggest worry.
When you said you set it up to map the Filter-Id, did you test if the switch actually gave you the right admin level after logging in? I've heard that sometimes the auth works but you still get a basic user prompt. Did you have to use any special format like putting the value in quotes?
That expression mapping trick is clever, I'll give you that. It does lock you into a specific group naming convention though, which becomes its own kind of tech debt when someone inevitably renames the group without checking the three other places it's hardcoded.
On the timeout mismatches, absolutely. We saw the same. The real kicker is that the session timeout on the legacy gear is often a global setting buried in some AAA config, not per-server. So you tune it for Okta and suddenly your TACACS+ sessions from the same box start dropping. Had to run a separate AAA server definition just for the Okta RADIUS source to avoid that mess.
And you're right about needing both attributes. We found some IOS versions would accept just `Filter-Id` but the really ancient stuff demanded the full `cisco-avpair`. Makes you wonder what we're actually paying for with this cloud identity broker if we're still debugging 20-year-old vendor quirks.
Your k8s cluster is 40% idle.