Routers/switch to ISE/Okta for MFA

[smolz]

Looking at changing our router/switch environment to use MFA with ISE/Okta.  Trying to find any information on this hasn't turned up much.

I am assuming i need to change the AAA to use Radius, but unsure how to go about the rest.  Right now with ISE when you login it is using AD to authenticate you, then based on AD group assignment you are given access.

[thomas]

Currently SAML based authentication with Identity Providers (IdPs) is only available for web portal single sign on (device registration, sponsor), not 802.1X authentication.

You would want to consider doing RADIUS proxy instead.

[smolz]

---

@thomas wrote:

Currently SAML based authentication with Identity Providers (IdPs) is only available for web portal single sign on (device registration, sponsor), not 802.1X authentication.

You would want to consider doing RADIUS proxy instead.

---

That is what I was looking at doing.  Just wanted to know if anyone has set this up. 

[NicolePerez91]

I am in process of getting this to work.  I got it to work using the authentication piece.  We use the Radius Agent and then use the Radius application in the cloud.  It doesnt pass authorization though.  SO if you you want the tfa with the username login you could say authorization NONE OR set it to local and mimick the account login with the username command with the privilege level set.

It works for that but OKTA does not send back the shell command.  It will send back groups in OKTA but not the shell command.

[NicolePerez91]

There is a reference in the Client IP for Vendor Specific but the only response is in the groups.  If you know of a way to reference Cisco-AV-Pair = shell:priv-lvl=7 that would be awesome.  I can get it to send group names back but not sure how I would reference that in aaa switch configuration. 

[smolz · Accepted solution]

We ended up reusing the same config we had on the router/switches using TACACS and Cisco ISE.  The only thing we changed on the devices was the timeout to 60 seconds.   Then in ISE we created a Radius Token server that pointed to Okta, there was an option that we had to check to not reauth or something.  Then we changed the device admin policy to use the Okta server for authentication.

[NicolePerez91]

I figured as much that I would have to end up using our Clearpass as a tacacs solution using tfa to OKTA if I want to receive the shell response back.  I was trying to eliminate complexity and figured OKTA has this Radius App and the solution should be like a Radius Server.  Just frustrating that they dont support this option or have this in their scope.  I did reach out to OKTA on this and they were basically saying that their product doesnt do this and was quickly trying to close my ticket.   Thanks for your response.

[smolz]

This is the setting

[gwarn]

I am working on this and have had some luck (specifically Cisco UCSM wouldn't work without the shell command).  My fix was as follows

1) create an AD group called admin (lower case)  Put your network admin AD accounts into this AD group.  Force AD import into OKTA to seed this new group and membership

2) Under the OKTA RADIUS for AAA (or whatever you have named your app) click sign on.  Go to Advanced RADIUS settings.

3) Edit - RADIUS attribute 26 Vendor-Specific, Vendor Specific ID = 009 and Attribute ID = 001

4) Group memberships to return (you should be able to search and find "admin"

5) Response format = repeating attributes

6) Group Name format = custom

7) shell:roles="${group.name}"

This method solved my UCSM issue.  I have some A10 load balancers that don't give me priv 15 yet and when I compare my old RADIUS solution to OKTA I need to pass this (shell:priv-lvl=15) but am struggling with it so far.  There are options for delimiter and how to respond and while I can see it in my wireshark trace and it looks right A10 device is not taking it.  I have used this on Nexus, ISRs, MDS, ASA and just about every catalyst switch without issue so far though.  One final thought you may find some devices that don't properly support OKTA push responses.  Workaround is simple.  Give it your OKTA username for user and okta password,okta.verify.tokencode all as the password.  Works great on UCSM and Digi Console servers.

Hope this helps