cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

930
Views
25
Helpful
3
Replies
victor.mansson
Beginner

ISE Policy Sets - Condition for MS Windows

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?

1 ACCEPTED SOLUTION

Accepted Solutions
Greg Gibbs
Cisco Employee

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:

Screen Shot 2021-09-20 at 8.44.16 am.png

View solution in original post

3 REPLIES 3
Milos_Jovanovic
Collaborator

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
Cisco Employee

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:

Screen Shot 2021-09-20 at 8.44.16 am.png

View solution in original post

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

BR,

Milos

Create
Recognize Your Peers
Content for Community-Ad

ISE Webinars



Did you miss a previous ISE webinar?

CiscoISE YouTube Channel