ISE Design – Going Above The Configuration
Infrastructure By Louis Spencer JR | September 24, 2018
Note: It may not be possible to standardize every switch. If you have a mixed Cisco and non-Cisco environment for example, you might have to utilize SNMP on the non-Cisco switch and device sensor on the Cisco switches for profiling. I would still create standard templates for like groups of network access devices.
#4 – Know the hardware limitations of your network access devices – Depending onyour business requirementsand how granular you need to get, you might find yourself having certain hardware limitations if you go with a certain deployment strategy. For example, if you have a strict policy to ONLY allow access to certain domain controllers or servers on 50+ different ports and your policy is to define the 20 or so server IPs in that access list, you might find yourself running out of TCAM space with DACLs. If your business requirements are for greater east-west segmentation where simple VLAN segmentation won’t cut it and you have TCAM limitations, you might have to consider a different implementation strategy utilizing Security Group Tags (SGTs). Knowing these limitations before you start actually deploying ISE is important because a mass redesign in the middle of a deployment is never pretty.
#5 – Start Profiling ASAP – Before any sort of enforcement, I recommend configuring the network access devices to send all the profiling information back to ISE. Configure and turn on RADIUS, DHCP, Active Directory, DNS, etc probes and get as much rich detail about the endpoints on your network as possible so you can start to group like endpoints together to craft your policy. Half of being able to create an effective policy is knowing what’s on your network first.
#6 – Know your supplicants – No, I don’t mean profiling. For example, if you have Macs or Linux machines in your enterprise, you should account for them. Unlike Windows PCs which can easily get their supplicants provisioned via Group Policy, certain corporate endpoints might need to be onboarded through something like the BYOD feature or simply have their configuration pushed through something like Casper to insure that you are providing scalable and consistent configurations across all your endpoints.
#7 – Know the limitations of your endpoints – A popular segmentation method is VLANs but one thing I seldom see taken into account is DHCP changes. With the AnyConnect posture module, you can have it trigger a DHCP release and renew on PC endpoints but for your non-PC devices that don’t know that you just changed the VLAN on it, how will they know that they should issue a DHCP request? Phones should be an issue since it’s only getting an IP on the voice VLAN and you can allow voice domain permissions but your other endpoints might have a problem. You can configure ISE to do a port bounce after successful authentication which should trigger DHCP on the endpoint but it might cause your PoE devices to have to reboot on initial connection. Food for thought and something to consider when designing your implementation.
#8 – Always Be Testing – ISE has the wonderful ability to place policies in monitor mode and the ability to migrate endpoints into enforcement mode on switch-by-switch or even port-by-port basis. With monitor mode, you have the ability to test your policies as if they were enforcing without disrupting a single endpoint. This gives you the ability to really fine tune your policies before you move to enfrocement. After testing, I would start with a pilot group of users for enforcement and based on the results, start slowly rolling it out to the rest of the environment.
#9 – Communicate with your end users – Whenever you restrict access to resources, it’s bound to cause someone to notice. If ISE is deployed and you suddenly started blocking user’s personal devices, they will notice rather quickly. Communication is key. Let them know you are going to be making changes and what the new policy they will be adhering to is. This helps keep expectations consistent and prevents as many calls to your helpdesk.
During and After the deployment
Now you’ve started to roll out ISE in enforcement mode. What do you do now? First I would recommend having a day 2 plan before you get there. Who’s going to be supporting any issues if they arise? If you haven’t properly planned this out, it will be you getting every call to the helpdesk for a mistyped password.
I would recommend creating a troubleshooting guide for the help desk to use to vet simple issues such as a mistyped password or misconfigured supplicant. Force them to use it before calling you so you are not stuck supporting a fat fingered password that is passed off as an ISE issue. Here is a good template I have used several times in the last few years:
Helpdesk Troubleshooting Guide
Another recommendation I would make is the thoroughly document your ISE deployment and diagram how the deployment is set up. Use Visio to create a diagram of how the individual ISE appliances are set up in the network for others to be able to troubleshoot when you are not around. Cisco is kind enough to also provide Visio stencils which can be downloaded here. I recommend doing both a physical diagram of how any equipment is stacked and a logical diagram of the design.