Cisco Ise 2.4 Ad Integration

  1. Cisco Ise 2.4 Ad Integration Tutorial
  2. Cisco Ise 2.4 Active Directory Integration
  3. Cisco Ise 2.4 Ad Integration System

The purpose of this article is to demonstrate the steps to integrate Cisco ISE with a Microsoft Active Directory Domain. Our Example network is depicted below. The purpose of this blog post is to document the configuration steps required to configure Wireless 802.1x authentication on a Cisco vWLC v8.3 using Cisco ISE 2.4 as the RADIUS server. WLC Configuration Define AAA Servers Login to the WLC WebGUI Click Advanced Navigate to Security AAA RADIUS Authentication Click New Define.


This document describes how Identitity Service Enginer(ISE) and Active Directory(AD) communicate, and all the protocols that are being used. It also covers AD filters and flows.



Cisco reccomends that you have basic knowledge of :

  • ISE 2.x and Active Directory integration .
  • External identity authentication on ISE.

Components Used

  • ISE 2.x .
  • Windows Server (Active Directory) .

AD Protocols

Kerberos Protocol

The Kerberos protocol name is based on the three-headed dog figure from the Greek mythology known as Kerberos. The three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired service 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). As exemplified in Figure 1, three exchanges are involved when the client initially accesses a server resource:

  1. AS Exchange.
  2. TGS Exchange.
  3. Client/Server (CS) Exchange.
  • Domain Controller = KDC (AS + TGS).
  • Authenticate to AS (the SSO portal) with your password.
  • Get a Ticket Granting Ticket (TGT) (a la session cookie).
  • Request log in to a service (SRV01).
  • SRV01 “redirects” you to KDC.
  • Show TGT to KDC –I’m already authenticated.
  • KDC gives you TGS for SRV01.
  • “Redirect” to SRV01.
  • Show service ticket to SRV01.
  • SRV01 verifies/trusts service ticket.
  • Service ticket has all my information.
  • SRV01 logs me in.

When initially logging on to a network, users must negotiate access by providing 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 successfully authenticated, the user is granted a Ticket to Get Tickets (TGT) that is valid for the local domain. The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password. The TGT is cached on the local machine in volatile memory space and used to request sessions with services throughout the network. The following is a discussion of the TGT retrieval process.

The user presents the TGT to the TGS portion of the KDC when desiring access to a server service. The TGS on the KDC authenticates the user's TGT and creates a ticket and session key for both the client and the remote server. This information, known as the service ticket, is then cached locally on the client machine.

The TGS receives the client's TGT and reads it using its own key. If the TGS approves of the client's request, a service ticket is generated for both the client and the target server. The client reads its portion using 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 client/server exchange coming next.
below is an example when applying test user on ISE using Kerberos:

Packet captures from ISE for a user who successfully authenticated:

The AS-REQ contains the username, if password is correct the AS service provide us with a TGT encrypted with user password, and after that the TGT is provided to the TGT service to get a session ticket, once you get a session ticket then authentication is done successfully.

Below captures are for the scenario were the password given by client is wrong:

As seen if the password is wrong the AS request will fail hence, you will not get a TGT:
logs on ad_agent.log file when password is wrong:

2020-01-14 13:36:05,442 DEBUG ,140574072981248,krb5: Sending request (276 bytes) to RALMAAIT.COM for [email protected],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

MS-RPC Protocol

ISE uses MSRPC 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.

flow is as below:

  • Create an SMB session connection.
  • Transport RPC messages over SMB/CIFS.TCP port 445 as a transport
  • SMB session takes care of finding out on which port a particular RPC service runs and handles user authentication as well.
  • Connect to hidden share IPC$ for inter-process communication.
  • Open an appropriate named pipe for the desired RPC resource/function.

Transact the RPC exchange over SMB.

The negotiate protocol request/response 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 connecting to a special share IPC$, this inter-process communication share provides the means of communicating between hosts and also as a transport for MSRPC functions.

Then you are at the packet #77 where it is Create Request File and the file name is the name of the service you are connecting to, in this case it is the netlogon service.

Now you are at packets number 83 and 86, the NetrlogonSamLogonEX request is where you send the username for the client authenticating on ISE to the AD at the field Network_INFO, the NetrlogonSamLogonEX response packet reply with the result, some flags values for the

NetrlogonSamLogonEX response meaning:
0x00000000 is STATUS_SUCCESS
0x00000103 is STATUS_PENDING

ISE integration with Active Directory(AD)

ISE will use LDAP, KRB, and MSRBC to communicate with AD during the join/leave and authentication process. You will find in the next sections the protocols, searching format and the mechanism used to connect to a specific DC on AD and authenticating the users against that DC. In case the DC become offline for any reason ISE will failover to the next available DC and the authentication process will not be affected.

Join ISE to AD


Prerequisites for Integrating Active Directory and ISE

  1. Ensure you have the privileges of a Super Admin or System Admin in ISE.
  2. Use the Network Time Protocol (NTP) server settings to synchronize the time between the Cisco server and Active Directory. The maximum allowed time difference between ISE and AD is 5 minutes
  3. The configured DNS on ISE must be able to answer SRV queries for DCs, GCs, and KDCs with or without additional Site information.

Note: 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 by searching 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 using the standard AD replication service. for more information you can check https://theitbros.com/global-catalog-active-directory/

  1. Ensure that all the DNS servers can answer forward and reverse DNS queries for any possible Active Directory DNS domain you want to use.
  2. AD must have at least one global catalog server operational and accessible by Cisco, in the domain to which you are joining Cisco.

Join AD domain

Cisco Ise 2.4 Ad Integration Tutorial

First ISE will apply Domain Discovery to get information about the join domain in three phases:

  1. Queries joined domains—Discovers domains from its forest and domains externally trusted to the joined domain.
  2. Queries root domains in its forest—Establishes trust with the forest.
  3. Queries root domains in trusted forests—Discovers domains from the trusted forests.
  4. Additionally, Cisco ISE discovers DNS domain names (UPN suffixes), alternative UPN suffixes and NTLM domain names.

Then ISE will apply a DC discovery to get all information about the available DCs and GCs, and proceed as below:

  1. The join process will be started by entering the credentials of super admin on AD that exist in the domain itself. If it exists in a different domain or subdomain, the username should be noted in a UPN notation ([email protected]).
  2. ISE will send a DNS query asking for all DCs, GCs and KDCs records if DNS reply did not have one of them in its answer then the integration will be failed with DNS related error.
  3. ISE will use the CLDAP ping to discover all DCs and GCs by sending a CLDAP requests to the DCs according to their priorities in the SRV record; the first DC response will be used, and ISE will be connected to that DC. One of the factor that used to calculate the DC priority is the time taken by the DC to response to CLDAP pings; a faster response will get 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 DC's in site (If no site then all DC's in domain). The CLDAP response contains DC site and Client site (e.g. site to which ISE machine is assigned).

  1. Then ISE will get TGT with 'join user' credentials.
  2. Generate ISE machine account name using MSRPC. (SAM and SPN)
  3. Search AD by SPN if ISE machine account is already existing (e.g pre-created), if ISE machine does not exist yet ISE will create a new one (you can find brief description about the SPN and SAM in the upcoming section).
  4. Open Machine account, set ISE machine account password, and verify ISE machine account is accessible.
  5. Set ISE machine account attributes (eg. SPN, dnsHostname, etc.).
  6. Get TGT with ISE machine credentials using KRB5 and discover all trusted domains.
  7. When the join is complete, ISE node will update its AD groups and corresponding SIDS and automatically will start the SID update process. You must ensure that this process can complete on the AD side.

Leave AD domain

When ISE leave the AD below should take into considerations:

  1. You need to use a full AD admin user to perform the leave processes, this will insure that ISE machine account will be removed from the Active Directory database.
  2. If the AD was left without credentials, then the ISE account will not be removed from the AD and you have to delete it manually.
  3. When you reset ISE configuration from the CLI or restore configuration after a backup or upgrade, it performs a leave operation, disconnecting the ISE node from the Active Directory domain, if it is already joined. However, the ISE node account will not be removed from the Active Directory domain. you recommend that you perform a leave operation from the Admin portal with the Active Directory credentials because it also removes the node account from the Active Directory domain. This is also recommended when you change the ISE hostname.

DC failover

When the DC connected to ISE become offline or unreachable for any reason DC failover will triggered automatically on ISE. DC failover can be triggered by the below conditions:

Cisco ise 2.4 ad integration system
  1. AD connector detects currently selected DC became unavailable during some CLDAP, LDAP, RPC or Kerberos communication attempt. In such cases, the AD connector initiates DC selection and fails over to the newly selected DC.
  2. DC is up and responds to CLDAP ping, but AD Connector can’t communicate with it for some reason (e.g. RPC port is blocked, DC is in ‘broken replication’ state, DC has not been properly decommissioned etc.). In such cases, the AD connector initiates DC selection with a black list (“bad” DC is placed in the black list) and tries to communicate with the selected DC. Neither the DC selected with the blacklist nor the blacklist is 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 (‘tries’ means gets DC from DC selection and tries to communicate with it). ISE will blacklist AD Domain Controllers if there is an unrecoverable network or server error to prevent ISE from using a bad DC hence, reducing the proccing time and headache. Please keep in mind that DC will not be added to black list if it does not responses to CLDAP pings, ISE will only lower the priority of the DC which does not response.


ISE-AD communication through LDAP

ISE will search for machine or user in AD using one of the below searching formats, if the search was for machine then ISE will add “$” at the end of the machine name, below is a list of Identity types which will be used to identfy a user in AD:

  • SAM name: username or machine name without any domain markup, this will be the User Logon Name in AD.

Example: sajeda or sajeda$

  • CN: is the user display name on AD, it should not be same as the SAM.

Example: sajeda Ahmed.

  • User Principal Name (UPN): is a combination of the SAM name and the domain name ([email protected]).

Example: [email protected] or [email protected]

  • Alternative UPN: is an additional and/or alternative UPN suffixes that configured in the AD other than domain name. This configuration is added globally in the AD (not configured per user) and it is not necessary to be a real domain name suffix. Each AD can have multiply UPN suffix(@alt1.com,@alt2.com,…, etc).

Example: main UPN ([email protected]), alternative UPN :[email protected] , [email protected]

  • NetBIOS prefixed name: is the domain nameusername of machine name.

Example: CISCOsajeda or CISCOmachine$

  • Host/prefix with unqualified machine: this will be used for machine authentication when the machine name only is used, it will be host/machine name only

Example: host/machine

  • Host/ prefix with fully qualified machine: this will be used for machine authentication when the Machine FQDN is used, usually in case of certificate authentication, it will be host/FQDN of the machine

Example: host/machine.cisco.com

  • SPN name: The name by which a client uniquely identifies an instance of a service, e.g., HTTP, LDAP, SSH, etc. used for Machine only.

User authentication against AD flow:

  1. Resolve Identity and determine identity type - SAM, UPN, SPN etc. If ISE receive the identity as a username only, then it will search for a matching SAM account in the AD. if ISE receive the identity as a [email protected] then it will search for a matched a UPN or mail in the AD. in both scenario ISE will use additional filter for machine (computer) or username (person)
  2. Search domain or forest (depends on identity type)
  3. Keep info about all matching accounts (JP, DN, UPN, Domain etc.)
  4. If none matching account is found, then AD will reply with user is unknown.
  5. Perform MS-RPC (or Kerberos) authentication for each matching account
  6. If only single account matches to incoming identity and password, then authentication successful
  7. If multiple accounts match to incoming identity then ISE will use the password to solve the ambiguity, so that the account with a matching password will be authenticated and the other accounts will increase the incorrect password counter by 1.
  8. If none account matches to incoming identity and password, then AD will reply with wrong password.

ISE Searching Filters

Filters will be used to identify an entity that want to communicate with AD, ISE will always search for that entity in the users and machines groups,

some examples of search Filters:

  1. SAM search: If ISE receives an identity as a username only without any domain markup then ISE will treat this username as a SAM and will search in AD for all making users or machine that have that identity as a SAM name. If the SAM name is not unique then ISE will use 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.
  1. UPN or MAIL search: If ISE receive an identity as a [email protected], ISE searches each forest’s global catalogs looking for a match to that UPN identity or Mail identity “identity=matching UPN or email”. 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.
  1. NetBIOS search: If ISE receive an identity with a NetBIOS domain prefix (ex:CISCOsajedah), then ISE will search in searches the forests for the NetBIOS domain, Once found, it then looks for the supplied SAM name (sajeda in our example)
  1. Machine base search: If ISE receive a machine authentication, with the identity having a host/prefix, then ISE 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, 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 will be seen in ISE ad-agent.log files

Note: ISE 2.2 patch 4 and prior and 2.3 patch 1 and prior was identifying users using the attributes SAM, CN, or both. Cisco ISE, release 2.2 Patch 5 and above, and 2.3 Patch 2 and above, use only sAMAccountName attribute as the default attribute.


This document describes the configuration process for integration of the Identity Services Engine (ISE) pxGrid version 2.4 and Firepower Management Center (FMC) version 6.2.3.



Cisco recommends that you have knowledge of these topics:

  • ISE 2.4
  • FMC 6.2.3
  • Active Directory/Lightweight Directory Access Protocol (LDAP)

Components Used

The information in this document is based on these software and hardware versions:

  • Standalone ISE 2.4
  • FMCv 6.2.3
  • Active Directory 2012R2

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.

Configure ISE

Step 1. Enable pxGrid Services

  1. Log into the ISE Admin GUI, navigate to Administration > Deployment.

2. Select the ISE node to be used for pxGrid persona as shown in the image.

3. Enable pxGrid service and click Save as shown in the image.

4. Verify that the pxGrid services are running from the CLI.

Note: It might take up to 5 minutes for the pxGrid services to fully start and determine High Availability (HA) state if more than one pxGrid node is in use.

5. SSH into the ISE pxGrid node CLI and check the application status.

6. Access the ISE Admin GUI and verify that the services are online and working. Navigate to Administration > pxGrid Services.

7. At the bottom of the page, ISE should display Connected to pxGrid <pxGrid node FQDN> as shown in the image.

Step 2. Configure ISE to Approve all pxGrid Certificate-Based Accounts

1. Navigate to Administration > pxGrid Services > Settings.

2. Check the box: 'Automatically approve new certificate-based accounts' and click Save as shown in the image.

Note: The administrator should manually approve the FMC connection to ISE if this option is not enabled.

Step 3. Export ISE MNT Admin Certificate and pxGrid CA Certificates

1. Navigate to Administration > Certificates > System Certificates.

2. Expand the Primary Monitoring (MNT) node if not enabled on the Primary Administration node.

3. Select the certificate with the Used-By 'Admin' field.

Note: This guide uses the default ISE Self-Signed Certificate for Admin usage. If you use a Certificate Authority (CA) signed Admin Certificate you need to export the Root CA that signed the Admin certificate on the ISE MNT node.

4. Click Export.

5. Choose the option to Export Certificate and Private Key.

6. Set an encryption key.

7. Export and Save the file as shown in the image.

9. Return to the ISE System Certificates screen.

10. Determine the Issued By field on the certificate with the 'pxGrid' usage in the Used By column.

Note: In older versions of ISE, this was a self-signed certificate, but from 2.2 onwards this certificate is issued by the Internal ISE CA Chain by default.

11. Select the Certificate and click View as shown in the image.

12. Determine the top level (Root) certificate. In this case it is 'Certificate Services Root CA - tim24adm'.

13. Close the certificate view window as shown in the image.

14. Expand the ISE Certificate Authority Menu.

15. Select Certificate Authority Certificates.

16. Select the Root Certificate that was identified and click Export. Then save the pxGrid Root CA certificate as shown in the image.

Configure FMC

Step 4. Add a new realm to FMC

  1. Access the FMC GUI and navigate to System > Integration > Realms.
  2. Click on New Realm as shown in the image.

3. Fill out the form and click the Test Active Directory (AD) Join button.

Note: The AD Join Username should be in User Principal Name (UPN) format or the test fails ([email protected]).

4. If the Test AD Join is successful, click OK.

5. Click on the Directory tab and then click Add directory as shown in the image.

6. Configure IP/Hostname and Test Connection.

Note: If the Test fails, verify the credentials on the Realm Configuration tab.

7. Click OK.

8. Click the User Download tab as shown in the image.

9. If not already selected, enable user and group download

10. Click Download Now

11. Once the list populates, add desired groups and select Add to Include.

12. Save the Realm Configuration.

13. Enable the Realm State as shown in the image.

Step 5. Generate FMC CA Certificate

1. Navigate to Objects > Object Management > Internal CAs as shown in the image.

2. Click Generate CA.

3. Fill out the form and click Generate self-signed CA as shown in the image.

4. Once generation completes, click on the pencil to the right of the generated CA Certificate as shown in the image.

5. Click Download.

6. Configure and confirm the encryption password and click OK.

7. Save the Public-Key Cryptography Standards (PKCS) p12 file to your local file system.


Step 6. Extract the Certificate and Private Key from the Generated Certificate with the Use of OpenSSL

This might be done either on root of the FMC, or on any client capable of running OpenSSL commands. This example uses a standard Linux shell.

1. Use openssl in order to extract the certficate (CER) and private key (PVK) from the p12 file.

2. Extract the CER file then configure the certificate export key from the cert generation on FMC.

3. Extract the PVK file, configure the certificate export key, then set a new PEM pass phrase and confirm.

4. You will need this PEM phrase in the next step.

Step 7. Install certificate into FMC

1. Navigate to Objects > Object Management > PKI > Internal Certs.


2. Click Add Internal Cert as shown in the image.

3. Configure a name for the Internal Certificate.

4. Browse to the location of the CER file and select it. Once the Certificate Data populates, select the second.

5. Browse Option and select the PVK file.

6. Delete any leading 'Bag attributes' and any trailing values in the PVK section. The PVK should begin with -----BEGIN ENCRYPTED PRIVATE KEY----- and end with -----END ENCRYPTED PRIVATE KEY-----.

Note: You will not be able to click OK if the PVK text has any characters outside of the leading and trailing hyphens.

7. Check the Encrypted box and configure the password created when the PVK was exported in Step 6.

8. Click OK.

Step 8. Import the FMC Certificate into ISE

1. Access the ISE GUI and navigate to Administration > System > Certificates > Trusted Certificates.

2. Click Import.

3. Click Choose File and select the FMC CER file from your local system.

Optional: Configure a Friendly Name.

4. Check Trust for authentication within ISE.

Optional: Configure a Description.

5. Click Submit as shown in the image.

Step 9. Configure pxGrid Connection on FMC

1. Navigate to System > Integration > Identity Sources as shown in the image.

2. Click ISE.

Cisco Ise 2.4 Active Directory Integration

3. Configure the IP address or hostname of the ISE pxGrid node.

4. Select the + to the right of pxGrid Server CA.

5. Name the Server CA file and then browse to the pxGrid Root Signing CA collected in Step 3. and click Save.

6. Select the + to the right of MNT Server CA.

7. Name the Server CA file and then browse to the Admin certificate collected in Step 3. and click Save.

8. Select the FMC CER file from the dropdown list.

9. Click Test.

10. If the test is successful, click on OK, then Save at the top right of the screen.

Note: When you run 2 ISE pxGrid nodes, it is normal for one host to show Success and one to show Failure since pxGrid only runs actively on one ISE node at a time. It depends on the configuration whether which Primary host might display Failure and Secondary host might display Success. This is all dependent on which node in ISE is the active pxGrid node.


Verification in ISE

1. Open the ISE GUI and navigate to Administration > pxGrid Services.

If all was successful, there should be two firepower connections listed in the client list. One for the actual FMC (iseagent-hostname-33bytes), and one for the test device that was used when you clicked the Test button in FMC (firesightisetest-hostname-33bytes).

The iseagent-firepower connection should display 6 subs and appear online.

The firesightisetest-firepower connection should display 0 subs and appear offline.

Expanded view of the iseagent-firepower client should display the six subscriptions as shown in the image.

Note: Due to CSCvo75376there is a hostname limitation and Bulk Download fails. The test button on the FMC displays a connectivity failure. This affects 2.3p6, 2.4p6, and 2.6. The current recommendation is to run 2.3 patch 5 or 2.4 patch 5 until an official patch is released.

Verification in FMC

1. Open the FMC GUI and navigate to Analysis > Users > Active Sessions.

Any Active Sessions published via the Session Directory capability in ISE should be displayed in the Active Sessions table on FMC.

From the FMC CLI sudo mode, the 'adi_cli session' should display the user session information sent from ISE to FMC.


Cisco Ise 2.4 Ad Integration System

There is currently no specific troubleshooting information available for this configuration.