cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1381
Views
0
Helpful
1
Replies

ACS 5.x large-scale design (multiple locations)

brian.k.clarke
Level 5
Level 5

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.

1 Accepted Solution

Accepted Solutions

Nicolas Darchis
Cisco Employee
Cisco Employee

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

View solution in original post

1 Reply 1

Nicolas Darchis
Cisco Employee
Cisco Employee

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