cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Announcements
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

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.

178
Views
5
Helpful
1
Replies
Highlighted
Beginner

Building policy-sets from design perspective

policyHello Everyone

 

My question less technical. I am just wondering, because I came across a lot Blogs about 802.1x and their setups. On many of them I saw the following

 

Example:

 

Authorization Policy

If: Wired_MAB &

if: IdentityGroup:Name Equals: Endpoints. Identity Group: Trusted_Devices

 

Question:

Why many people add Wired_MAB or Wired_8021x also on the Authorization policy? I was thinking of it and I've found some ideas:

 

- Scalability: In case they add additional to Wired_MAB also Wired_8021x to the same Policy?

- Because of "Authentication open"?

 

Do you have some suggestions? or can you explain me why this would be a good idea?

 

Thanks in advance,

Regards,
Max

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
VIP Advisor

Re: Building policy-sets from design perspective

For me it comes down to three things.

1. Ease of use/organization
2. Performance and scale
3. Reporting

One and three could fall in to one, but the ability to know where to go to look to troubleshoot something is a huge bonus. It provides another key detail and the ability to use a course filter when parsing data. Writing 802.1x vs MAB policy, you can end up with some of the same endpoint flows but under a different method you can avoid having to write more complex rules to avoid conflict. Since ISE is a first match policy flow like an ACL, splitting auth out by 802.1x/mab makes this easier on yourself.

On performance, having individual policy sets for various reasons can prevent ISE From having to parse large lists of policy that don't apply. As a high level example of this, if you have 802.1x and MAB in the same policy set, the 802.1x authentications very likely don't need to be evaluated against MAB policy, or vice versa. You also specify identity stores to be looked at when defining an individual policy set, further reducing lookups we might not need with MAB against an external ID store.

Many large complex deployments even have multiple policy sets for 802.1x and MAB. At the end of it all, each deployments design comes down to the use cases you have to work with, and various segments that might need different treatment.

There is a good outline of designing policy sets/ authorization rules in this Cisco Live presentation.
https://www.ciscolive.com/global/on-demand-library.html?search=ise&search.event=ciscoliveus2019#/session/1551475823491001BB2t

View solution in original post

1 REPLY 1
Highlighted
VIP Advisor

Re: Building policy-sets from design perspective

For me it comes down to three things.

1. Ease of use/organization
2. Performance and scale
3. Reporting

One and three could fall in to one, but the ability to know where to go to look to troubleshoot something is a huge bonus. It provides another key detail and the ability to use a course filter when parsing data. Writing 802.1x vs MAB policy, you can end up with some of the same endpoint flows but under a different method you can avoid having to write more complex rules to avoid conflict. Since ISE is a first match policy flow like an ACL, splitting auth out by 802.1x/mab makes this easier on yourself.

On performance, having individual policy sets for various reasons can prevent ISE From having to parse large lists of policy that don't apply. As a high level example of this, if you have 802.1x and MAB in the same policy set, the 802.1x authentications very likely don't need to be evaluated against MAB policy, or vice versa. You also specify identity stores to be looked at when defining an individual policy set, further reducing lookups we might not need with MAB against an external ID store.

Many large complex deployments even have multiple policy sets for 802.1x and MAB. At the end of it all, each deployments design comes down to the use cases you have to work with, and various segments that might need different treatment.

There is a good outline of designing policy sets/ authorization rules in this Cisco Live presentation.
https://www.ciscolive.com/global/on-demand-library.html?search=ise&search.event=ciscoliveus2019#/session/1551475823491001BB2t

View solution in original post