In this article, we will look at how to integrate the Windows Active Directory with the Cisco Secure Access Control System (ACS). We will be using the Cisco Secure ACS version 5.3 and Windows Server 2008 as our Active Directory. The lab setup is as shown below:

As you may be aware, there are two identity sources that the ACS can use for authentication/authorization purposes: The internal identity store and the external identity store. The internal identity store is nothing more than the local database of the ACS itself, while the external identity store can be an LDAP server, Active Directory, an RSA SecurID token server, and so on.

One of the benefits of integrating the Cisco Secure ACS with external identity stores such as the Windows AD is that an organization may already have users and computers set up on those external identity stores. Instead of recreating these credentials on the Cisco Secure ACS, you can just make use of the existing ones on the external servers.

There are a couple of prerequisites that must be met before you can join the Cisco Secure ACS to a Windows domain, including:

  • The date, time, and time zone settings on the ACS must match these settings on the AD primary domain controller. This could mean setting them manually or synchronizing with an NTP server.
  • The domain name configured on the ACS (via the CLI) should be the same as the domain you want to join.
  • The DNS server must be correctly configured on the ACS so that domain names can be properly resolved.
  • The username you use to join the ACS to the domain must have appropriate privileges (e.g., part of domain administrators).

To meet the first three requirements above, the relevant configuration on the ACS we are using for this lab is as follows:

hostname ACS1
!
clock timezone UTC
ntp server 172.16.1.1
!
ip domain-name inelab.local
ip name-server 172.16.10.100
!
interface GigabitEthernet 0
 ip address 172.16.1.100 255.255.255.0
!
ip default-gateway 172.16.1.1

To meet the last prerequisite, I have created a user called “acsadmin” with a password of “cisco123” and added that user to the administrators group. That should give this user sufficient privileges to allow the ACS join the domain.

Having configured the prerequisites, we can now log in to the web portal of the Cisco Secure ACS. To join the Windows domain, we will navigate to Users and Identity Stores > External Identity Stores > Active Directory.

On this page, we will configure the active directory domain name, which is “inelab.local” in our case. We will also specify the username (“acsadmin”) and password for that username (“cisco123”) on this page.

One thing that is helpful is to use the “Test Connection” button to confirm that you have entered accurate credentials and that the domain is reachable. If the connection succeeds, you should get a message like “Connection test to ‘domain name’ succeeded”:

Once our test has succeeded, we need to save our configuration using the “Save Changes” button at the bottom of the page. If all goes well, you should see a connectivity status of “CONNECTED” for that domain:

Note #1: Even though the test connection is successful, you may get an error when you save your configuration. From my own experience, I got an error because the username I used to join the ACS to the domain did not have sufficient privileges. The error dialog I got is as shown below:

Note #2: The user you use to join the ACS to the domain does not have to be among the administrators. Refer to this link for the minimum privilege(s) that such a user must have (as specified in the “Username” row).

When the ACS has been joined to the domain, two new tabs appear on that page: Directory Groups and Directory Attributes. You can add items under these tabs that can be used in policy conditions. For example, you may want only users who belong to the AD group “Network Admins” to be able to manage network devices. As such, you need to add the “Network Admins” AD group on the ACS Directory Groups, else you won’t be able to use that group in your policy.

Note: You don’t have to add any directory groups for authentication to work. By default, the ACS will authenticate users by searching the entire domain of the AD.

In this article, we will not add directory groups or attributes; we will just confirm that the ACS can successfully authenticate users using the Windows AD. To do this, I will navigate to Access Policies > Access Services > Default Network Access > Identity. By default, the ACS authenticates users for default network access using its internal identity store.

We will change this so that the ACS will use the AD we just added (click”Select” then choose the AD).

We can test user authentication from the router. The router is already configured with the ACS as a radius server as follows:

aaa new-model
radius-server host 172.16.1.100 key cisco

The router has also been added as a network device on the Cisco Secure ACS:

We can use the test aaa command from the EXEC mode on the router to test AAA for a particular user. We will test using the “acsadmin” user we configured on the Windows AD.

As you can see, the user was successfully authenticated. We can look at the details of this authentication request by navigating to Monitoring and Reports > Launch Monitoring and Report Viewer; then we click on the Authentication – RADIUS – Today link on the page that opens and select the details (magnifying glass symbol) for the request we are interested in:

A snippet of the details is shown below and, as you can see, “AD1” was the Identity store that was used to authenticate the user.

Summary

In this article, we have seen how to integrate Windows AD with the Cisco Secure ACS so that the AD can be used as an external identity store. We also tested our configuration by authenticating a user against the Windows AD.

I hope you have found this article insightful.

References and Further Reading