ISE Policy Sets - Condition for MS Windows

[victor.mansson]

Hi all

We are trying to merge a few of our SSID into one SSID with the help of ISE.

To keep things easier and cleaner we would like to have multiple Policy Sets for the same SSID.

One Policy Set for our MS Windows (Domian machines) and one Policy Set for the rest.

We are running EAP-TEAP for our Windows machines and EAP-TLS for the rest (Phones, tables etc).

Im looking for a Condition in Policy Sets to filter out only MS Windows machines.

Have anyone successfully implemented this and can point me in the right direction?

[Milos_Jovanovic]

Hi @victor.mansson,

I would use one policy set for this one SSID. Policy sets are indeed created for more optimal processing of data, but also for logical organization of the configuration. From my standpoint, one SSID is one service and should be treated under one policy set. Within policy set, I would create different conditions for authentication/authorization, which would differentiate domain machines from rest.

As I don't believe you would be able to differentiate EAP-TEAP from EAP-TLS (I don't see condition apart from EAP-TLS, and both are reported as EAP-TLS on ISE), you would need to use profiling to identify Windows devices.

BR,

Milos

[Greg Gibbs · Accepted solution]

I would agree with @Milos_Jovanovic about using a single Policy Set per SSID. Splitting Policy Sets for the different endpoint types within the same Policy Set would likely add more complexity rather than reducing it.

ISE Profiling is what identifies the endpoint as a Windows PC (from the DHCP class-identifier), and Profiling is a post-auth activity. You can't use Profiling in the Policy Set or AuthC Policy matching conditions. If your Windows SOE is using TEAP, you can match on that in the AuthC Policy using the Network Access·EapTunnel Equals TEAP condition. This would allow you to have different AuthC Policies for TEAP (using a CAP and ISS to check against AD) and EAP-TLS (using just a CAP; assuming there is no external ID store to check identity against for those endpoints). You can then use similar matching conditions in your AuthZ Policy to provide differentiated access if necessary.

I've used this same approach with many customer deployments and have never had any issues.

Example:

[Milos_Jovanovic]

Thanks @Greg Gibbs. I haven't used TEAP before, and I was unaware of this.

BR,

Milos