The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how Identitity Service Engine (ISE) and Active Directory (AD) communicate, protocols that are used, AD filters, and flows.
Cisco reccomends a basic knowledge of :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user, and the server to access.
The KDC is installed as part of the Domain Controller (DC) and performs two service functions: The Authentication Service (AS) and the Ticket-Granting Service (TGS).
Three exchanges are involved when the client initially accesses a server resource:
When initially logged on to a network, users must negotiate access and provide a log-in name and password in order to be verified by the AS portion of a KDC within their domain.
The KDC has access to Active Directory user account information. Once authenticated, the user is granted a Ticket Granting Ticket (TGT) that is valid for the local domain.
The TGT has a default lifetime of 10 hours and is renewed throughout the user log-on session without the requirement of the user to re-enter his password.
The TGT is cached on the local machine in volatile memory space and is used to request sessions with services throughout the network.
The user presents the TGT to the TGS portion of the KDC when access to a server service is needed.
The TGS on the KDC authenticates the user TGT and creates a ticket and session key for both the client and the remote server. This information (the service ticket) is then cached locally on the client machine.
The TGS receives the client TGT and reads it with its own key. If the TGS approves of the client request, a service ticket is generated for both the client and the target server.
The client reads its portion with the TGS session key retrieved earlier from the AS reply.
The client presents the server portion of the TGS reply to the target server in the next client/server exchange.
Example:
Packet captures from ISE for an authenticated user:
The AS-REQ contains the username. If the password is correct, the AS service provides a TGT encrypted with the user password. The TGT is then provided to the TGT service to get a session ticket.
Authentication is successful when a session ticket is received..
This is an example where the password given by client is wrong:
If the password is wrong the AS request fails and a TGT is not received:
Logs on the ad_agent.log file when password is wrong:
2020-01-14 13:36:05,442 DEBUG ,140574072981248,krb5: Sent request (276 bytes) to RALMAAIT.COM,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Received error from KDC: -1765328360/Preauthentication failed,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 DEBUG ,140574072981248,krb5: Preauth tryagain input types: 16, 14, 19, 2,LwKrb5TraceCallback(),lwadvapi/threaded/lwkrb5.c:1325
2020-01-14 13:36:05,444 WARNING,140574072981248,[LwKrb5GetTgtImpl ../../lwadvapi/threaded/krbtgt.c:329] KRB5 Error code: -1765328360 (Message: Preauthentication failed),LwTranslateKrb5Error(),lwadvapi/threaded/lwkrb5.c:892
2020-01-14 13:36:05,444 DEBUG ,140574072981248,[LwKrb5InitializeUserLoginCredentials()] Error code: 40022 (symbol: LW_ERROR_PASSWORD_MISMATCH),LwKrb5InitializeUserLoginCredentials(),lwadvapi/threaded/lwkrb5.c:1453
ISE uses MS-RPC over SMB, SMB provides the authentication and does not require a separate session to find where a given RPC service is located. It uses a mechanism called “named pipe” to communicate between the client and server.
Transact the RPC exchange over SMB.
The negotiate protocol request/response
line negotiates the dialect of SMB. The session setup request/response
performs the authentication.
Tree Connect Request and Response connect to the requested resource. You are connected to a special share IPC$.
This inter-process communication share provides the means of communication between hosts and also as a transport for MSRPC functions.
At packet 77 is Create Request File
and the file name is the name of the connected service (the netlogon service in this example).
At packets 83 and 86, the NetrlogonSamLogonEX request is where you send the username for the client authentication on ISE to the AD at the field Network_INFO.
The NetrlogonSamLogonEX response packet replies with the results.
Some flags values for the NetrlogonSamLogonEX response:
0xc000006a is STATUS_WRONG_PASSWORD
0x00000000 is STATUS_SUCCESS
0x00000103 is STATUS_PENDING
ISE uses LDAP, KRB, and MSRBC to communicate with AD during the join/leave and authentication process.
The next sections provide the protocols, search format, and mechanisms used to connect to a specific DC on AD and user authentication against that DC.
In the event that the DC becomes offline for any reason, ISE fails over to the next available DC and the authentication process is not affected.
A Global Catalog server (GC) is a domain controller that stores copies of all Active Directory objects in the forest.
It stores a complete copy of all objects in the directory of your domain and a partial copy of all objects of all other forest domains.
Thus, the Global Catalog allows users and applications to find objects in any domain of the current forest with a search for attributes included to GC.
The Global Catalog contains a basic (but incomplete) set of attributes for each forest object in each domain (Partial Attribute Set, PAT).
The GC receives data from all the domain directory partitions in the forest. They are copied with the standard AD replication service.
Prerequisites for Active Directory and ISE integration
ISE applies Domain Discovery to get information about the join domain in three phases:
Additionally, Cisco ISE discovers DNS domain names (UPN suffixes), alternative UPN suffixes and NTLM domain names.
ISE applies a DC discovery to get all information about the available DCs and GCs.
One factor that is used to calculate the DC priority is the time taken by the DC to response to CLDAP pings; a faster response receives a higher priority.
Note: CLDAP is the mechanism that ISE uses to establish and maintain connectivity with the DCs. It measures the response time until the first DC answer. It fails if you see no answer from DC. Warn if response time is bigger than 2.5 seconds. CLDAP ping all DCs in site (If no site then all DCs in domain). The CLDAP response contains DC site and Client site (the site to which ISE machine is assigned).
When ISE leaves, the AD must consider:
When the DC connected to ISE become offline or unreachable for any reason, DC failover is triggered automatically on ISE. DC failover can be triggered by the these conditions:
In such cases, the AD connector initiates DC selection with a blocked list (“bad” DC is placed in the blocked list) and tries to communicate with the selected DC. The DC selected in the blocked list is not cached.
AD connector must complete failover within reasonable time (or fail if it is not possible). For this reason, AD connector tries limited number of DCs during failover.
ISE blocks AD Domain Controllers if there is an unrecoverable network or server error to prevent ISE from the use of a bad DC. DC is not added to blocked list if it does not respond to CLDAP pings. ISE only lowers the priority of the DC which does not respond.
ISE searches for machine or user in AD with one of the these search formats. If the search was for a machine, then ISE adds “$” at the end of the machine name. This is a list of Identity types which is used to identfy a user in AD:
Each AD can have multiple UPN suffix(@alt1.com,@alt2.com,…, etc). Example: main UPN (sajeda@cisco.com), alternative UPN :sajeda@domain1 , sajeda@domain2
Filters are used to identify an entity that want to communicate with AD. ISE always searches for that entity in the users and machines groups.
Examples of search Filters:
If the SAM name is not unique, ISE uses the password to differentiate between users and ISE is configured to use a passwordless protocol such as EAP-TLS.
There are no other criteria to locate the right user, so ISE fails the authentication with an “Ambiguous Identity” error.
However, if the user certificate is present in Active Directory, Cisco ISE uses binary comparison to resolve the identity.
If there is a unique match, Cisco ISE proceeds with the AAA flow.
If there are multiple join points with the same UPN and a password or the same UPN and Mail, Cisco ISE fails the authentication with an “Ambiguous Identity” error.
If a fully-qualified domain suffix was specified in the identity, for example host/machine.domain.com, Cisco ISE searches the forest where that domain exists.
If the identity is in the form of host/machine, Cisco ISE searches all forests for the service principal name.
If there is more than one match, Cisco ISE fails the authentication with an “Ambiguous Identity” error.
Note: Same filters are seen in ISE ad-agent.log files
Note: ISE 2.2 patch 4 and prior and 2.3 patch 1 and prior identified users with the attributes SAM, CN, or both. Cisco ISE, release 2.2 Patch 5 and above, and 2.3 Patch 2 and higher, use only sAMAccountName attribute as the default attribute.
Revision | Publish Date | Comments |
---|---|---|
2.0 |
03-Aug-2022 |
Grammar, structure, machine translation, style, format |
1.0 |
06-Feb-2020 |
Initial Release |