ISE 2.3 Policy set config best practice

[Madura Malwatte]

Fo a basic wired dot1x and mab what is the recommended / best practice in how the authentication and authorization policies are configured?

I have seen some guides where the authorization rules for users and computers just matches the AD domain, where the authentication policy matched dot1xz or mab (see example 1).

While other guides have a match both AD domain AND Wired_802.1X. Or for non dot1x endpoints it would match a logical profile AND Wired_MAB together (see example 2). Is this necessary? In the authentication policy or policy set we are already checking on either MAB or dot1x and when getting into the authorization policies why is it necessary to match again on mab or dot1x? I can't see any reason why this would be helpful?

example 1:

example 2:

Can someone point me to documentation on any best practice around basic policy set configuration?

[Arne Bier]

It's a great question because it drives the overall design of your Policy Sets.

There is no right or wrong way, but I think one can spot a bad design (or an inefficient design) once it's right in front of you - but then it may be too late, or require a lot of re-work.

The theory is that once you have passed authentication, then any condition that was used in Authentication does not need to be "re-checked" in Authorization.  A classic issue I have seen all over the place is that people check for Wired_MAB in Authentication, and then again in ALL of their Authorization rules.  Why? What for?  The best design would be one that uses a Policy Set Condition of Wired_MAB - and then the authentication doesn't need to check for it again, nor does the Authorization.  The Radius packet should only be inspected once for that group of attributes that makes up Wired_MAB.

If you designed it "wrong" then you might have a Policy Set Condition  called "Wireless" where you try and catch any NAS requests for MAB or 802.1X and then you're mixing two things into one.  Then you are forced (by your bad design) to constant disambiguate between a MAB and a 802.1x - don't do that to yourself. 

I think the design tenet should be - Understand your call flows and their Radius contents and then find the distinguishing factors for each flow - use those distinguishing factors to create individual Policy Sets.

Example - create one Policy Set for

Wired_802.1X

Wireless_8021X

MAB

PAP_Auth

If you have multi-vendor stuff then you might be lucky enough to get away with the ISE Device Profiles because ISE does a great job to abstract vendor differences.  But in one case, for Wireless_MAB, I had to create many Authorization Rules because Vendors X, Y, Z needed such a diverse set of Authorization results, that ISE could not abstract. At one point I thought I would have been better off to create three Policy Sets instead, and use NDG Device_Type in the main Condition

Wireless_MAB_Aruba (Condition: Wireless_MAB AND Device_Type EQUALS Aruba)

Wireless_MAB_HPE (Condition: Wireless_MAB AND Device_Type EQUALS HPE)

Wireless_MAB_Cisco (Condition: Wireless_MAB AND Device_Type EQUALS Cisco)

In the above case, my Authorization Rules would look a lot simpler.

Not to mention that if Policy Sets are badly designed, then you're just taxing the CPU and making your logs look more complex than they need to - efficiency is a good thing.

Also have a look at the ever brilliant BRKSEC-3699 for tips on structuring the conditions to allow more efficient processing in ISE. 

[paul · Accepted solution]

My best advise on policy sets is to make them granular and match up with your use cases.  I produce decision tree diagrams for each use case in ISE and then my policy sets match those diagrams:

1. Wired Dot1x
2. Wired MAB
3. Corporate Secure SSId
4. Guest SSID
5. Employee BYOD SSID
6. Corporate VPN
7. Vendor VPN
8. FMC Access

Granular policy sets makes your rules easy to digest and makes ISE efficient because the policy sets (other than wired MAB) are very small.

[Madura Malwatte]

Hi Paul / Arne,

Thanks for the replies and confirming what I was leaning towards as well. I like the idea of breaking out the policy sets per use case and being as granular as possible.

One thing I wanted to know - Change of Authorization (CoA) is that possible between policy sets? For example I have a MAB policy set to do a CWA redirect for BYOD on-boarding, then my Dot1x policy set has the authorization policy to match a byod registered device. Can I device move between policy sets automatically?

[paul]

It depends on how the CoA is done.  If you are doing a CoA telling the switch to reauth using the last method then you aren't going to move from MAB to Dot1x.  The switch I believe will just run a MAB authentication again.  I haven't tested trying to switch authentication methods with a CoA.

[Jason Kunst]

I would think a COA would work as long as it causes it to switch and hit the other policy set. You will need to test your flow and see how it works

[paul]

Jason,



The issue is with how the CoA is sent:



subscriber:reauthenticate-type=last,

subscriber:command=reauthenticate,



If the "subscriber:reauthenticate-type=last" is sent it tells the switch to CoA using the last method the MAC address used to authenticate. So say for example you wanted to BYOD register your Dot1x devices before allowing them on and you separated your Wired MAB and Wired Dot1x policy sets (like I do). Your Wired Dot1x policy set may look like this:



If MAC is in BYOD_Registered endpoint identity group and PEAP Domain User then allow access else deny Dot1x



MAB policy set would say:



Redirect to BYOD registration portal.



If an unregistered device comes in Dot1x will fail and they will get redirected to the registration portal. Once they register the CoA is sent. If the CoA contains "subscriber:reauthenticate-type=last" the switch will only do MAB again and not allow the Dot1x rule to be reevaluated.



Like you said you would have to test.