cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3690
Views
16
Helpful
11
Replies

Wired Dot1x ISE Deployment approach - Am I doing the right thing?

shamax_1983
Level 3
Level 3

Hi Experts,

 

Really appreciate your input as this is my first major deployment so wanted to hear from experts around the world and see if my approach is correct and/or justifiable.

 

So I'm in the process of deploying Wired ISE on an existing environment and initially (as pursued by Cisco) thought I would use Low-Impact mode mostly because it sounded good.  So I first started putting all of my policies together in a lab environment. My Key objectives are,

 

1) If a device is dot1x enabled, make the VLAN change (dVLAN) on the port accordingly (as this is a brownfield network, I couldn't just do dACLs and we have different user categories currently allocated to different VLANs based on AD attributes)

2) If dot1x is NOT enabled, if MAB policy is found for the specific MAC address, allocate the specific VLAN (via dVLAN)

    - These MAB groups could be Manually adjusted or,

    - MAB groups are populated based on profiling info (this is how a CiscoPhone and WAPs are getting Authenticated)

3) If none of the above, the default MAB rule in ISE (last rule at the bottom) will put that device in the restricted VLAN (using dVLAN).

    - Devices that might get put into this restricted VLAN could be a PC (without Dot1x), Phone, WAPs, Printers etc.

    - While sitting in this restricted VLAN, the following two things will happen

         1) Switch/ISE will try to profile the device - If the device is profiled to be a Phone, WAP or Printer, ISE will send a COA to the switch so next time it will put the device in the correct VLAN (based on the  #2 mentioned above)

         2) In addition to profiling, the switch will also do a URL redirect to the Guest portal so if it was a PC, user can gain guest access.

 

So, I have all the policies above correctly setup on my LAB setup and it works pretty well.

 

So, moving forward, the next thing I wanted to do was to try out my policies in production in "Low-Impact" mode.  But I quickly realized that the so-called "Low-Impact mode" would only be "Low-Impact" only if the switch receives radius REJECTS or ACCEPTS with no AuthZ changes. What this means is that, if your policy has an ACCEPT with VLAN change or a ACL change (as the AuthZ result), the VLAN/ACL change will be imposed. So what this means is that I can't really test anything as all of my rules do have a VLAN change as the AuthZ result.  So in my case (and I believe in most other deployments - please let me know), the Low-Impact mode is not something I can use effectively.

 

The other things I realized is that switch/ISE will not profile anything that is REJECTED. What this means is that, as mentioned above, for all the things that you want to be profiled (and then used in a MAB rule), they should be put in a VLAN followed by a radius ACCEPT (if it was rejected by Radius that device will never get profiled). In my case, this is the Restricted VLAN as mentioned above (#3).

 

So after thinking/testing/reading and researching all the above behaviours, I have come to the conclusion that using "Closed mode" with a Default rule in ISE (at the bottom of the ruleset) to ACCEPT anything to the Restricted-VLAN (where I have Guest redirection and Profiling happening) is the best way to go ahead and to me, it looks like a much better and robust way to go ahead. Also, I have concluded that the Low-Impact mode (as prescribed by Cisco) is not compatible with my scenario.

 

I have also thought about the other ways to realize the benefits of the low-impact mode for my deployment. So what I realized is that, if I have all my policies intact and changed all of the AuthZ results to be "permitAll" (instead of the dVLAN changes planned to be deployed in production), including on the AuthZ rule used for the "Default Restricted VLAN", I can see how things are profiled and what rules various devices are hitting (without actually making any changes to the production switch port). I believe this is the most I can test on production (without making any changes to the production traffic flows). When I can confirm that all devices are hitting the right rules and getting profiled correctly, I can turn on "closed mode" on the switches and change the AuthZ results from permitAll to the specific ones that have planned/tested in the LAB environment. 

As I am using IBNS2 setup with C3PL, I can easily role this out initially port by port and after testing in a large enough portion of the network(and when I am confident that all is fine), I can go switch-wide rollouts.

 

So my question is this; Am I thinking correctly here?. Am I missing some key element here?  Did you guys use the Low-Impact mode in your case in a different way?. In your experience, do you see any potential issues with my approach?. Any thoughts advice around my plan?

 

Thanks in advance.

 

1 Accepted Solution

Accepted Solutions

Yes what you have outlined is good approach given you would like to use dVLAN as primary way to segment traffic. However, if your end goal is to go closed mode you may not want to start out with open mode, rather go closed mode with permit access for all use cases on ISE as a start. This will save you from having to touch all network devices when you want to go full closed mode. This is especially the case if you plan to transition from open mode to closed mode in a relatively short time. Giving permit access regardless of result will almost mimic what open mode gives in terms of visibility with easier path to full closed mode. Also note that endpoint behavior is different depending on open mode is used or not, so if you start out with open mode and transition out to closed mode, you will end up having to relearn troubleshooting the access issues. Also, now you have mix of two distinct deployments that you need to deal with while the whole deployment has been converted to closed mode.

View solution in original post

11 Replies 11

Before implementing closed/low-impact mode, it is advisable to start with Monitor mode(default rule is permitted) to see how many endpoints fails, failure reason & consideration. Once most of the failures are fixed, then you should consider moving either low-impact mode/closed mode.

Low-impact Mode -> This is ideal for PXE boot environments & a pre-auth ACL is used to control network access for the pre-auth state. Vlan changes are not recommended in this mode.

Closed mode -> In this mode, the port will be closed by default. Only EAPoL packets are allowed for dot1x authentication & this method is suitable for dynamic VLAN authorization.

Kindly go through this guide for wired deployment perspective.

 

-Aravind

Thanks for your reply. But I already know what those modes are and I have already read those guides. Please read my initial post, my question is about the practical implementation.

Thanks

Your approach looks promising, you can handle all the below scenarios with this.

1.Dynamic VLAN using dot1x based on AD group.

2.Endpoint identity group/profiling based policy to get respective VLAN.

3. Any other endpoints will get limited access(DHCP, DNS, ISE server) with URL redirection to get guest access.

 

Just a quick question, are you planning to do computer + user authentication. If so please configure a policy for domain computers to get access to patch management/GPO/DC server in an ideal state.

-Aravind

Thanks Aravind.

shamax_1983
Level 3
Level 3

Anyone else wants to comment please?. I was expecting more inputs. Much appreciated.

 

Thanks

Yes what you have outlined is good approach given you would like to use dVLAN as primary way to segment traffic. However, if your end goal is to go closed mode you may not want to start out with open mode, rather go closed mode with permit access for all use cases on ISE as a start. This will save you from having to touch all network devices when you want to go full closed mode. This is especially the case if you plan to transition from open mode to closed mode in a relatively short time. Giving permit access regardless of result will almost mimic what open mode gives in terms of visibility with easier path to full closed mode. Also note that endpoint behavior is different depending on open mode is used or not, so if you start out with open mode and transition out to closed mode, you will end up having to relearn troubleshooting the access issues. Also, now you have mix of two distinct deployments that you need to deal with while the whole deployment has been converted to closed mode.

Thanks for your insight.

 

I guess the reason I am using the open mode initially is that I don't want to introduce changes directly at the initial stage. If I used the closed mode at the initial roll-out, that would also imply that by the time the new port config is applied (with Closed mode), I should be 100% sure that the profiling and the policies are correct from the getgo.  But I understand your where you coming from, having to do this on all switches all over again (and possibly uncover new behaviours as well) in the second round when I enable the closed mode. So maybe I will only go with the open mode initially for a handful of switches and do the rest directly using the closed mode. 

Your authentication policy plan sounds like you have a good grasp on what you want to do. If I had the choice though I wouldn't do dvlans or dacls, I would build out TrustSec leveraging SGT's and SGACL that are vlan agnostic. It doesn't matter what IP or VLAN an endpoint is on, it depends what policy you write for your SGACLs.

Now the caveat here is that you have to "build out" the TrustSec framework, carrying SGT's inline end to end is ideal, but in smaller environments you can inline tag in the LAN then use SXP to bridge the WAN. I say smaller environments because SXP doesn't scale great. There are lots of WAN overlays that support inline tagging today, a big miss right now is that Cisco SDWAN (Viptela) does not yet support inline tagging.

A second caveat is the hardware support and I typically only suggest deploying TrustSec on the hardware that has full support. By full support I mean inline tagging and SGACL capabilities. There are some use cases where you do not need SGT's at the LAN or across the WAN, typically north south enforcement where you send SGT's to a central enforcement point, this is usually a warm up for a full deployment.

Just an option. What ever you do, design to your requirements and make sure it's scalable and supportable,

Thanks, Damien.
Yes, I was evaluating SGT as well but left it for the next phase due to some of the hardware limitations (as you mentioned above). But definitely very valid points.


Arne Bier
VIP
VIP

Nice explanation.  I didn't know some of the things you had mentioned (like profiling is not done when an endpoint is rejected etc.) - good to know.

 

I have to admit, I go straight to closed mode in all cases.  Why waste time, right?  And if there is a device out there that doesn't play ball, then just leave that port in access mode or whatever until it's a member of MAB or another solution is found. MAB is the solution for these "problem cases" and I agree that it can become an admin burden if there are more exceptions than the rule.

 

IBNS 2.0 is also a good choice because you can plan for things like setting a profile for an endpoint that lives locally on the switch and gets applied in case ISE is unreachable.  I have not implemented this myself, but I left that option on the table in case the customer wanted it.  Seems a nice HA feature.

Thanks, Arne.

Good information around local profiling. I am definitely going to look into that. Thanks for mentioning that.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: