ACS 5.6 install notes

Cisco Access Control Server (ACS) 5.6 install

I had a project to install ACS 5.6 for a customer..and I just wanted to go into a bit of detail of what I did for them!

ACS 5.6 can be installed on a VM or a physical chassis.  With regards to the physical chassis, there are a few options: Cisco's SNS 3415 chassis (who the customer used in this case) or the legacy Cisco 1113 chassis.  In the past, I'd always used the 1113 chassis or VMs--This was my first SNS 3415 install.

Before we dig into the ACS specifics, I'll discuss the setup of the device!

Racking:

The setup was fairly easy (with a bit of googling!)--as there were no instructions in the box.  The box comes with the physical chassis, a set of rails, mounting screws, power cables, ethernet cables, and a serial dongle.  The trick to mount the rails were to pull up on a tab on the end of the rail and pull back on the spring loaded mounts (1).  You then slide the square (or circular, depending on your rack) pegs into the rack (2).  Once they are in, pull on the same tab and the spring will close the gap and hold the bracket firmly against the rack (1).  Once you do the same for the backside of the rail (make sure they are on the same RU!!), there is a screw hole on the front of the rack to keep the rail from coming undone.  After you get the screws it, it is as simple as sliding the server onto the rails, as it already has the mounts on the server.  Once mounted, I ran ethernet to two different switches.  

The SNS 3415 supports bonding the physical ethernet ports so to provide upstream switch and cable redundancy.  When you bond the ports it creates a logical bond port.  One port is active while the secondary is passive; both ports will share the same MAC address so to avoid any bridging loops/mac address-table instability.  Just for verification sake, I took down one of the ports and at most saw a single packet lost.

 

Once you power on the device, it will immediately prompt you with the configuration items: hostname, IP address, gateway, name server, domain, CLI login, password, etc.  

Now!  Lets get to the meat of it all!

To start things off..lets get this baby integrated with AD!

This part is pretty darn easy.  Simply click on "join/test connection" from the "Active Directory" sub-section and enter the required information.  Remember, if you're using the name service, you must have configured the name-services in the CLI beforehand!  NOTE: When adding the ACS server to AD, The AD account required for domain access in ACS should have either of these privileges:

• Add workstations to domain user right in corresponding domain.

• Create Computer Objects or Delete Computer Objects permission on corresponding computers     container where ACS machine's account is created before joining ACS machine to the domain.

Integrating AD allows us to do two important things: Use our AD accounts for device management and ACS management.  For device management purposes, you can map certain AD user groups to certain rights/command sets.  Furthermore, you can map certain AD groups certain ACS rights (read/write/superadmin).

To select the AD groups you wish to use, click select under "Directory Groups."  If your device is joined and connected to AD, you should see a list of the groups available.  In this example I simply added a generic "Domain Admins."

Call me crazy, but I want both users in active directory and local users to be able to access the devices.  Who knows...maybe you have a vendor who you want to grant network access but don't want to create an AD account?  To do so, go to "Identity Store Sequences" and create a custom ID store.  Under the "Authentication and Attribute Retrieval Search List" choose both AD1 and Internal users.  In this order, it will first verify if the user is in AD, but if not, will check the local user store.

Implementation:

Time to create some Identity groups!  Identity groups are nothing more than a container in which you can associate certain rights/privileges.  In a basic ACS setup I'd create two identity groups: Read only users (users who can only run show commands) and Network admins (unlimited access).

Shell profiles!  Shell profiles are a place where you can assign attributes (default/maximum privilege, shell timeouts, etc).  Here I would create two shell profiles: Network Admins and Read Only.  The example below is pretty much the only values I'd put in for the Network Admins shell profile.  For the Read Only profile I'd set the default privilege to 1 and configure a timeout value of 10 minutes.   

Command sets!  Shell profiles are where you identify what commands can be run.  For example purposes, I'd create two shell profiles: Show only and Permit any.  Show only is limited to basic show commands while Permit any can run any command.  

By not listing any arguments, any parameter of the given commands are permitted.  For example, since the "show" command is allowed, it would also allow show run, show ip interface brief, etc.  If we were to have listed the argument "run" under arguments, then only the show run command would per permitted.

For the permit any, it is as simple as checking the "Permit any command that is not in the table below" checkbox.  Since we did not list any commands, all commands will be allowed!

Now that we have the identity groups, shell profiles, and command sets created, now we have to configure the device management.  Under the access policies section you will see access services.  Unless its a large scale deployment..I'm fairly comfortable using the default device admin service.  Under "Default Device Admin" you will see three fields: Identity, Group Mapping, and Authorization.  If you do not see one of these, click on "Default Device Admin"--there should be checkboxes for each area.  

Identity: This area is fairly simple.  When a username is entered, it needs to know where to lookup the username for access.  I've been successful leaving it in "Single result selection" and using the custom identity store we created at the start.  

Group Mapping: Here is where we map the AD group to a particular identity group.

If you do not see any of the fields above, click on "customize" in the bottom right hand corner.  For this particular customer, they weren't interested in the "Read only" user group...but it would be the same process tying the read only AD group to the predefined read only identity group.

Authorization: Here is where we put a bow on everything---we tie the identity group to the pre-defined shell profile and command sets!

While the read only users is not being used, I still created the authorization rule in the event they change their minds.  Furthermore, the customize bottom button at the bottom right corner can give you a TON of conditions (should you want to use them).  You can setup authorization rules based on device type, location, time, IP address, etc.

In addition to the AD mappings, we were also able to use the local users.  The key for this is to specify what identity group the user is in under the user settings.  In the example below, kyle.barnes would be part of the shell profile "Network Admins" and the command set "Permit any."

Adding network devices:

This part is super easy if you aren't being picky in your authorization rules.  In this customer's case, they didn't care about having location/device type specific rules, so I didn't have to be too granular in the device addition.  

I created 3 device types (Router, switch, and firewall) under network resources.  Was this necessary, given their requirements?  No.  I included the device type for logging purposes.  If one only cares for the bare bones, then he or she would only need to include the name, IP address, and TACACS shared secret!

AAA configurations:

Here is where things can get tricky.  Lets start easy...tacacs-server configs!

ip tacacs source-interface <management interface>

tacacs-server host <ACS IP address>

tacacs-server key 0 <shared secret configured in the network resources>

Now the fun part..

One thing I may add is more accounting on the commands.  I feel as if I can sometimes get more information than via the authorization logs.

Time for device administration!

As I said previously, we can now manage the ACS server with our AD credentials!  To do so, you need to configure the Administrative access control section as follows:

This rule basically says, "If you are trying to connect with a username, let me try and compare it against my AD ID store."

Lastly, the Authorization Policy says "Ok, let me see what group that particular user is in.  Once I find it, you will have the resulting role."  In the picture above, if your AD account is in the group "Domain Admins" then you'll have SuperAdmin rights.

Important notes!

• Default ACS web login: U: acsadmin P: default -- by default acsadmin is the recovery account.  Regardless of how anything is setup it will let you in!