AD connector selects a domain controller (DC) for a given domain as follows:
1. Performs a DNS SRV query (not scoped to a site) to get a full list of domain controllers in the domain.
2. Performs DNS resolution for DNS SRVs that lack IP addresses.
3. Sends CLDAP ping requests to domain controllers according to priorities in the SRV record and processes only the first response, if any. The CLDAP response contains the DC site and client site (for example, site to which the Cisco machine is assigned).
4. If the DC site and client site are the same, the response originator (that is, DC) is selected.
5. If the DC site and client site are not the same, the AD Connector performs a DNS SRV query scoped to the discovered client site, gets the list of domain controllers serving the client site, sends CLDAP ping requests to these domain controllers, and processes only the first response, if any. The response originator (that is, DC) is selected. If there is no DC in the client's site serving the site or no DC currently available in the site, then the DC detected in Step 2 is selected.
You can influence the domain controllers that ACS uses by creating and using an Active Directory site. See the Microsoft Active Directory documentation on how to create and use sites.
ACS also provides the ability to define a list of preferred DCs per domain. This list of DCs will be prioritized for selection before DNS SRV queries. But this list of preferred DCs is not an exclusive list. If the preferred DCs are unavailable, other DCs are selected. You can create a list of preferred DCs in the following cases:
■The SRV records are bad, missing or not configured.
■The site association is wrong or missing or the site cannot be used.
■The DNS configuration is wrong or cannot be edited.
Resolve Identity Algorithm
For an identity, different algorithms are used to locate the user or machine object based on the type of identity, whether a password was supplied, and whether any domain markup is present in the identity. Following are the different algorithms used by ACS to resolve different types of identities.
Resolving SAM Names
If the identity is a SAM name (username or machine name without any domain markup), ACS searches the forest looking for the identity. If there is a unique match, ACS determines its domain or the unique name and proceeds with the AAA flow.
If the SAM name is not unique and ACS is configured to use a password less protocol such as EAP-TLS, there are no other criteria to locate the right user, so ACS fails the authentication with an “Ambiguous Identity” error. However, if the user certificate is present in Active Directory, ACS uses binary comparison to resolve the identity.
If ACS is configured to use a password-based protocol such as PAP, or MSCHAP, Cisco continues to check the passwords. If there is a unique match, ACS proceeds with the AAA flow. However, if there is more than one account with the same password, ACS fails the authentication with an “Ambiguous Identity” error.
You should avoid username collisions. This not only increases efficiency and security but also prevents accounts from being locked out. For example, there exist two “chris” with different passwords and ACS receives only the SAM name “chris”. In this scenario, ACS will keep trying both accounts with SAM name “chris,” before deciding the correct one. In such cases, Active Directory can lock out one of the accounts due to incorrect password attempts. Therefore, you should try to use unique usernames or ones with domain markup. Alternatively, you can qualify the SAM names if you use specific network devices for each Active Directory domain.
If the identity is a UPN, ACS searches each forest’s global catalogs looking for a match to that UPN identity. If there is a unique match, ACS proceeds with the AAA flow. If there are multiple join points with the same UPN and a password was not supplied or does not help in determining the right account, ACS fails the authentication with an “Ambiguous Identity” error.
ACS also permits an identity that appears to be a UPN to also match the user’s mail attribute, that is, it searches for “identity=matching UPN or email”. Some users log in with their email name (often via a certificate) and not a real underlying UPN. This is implicitly done if the identity looks like an email address.
Resolving Machine Identities
If it is a machine authentication, with the identity having a host/prefix, ACS searches the forest for a matching servicePrincipalName attribute. If a fully-qualified domain suffix was specified in the identity, for example host/machine.domain.com, ACS searches the forest where that domain exists. If the identity is in the form of host/machine, ACS searches all forests for the service principal name. If there is more than one match, ACS fails the authentication with an “Ambiguous Identity” error.
If the machine is in another identity format, for example firstname.lastname@example.org, ACME\laptop$ or laptop$, ACS uses the normal UPN, NetBIOS or SAM resolution algorithm.
Resolving NetBIOS Identities
If the identity has a NetBIOS domain prefix, for example ACME\jdoe, ACS searches the forests for the NetBIOS domain. Once found, it then looks for the supplied SAM name (“jdoe” in this example) in the located domain. NetBIOS domains are not necessarily unique, even in one forest, so the search may find multiple NetBIOS domains with the same name. If this occurs, and a password was supplied, it is used to locate the right identity. If there is still ambiguity or no password was supplied, ACS fails the authentication with an “Ambiguous Identity” error.
Note: Cisco recommends you to use more than a 4GB RAM platform for a deployment that has more than 100,000 devices. ACS runtime crashes when you use a machine with 4GB RAM or less in a deployment that has more than 100,000 devices.
Note: Previous releases of ACS disconnects the Active Directory domain and displays the status as “joined but disconnected” in the Active Directory connection details page, when you stop the ad-client process manually from ACS CLI. But in ACS 5.8, when you stop the ad-client process manually from ACS CLI, ACS disconnects Active Directory domain and displays the status as “None” in Active Directory connection details page. If you start the ad-client process again from ACS CLI, ACS gets connected to the Active Directory domain and displays the status as “joined and connected” in AD connection details page.
Note: ACS displays the “Invalid Password” error message in ACS Reports for the following scenarios when you authenticate users and administrators against RSA Identity Server or RSA SecurID Server:
1) Invalid Password is entered
2) User is disabled in external identity store
3) User does not exists in the external identity store
Note: Authentications are not obligated to fail immediately when you disable ACS account from Active Directory domain. Authentications can work as long as there are established connections or TGT tickets. Authentications can fail with different errors based on LDAP, Kerberos or RPC depends upon which connection it is using to connect to ACS. It also depends on replication between Domain Controllers.
Note: Previous releases of ACS starts the adclient process only after joining the Active Directory domain in ACS. But, ACS 5.8 starts the adclient process soon after installing it.
Note: In ACS 5.8, you must manually join the Active Directory with ACS after upgrading ACS 5.x to ACS 5.8. See Installation and Upgrade Guide for Cisco Secure Access Control System for more information on upgrade methods.
Note: The Windows AD account, which joins ACS to the AD domain, can be placed in its own organizational unit (OU). It resides in its own OU either when the account is created or later on, with a restriction that the appliance name must match the name of the AD account.
Note: ACS does not support user authentication in AD when a user name is supplied with an alternative UPN suffix configured in OU level. The authentication works fine if the UPN suffix is configured in domain level.
Note: Administrators can perform operations the join or leave operations from the secondary server. When you perform these operations from the secondary server, it affects only the secondary server.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
Copyright © 2015-2018, Cisco Systems, Inc. All rights reserved.