Wired DOT1X Authentication using List Name /NOT default

[chris-lawrence]

Community,

I have a requirement for DOT1X authentication using multiple vrf-aware RADIUS server groups on my Catalyst 3850. 16.3.6 Denali. I have followed the "vfr aware aaa" documentation.

aaa authentication dot1x black_list group black-radius (for VRF black)

aaa authentication dot1x blue_list group blue-radius (for VRF blue)

Although the command structure supports placing these commands, it does nothing in authenticating to my two radius environments. I'd like to be able to process black to black and blue to blue but when I enter these, authentication doesn't work at all until I fallback using "default":

aaa authentication dot1x default group black-radius.

If anyone is wondering what I am doing - I have a single switch environment hosting two clients, and I have certificates in my endpoints that work with my radius to authenticate the endpoint to an environment. Its just that it can be one or the other but not both.

Does anyone know if this is supported? Using these named lists with dot1x? 

Any documentation available?

Thanks.

[Timothy Abbott · Accepted solution]

Hi Chris,

This sounds more like an possible switch configuration issue that something that would be ISE specific. I suggest reaching out to the TAC to further troubleshoot and figure out if that switch configuration is possible.

Regards,
Tim

[vivekshukla]

Hi Chris, did you manage to find a solution for this. I have an exact same requirment as yours and trying to find a solution.

[chris-lawrence]

Hi Vivekshukla,

unfortunately this was ACS and not ISE - I do know that ISE is not VRF-aware. I’ve actually not had to complete that design - it fell through. ISE is a whole different beast. Sorry can’t help you.

chris

[chris-lawrence]

Perhaps I can think about this tomorrow and report back to you if I think about something…

[vivekshukla]

Thanks Chris, I did some more digging after posting this and the config I am after is possible via IBNS 2.0 . I will test it during next week and if everything is working will post back on this thread for anyone else with same problem. 

[vivekshukla]

I have completed my testing and it is working using IBNS 2.0. With IBNS 2.0 we have option to define seperate radius server for each interface using service policy. Combine it with vrf aware aaa and we have our solution. More information on below link under section 

Differentiated Authentication with IBNS 2.0

https://community.cisco.com/t5/security-knowledge-base/ise-secure-wired-access-prescriptive-deployment-guide/ta-p/3641515

[davidgfriedman]

Are you sure you're using it correctly?  I was under the impression the point of two different radius servers was to allow you to use one for dot1x and one for ssh logins, assuming you didn't have a dedicated TACACS+ capable server for login controls.  Out of curiosity, I tried this on my lab 9200 series and while it took the command, the logs showed another thing entirely:

Nov 2 17:53:39.628 EDT: %PARSER-5-HIDDEN: Warning!!! ' aaa authentication dot1x blue radius group ISE' is a hidden command. Use of this command is not recommended/supported and will be removed in future.

Do you have any similar warnings in your Denali IOS after you type in your aaa VRF style commands?

This matches up with me being unable to find anything for this EXCEPT in cases where you might want to split authz to a different server than authc.  As for why I found the VRF option in the dynamic author and radius servers, that would be for their basic communication routing setups. So that leads me to think the option is not for VRF based authentication.  If that were the case, how would you even tie a port to the VRF? It would have to be a way to tie in authorization (after authentication is done), for which I don't see anything.  Food for thought.  I'll definitely be following this topic.

[chris-lawrence]

Hi David,

My use case was that I was using a common NAD that provides potential access to two different customers. Customer 1 (BLACK) would come in on a VRF'ed zone and the AuthC would be directed to the BLACK-ACS (at this time, we were not using ISE). Likewise on the BLUE VRF'ed zone, that customer would hit the BLUE-ACS. The project fell apart so I didn't have to find a solution but it was an interesting problem that Vivekshuka was looking into. I'm always interested in integrations like this and what solutions I can define.