cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6329
Views
23
Helpful
9
Replies

CISCO ISE- Policy Sets

JohnRound
Level 1
Level 1

cISE.JPGWe have a main 'WIRELESS' policy with various Authorization policies in place for several of our wireless networks etc.

 

At the moment I am playing around with certificate authentication etc and have set up a TEST SSID, but need to fiddle around with the Authentication Policy a little which I obviously don't want to do in the production 'WIRELESS' policy as it may affect the other networks.

 

Therefore I set up 'WIRELESS_TEST' as a policy as you can see which is initially pretty much a copy and paste of the live policy, but only containing the TEST SSID under Authorization policies.

 

The trouble is, I cannot then connect to the TEST SSID if I try as the 'WIRELESS' policy has a 'DenyAccess' set up as the Default Authorization policy rule (if a client doesn't match any of the other rules I assume)

 

What is the best way to resolve this?  Do I need to move my 'WIRELESS_TEST' above 'WIRELESS' and set 'PermitAcess' as the Default Authorization policy rule in 'WIRELESS_TEST'?

 

Many thanks :)

2 Accepted Solutions

Accepted Solutions

paul
Level 10
Level 10

I am a big believer in discreet policy sets that match each use case.  Ideally, you don't want to have one policy set for all your wireless SSIDs.  You should have a policy set for each SSID.  This makes the rule set easier to look at and minimized the risk of mistakenly allowing someone on the network that shouldn't get on.  The WLCs send the SSID name at the end of the RADIUS Called Station ID attribute.  You can use that as the admission criteria.

 

In your case, if you just want to do this for the test SSID, move your policy above the production one and change the admission criteria to "RADIUS Called Station ID ends with TEST-SSID" or whatever your SSID name is.  Remove the device type conditions.

View solution in original post

Thanks, to make things more simple I added a new Authentication Policy in the existing 'WIRELESS' policy that only hits under the conditions suggested (RADIUS Called Station ID Contains = TESTSSID), I can see a limited number of hits going through to that Authentication Policy so seems to be working and it has resolved my issues with properly authenticating via certificates (Default policy not set up to scan enough fields in the certificate to authenticate device/user)

 

At the moment we just moved everything over from ACS so will probably start to split things up etc. later on, 

View solution in original post

9 Replies 9

paul
Level 10
Level 10

I am a big believer in discreet policy sets that match each use case.  Ideally, you don't want to have one policy set for all your wireless SSIDs.  You should have a policy set for each SSID.  This makes the rule set easier to look at and minimized the risk of mistakenly allowing someone on the network that shouldn't get on.  The WLCs send the SSID name at the end of the RADIUS Called Station ID attribute.  You can use that as the admission criteria.

 

In your case, if you just want to do this for the test SSID, move your policy above the production one and change the admission criteria to "RADIUS Called Station ID ends with TEST-SSID" or whatever your SSID name is.  Remove the device type conditions.

anthonylofreso
Level 4
Level 4

Create a new test wireless policy set, and configure a condition to match the WLAN ID.

Cisco_WLC and Airespace:Airespace-Wlan-Id EQUALS 2

I avoid using the WLAN ID number as that could change. Using RADIUS Called Station ID and the actual SSID name takes the WLAN ID out of the equation.


Hmm, interesting point. When would the WLAN ID change? Do you mean in the case of two WLANs using the same SSID w/different security policies?

You can rebuild an SSID using a new WLAN ID. I guess my point is the SSID Name doesn't change.



Also you can have more than one WLAN ID number having the same SSID name. I have used that trick with AP Groups to roll out SSID changes, like cutting over from ACS to ISE.


Or if you want to get even simpler, use the condition called "Normalised Radius·SSID" instead of Called-Station-ID (even though technically, under the covers that's what it is) - the Normalised Radius·SSID just makes it a bit clearer to understand.

 

I would always use the CONTAINS operator because you should not care exactly how the NAD has populated the Called-Station-ID

 

e.g.

Normalised Radius·SSID CONTAINS Corp

Yep normalized works as well. I like using the RADIUS Called Station ID as it is the unchanged value that is passed by the WLC. If something goes wrong with the normalization process I don't want my wireless connections to break. Not that ISE has ever had issues with data manipulation. :)



I use Ends With just to be more specific, but I have used contains as well.


Thanks, to make things more simple I added a new Authentication Policy in the existing 'WIRELESS' policy that only hits under the conditions suggested (RADIUS Called Station ID Contains = TESTSSID), I can see a limited number of hits going through to that Authentication Policy so seems to be working and it has resolved my issues with properly authenticating via certificates (Default policy not set up to scan enough fields in the certificate to authenticate device/user)

 

At the moment we just moved everything over from ACS so will probably start to split things up etc. later on, 

Few years ago while moving from MS NPS Wireless radius authentication, I was face on a dilemma, we had three 5508 WLC and same SSID was configured with different WLAN ID on each of them, fortunately finding the solution you are mentioning was my "Eureka time", I mean using the RADIUS Called Station ID and the actual SSID name.