EAP-TLS with MAC Address Whitelist

[CMack6]

Hello everyone! 

First, let me preference this post with this is my first time working with ISE and 802.1x.  So, thank you for your patience and assistance!!!

I have ISE v3.0 right now – I am going to upgrade to v3.1 prior to starting this deployment.  I will be using EAP-TLS and EAP-TTLS (inner method EAP-MSCHAPv2).  I have to utilize both as half of my IoT devices do not support EAP-TLS at this time. 

What I am wanting to do (to meet my company’s standards) is to require the 802.1x authentication to be successful AND have the MAC Address on a whitelist.  Obviously, if the 802.1x authentication fails, access is blocked to the port.  But what I am looking for assistance for is if 802.1x authentication is successful, but the MAC is not on a whitelist, then that port gets moved to a honey pot and or the port just gets disabled.  So, a multi-factor format here. 

Is this possible in ISE?  Thank you!!

[Rodrigo Diaz]

hello @CMack6  , yes it's possible to have such configurations on ISE what you need to do in this scenario is to create an authorization rule that is going to include 2 conditions, one that links the mac address that you have listed in a group and another include the condition for EAP-TLS please refer to the example that I am posting below :

In case the authorization rule is not hit , in this scenario you can enforce another rule below and deny the endpoints that are not listed in the endpoint identity group . 

Let me know if that helped you . 

[hslai]

@CMack6  Adding to what suggested above...

We may also constraint on the allowed protocols, the identity sources, and the authentication options. For example, we may define our own allowed protocols to allow only EAP-TLS and EAP-TTLS. Then, use this allowed protocols in our own policy set. For each authentication policy rule, there are options for (1) if Auth fail (REJECT as the default), (2) if User not found (REJECT as the default) and (3) if Process fail (DROP as the default) and the default selections are usually good.

In the authorization rules, Network_Access_Authentication_Passed is a library condition to indicate the authentication is successful so you might consider using it.

[hurairak253]

We might also constraint on the allowed protocols, the identification resources, and the authentication alternatives. For example, we may additionally define our very own allowed protocols to permit most effective EAP-TLS and EAP-TTLS. Then, use this allowed protocols in our own coverage set. For every authentication policy rule, there are options for (1) if Auth fail (REJECT as the default), (2) if User now not found (REJECT as the default) and (3) if Process fail (DROP because the default) and the default picks are typically properly.

In the authorization rules, Network_Access_Authentication_Passed is a library circumstance to signify the authentication is a hit so that you would possibly consider the use of it.