So what is ACS? ACS stands for Access Control System and is a product developed by Cisco. The primary features of ACS is to provide Remote Authentication Dial In User Service (RADIUS) and Terminal Access Controller Access-Control System Plus (TACACS+).
These protocols are designed for use in Authentication, Authorization and Accounting (AAA) situations. I.e. they provide centralised access and control to resources. In the case of this post, we're using a Microsoft Active Directory server to store credentials. ACS provides the AAA services and a AAA client (in this case a router) accesses the AAA server in order to authenticate users. In laymens terms it allows you to log into multiple boxes with a single set of credentials.
This post is intended as a guide to deploy an ACS 5.8 appliance, the following topics will be covered:
- Deploying a VM and booting into the ACS installer from .ISO
- Installing ACS with a few settings configured
- Patching ACS to the latest version
- Adding the root patch (available from Cisco TAC) for troubleshooting (optional)
- Getting started with the GUI
- Integrating ACS into Windows Active Directory (Using Windows Server 2012 R2)
- ACS Operational Overview
- Adding Network Devices within ACS
- Configuring ACS for TACACS+ authentication
- Configuring ACS for RADIUS authentication
Let's get started! First we'll need to get the ACS .ISO file from www.cisco.com. The current version of ACS as of today is 5.8, and the ISO is ACS_v18.104.22.168.iso. It will also be worth downloading the latest patch so we can get the most recent fixes etc. The current patch version is 32.5 and the image name is 5-8-0-32-5.tar.gpg
Next we need to create the VM that we're going to use to run the .ISO on. There are some minimum requirements which must be met or the ACS installer will fail. For very small deployments this can be reduced after deployment.
The minimum requirements are as follows:
- 4GB RAM
- 2 vCPUs
I'm not sure if there is a minimum hard disk size, however I'd deploy it with at least 100GB (for a small deployment) but use thin provisioning. If in doubt, make the disk size bigger than you need and thin provision as it'll only grow as it uses space but if you run out of space you'll be in for a world of pain later down the line.
Cisco recommends using thick provisioning however for a lab / test setup I do not expect the disk to grow nearly as big as provisioning size, so I'll stick with thin (I'm also using an NFS datastore in VMware, so thin is my only option!)
It is also worth noting that you will need to select the following options when configuring your VM:
- OS Type: Red Hat Enterprise Linux 6 (64-bit)
- NIC Type: E1000 Note: ACS is not compatible with VMXNET adapters!
Attach the ISO as you normally would (I always go for the datastore option) and fire up the VM. The installer should start automatically and present the following:
We want to install via the VMware console, which is actually a remote KVM so we need option 1.
It is worth noting option 3 at this stage - if you lose the administrator password you will need this ISO again and to boot from it in order to reset the password.
For detailed steps refer to the cisco deployment guide: HERE
Following part 1 the appliance will boot up and automatically install ACS to the primary hard disk. All of this is automated but when it has finished you will be prompted with the following:
After entering setup you will be prompted for some settings. Below is a screenshot of the settings I used for this configuration. If you're integrating ACS into Active Directory it is important to configure the settings according to your setup. For example ACS needs to be able to find AD, so my DNS server in this case is my AD server. The domain name I have used is also the domain name of the AD server which is dchidell.lab
Following this, ACS will configure networking and run some tests to make sure the appliance is suitable for use (network reachability, disk performance etc).
If everything goes well you will be presented with a simple but satisfying prompt:
Since I've enabled SSH I'll continue the configuration through that.
We could go ahead and begin configuration of the appliance but first I'd like to make sure we're up to date on the latest patch.
SSH to the appliance with the credentials you entered in the initial setup wizard. If you've not enabled SSH you'll have to use the VMware console to log in.
acs/admin# acs/admin# conf t Enter configuration commands, one per line. End with CNTL/Z. acs/admin(config)# repository TFTP_SERVER acs/admin(config-Repository)# url tftp://10.53.230.126 acs/admin(config-Repository)# exit acs/admin(config)# exit acs/admin# acs patch install 5-8-0-32-5.tar.gpg repository TFTP_SERVER md5: 8db30ce02d046d480addd267edc4bb44 sha256: c0647392927c6b4d1eb1bee73c24fe5513c24425bf9ba731d572f188a84dd9f9 % Please confirm above crypto hash matches what is posted on Cisco download site. % Continue? Y/N [Y] ? Installing ACS patch requires a restart of ACS services. Continue? (yes/no) yes Calculating disk size for /opt/CSCOacs/patches Total size of patch files are 823 M. Max Size defined for patch files are 2000 M. Stopping ACS. Stopping Management and View............................................................... Stopping Runtime....... Stopping Database..... Stopping Ntpd... Cleanup... Stopping log forwarding ..... Installing patch version '22.214.171.124.5' Installing ADE-OS 2.0 patch. Please wait... About to install files Removing old war Removing old war Removing old war Removing old war Removing old war Removing old war Removing old war Installing PBIS patch. Please wait... Installing new JRE. Please wait... /opt/CSCOacs/patches/5-8-0-32-5 Patch '5-8-0-32-5' version '126.96.36.199.5' successfully installed Starting ACS .... To verify that ACS processes are running, use the 'show application status acs' command. acs/admin#
It's worth noting that this requires the command acs patch and not just patch. We'll use the standard patch command in the next section to access the root shell.
Applying the root patch:
This section is a little specialist - usually you would never need root access to the appliance and this is something Cisco TAC would provide access to, but when I'm testing something I like to be able to go right in and see how it ticks.
The root patch is very similar to the standard application patch:
acs/admin# application install rpssh64.tar.gz TFTP_SERVER Save the current ADE-OS running configuration? (yes/no) [yes] ? Generating configuration... Saved the ADE-OS running configuration to startup successfully Getting bundle to local machine... md5: 222f3bdf4de4165ac786bd040f940512 sha256: 4306a92ed434ed34bbbaa39ec1e4ef27fff10bf53b6711c1005b4f553ca539be % Please confirm above crypto hash matches what is posted on Cisco download site. % Continue? Y/N [Y] ? Unbundling Application Package... Initiating Application Install... Application successfully installed acs/admin# acs/admin#
Following the root patch install we'll have to restart the CLI to gain access to the root shell.
acs/admin# acs/admin# root_enable Password : Password Again : Root patch enabled acs/admin# acs/admin# root Enter root patch password : Starting root bash shell ... ade # ade # date Fri Nov 11 12:49:48 UTC 2016 ade # pwd /root ade #
We now have root!
The CLI of ACS is basic, and can only be used to configure administration parameters of the ACS instance, and not used to configure the actual functionality of the appliance, this must be done through the GUI.
The GUI is exceptionally picky over the browsers it supports, with this latest patch I have noticed it actually disables logging in if you're not using a supported browser! The supported browser I use is Firefox, and this seems to work well.
For the initial connection enter https://yourip into the browser. HTTP does not automatically redirect to HTTPS.
You should be greeted with the following:
If not, the application may not yet be running, you can check the status of ACS from the CLI:
acs/admin# show application status acs ACS role: PRIMARY Process 'database' running Process 'management' running Process 'runtime' running Process 'adclient' running Process 'ntpd' running Process 'view-database' running Process 'view-jobmanager' running Process 'view-alertmanager' running Process 'view-collector' running Process 'view-logprocessor' running acs/admin#
Log into the GUI for the first time using the default credentials:
You will be prompted to change your password and enter a license key, once those are done you'll be welcomed by the main menu:
Active Directory Integration:
ACS can use an internal database of users, but can also integrate with various external identity sources.
We'll add Active Directory by navigating to Users and Identity Stores -> External Identity Stores -> Active Directory
Click the join button and enter the Active Directory information.
Upon success you can see that ACS is joined to the domain:
Now we can import our groups from Active Directory. I've created two groups called Network_Admins and Network_Operators. There are also 3 users called Bob, Dave and Steve. All of these sit in an Organisational Unit called Lab Accounts.
I've added these users to the groups and renamed them so we can easily see which user is part of which group. Naturally Dave has the highest privileges!
We can add these groups to ACS by clicking the Directory Groups tab and then the Select button. From the popup window we can then select the groups we've got in AD and add them into ACS.
ACS Operational Overview
Now we've got our identity source configured, we can go ahead and start to configure TACACS+. There's quite a few components to this but I'll try break them down as best I can.
The way ACS works is based on policies and has a flow like architecture. Essentially when a client uses the service, a service has to be determined. ACS has two services pre-determined, match Radius and match Tacacs. These can be seen in the Access Policies -> Access Services -> Service Selection Rules. No changes have to be made here since we're either going to be using radius or tacacs.
After this service selection has been made we now find ourself inside the configuration of a specific service. The two we have available are Default Device Admin and Default Network Access. It might not seem obvious from first glance but you can think of these two as the following:
- Default Network Access = RADIUS
- Default Device Admin = TACACS+
Within each of these services we can see two options, Identity and Authorization.
Identity is simply where are we going to find the identity of a user, it does NOT deal with the groups of users just yet.
The authorization section is where we define parameters relating to groups etc within Active Directory. We'll cover some more of the components relating to each service in the following sections, but below is how the flow of operations works within ACS (named to what we're going to use later):
This is a nice short section but applies to both TACACS+ and RADIUS so thought I would cover it here to avoid duplication of efforts.
Essentially you need to add your devices into ACS so ACS knows about the device. Navigate to Network Resources -> Network Devices and AAA Clients
From here we can add a device with a specific name, IP and shared secret for TACACS+ and RADIUS.
I've added my CSR1000V with it's IP as well as it's shared secret.
It's worth noting you can add ranges or groups of IPs to share credentials. This is good if you've got a list of devices which all use the same shared secrets and you don't want to go through the hassle of adding each device manually.
There is also another option called Default Network Device which, if enabled, will provide a default set of secrets which ACS will try and validate against should no specific device or range of devices be defined.
TACACS+ is great for use when logging into devices, it offers exceptionally granular controls for a particular set of users which can be really useful if you want to determine exactly what a user can and cannot do.
For this post I'll be using a CSR1000v virtual router as our TACACS+ client, this has been freshly installed with nothing more than an IP on it so I can reach it.
First, let's configure the identity source we want to use to authenticate our users. Navigate to Access Policies -> Default Device Admin -> Identity
Personally speaking I prefer the Rule based result selection as this provides a more granular approach - even though I generally have only one rule!
Create a new rule. Call it something suitable. I'm going to call mine Active_Directory_Tacacs.
Select the Compound Condition box. This is where we determine under what condition are we going to use this set of authentication parameters. Since we're not looking for anything complex at the moment, we'll select the System dictionary, and the Protocol attribute. Then select Tacacs for the value and add it to the condition set.
Select the identity source and pick the Active Directory option.
You should now be able to see the Identity rule in place. If you like we can use the Default option of Internal Users as a backup. I don't want this, if my AD server is down we'll drop the request. We can click on Default and change the identity source to DenyAccess.
Next we need to create a Command Set which is used in the authorization stage. The command set describes what commands the user can perform once they've been authenticated. We'll create two, one for full access and one for just show commands.
Head to Policy Elements -> Authorization and Permissions -> Device Administration -> Command Sets
Create a new command set. Call it something useful, I'm using Permit_All_Commands
Check the box for Permit any command that is not in the table below if you wish to permit everything. Submit.
Let's create another for just show commands. Again call it something sensible, I'm using Permit_Show_Commands
I've added two commands to the list show and exit. If no arguments are specified, all arguments are permitted. I'm also going to deny show run as I don't want my entire configuration duplicated. Note: You must specify the full command, not the abbreviated version!
We also have to define the shell role our users will have. This is done in the Shell Profiles section. Let's create a shell profile which gives priv 15 access.
Create a new shell profile, call it something usable, I'll use Shell_Priv_15. Under the Common Tasks tab, set the default privilege to 15 and save the profile.
Now it's time to head back to our authorization access policy. Navigate to Access Policies -> Access Services -> Default Device Admin -> Authorization
This is where we define which groups can perform what functions. So we'll tie together the groups we've made in Active Directory and the command sets we just created.
Before we create a rule we need to change the conditions present. So select the Customize button near the bottom right. Here we can select the conditions available to us when creating rules. We need to pick our AD instance so add that over to the selected set, AD1:ExternalGroups in my case. We also need to select a custom result set as well, so add the Command Sets over to the right too.
Create a new rule, lets do the full admin access policy first, so I'll call this one AD_Network_Admins. The Identity group we're using is the group within Active Directory, the shell profile we'll select the Shell_Priv_15 profile, and the command sets we can select the Permit_All_Commands set we created earlier.
Save the rule and now let's create another one for the network operators (purely show commands). This is created in the exact same way, but select the correct group in AD as well as the correct command set. For the shell profile this affects if the network operator gets through the enable prompt or not. This makes no difference as to what they can do, as every command is authorized by ACS.
We also want to deny access to anyone who cannot be authorized, so let's change the default rule at the bottom to Deny Access and save the changes.
Right, we should be good to go from the ACS side! Now we just need to configure AAA on our router:
Router# Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#aaa new-model Router(config)#aaa authentication login default group tacacs+ local Router(config)#aaa authorization exec default group tacacs+ local Router(config)#aaa authentication enable default group tacacs+ enable Router(config)#aaa authorization commands 0 default group tacacs+ local Router(config)#aaa authorization commands 1 default group tacacs+ local Router(config)#aaa authorization commands 15 default group tacacs+ local Router(config)#aaa authorization config-commands Router(config)#tacacs server ACS Router(config-server-tacacs)#address ipv4 10.53.228.9 Router(config-server-tacacs)#key Cisco Router(config-server-tacacs)#exit Router(config)# Router(config)#aaa group server tacacs+ TACACS_SERVERS Router(config-sg-tacacs+)#server name ACS
aaa new-model aaa authentication login default group tacacs+ local aaa authentication enable default group tacacs+ enable aaa authorization exec default group tacacs+ local aaa authorization commands 0 default group tacacs+ local aaa authorization commands 1 default group tacacs+ local aaa authorization commands 15 default group tacacs+ local aaa authorization config-commands tacacs server ACS address ipv4 10.53.228.9 key Cisco aaa group server tacacs+ TACACS_SERVERS server name ACS
Time to test! Let's login as dave who should get access to every command:
[email protected]chidell-mac:~$ telnet 10.53.228.10 Trying 10.53.228.10... Connected to 10.53.228.10. Escape character is '^]'. username: dave password: Router# Router# Router# Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#hostname Dave-wins Dave-wins(config)# Dave-wins(config)#
Excellent! Let's try Steve who should only get show commands, but not show run
[email protected]:~$ telnet 10.53.228.10 Trying 10.53.228.10... Connected to 10.53.228.10. Escape character is '^]'. username: steve password: Router> Router>en Command authorization failed. Router>conf t ^ % Invalid input detected at '^' marker. Router>show ip int brief Interface IP-Address OK? Method Status Protocol GigabitEthernet1 10.53.228.10 YES manual up up GigabitEthernet2 unassigned YES unset administratively down down GigabitEthernet3 unassigned YES unset administratively down down Router> Router> Router>show run ^ % Invalid input detected at '^' marker. Router>
Also good news! Steve can't do anything apart from standard show commands!
But how about bob? He shouldn't be able to log in at all!
[email protected]:~$ telnet 10.53.228.10 Trying 10.53.228.10... Connected to 10.53.228.10. Escape character is '^]'. username: bob password: % Authentication failed username:
Fantastic! TACACS+ is done!
RADIUS is similar to TACACS+ in it's implementation, nevertheless I will run through all the steps.
We're using the same CSR1000v as last time, but I have removed all the TACACS+ config and we'll add some RADIUS config instead.
First, let's configure the identity source we want to use to authenticate our users. Navigate to Access Policies -> Default Network Access -> Identity
Like before, I like to use rule based for granularity. Here's the configuration I used:
I've also gone ahead and changed the Default at the bottom to DenyAccess just like we did for TACACS+.
Now we need to create an Authorization Profile, this is similar to a Shell Profile for TACACS+. Navigate to Policy Elements -> Network Access -> Authorization Profiles and create a new one.
Now unlike TACACS+, RADIUS does not have the level of granularity, but we can still send particular attributes back from the ACS server. So let's create a new profile and set it so we get priv 15 when we log in. This will be for the network admins.
Under RADIUS Attributes we'll have to add a new attribute, this is from the RADIUS-Cisco dictionary and must be as follows:
- Dictionary: RADIUS-Cisco
- Name: cisco-av-pair
- Value: shell:priv-lvl=15
Once you've added the attribute it should look like the following:
Save the profile and head to the Authorization policy Access Policies -> Default Network Access -> Authorization
From the Customize button in the bottom right, select the AD external groups option for the conditions.
Create a new policy. Call it something useful, I'm using AD_Network_Admins. Add the AD group we're using for network admins.
Now let's add another for Network Operators. This time we'll select the default Permit Access authorization profile.
We'll also change the default rule to deny access.
That's it for ACS! Time to add some router config:
Router# Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#aaa new-model Router(config)#aaa authentication login default group radius local Router(config)#aaa authorization exec default group radius local Router(config)#radius server ACS Router(config-radius-server)#address ipv4 10.53.228.9 Router(config-radius-server)#key Cisco Router(config-radius-server)#exit Router(config)# Router(config)#aaa group server radius RADIUS_SERVERS Router(config-sg-radius)#server name ACS
aaa new-model aaa authentication login default group radius local aaa authorization exec default group radius local radius server ACS address ipv4 10.53.228.9 key Cisco aaa group server radius RADIUS_SERVERS server name ACS
You'll notice it's similar to TACACS+ but we've got less lines to do with authorization of commands. This is because RADIUS does not support the granularity of TACACS+ and just sends back a response and closes the connection.
Let's try logging in with dave:
[email protected]:~$ telnet 10.53.228.10 Trying 10.53.228.10... Connected to 10.53.228.10. Escape character is '^]'. User Access Verification Username: dave Password: Router# Router# Router# Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#exit Router# Router#
Success! Dave get's straight into priv 15 as expected.
Now how about Steve?
[email protected]:~$ telnet 10.53.228.10 Trying 10.53.228.10... Connected to 10.53.228.10. Escape character is '^]'. User Access Verification Username: steve Password: Router> Router> Router> Router>en % Error in authentication. Router>
Perfect! Steve just has basic authorization and RADIUS does not send back a priv level to use. As a result we're placed at an unprivileged prompt. The problem here is we have to specify locally what each priv level represents.
Now what about bob, who has no access:
[email protected]:~$ telnet 10.53.228.10 Trying 10.53.228.10... Connected to 10.53.228.10. Escape character is '^]'. User Access Verification Username: bob Password: % Authentication failed Username:
Excellent! No access!
Both RADIUS and TACACS+ work great and are fairly straightforward to configure in ACS. There's a few quirks here and there which take some getting used to, but for the most part it's not too bad at all.
It's worth mentioning as well that ACS keeps a full log of all activity which can be viewed using the Log Viewer at Monitoring and Reports -> Launch Monitoring and Report Viewer