Cisco Secure Access Control Server for Windows 4.0
Cisco Secure ACS (Access Control Server) for Windows version 4.0 is out now, providing a variety of new enhancements and capabilities. In this article we'll look at why you might want it, and what the most important of those new capabilities might be. There are also several screen captures showing off the user interface, with a focus on showing the new features.
Peter Mello of Atrion was kind enough to work with the author (Pete Welcher) and provide screen captures and information -- any errors remaining in this article are solely PJW's fault. Peter Mello took a lot of screen captures showing all the aspects of ACS, with some sample network devices groups, policies, and captures showing the NAC Framework-related posture screens. This set of captures is a pretty nifty view into what ACS might look like after you've set up some working external databases, policies, device lists, etc.
I've edited the screen captures lightly to put in some headers and reformat, then put them into Adobe PDF format. Due to the graphics, the PDF version is large, so I divided them into 4 large PDF files. CAUTION: these are still up to 17 MB each. You may download them if you want much more detail than the reduced size of the few images there was room to include below! The detailed capture files can be found at:
And many thanks from PJW to PM!
What is ACS?
I used to describe Cisco as being in the network "glue" or interconnection business -- not just network connectivity, but providing a way to get various products to talk to each other, allowing you to tie together different pockets of computing, different protocols, etc. I've always thought of Cisco Secure Access Control Server (ACS) as a solid example of a interconnectivity or glue product. (A marketing person will probably be wishing I'd said something more like "swiss army knife"). Anyway, on to what ACS is and does...
ACS is used to provide centralized enforcement of logins and privileges and policy. It provides an authentication and authorization control point between network devices which speak TACACS+ or RADIUS, and user/group databases that live in servers, e.g. LDAP or Active Directory. ACS is also a major component in the Cisco trust and identity network security schemes (802.1x, NAC).
ACS administers user access for Cisco routers, VPNs, firewalls, dialup and DSL connections, cable access solutions, storage, content, VoIP, wireless, and switches that use 802.1x access control. It is an important component in Network Admission Control (NAC).
ACS comes in three (3) forms:
- ACS for Windows 4.0
- ACS for UNIX (End of Life, apparently)
- ACS Solution Engine (network appliance)
We will focus mainly on the first of these. The last item is an appliance version of ACS for UNIX, apparently replacing the software version of that product. It appears to be available in version 4.0 running on hardware platform 1113. (The End of Life / End of Sale notice you may see is because ACS 4.0 Solution Engine runs on new hardware).
What's New in ACS 4.0?
ACS has had several incremental releases such as 3.3.2 and 3.3.3, each with interesting features. You may want to look at the Release Notes if you haven't been tracking those changes.
Version 4.0 of ACS brings some major new features, including:
- Network Admission Control (NAC) 2.0 support
- Support for more devices
- Profiles for authentication and authorization
- New storage infrastructure
- LDAP improvements
- Shared secrets for RADIUS and TACACS+ device groups
- Authentication improvements
- Extended replication support
- Shared RADIUS Authorization Components (RACs)
- Machine Access Restrictions (MAR) exemption lists
- Support for WLAN controllers and ASA appliances
Of these, the biggest is the NAC support. We won't get too deeply into that, since NAC is another article or two all by itself. The short version: the role of ACS in NAC is as policy decision point. It ties together Cisco Trust Agent, evaluates the state of the host, provides per-user authorization to the network device, and can download access lists, and VLAN assignment. It also does security policy verification of host credentials, which enforces policy items such as OS patch level or antivirus signature file version. ACS policies can be extended by forwarding credentials to third-party or external policy servers.
I hear that performance had to be substantially enhanced to support NAC. The benefit: now ACS supports up to 35,000 devices.
Network access profiles are a new feature that could be quite useful. They allow classification of access requests based on network location, device belonging to a network device group, protocol, or other RADIUS attributes sent by the device the user is connecting through. In addition, authentication, access control, posture validation, and authorization policies can be mapped to profiles. Posture refers to pre-requisites for admission, as in NAC.
An example use of profiles would be to have different access policies for VPN than for wireless access. This is the example in the Release Notes, but I've actually tried to figure this out for someone who wanted different dial, VPN, and wireless policies. They were trying to tackle it with Microsoft groups of users and a prior version of ACS. This lead to what I call the "Venn diagram" problem where they were trying to match rules: Group A AND Group B AND Group C, then A and B but not C, etc. That got messy fast!
Peter Mello recently ran into this since he had to only allow authentication against an RSA database for Internet Client devices while alternatively only authenticating against the Active Directory for 802.1x clients (using ACS3.2). Conclusion: profiles really help when you need different authentication, authorization, etc. for different groups of devices or for different ways of connecting to the network.
The storage improvement is to use a SQL database for user and configuration information. Apparently the previous version used the Windows Registry more. The Registry is now used only for application-related information.
LDAP successful authentications are now cached.
Authentication improvements include support for Microsoft Windows Callback, external user authentication via an enable password, and certificate revocation list checking during EAP-TLS.
The online help was improved -- separate window, search button, ability to open PDF version of the User Guide.
Group mappings for external Novell NDS databases can now be done using generic LDAP group set mappings.
MAR (Machine Access Restriction) Exemption lists allow you to specify which groups are allowed network access whether or not machine authentication succeeeds. This can be configured for specific user groups, for example administrators.
RAC (RADIUS Authorization Component) support means RACs are a new type of shared profile. The shared RACs contain groups of RADIUS attributes which can be assigned to user sessions dynamically, based on a policy.
Profiles and Postures
One very useful new feature of Cisco's ACS4.0 is the ability to return different authentication and authorizations depending upon the calling/requesting user and device parameters. Profiles are created along with corresponding policies. When requests are processed they are checked against the Profiles in a top down/first match process. If a Profile is matched, the Authentication Policies defined for that Profile are processed, the Posture Validation applied, and the Authorization determined. If no Profiles match, the global default can be set to either deny access or grant access.
Profile matching is based on the IP address of the device the user is being authenticated on, along with chosen RADIUS attributes. The RADIUS variant (IETF, Aironet, IOS, third parties) can also be matched. See the documentation for details.
For this matching, a profile's matching IP addresses are specified with a group defined in the "Shared Profile Components" / "Network Access Filter" part of ACS. Devices can be added to the Filter as part of a Network Device Group (previously defined within the "Network Configuration" tab or as a single device. The single device might or might not be a member of a Network Device group. Client Devices (or Network Device Groups) may belong to multiple Filter groups. In other words, you have lists built up out of devices or other lists. These are used in first match fashion to determine which profile to apply.
The Profile match determination can also use RADIUS attributes of the authentication request. An attribute match can be defined as a value, range or comparison. Multiple matches are allowed either of the same attribute with different values or a combination of different attributes "logically AND-ed". Depending on the attribute different logical operators are available from the pull down.
Once a Profile is matched the Policy part of that Profile are applied to the client request. A policy consists of three parts Authentication, Posture, and Authorization.
Authentication consists of what protocols is this device allowed to authenticate using, e.g. PAP/CHAP/MS-CHAP v1/v2, along with specifying the EAP variant allowed (PEAP/EAP-FAST/EAP-TLS and the various specifics for each). Also specified here is which Credentials Database to use, allowing you to restrict authentication to certain databases instead of searching all databases or cached entries as in earlier versions of ACS.
Posture is about checking security policy compliance -- the NAC aspect of this.
Authorization is where the fun really begins. A Condition can be defined based on a user group which the user is assigned to during authentication. This could be set depending on the external database the user is authenticated from, or based on an Active Directory group. Note that when you assign group membership a user is assigned to only one group, if a users is in two active directory groups the group given the highest preference is the one the user is assigned to. Preference is set in the External User Database section. The Condition specifies what happens if a user's group matches. They can be explicitly denied access, or RADIUS attributes can be set applying to them, or ACL's can be specified. Alternatively if no group match condition is met the default can be to deny access.
One example use would be to dynamically set the user VLAN. In wireless this is known as "AAA Over-ride". It allows you to use one SSID, then assign the user's VLAN and/or ACL based on the group they authenticate into. The alternative is multiple SSID's, with each assigned a fixed VLAN. You would then have to communicate to users which SSID to use.
What Else Is New?
A year-old ACS feature you might not have noticed: Cisco slipped in some CiscoWorks integration to ACS with CiscoWorks LMS 2.5 and ACS 3.2 or later. The documentation for this is pretty darn thin. You can go into CIscoWorks and register it with ACS. You can then set up custom group policies for which parts of CiscoWorks can be run. These can be tied to device groups. This would be for bigger shops where different people manage different devices, and where custom security roles are needed. I expect more features like this as the Cisco SONA (Services over Network Architecture) continues: think of security team managing the firewall module (FWSM), applications team managing the content switching module (CSSM), etc.
Screen Captures from ACS 4.0
Here's the part you've been waiting for -- some screen captures showing off ACS 4.0.
This screen capture shows group setup. I included it since you can see how per-group ACL's and other policy elements can be applied through ACS.
This screen capture shows the various kinds of shared profile components you can set up in ACS 4.0.
This screen capture shows Network Access Filtering (NAF's). Recall this is a list of devices that an ACS profile applies to (matches).
This screen capture shows some RADIUS Authorization components.
This screen capture shows details of the above "Look But Don't Touch" (show command) privilege level component.
This screen capture shows some device groups.
This screen capture shows the ACS Interface Configuration. It is included since I (PJW) have always found this the most confusing aspect of ACS. The point is, you have to enable use of various RADIUS and TACACS+ features here, or they are not visible when configuring Users and Groups. The reasoning for this approach was, I believe, to try to minimize the sheer complexity of what you have to look at in setting up Users and Groups, by leaving out those features you don't use.
This screen capture shows Posture Validation. This is where you set up the security posture checking for NAC 2.0 within ACS 4.0. Note the Boolean logic for the condition checked.
This screen capture shows more detail for setting up Posture Validation.
This screen capture shows the main screen for the Network Access Profiles that were mentioned earlier. You can see different profiles for different device groups here (thanks to Peter Mello!).
I was going to include something about system requirements for ACS 4.0, but it didn't seem worth the space. You can find this out pretty easily in the product documentation -- and anything I put into print might soon become incorrect.
Here are some links you may find useful, in researching more about ACS 4.0 for Windows:
Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher Pete's email address.
Copyright (C) 2006, Peter J. Welcher