Chapter 5. Configuring External Databases (Identity Stores) with ACS

Chapter 4, “Getting Familiar with ACS 5.1,” explored internal identity stores and detailed how they can be integrated with available policies and rules. At this point, you might be wondering what to do if you already have a database in place? Are you supposed to do some kind of export and import of available databases into Cisco Secure ACS Server? The logical and feasible answer would be to extend Cisco Secure ACS Server to these already present databases, which can be referred as external databases or external identity stores with reference to Cisco Secure ACS. This approach does not introduce any overhead on the part of Cisco Secure ACS or external identity stores to maintain or sync it with each other. Both entities are maintained separately.

External Databases/Identity Stores

The choices available for external databases or external identity stores are decent enough on Cisco Secure Access Control Server 4.2 and Cisco Secure Access Control System 5.1. This section looks at the different external databases options available on ACS 4.2 and ACS 5.1. You will also learn how these external users or identities are processed in both versions.

External Databases/Identity Stores in Cisco Secure Access Control Server 4.2

On ACS 4.2, users are categorized into three categories:

• Known Users: Users who are explicitly added to the ACS internal database. This addition can take place manually by the ACS administrator through the GUI or automatically using Relational Database Management System (RDBMS) synchronization or by using the CSUtil.exe database utility.

• Unknown Users: Users whose accounts do not exist in the ACS internal database.

• Discovered Users: Users whose accounts are created in the ACS internal database after successful authentication by using the Unknown User Policy (through an external database in the policy) on the ACS server. All discovered users are previously unknown users on the ACS server. After they are discovered; the user accounts created on the ACS internal database contain only username and password authentication list settings reflecting the database from where the user was discovered, and a group to which this user is assigned on ACS server as defined by group mapping for the particular external database.

After ACS 4.2 is integrated with an external database or external identity store, if a user is not explicitly added to the ACS internal database with password authentication list pointing toward the external database, the very first time when a user authenticates, he or she is marked as an unknown user. ACS then checks the configuration of the Unknown User Policy. Depending on the action defined for an unknown user, one of the following actions occurs:

The user is rejected (due to “Fail the attempt” option selection).

An attempt is made to discover the unknown user (due to “Check the following external user databases” option selection) in the selected external user databases.

The Unknown User Policy option is available on ACS 4.2 under the External User Databases > Unknown User Policy option, as shown in Figure 5-1.

Figure 5-1. ACS 4.2 Unknown User Policy

Multiple databases can be selected for unknown user discovery. If a user is not found in one database, the next sequential database is searched. The search order can also be configured in this section for the unknown user. When selecting multiple databases for unknown user discovery, you can place the database at the top of the list that does the following:

• Processes maximum authentication/authorization requests

• Processes requests that are associated with time-sensitive AAA clients or authentication protocols

• Requires the most restrictive mandatory credential types

For explanation purposes, assume that Network Access Profile (NAP) is configured on ACS 4.2, and the request matches the criteria defined in one of the NAP policies. In this case, the user is not discovered (if unknown) as defined in the Unknown User Policy section. The unknown user is discovered depending on the database definition available on the particular NAP policy.

Users can be authenticated on Cisco Secure Access Control Server 4.2 when using the following external databases:

• Windows User Database

• Generic LDAP

• Open Database Connectivity (ODBC)–compliant relational databases (ACS for Windows)

• LEAP Proxy Remote Authentication Dial-In User Service (RADIUS) servers

• RADIUS Token server

• RSA SecurID Token Server

• RSA Authentication with LDAP Group Mapping

External Databases/Identity Stores in Cisco Secure Access Control System 5.1

In Cisco Secure Access Control System 5.1, there is no concept of known, unknown, and discovered users as there is with Cisco Secure Access Control Server 4.2. In ACS 5.1, an external database or identity store is selected for user authentication and attribute retrieval based on policies and rules. After an external identity store is configured, it can be used in Access Service’s Identity section, where an identity store of choice can be selected.

ACS 4.2 has an option for selecting multiple external databases so that a user can be searched until it is not found. ACS 5.1 has a similar feature, which is known as identity store sequences.

The identity sequence is made up of two components:

• One for authentication

• Other for retrieving attributes

There are two methods of authentication available:

• Certificate based

• Password based

An identity store sequence can be created from the following option: Users and Identity Stores > External Identity Stores > Identity Store Sequences.

If you choose to perform certificate-based authentication, a single certificate authentication profile is used, as shown in Figure 5-2.

Figure 5-2. Identity Store Sequence Object Certificate Based Authentication

If you choose to perform password-based authentication (see Figure 5-3), you can define a list of identity databases to be accessed in sequence until the authentication succeeds. If the authentication succeeds, the attributes within the database are retrieved.

Figure 5-3. Identity Store Sequence Object Password-Based Authentication

In addition, you can configure an optional list of databases from which additional attributes can be retrieved. These additional databases can be configured irrespective of whether you use password-based or certificate-based authentication. If a certificate-based authentication is performed, the username is populated from a certificate attribute and this username is used to retrieve attributes from all the databases in the list. When a matching record is found for the user, the corresponding attributes are retrieved.

An identity store sequence object, once created, as shown in Figure 5-3, can be used to process a complex request where multiple identity stores and profiles are involved.

On ACS 5.1, the following external identity stores options are available:

• LDAP

• Active Directory

• RSA SecurID Token Server

• RADIUS Identity Server

The next section examines individual external databases or external identity stores configured on Cisco Secure ACS.

Configuring Active Directory

Microsoft Active Directory configuration is available on both Cisco Secure ACS 4.2 as well as Cisco Secure ACS 5.1. There lies a difference in the way Microsoft Active Directory is integrated with both as described in the sections that follow.

Active Directory Configuration on Cisco Secure Access Control Server 4.2

As you already know, Cisco Secure Access Control Server 4.2 is available in two platforms: Solution Engine and Cisco Secure ACS for Windows. Due to differences in platform, there lies a minor difference in integrating Solution Engine and Cisco Secure ACS for Windows with Microsoft Active Directory.

For Cisco Secure Access Control Server for Windows, the Windows server needs to be a member server or a domain controller to be able to communicate with the Microsoft Active Directory.

To configure the Windows database on Cisco Secure ACS for Windows, you need to navigate to External User Databases > Database Configuration > Windows Database > Configure.

For Solution Engine, there is a minor difference in integration. To ensure solution engine communication with Microsoft Active Directory, you need to install Cisco Secure Remote Agent. This remote agent software needs to be installed on a member server or a domain controller. When installation completes, you need to add a remote agent entry under the Network Configuration section on Solution Engine to make it available for use.

To configure the Windows database on Cisco Secure ACS Solution Engine, navigate to External Users Databases > Database Configuration > Windows Database > Configure > Windows Authentication Configuration.

Under this section, you have the following options available for configuration with the Windows database as shown in Figures 5-4, 5-5, 5-6, and 5-7:

• Dialin Permission: By enabling this option, network access to users can be restricted based on Windows dial-in permission.

• Unknown User Policy: If a user does not exist in the Windows database, or has typed an incorrect password, the error 1326L (bad username or password) is returned. With an unknown user policy, if you have multiple databases and the Windows database is not the last database in the list, ACS treats this error (1326L) as a wrong password and does not attempt authentication from the next external database in the list. This option should be enabled to search external databases in the list after Windows database if the 1326L error is returned.

• Configure Domain List: In a scenario where the same username exists in more than one trusted domain, and it is not practical for users to explicitly specify the domain name while authenticating, a domain list can be configured. ACS will try to authenticate the user normally. If the user authentication fails, ACS will retry authentication for each domain specified in the domain list.

• MS-CHAP Settings: These options are required if you want ACS to support MS-CHAP–based password changes for Windows user accounts.

• Windows EAP Settings: The following options are available under this section:

Password change during EAP authentication

Machine Authentication feature on ACS for PEAP and EAP-TLS

Machine Access Restriction

• Windows Authentication Configuration: For ACS, it is essential to provide a workstation name during Windows authentication. The default workstation name is CISCO. If you would like to provide a different workstation name during authentication, it can be specified in this section. This section has another option available that allows evaluation of nested groups during group mapping.

Figure 5-4. ACS 4.2 Windows Authentication Configuration Section

Figure 5-5. ACS 4.2 Windows Authentication Configuration Section (Continued)

Figure 5-6. ACS 4.2 Windows Authentication Configuration Section (Continued)

Figure 5-7. ACS 4.2 Windows Authentication Configuration Section (Continued)

Active Directory Configuration on Cisco Secure Access Control System 5.1

Cisco Secure Access Control System 5.1 is available as an appliance and VMWare. Both available platforms have no difference when it comes to configure Microsoft Active Directory. Previously, the Cisco Secure Access Control Server 4.2 appliance was dependent on an additional piece of software (Remote Agent) to integrate ACS and Windows AD. In ACS 5.1, no such software is required. ACS 5.1 is joined with Microsoft AD with few simple steps, which this section examines.

ACS supports the following Microsoft AD domains:

• Windows Server 2000

• Windows Server 2003

• Windows Server 2008

With an external identity store such as Microsoft AD, ACS 5.1 supports the following authentication protocols:

• PAP

• MSCHAPv1

• MSCHAPv2

• EAP-GTC

• PEAP

• EAP-FAST

• EAP-TLS

To authenticate user and machine from Microsoft AD, ACS needs to be joined to the AD. Joining ACS with AD is fairly simple as compared to Cisco Secure ACS 4.2 because you do not need to perform post-installation tasks or install remote agent software.

To join ACS with AD, perform the following:

Step 1. Go to Users and Identity Stores > External Identity Stores > Active Directory.

Step 2. Under Connection Details, specify an Active Directory domain name; for example, cisco.com.

Step 3. Specify a username and password for the account that will be used to join the ACS sever to the AD. Ensure that the account being used has sufficient privileges to search the domain and create a computer account on AD to join ACS into AD.

Step 4. Press Test Connection to ensure that you are able to communicate with AD. A message appears informing you whether the AD server is routable within the network and authenticating the given AD username and password.

Step 5. If the connection was successful, click Save Changes.

If ACS was joined successfully with AD, you should see information under the Connectivity Status section including the name of the domain for Joined to Domain: and Connectivity Status: as CONNECTED as shown in Figure 5-8.

Figure 5-8. ACS 5.1 Active Directory Identity Store

Configuring LDAP

Lightweight Directory Access Protocol (LDAP), defined in RFC 2251, is an application protocol for querying and modifying directory services running over TCP/IP. ACS 4.2 and 5.1 integrates with an LDAP external database by using the LDAP protocol.

LDAP Configuration on Cisco Secure Access Control Server 4.2

To configure LDAP on ACS 4.2, you need to navigate to External User Database > Database Configuration > Generic LDAP.

Under this section, you have four sections available for configuration:

• Domain Filtering

• Common LDAP Configuration

• Primary LDAP Server

• Secondary LDAP Server

Domain Filtering

Under this section you can control how any user authentication request is submitted for authentication to the LDAP server. It can be submitted in its entirety as it is provided by the end user, or it can be stripped based on the configuration parameters available in this section and then forwarded to the external database or LDAP identity store (see Figure 5-9 in the next section). Through filtering, you can also define what domains are processed by the LDAP server.

Figure 5-9. ACS 4.2 LDAP External Database Configuration

Common LDAP Configuration

This section outlines the common LDAP configuration parameters used for user authentication and group mapping available through an LDAP database. The following configuration parameters are available under this section as shown in Figure 5-9.

• User Directory Subtree: Distinguished Name (DN) of the subtree where all users exist.

• Group Directory Subtree: DN of the subtree where all groups exist.

• UserObjectType: Attribute name in the user record that contains the username.

• UserObjectClass: Unique value of the LDAP objectType attribute that identifies the record as a user.

• GroupObjectType: Attribute name in the group record that contains the group name.

• GroupObjectClass: Unique value of the LDAP objectType attribute that identifies the record as a group.

• Group Attribute Name: Attribute name in the group record that contains the list of user records that are a member of that group.

Apart from attribute definition in the preceding list, the following options are also available under this section:

• Server Timeout

• On Timeout Use Secondary

• Failback Retry Delay

• Max. Admin Connections

Primary and Secondary LDAP Server

In this section, you define the connectivity details for the Primary LDAP server (required) and for the Secondary LDAP server (optional) as shown in Figure 5-10.

Figure 5-10. ACS 4.2 LDAP External Database Configuration

By default, the LDAP server listens on TCP/IP port 389. If you want to use secure authentication, port 636 is usually used. If you do not secure communication between ACS and the LDAP server, user credentials are passed to the LDAP server in clear text. ACS uses SSL to encrypt communication between ACS and the LDAP server. If you decide to select the Use Secure Authentication option, you must select between Trusted Root CA and Certificate Database Path. Please note that ACS supports only server-side authentication for SSL communication with the LDAP server. The preferred way to configure secure authentication is by selecting Trusted Root CA. To use the Trusted Root CA option, you need to obtain a CA certificate from the LDAP server and install it in the ACS server as a trusted root CA (as described in Chapter 8, “IOS Switches,” in the section, “Certificate Installation on ACS.”

LDAP Configuration on Cisco Secure Access Control System 5.1

To configure LDAP on ACS 5.1, you need to navigate to Users and Identity Stores > External Identity Stores > LDAP.

Configuring LDAP on ACS 5.1 is a three-step process:

Step 1. General. In this step, you provide a name for the LDAP database or identity store instance, along with a description about this connection in the field provided as illustrated in Figure 5-11.

Figure 5-11. ACS 5.1 LDAP Identity Store Configuration; Step 1

Step 2. Server Connection. In this next step, you need to specify the connection details about the LDAP server as shown in Figure 5-12 so that ACS 5.1 can communicate with the LDAP server.

Figure 5-12. ACS 5.1 LDAP Identity Store configuration; Step 2

This section has two subsections.

• Server Connection: In this section you can configure to enable or activate your secondary server, as well as how the primary and secondary LDAP server should be contacted in the event that the primary server is not reachable.

• Primary Server & Secondary Server: In this section, you provide the IP address or hostname, port, authentication access details, root CA (if you are using secure LDAP), server timeout, and maximum admin connections.

Before proceeding toward the next step, there is a Test Bind To Server button provided at the bottom of the page to ensure that connection to primary and secondary (if any) LDAP server is successful based on the information provided in this section. Use the Test Bind To Server button to ensure that, based on the information provided, you are able to connect to the LDAP server.

If you are able to connect successfully, you should see the message Connection test bind Succeeded. In case there is some issue in establishing a successful connection, a pop-up box will appear with the possible cause.

Step 3. Directory Organization. This section is divided into four subsections as shown in Figure 5-13:

• Schema: In this section you specify the schema of the LDAP server from which you are trying to connect and retrieve information. In this section, you define Objectclass and Attribute name for Subject and Group. In this section you also specify whether Subject objects contain reference to groups or Group objects contain reference to subjects, along with how subjects in a group are stored in a member attribute. All this information needs to be collected beforehand from the LDAP administrator to ensure successful information verification or retrieval from the identity store.

• Directory Structure: In this section you define from where search should begin to search a Subject as specified by Subject Search Base, and for Group as specified by Group Search Base.

• Username PrefixSuffix Stripping: If it is required to send subject or username information to the identity store, that can be configured on this section according to need.

• MAC Address Format: If you have built a MAC address database on the LDAP server, in order to authenticate the MAC addresses you need to specify the format in which MAC address need to be searched in the LDAP identity store.

Figure 5-13. ACS 5.1 LDAP Identity Store Configuration; Step 3

Before finishing and submitting this step, ensure that you are able to retrieve the information successfully using the Test Configuration button provided for testing under the Directory Structure subsection.

If information is retrieved successfully, you should see the number of subjects and groups in the information provided in the pop-up box.

Configuring RSA SecureID

RSA SecureID provides two-factor authentication, which is one of the more secure means of authentication available today. In this two-factor authentication, the user provides a personal identification number (PIN) along with a single-use token generated from a time code algorithm. Because the token is a single-use token, it can be used only once; also, different tokens are generated at fixed intervals. Therefore, for authentication, a correct token along with a PIN need to be provided. A correct combination of both provides a higher degree of certainty that the user being authenticated is a valid user.

RSA SecureID Configuration on Cisco Secure Access Control Server 4.2

The configuration processes for RSA SecureID on ACS 4.2 for Windows and on the ACS 4.2 solution engine differ only slightly.

When configuring RSA SecureID on ACS 4.2 for Windows, you need to install the RSA ACE client on the server and the sdconf.rec file needs to be copied to the Windows directorysystem32 directory. To ensure that the server is able to communicate with the RSA SecureID server, you can test the connection from the Control Panel by running the Test Authentication utility provided in the ACE client application.

After the RSA ACE client is installed and is configured properly to communicate with RSA SecureID server, navigate to External User Databases > Database Configuration > RSA SecureID Token Server > Create New Configuration > Submit > Configure.

If everything was set up properly, you should see a message displaying the name of the RSA SecureID server and the path to the authenticator dynamic link library (DLL).

For the ACS 4.2 Solution Engine, the process of integrating RSA SecureID is even simpler. You only need to obtain the sdconf.rec file from the RSA administrator and upload it to the ACS 4.2 solution engine through a FTP server.

Navigate to External User Databases > Database Configuration > RSA SecureID Token Server, fill in the FTP server details, and select Upload sdconf.rec.

RSA SecureID Configuration on Cisco Secure Access Control System 5.1

Configuring RSA SecureID as an external identity store is very similar to the process that you followed for ACS 4.2 Solution Engine.

On ACS 5.1, navigate to Users and Identity Stores > External Identity Stores > RSA SecurID Token Servers and click on Create to create a new instance for RSA SecureID on ACS 5.1.

Provide a name to this RSA instance under the General section, and upload the sdconf.rec file provided by the RSA administrator for ACS 5.1 Server and ACS 5.1 will begin communicating with RSA SecureID for two-factor authentication.

Group Mapping

The group mapping feature in external user databases or identity stores is used to associate users to an ACS group. This can be done to create logical association to the ACS groups, but is primarily done for the purpose of assigning authorization profiles based on group membership in external databases or identity stores.

Group Mapping on Cisco Secure Access Control Server 4.2

For ACS 4.2, in the case of the TACACS+ protocol, all the authorization attributes or profiles are configured at group level or user level. If you want to assign authorization to a specific group of users based on group membership they share on an external database, you need to map that external group to an ACS group and assign authorization to that ACS group.

In the case of the RADIUS protocol, you have the option to use a Network Access Profile (NAP) where it is not necessary to configure authorization attributes for an ACS group. Authorization attributes can be assigned depending on certain conditions, however, and among those conditions, group membership can be one of the deciding factors.

With ACS 4.2, every user needs to be a part of some group, so group mapping is very essential for any user, be it ACS local, internal user, or unknown user discovered from an external database.

To configure group mapping on ACS 4.2, navigate to External User Databases > Database Group Mappings.

For a database to appear under the section Database Group Mappings, it must first be configured under the External User Databases > Database Configuration section.

An unknown user on ACS 4.2, after being discovered, is assigned a group on ACS. The process of electing a group (group mapping) is described in this section.

Before delving into the group mapping options available for different external databases, you first need to understand group mapping order. On ACS 4.2, any user known or discovered can be a part of only a single ACS group. Even if the discovered user is a member of multiple groups on external database, on ACS, the user can be associated to only a single ACS group.

Say, for instance, you have a user on Microsoft Active Directory that is a member of three groups; namely, Group01, Group02, and Group3. On ACS, you create two mappings:

• If a user is a member of Group01 and Group02, map to ACS group ACSGroup01.

• If a user is a member of Group01 and Group03, map to ACS group ACSGroup02.

The user in question satisfies both conditions. Should this user be associated with group ACSGroup01 or ACSGroup02? The user cannot be a part of both groups in ACS 4.2.

This condition is controlled and resolved by group mapping order. ACS starts at the top of the list of group mapping for the external database. It sequentially checks user group membership in the external database against each group mapping in the list. As soon as the first group set mapping match is found, ACS assigns the user to the ACS group and the group mapping process stops.

Moving back to the original user in question, if you have the ACSGroup01 mapping above ACSGroup02 mapping, the user will be mapped to ACSGroup01 and vice versa.

Figure 5-14 shows an example of External User Database (LDAP) group mapping.

Figure 5-14. ACS 4.2 Group Mapping and Group Mapping Order

Group Mapping on Cisco Secure Access Control System 5.1

ACS 5.1 provides more advanced features and flexibility when it comes to group mapping.

The external identity store option available on ACS 5.1 has LDAP, Active Directory, RSA SecurID Token Servers, and RADIUS Identity Servers.

Out of all the external identity store options available on ACS 5.1, you can achieve group mapping with three external identity stores:

• LDAP

• Active Directory

• RADIUS Identity Servers

After you have created an instance for LDAP and Active Directory on ACS 5.1, two tabs or options automatically appear in that instance configuration:

• Directory Groups

• Directory Attributes

In the case of RADIUS Identity Stores, you get Directory Attributes only.

On ACS 5.1, the group mapping option feature available is dependent on the attribute retrieval from the external identity store.

Group Mapping with LDAP Identity Stores

When you create an LDAP identity store, ACS also creates a new dictionary for that store with two attributes: ExternalGroups and IdentityDn.

A custom condition for group mapping from the ExternalGroups attribute is created; the condition name has the format LDAP ID_store_name:ExternalGroups for LDAP identity stores.

If you create policy conditions from attributes of user or subject records to be referenced in policy rules from the Directory Attributes section in the identity stores, these conditions have the format LDAP ID_store_name : attribute for LDAP identity stores.

To view or edit the customer conditions created, navigate to Policy Elements > Session Conditions > Custom.

For LDAP, to make groups available as options in the rule table for group mapping conditions, the groups need to be selected under the Directory Group section: Users and Identity Stores > External Identity Stores > LDAP > Directory Groups.

Select the groups under Selected Directory Groups column using the Add or Select option as shown in Figure 5-15. The list populated in this section will be used as option when creating the policy condition.

Figure 5-15. Directory Groups for LDAP Identity Store

Group Mapping with AD Identity Stores

When you configure an AD identity store, ACS also creates a new dictionary for that store with two attributes: ExternalGroups and IdentityAccessRestricted.

A custom condition for group mapping from the ExternalGroups attribute is created; the condition name has the following format:

AD1:ExternalGroups

If you create policy conditions from attributes of user or subject records to be referenced in policy rules from the Directory Attributes section in the identity stores, these conditions have the following format:

AD1 : attribute

To view or edit the customer conditions created, navigate to Policy Elements > Session Conditions > Custom.

For Active Directory, to make groups available as options in the rule table for group mapping conditions, the groups need to be selected under Directory Group section: Users and Identity Stores > External Identity Stores > Active Directory > Directory Groups as shown in Figure 5-16.

Figure 5-16. Directory Groups for Active Directory

Select the groups under Selected Directory Groups column using the Add or Select option. The list items populated in this section will be used as options when creating policy condition.

Group Mapping with RADIUS Identity Stores

In ACS 5.1, to the provide per-user group mapping feature for RADIUS Identity Servers identity stores, you use the attribute retrieval and authorization mechanism for users that are authenticated with a RADIUS identity store. For this, you must configure the RADIUS identity store to return authentication responses that contain the [00901] cisco-av-pair attribute with the following value:

ACS:CiscoSecure-Group-Id=N,

This is configured from Users and Identity Stores > External Identity Stores > RADIUS Identity Servers > Edit the RADIUS Identity server instance > Directory Attributes, as shown in Figure 5-17.

Figure 5-17. Directory Attributes Section for RADIUS Identity Server

N can be any ACS group number from 0 through 499 that ACS assigns to the user. Then this attribute is available in the policy configuration pages of the ACS web interface while creating authorization and group mapping rules.

Group Mapping Conditions for LDAP, AD, and RADIUS Identity Databases

After attributes have been defined and groups have been selected, you can proceed toward the final step of using these group mapping conditions. For that you need to navigate to section Access Policies > Access Services.

You can create a new Access Service or edit an existing one. To make use of the group mapping feature, you can either enable Group Mapping under Policy Structure, or you can use it under Authorization, as shown in Figures 5-18 and 5-19.

Figure 5-18. Authorization Rule Using ExternalGroups as Condition

Figure 5-19. Authorization Policy

If you have enabled Group Mapping under Policy Structure, using this policy you can associate a user in an external identity store to an ACS group based on the group membership a user has with an external identity store, as shown in Figures 5-20 and 5-21.

Figure 5-20. Group Mapping Rule Using ExternalGroups as Condition

Figure 5-21. Group Mapping Policy

Make sure that you have selected Rule based result selection under Group Mapping Policy for an Access Service. When done, you will have the option to Create a rule; in this section, you can create a rule according to the specified requirements and associate a user to a particular group on ACS. Another way to utilize the group mapping feature is under the Authorization policy. Under Authorization, you can use the ExternalGroups attribute as one of the conditions and, depending on the result, authorization can be applied.

Summary

This chapter discussed what external databases or external identity stores are and how they can be integrated with ACS 4.2 and ACS 5.1. Apart from that, you also learned the following:

• On ACS 4.2, users fall under three categories: known, unknown, and discovered users.

• On ACS 4.2, the Unknown User Policy decides how an unknown user is discovered.

• On ACS 4.2, various external database options are available: Windows User Database, Generic LDAP, ODBC, LEAP Proxy RADIUS servers, RADIUS Token Servers, and RSA SecureID.

• On ACS 5.1, you have the following external identity store options available: LDAP, Active Directory, RSA SecurID Token Server, and RADIUS Identity Store.

• On ACS 5.1, you have two methods of authentication available: certificate-based and password-based.

• You learned the individual configuration settings for Active Directory, LDAP and SecurID server on ACS 4.2 and ACS 5.1.

• Using external group membership associations, users from external databases or identity stores can be assigned different authorization attributes.

• On ACS 4.2, Group Mapping Order is important. It starts from top to bottom and terminates as soon as the first group set mapping is found.

• On ACS 5.1, external groups are identified using the ExternalGroups attribute. This attribute can be used in Access Service for the Group Mapping policy or Authorization policy as a condition.