Objective 2.04 in the 301a syllabus requires the candidate to have an understanding of the authentication process as it relates to remote authentication and authorisation on a BIG-IP system.

The BIG-IP system utilises two different account types:

System maintenance account:

This is your 'root' user, the account which is enabled by default on a BIG-IP device. This is the most powerful user on the system and by default it is granted full access to all BIG-IP system resources.

Standard user account

These are user accounts that are manually created by an administrator. These accounts can use local or remote authentication & authorisation.

A special note regarding the 'admin' account. Although this account comes on a BIG-IP system by default, it is still considered a user account because it resides in the local user account database.

This is the first of three posts that will provide detail on how to setup three methods of authentication & authorisation using a remote authentication server using the following protocols:

• TACACS+
• LDAP
• RADIUS

Cisco ACS TACACS+

TACACS+ is a protocol developed by Cisco and is used for all things Authentication, Authorisation & Accounting (AAA). TACACS+ adds a further layer of security to the process by encrypting the entire packet between the client and the server. The following section will show you how to setup the Cisco ACS v5.6 server to allow a BIG-IP system to utilise its AAA services. As we are also interested in remote authorisation I will demonstrate how to setup Active Directory integration so you can use AD Groups to determine roles on the BIG-IP. I will not be demonstrating Accounting in this post.

For this demonstration I have used a 90 day trial license of the ACS product. Note that you will need a CCO account with sufficient privileges to download this software.

AD Integration

First up let's integrate Cisco ACS with Active Directory. As this is a lab setting, all devices are on a common subnet. In a production environment you'll need to ensure you have the necessary ports open between the servers.

In ACS go to Users and Identity Stores >  External Identity Stores >  Active Directory, then click Join/Test Connection. Add the domain name for your network, then add an AD user + password with sufficient access to be able to create/delete Computers to the domain. Click Test Connection. A successful outcome should look like this:


Close this window and click Join on the first popup window. The two systems should now be integrated with ACS showing as a Computer device on AD and ACS showing as Joined and Connected:



Now we have AD integration we can leverage AD Directory Groups to provide granular authorisation to the BIG-IP based upon the group a user resides in. First we need to tell ACS which Directory Groups it can use for group mapping conditions.

In the same section we were in - Users and Identity Stores >  External Identity Stores >  Active Directory, click the Directory Groups tab then click Select. We need to now tell ACS the Search Base DN to start the group search. I've gone and started at the Users level as this is where I have defined my F5 user groups. I've also filtered it down to search for the specific groups I wish to add into ACS:

For the purposes of this demonstration I have added in a group containing F5 Admins (read/write access) and a group for F5 Operators (read-only access). Don't forget to save the configuration!

Identity Store Sequence

Now we need to tell ACS which databases to use for authentication using the Identity Store Sequence feature. Go to Users and Identity Stores >  Identity Store Sequences and click Create. Provide a meaningful name for the sequence and for the Authentication Method List select Password Based. Now add into the Selected box on the right the 'AD1' object within the Authentication and Attribute Retrieval Search List & Additional Attribute Retrieval Search List boxes. Click Submit.


First we need to add define a Device Group. Go to Network Resources >  Network Device Groups >  Device Type and click Create, enter a meaningful name, then click Submit.

Secondly we to add the device itself. Browse to Network Resources >  Network Devices and AAA Clients click Create and provide a meaningful name (hostname is a good idea), add it to the Device Group we've created, the IP address the ACS will expect the request to come from, and finally ensure that we select TACACS+ as the authentication protocol and include the Shared Secret key. Click Submit.


Now we need to create an Identity Group. Go to Users and Identity Stores >  Identity Groups and click Create. We'll create two Identity Groups; one for the F5 Admins and one for the F5 Operators.

Now we need to bind the Identity Groups to the appropriate Active Directory Groups. Go to Access Policies >  Default Device Admin, ensure the checkbox for Group Mapping is ticked click Submit.

Go Access Policies >  Default Device Admin > Group Mapping and select the Rule based result selection radio button and click OK when it warns you. Now click Create and give the rule a name and ensure the Compound Condition box is ticked. In the Dictionary choose the Active Directory config which takes the form AD-AD1. Click the Select button next to Attribute and then click ExternalGroups, then click OK. In the Value box click Select and now choose the AD Directory Groups the F5 admins reside in, then click OK. Now highlight the value in the Value box and click Add to add it to the Current Condition Set. In the Results box select the F5 admin Identity Group. Click OK. Repeat the above steps to create the Operator group and save.
We now need to select the Identity Source Sequence for the device admin authentication. Go to Access Policies >  Default Device Admin > Identity and click Select then choose the Active Directory object created in the Identity Store Sequence and click OK, then save.

Authorisation  

The next piece deals with authorisation and ensures the ACS passes back the appropriate attributes to the LTM. Go to Access Policies >  Access Services >  Default Device Admin >  Authorization and click Create. We'll start with the F5 Admin authorisation. Give it a name then under Conditions > Identity Group check the box and select 'in' then click the Select button and choose the 'F5-Admin' Identity Group created above and click OK.

Now select the checkbox next to the NDG: Device Type box and select 'in' then click the Select button and select the 'F5' Device Type created above and click OK.


In the Results section click the Select button. We'll create a shell profile on the fly. Click Create and on the General tab enter a meaningful name such as 'F5-Admin-Shell'. In the Common Tasks tab enter a value of Static, then 1 for the Default Privilege Level and Static then 15 for the Maximum Privilege Level.


In the Custom Attributes tab enter 'F5-LTM-User-Info-1' into the Attribute box. Leave the default Requirement of Mandatory and for the Attribute Value select Static and enter the following into the box - admin. Now click Add^, then Submit.

 Repeat the process by creating another shell profile for the Operators, however, use the value 'Ops' in the Attribute Value box. Now back on the Shell Profiles popup window select the 'F5-Admin-Shell' radio button and click OK, then OK again.


You will need to create another Device Administration Policy for the F5 Operators group but as you have already create the Operator shell profile above you won't need to go through that specific process again. You should now have two authorisation policies:

Finally the Cisco ACS TACACS+ server is now ready. Let's move onto the BIG-IP...

F5 TACACS+ AAA

Authentication

If we head on over to System  ››  Users : Authentication we have the option to change the authentication method for the entire box, that is, both GUI and SSH (terminal) access. There are a few key pieces of configuration required to set this up.

• Servers: No hidden meaning here. Quite simply add all the TACACS+ servers either by IP address or hostname (DNS is required to be configured for hostname resolution).
• Secret: Enter the password used to encrypt the TACACS+ session between the BIG-IP and the Cisco ACS servers.
• Encryption: For TACACS+ we set this to enabled.
• Service Name: For most implementations the value ppp is required.
• Protocol Name: This is the protocol associated with the Service Name. For most implementations the value ip is required.
• Authentication: If your ACS setup is active/standby leave the default option. If active/active choose the second option.
• Accounting Information:  As per the Authentication setting.
• Role: It may seem odd at first but we want to set this to No Access. The reason is because we don't want to do authorisation on the box itself.
• Partition Access: This will vary according to your setup but if only using the default partition leave this at the default setting of Common.
• Terminal Access: This can be left at the default as we control TMSH (CLI) access via authorisation.

Putting it altogether we have following:

Authorisation

On BIG-IP devices, the role a user is given is determined when using remote authorisation is determined by the Remote Role Group feature. We'll create two groups; one for admin and one for Operator. Go to System  ››  Users : Remote Role Groups and click Create, and enter the fields as shown:

Testing

With that we are now ready to test. I am using Wireshark to capture the TACACS+ packets between the BIG-IP and the ACS servers. If you open up Wireshark and go to Edit > Preferences > Protocols > TACACS+ you are able to enter the encryption key so you can see the messages in plain view. Of course, in a production setting you would need to consult your group security before doing this in Wireshark.

I have created two users on AD - John who is in the 'F5 Admins' group and Dave who is in the F5 Operators group. If I first log in using John's AD credentials...success! I am logged in and granted the Administrator role:



If I login using Dave's AD credentials it is also successful and I am granted the Operator role as planned:


If we analyse the Wireshark capture for Dave's transaction we see that the BIG-IP first sends a TACACS authentication packet:


The ACS then contacts Active Directory using LDAP and Kerberos requesting authentication for user 'Dave'. Once passed the ACS returns a TACACS authentication response back to the BIG-IP:

The BIG-IP now sends a TACACS authorisation message to ACS:


The ACS server then evaluates the request and responds back with the attributes within the Operator Shell Profile:


The BIG-IP now evaluates its Remote Role Group configuration and compares the attribute the ACS has sent back ('F5-LTM-User-Info-1=Ops') and then applies the Operator role to this user's login session.

Summary

There is no doubt that there are many steps to configure Cisco ACS for AAA services. This example only really touched on ACS's capabilities. A production enterprise system would go further in carving up the various locations, departments etc. to provide fine granular authentication and authorisation to network devices. From a BIG-IP perspective the Remote Role Groups feature provides us a relatively simple way to limit user access. This example only used two roles, however, the BIG-IP system offers many more depending on your needs.