11-10-2010 09:53 AM - edited 02-21-2020 10:25 AM
I understand the basic ACS (single-site) design, but let's now consider a multi-location environment - for example, 10 remote offices connected over a high-bandwidth MPLS WAN. My questions involve what would happen (and how to protect against) ACS/authentication/authorization problems if the centralized ACS HA pair became inaccessible, either due to appliance failure, of the WAN connection back to HQ dropped. Specifically:
1) If there is no ACS appliance (primary or secondary) available to provide authentication, do all the 802.1x-configured ports fail-close, I suspect? If true, that would mean that a remote site that was being authenticated through a centralized ACS solution would effectively disable all of the local switch ports configured for 802.1x, and all the workstations at that site would get ZERO network connectivity, even to local resources... (very bad). Is there any way of adapting this behavior so that if the ACS is not available, some other form of restricted access (or even fail-OPEN) would be a configurable option?
2) If there's no way around a 100% "fail-close" in the situation above, would it always be recommended to have an ACS appliance at each remote site (assuming they'd have any reason to still have local network connectivity - local network/server resources, local Internet connection, etc.)?
3) If an ACS was deployed at each remote site (so, as a secondary to the primary back at HQ) - please confirm that the local switches could be configured to authenticate/authorize to the local ACS first, then failover to an ACS back at HQ for backup. Of course, THIS would require that there's an Active Directory server at each location also for the ACS to pass credentials to...
Just looking for larger-scale ACS design guidelines, and haven't found anything specific enough yet. (So, links to reference docs/presos would also be very helpful. Stuff like the BW requirements for a recommended number of hosts/devices that should be allowed to use ACS over a certain speed link, etc.
Thanks, folks.
Solved! Go to Solution.
11-16-2010 03:34 AM
Hi !
1) For a switch with dot1x, there are 3 kind of special actions :
-Guest vlan : vlan where the port is put into when the client is not dot1x reactive
-Critical vlan : vlan where the port is put into when the Radius server is dead (when ALL servers are dead actually)
-Auth-fail vlan : vlan to put when the client failed authentication.
So you can set different vlans with different types of access.
In case your ACS is down, you could give on each remote site a vlan that gives local connectivity for example. Or even full connectivity (only drawback is that this means an attacker can bring your main ACS down and get access to your network at a remote office).
The new way to configure this on switches after 12.2.50 is "authentication event x", where the x can be "server-dead" or "no response", etc ... it's then quite clear what they do.
2) Putting an ACS on each remote site is maximum redundancy but it comes at a cost !!! That's up to you to decide. You could have one extra ACS on some other remote site. This could help in the situation where HQ is down but remote offices are up.
Now if a remote office loses WAN connection, it's a different topic. I think forcing the vlan to authorize in vlan which gives local access is ok (critical vlan)
3) Yes you can configure the order on the switches. You can then decide to take the "remote office" ACS first and the HQ ACS only if the other is down.
AD stays a problem though ....
The question is how much can you duplicate ? Putting an ACS on all remote sites won't help in case a remote site's WAN link is down because the ACS wont' have AD access (unless you have some internal users on acs too).
So really it depends on your needs, budgets and authentication mechanisms.
I hope I helped.
Nicolas
===
Don't forget to rate answers that you find useful
11-16-2010 03:34 AM
Hi !
1) For a switch with dot1x, there are 3 kind of special actions :
-Guest vlan : vlan where the port is put into when the client is not dot1x reactive
-Critical vlan : vlan where the port is put into when the Radius server is dead (when ALL servers are dead actually)
-Auth-fail vlan : vlan to put when the client failed authentication.
So you can set different vlans with different types of access.
In case your ACS is down, you could give on each remote site a vlan that gives local connectivity for example. Or even full connectivity (only drawback is that this means an attacker can bring your main ACS down and get access to your network at a remote office).
The new way to configure this on switches after 12.2.50 is "authentication event x", where the x can be "server-dead" or "no response", etc ... it's then quite clear what they do.
2) Putting an ACS on each remote site is maximum redundancy but it comes at a cost !!! That's up to you to decide. You could have one extra ACS on some other remote site. This could help in the situation where HQ is down but remote offices are up.
Now if a remote office loses WAN connection, it's a different topic. I think forcing the vlan to authorize in vlan which gives local access is ok (critical vlan)
3) Yes you can configure the order on the switches. You can then decide to take the "remote office" ACS first and the HQ ACS only if the other is down.
AD stays a problem though ....
The question is how much can you duplicate ? Putting an ACS on all remote sites won't help in case a remote site's WAN link is down because the ACS wont' have AD access (unless you have some internal users on acs too).
So really it depends on your needs, budgets and authentication mechanisms.
I hope I helped.
Nicolas
===
Don't forget to rate answers that you find useful
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide