cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3010
Views
0
Helpful
4
Replies

Cisco ISE 2.4 Policy Set Design

zsmithtek
Level 1
Level 1

This discussion is about opinions/recommendations and lessons-learned when designing ISE policy sets.  Currently using ISE 2.4.  I suppose ISE 2.3 is also applicable here.

 

I'm going to be using ISE for a ton of different things.  

 

Wireless - 802.1x SSIDs with CHAPv2/EAP-TLS for a handful of SSIDs, Guest Portal, BYOD Portal, Hotspot, Mac Auth for certain SSIDs for shop floor wireless equipment.

 

Wired - 802.1x, MAB, VLAN Assignment, domain PCs (trusted), Non-trusted devices

 

etc etc.

 

So - assuming you may have  a decent-sized ISE environment how do you all build your policy sets?  One for one or grouped? For example - Policy SET called Wireless - then wireless will have multiple authorization profiles in it for various SSIDs, MAB, whatever you are doing all in one policy set for wireless - or do you split these?  Policy set for GUEST Portal, Policy Set for BYOD, Policy Set for SSID1, Policy Set for SSID2, etc etc?  Same for wired?  

 

Then of course the million dollar question - whatever your design preference may be - .... Why .... ?

 

Input is greatly appreciated.  Thanks!

 

4 Replies 4

marce1000
VIP
VIP

 

 - You will find some guidelines from this thread :

   https://community.cisco.com/t5/identity-services-engine-ise/ise-2-3-policy-set-config-best-practice/td-p/3706294

M.



-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
    When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

Damien Miller
VIP Alumni
VIP Alumni
Personal opinion here, I like to begin a deployment grouping wired in to wired dot1x and wired mab together. Wireless is then grouped on a per SSID basis while VPN access receives its own policy set.

Logically breaking them up definitely makes it easier when it comes time to change or troubleshoot access problems. If you start to venture in to differentiated access with TrustSec, your single policy set can will balloon with authorization policies based on how many different tags you need to provision per access use case.

Just to clarify - are you suggesting you like to have one policy set for wired access - then in that policy set have 2 authorization policies, for example, one for 802.1x and one for MAB.

 

Then for wireless have a separate policy set for each SSID?

 

So for example, if we needed to use ISE for Wired MAB and 802.1x and had 1 SSID for 802.1x employee, 1 SSID for guest portal, and 1 SSID for employee BYOD - you would have 4 policy sets.  1 for the 2 wired needs and 3 for the wireless.  Is that an accurate representation of what you are stating?  

 

Thanks for the response.

Yeah. Unless we have quite a few authorization rules shared among different conditions, using distinct policy sets is a great way to organize them and make them easier to read and maintain.