cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
132796
Views
43
Helpful
19
Comments
Greg Gibbs
Cisco Employee
Cisco Employee

 

Introduction

*** NOTE: Microsoft has now renamed Azure AD to Entra ID. For all references to Azure AD in this document, the same concepts apply to Entra ID.

With many customers moving to a cloud-first strategy, it is important to understand the differences between traditional Active Directory and Entra ID and the caveats and limitations with how Cisco ISE integrates and/or interacts with these solutions. Understanding the additional value that Intune (Microsoft Endpoint Manager) can provide is also useful in many environments.

Let’s start by comparing some of the basic concepts between traditional Active Directory (On-Prem or Public Cloud) versus Entra ID.

Screenshot 2023-11-03 at 12.16.06 pm.png

 

Traditional AD Computer vs. Entra ID Device

A Windows Computer account in Active Directory is significantly different than a Windows Device in Entra ID.

The Computer account is an object created in Active Directory and used to assign Group Policy as well as perform various other operations within the domain. When a Computer joins the domain, a password is generated for that account which is rotated and synchronized with the domain every 30 days by default. This Computer account has an associated sAMAccountName, distinguishedName, objectSID, as well as various other attributes used within the domain.

Example Computer account attributes:

ad computer properties.png

 

In contrast, a Device is a basic construct in Entra ID that is created at the time of the Entra ID join operation and used for applying Configuration Profiles, Conditional Access Policies, and Compliance Policies via Intune (Microsoft Endpoint Manager). The Device account does not have an associated UPN. The main attributes used to identify the Device within Entra ID is a GUID (Globally Unique Identifier) labelled as the Entra Device ID. If the Device is managed by Intune, it will also have a GUID labelled as the Intune Device ID.

Computer accounts in traditional AD can be synchronized with Entra ID using the Entra Connect application.

The following screenshot is Entra ID’s view of the same domain computer above that was learned via the Entra Connect application.

Entra ID Device Properties.png

 

Traditional AD User vs. Entra ID User

With traditional AD, User accounts are manually created (or orchestrated) by domain administrators. Like Computer accounts, the User accounts are used to assign Group Policy as well as perform various other operations within the domain. The password is managed by the user and rotated manually based upon the requirements of the domain policy. The User account has an associated sAMAccountName, objectSID, userPrincipalName, as well as various other attributes used by the domain.

Example User account attributes:

ad user properties.png

 

With Entra ID, there are different ways that User accounts are created. Existing or new User accounts in traditional AD can be synchronized to Entra ID using the Entra Connect application. Groups created within traditional AD are also synchronized, so the group memberships associated with a User account are preserved. User accounts can also be created natively in Entra ID using multiple methods including manually via the portal or using the Entra APIs.

User accounts in Entra ID have an Object ID (unique within Entra ID) and a User Principal Name. For User accounts synchronized from Entra Connect, the User Principal Name will be the same in both Entra ID and traditional AD. Various other attributes are learned from Entra Connect, including the SAM account name and SID.

For User accounts created directly in Entra ID, the User Principal Name will end in ‘.onmicrosoft.com’ (unless another custom domain name is defined).

Example Entra ID User account synced from Entra Connect:

azureAD user basic properties.pngazureAD user on-prem properties.png

 

Example Entra ID User account created directly in Entra ID (not synced with traditional AD):

azureAD user basic properties no-sync.png

 

Windows and 802.1x Authentication with Traditional AD

When discussing 802.1x, it is important to understand that Windows computers have two distinct operating states; Computer and User.

When a Windows computer is first powered on and prior to a User logging in, Windows is in a Computer state. If network connectivity is available, a domain-joined Windows computer will attempt to communicate with the AD domain and check for any available Computer Group Policy changes.

When a User logs in, Windows will transition to the User state. If network connectivity is available, a domain-joined Windows computer will attempt to communicate with the AD domain and check for any available User Group Policy changes.
When a User logs out, Windows will again transition to the Computer state.

The state changes above are especially relevant when the Windows supplicant is enabled for 802.1x. There are three authentication modes commonly used in corporate environments using 802.1x authentication:

  • User or computer authentication
  • Computer authentication
  • User authentication

Example Windows supplicant options:

 windows supplicant dot1x auth options.png

 

With the authentication mode configured for ‘Computer authentication’ Windows will present only the Computer credential (either a Computer certificate for EAP-TLS, or a Computer hostname/password for PEAP-MSCHAPv2), regardless of whether Windows is in the Computer or User operational state.

With the authentication mode configured for ‘User authentication’ Windows will present only the User credential (either a User certificate for EAP-TLS, or a Username/Password for PEAP-MSCHAPv2), but only when Windows is in the User operational state. No credential is presented when Windows is in the Computer state, which typically means that the Computer has no authorization on the network prior to the User logging in.

With the authentication mode configured for ‘User or computer authentication’ Windows will present the Computer credential when in the Computer state. When the User logs in, a new session will be generated and Windows will present the User credential. Traditional 802.1x protocols like EAP-TLS and PEAP-MSCHAPv2 are only capable of presenting a single credential during the EAP communication, so the Computer and User sessions are not inherently related to each other.

The following diagram illustrates an example authentication flow using EAP-TLS with the supplicant configured for ‘User or computer authentication’.

 

Screenshot 2023-11-03 at 11.51.01 am.png

 

For the above example, the following screenshot shows the resulting RADIUS Live Logs in ISE.

eap-tls computer or user ise logs.png

 

TEAP authentication with Windows and Traditional AD

Windows 10 release 2004 and above supports a newer 802.1x EAP protocol called TEAP (Tunnel Extensible Authentication Protocol). TEAP is ratified by the IETF and is defined in the following RFC.
https://datatracker.ietf.org/doc/html/rfc7170

TEAP provides the ability to pass more than one credential via EAP. When used with the ‘User or computer authentication’ method, it allows the supplicant to provide both the Computer and User credentials in a single session using a feature called EAP Chaining. Cisco ISE can use this EAP Chaining result as a matching condition in the Authorization Policy rules. Like PEAP, TEAP is an outer protocol method that uses inner protocol methods such as EAP-TLS and MSCHAPv2 to provide User and/or Computer credentials that ISE can then authenticate individually against traditional AD.

When used with traditional AD, TEAP with EAP Chaining is a useful option to ensure authorization is granted for a corporate User logging into a corporate Computer.

See the following document for an example of how to configure TEAP with Windows and Cisco ISE.
https://www.ise-support.com/2020/05/29/using-teap-for-eap-chaining/

The following diagram illustrates an example authentication flow using TEAP (with an inner method of EAP-TLS) with the supplicant configured for ‘User or computer authentication’.

 

Screenshot 2023-11-03 at 11.55.06 am.png

 

For the above example, the following screenshot shows the resulting RADIUS Live Logs in ISE.

 

teap user or computer ise logs.png

 

The detailed ISE logs for the EAP Chained session reflect the EAPChainingResult of ‘User and machine both succeeded’.

ise detailed logs eapchainresult.png

 

Microsoft Intune Integration with ISE

Current versions of ISE also have the ability to integrate with Microsoft Intune (also known as Microsoft Endpoint Manager) to perform compliance checks for an endpoint. Cisco ISE version 3.1 and above support the MDM (Mobile Device Manager) APIv3. This version of the MDM API allows ISE to use a GUID (Globally Unique Identifier) value in the certificate presented by an endpoint using EAP-TLS to query the MDM vendor for compliance status. This compliance status (true/false) can then be used as a condition in the ISE Authorization Policy.

The MDM vendor must also support the Cisco ISE MDM APIv3 in leverage this feature. The following document provides information on integrating MDM and UEM (Unified Endpoint Management) systems with ISE.
Integrate MDM and UEM Servers with Cisco ISE

In addition to GUID-based lookups, the updated Microsoft Compliance Retrieval (NAC 2.0) API also supports MAC Address based lookups.

Additional information on the benefits of using the MDM APIv3 and GUID-based lookups with Intune (as opposed to MAC Address based lookups) are discussed in the following webinar on ISE Integration with Intune MDM.
YouTube - Cisco ISE Integration with Intune MDM

Please note that the Microsoft TLS Issuing CA certificates formerly used by the ISE Intune MDM integration function will expire on 27 June 2024. However, Microsoft has already completed the rotation of the certificates used for the Compliance Retrieval (NAC 2.0) API endpoints. With those changes, ISE is now only required to have the DigiCert Global Root G2 CA certificate in Trusted Certificates store for the MDM lookups to work properly.

https://techcommunity.microsoft.com/t5/intune-customer-success/intune-certificate-updates-action-may-be-required-for-continued/ba-p/1839655

 

Licensing requirements for Intune MDM integration

The Intune MDM lookups described in this blog are optional, but add an additional level of authorization for the User and Device sessions. As the Intune Registration and/or Compliance lookups are functions of the MDM Compliance feature in ISE, any sessions using these conditions will require a Premier license as per the Cisco ISE Licensing Guide.

 

Certificates and the GUID

For ISE to leverage the GUID for MDM lookups, it must be present in the certificate presented by an endpoint for EAP-TLS. ISE 3.1+ supports the GUID value present in either of the following certificate attribute fields.

  • Subject – Common Name
  • Subject Alternative Name – URI

The screenshot below shows the configuration options from the Administration > Network Resources > External MDM > MDM Servers < [server] menu in the ISE GUI. In this example, Intune is configured as an External MDM and ISE is configured to use the GUID value found in the ‘SAN URI’ field of the certificate as the Device Identifier to perform compliance checks against Intune.

 

ise mdm config.png

 

This GUID is the same value as the Intune Device ID for an endpoint that is managed by Intune. The screenshot below shows an example User certificate that includes the GUID in the SAN URI field.

 

Screenshot 2023-11-03 at 8.54.42 am.png

 

The screenshot below shows the Intune Device ID for the same endpoint in which the above User certificate is enrolled. This value is the same as the GUID shown in the certificate above.

 

Screenshot 2023-11-03 at 8.53.52 am.png

 

It is also important to note that this GUID can be present in the User certificate, Computer certificate, or both depending on how the Certificate Templates and enrollment policies (Group Policy, Intune Device Configuration Policies, etc.) are defined.

To perform device compliance checks in ISE for both Computer and User sessions, for example, the GUID would need to be present in both certificates. As the GUID relates to the Intune Device ID, the GUID value would be the same in both certificates.

 

Certificate Enrollment

As stated above, for ISE to leverage the GUID for MDM compliance checks, it must be present in the certificate. When using Intune, the GUID is inserted into the certificate at the time of enrollment by the User or Computer (or Device, in Azure terminology).

This end-to-end functionality requires the use of multiple solutions including traditional Active Directory [AD] and AD Certificate Services [ADCS] (On-Prem or in the cloud), Entra Connect, and the Intune Certificate Connector.

More information about AD Certificate Services [ADCS] can be found here:
Microsoft - Active Directory Certificate Services Overview

More information about Entra ID Connect can be found here:
Microsoft - What is Microsoft Entra Connect?

More information about the Intune Certificate Connector can be found here:
Microsoft - Certificate Connector for Microsoft Intune

The following diagram illustrates the basic flow for a Hybrid Entra Joined computer from the traditional AD join through the Intune MDM and certificate enrollment.

 

Screenshot 2023-11-03 at 11.46.34 am.png

 

The following steps occur as part of the flow illustrated above:

  1. The Computer is joined to the traditional (On-Prem or in the cloud) AD domain
  2. The Entra Connector synchronizes the Computer account with Entra ID
  3. The Computer account is assigned Group Policy to perform an automatic enrollment with the Intune MDM using the User credentials provided when the User logs in

    Example Group Policy Object:

    computer gpo for mdm enrol.png

  4. The Computer is registered with Entra ID and enrolled with Intune
  5. The pre-configured Device Configuration Profiles assigned to the User and/or Computer are pushed from Intune to the endpoint; they include (among other attributes):
    • Certificate Profiles (PKCS, SCEP, or PKCS Imported)
    • Trusted Certificate Profiles (for the Root CA chain)
    • Wired and/or Wi-Fi network Profiles (used to configure the supplicant for 802.1x)
  6. When the Certificate Profile (PKCS, in this example) is pushed to the endpoint, the enrolment is triggered
  7. As Intune cannot natively enrol a certificate, it communicates to the Intune Certificate Connector to enrol a certificate with ADCS on behalf of the Computer and/or User
  8. The Intune Certificate Connector provides the signed certificate(s) to Intune, which then pushes the certificate(s) to the endpoint, completing the enrolment

The combination of Intune and the Intune Certificate Connector is required in the flow described above as ADCS would otherwise have no knowledge of the Intune Device ID that must be inserted in the certificate as the GUID value.

The following screenshot shows an example PKCS User Certificate Profile used by the flow described above. The resulting enrolled certificate will have the following attributes:

  • Subject CN = username of the enrolled user
  • SAN URI = GUID string value used to insert the Intune Device ID

 

intune pkcs user cert profile.png

 

A similar certificate enrollment is also possible with Devices that are only Entra Joined (not a Computer joined to traditional AD). In that case, all components illustrated in the flow above would still be required except the traditional AD and Entra Connect.

The diagram below illustrates the basic flow for an Entra Joined Device.
 
 
Screenshot 2023-11-03 at 11.46.52 am.png
 

ISE Authentication Flow with Traditional AD & Intune MDM Compliance

With a Computer that is joined to traditional AD and enrolled with Intune (including the certificate enrolment with the GUID inserted), ISE can perform an MDM Compliance check as a condition for authorization. As the Compliance check requires the GUID as a Device Identifier, the authentication must use EAP-TLS to provide the GUID to ISE via the certificate. Either the traditional EAP-TLS or TEAP with an inner method of EAP-TLS [TEAP(EAP-TLS)] can be used for the authentication.

The following diagram illustrates the flow for a Hybrid Entra Joined Computer using TEAP(EAP-TLS) and configured for ‘User or Computer authentication’ mode with EAP Chaining. The flow includes both an EAP Chaining result of ‘User and computer both succeeded’ and an MDM Compliance check against Intune as conditions for Authorization.

 

Screenshot 2023-11-03 at 11.57.32 am.png

 

The screenshot below shows an example of ISE Authorization Policies related to the flow illustrated above. The policies are for a Wired endpoint using TEAP(EAP-TLS) with ‘User or Computer authentication’ mode and EAP-TLS and include the MDM Compliance check. Active Directory Group membership is also used as an Authorization condition for both the Computer and User sessions.

 

ise authz policy teap mdm.png

 

The following screenshot shows the ISE RADIUS Live Logs related to the above flow. The logs indicate authentication via TEAP(EAP-TLS) and include the GUID presented to ISE within both the Computer and User certificates.

 

ise live logs teap guid.png

 

Authentication/Authorization with ISE and Entra ID

When authenticating a User or Computer against traditional AD, ISE performs the lookups using traditional methods such as LDAP or Kerberos (depending on how ISE is configured to integrate with AD). Entra ID, however, does not directly support these traditional protocols. Due to these limitations, ISE can only integrate with Entra ID to authenticate and/or authorize a User using two methods (at the time of this writing); REST ID (supported from ISE 3.0) or EAP-TLS (supported from ISE 3.2).

 

Authentication with Entra ID via REST ID

ISE REST ID functionality is based on the new service introduced in ISE 3.0 - REST Auth Service. This service is responsible for communication with Entra over Open Authorization (OAuth) ROPC exchanges in order to perform user authentication and group retrieval.

For more information on how to configure ISE authentication against Entra ID using REST ID, see the following link.
Configure ISE 3.0 REST ID with Azure Active Directory

Authentication using REST ID is supported for Wired, Wireless, and Remote Access VPN connectivity. The authentication is performed using EAP-TTLS with an inner method of PAP and this option has the following caveats/limitations.

  • Computer authentication is not possible as there is no Device credential/password concept in Entra ID
  • The User is prompted for their credentials when connecting to the network; this can adversely impact the user experience, especially for Wired and Wireless connections
  • Intune MDM Compliance checks are not possible since there is no certificate presented to ISE with the GUID

 

User Authorization with Entra ID and EAP-TLS

ISE 3.2 introduced a new feature in which ISE can perform Authorization for an EAP-TLS User session using Entra ID user group membership as a condition. The ISE REST ID Service described above is also used to perform the lookup of group membership and other attributes associated with the Entra ID user using the Microsoft Graph API. Since the endpoint is authenticating via EAP-TLS using the User certificate, the GUID can be presented to ISE and MDM Compliance status can be used as a condition for Authorization.

For more detail on configuring ISE and Entra ID for authorization against Entra ID (not including the Intune integration), see the following link.
Configure ISE 3.2 EAP-TLS with Microsoft Azure Active Directory 

The following diagram illustrates the flow for an endpoint configured for EAP-TLS with ‘User authentication’ mode. Both the Entra ID group membership and Intune Compliance status are used as conditions for Authorization.

Screenshot 2023-11-03 at 11.47.44 am.png

In this flow, it is important to understand that ISE is not capable of performing Authentication against Entra ID. The Authentication in this case is only based on the client presenting a valid User certificate that is trusted by ISE. The User credential provided within the certificate is not checked against any Identity Store, which could raise security concerns with some organizations.

This flow has the following caveats and limitations:

  • A minimum of ISE 3.2 is required to perform the Group/Attribute lookup using REST ID as a condition for authorization
  • Computer authentication is not possible as there is no Device credential/password concept in Entra ID
  • The User Principal Name (UPN) must be used in either the Certificate ‘Subject – Common Name’ or ‘Subject Alternative Name’ field
  • The ISE Certificate Authentication Profile (CAP) used for Authentication must be configured to use the field with the UPN for the identity
  • TEAP(EAP-TLS) and EAP Chaining is supported for this flow from ISE 3.2 patch 5 and ISE 3.3 patch 1 due to the fix implemented by bugID CSCwd34467 

 

Example User Certificate with the UPN in the ‘Subject – Common Name’ field:

user cert upn.png

 

Example Entra ID User with UPN:

azure user upn.png

 

The following screenshot shows an example of a Certificate Authentication Profile configuration used for the above flow.

 

ise cap noad.png

 

The following screenshot shows an example Authentication Policy used for this flow. This policy uses values in the Certificate ‘Subject – CN’ and ‘Issuer – CN’ as matching conditions to differentiate from sessions using other Authentication methods. The ‘Subject – CN’ is matching on the suffix used by the User UPN (@trappedunderise.onmicrosoft.com).

 

ise authc policy azure eap-tls.png

 

The following screenshot shows an example Authorization Policy used for this flow. The policy uses similar matching conditions to those used in the Authentication Policy in addition to the Entra ID group membership and MDM Compliance status conditions.

 

ise authz policy azure eap-tls.png

 

The following screenshot shows the ISE RADIUS Live Logs related to the above flow.

 

ise live logs eap-tls guid.png

 

User Attributes from Entra ID

As of ISE 3.2 patch 4 (at the time of this writing), the following 44 Entra ID User Attributes can be added in ISE to be used in Authorization conditions for the 'User Authorization with Entra ID and EAP-TLS' flow described above.

 

country passwordPolicies
onPremisesDistinguishedName state
preferredLanguage preferredName
mySite department
isResourceAccount showInAddressList
mail userPrincipalName
city mailNickname
displayName givenName
companyName employeeId
jobTitle ageGroup
postalCode onPremisesSecurityIdentifier
legalAgeGroupClassification creationType
preferredDataLocation employeeType
accountEnabled mobilePhone
aboutMe streetAddress
externalUserState onPremisesImmutableId
onPremisesSyncEnabled onPremisesDomainName
onPremisesUserPrincipalName faxNumber
officeLocation securityIdentifier
surname usageLocation
deviceEnrollmentLimit userType
onPremisesSamAccountName consentProvidedForMinor

 

More details on configuring and troubleshooting the REST ID integration leveraged by this use case can be found in the following document.
Configure Cisco ISE 3.2 EAP-TLS with Microsoft Azure Active Directory 

 

Authentication/Authorization of an Entra Joined Device using EAP-TLS

Since first publishing this article, I've been asked by multiple peers and customers if similar flows can be used to authenticate/authorize a pure Entra Joined Device using EAP-TLS and a certificate enrolled by Intune.

The following diagram illustrates the flow that can be used to authenticate and authorize an Entra Joined Device when it is in the Computer state.

Screenshot 2023-11-03 at 11.49.11 am.png

This flow has the following caveats and limitations:

  • Authentication is based purely on a valid/trusted certificate presented by the client
  • The Device credential is not Authenticated against any Identity Store
  • TEAP(EAP-TLS) and EAP Chaining is supported for this flow from ISE 3.2 patch 5 and ISE 3.3 patch 1 due to the fix implemented by bugID CSCwd34467
  • Authorization is based only on the trusted certificate and (optional) Intune compliance
  • For Intune compliance (optional), the certificate used for the Computer state must be enrolled via an Intune Configuration Profile (Device certificate) so the GUID is present in the SAN field.
  • As there is no interaction with Entra ID, this specific flow can technically be used with ISE version 3.1 and above.

The following screenshot shows an example Authentication Policy used for this flow. This policy uses values in the Certificate ‘Subject – OU’ and ‘Issuer – CN’ as matching conditions to differentiate from sessions using other Authentication methods or EAP-TLS flows not involving Entra ID. The ‘Subject – OU’ attribute is a unique static value defined in the Intune Configuration Profile to provide this differentiation. The same Certificate Authentication Profile described above was used for this flow, so a single Authentication Policy will serve both the User and Computer (Device) flows.

aad_user_device_eap-tls_authC_policy.png

Example Intune Device PKCS Profile with OU:
intune_pkcs_profile_device_ou.png

 

The following screenshot shows an example Authorization Policy used for this flow as well as the above User flow. The policy uses similar matching conditions to those used in the Authentication Policy in addition to the MDM Compliance status conditions.

aad_user_device_eap-tls_authZ_policy.png

The following image shows example Live Logs from ISE 3.2 for an Entra Joined Device that is configured for EAP-TLS with 'User or computer authentication' using the User and Device Entra ID flows described above.

aad_user_device_eap-tls_live_logs.png

It is important to reiterate that the Device credential is not validated by any Identity Store and the Compliance state is checked using the GUID presented in the Device certificate.

If the Device certificate is somehow compromised, the GUID will also be compromised. This could allow a threat actor to gain network access using the certificate. In the event of a lost device and/or a compromised certificate, the Device should be retired or deleted from Intune immediately and the certificate should be revoked.

 

Entra Joined Device and Entra User with TEAP(EAP-TLS) and EAP Chaining

Due to the fix implemented by bugID CSCwd34467 in ISE 3.2 patch 5 and 3.3 patch 1, it is now possible to use the TEAP protocol and EAP Chaining feature described above for authorization of sessions involving Entra Joined Devices (not joined to Traditional AD) and Entra ID user accounts. The EAP Chaining results can be combined with other conditions described above (i.e. User Group/Attribute matches, Intune Registration/Compliance status) in the Authorization Policy.

The following diagram illustrates the flow that can be used for both the Device and User sessions in this use case.

Screenshot 2024-06-06 at 8.08.45 AM.png

As with the use cases described above, it is important to understand that ISE is not capable of performing Authentication against Entra ID for either the Device or User. The Authentication in this case is only based on the client presenting a valid User and Device certificate that is trusted by ISE. The User credential provided within the certificate is not checked against any Identity Store, which could raise security concerns with some organizations.
For the User session, the same Group and Attribute match conditions are supported as per the above use case with EAP-TLS

This flow has the following characteristics, caveats, and limitations:

  • A minimum of ISE 3.2 patch 5 or 3.3 patch 1 is required for support of the REST ID lookup and the bug fix
  • The Windows supplicant is configured for 'User or Computer Authentication' with the necessary TEAP(EAP-TLS) protocol settings
  • Use of Intune Registration/Compliance status as a condition of Authorization for either the Device and/or User session (which is optional) requires those certificates to be enrolled via an Intune Configuration Profile (Device/User certificate) so the GUID is present in the SAN field.
  • If User Group/Attribute conditions are used in the Authorization Policy (which is optional), the User Principal Name (UPN) must be used in either the Certificate ‘Subject – Common Name’ or ‘Subject Alternative Name’ field for the User certificate and the ISE Certificate Authentication Profile (CAP) used for User Authentication must be configured to use the field with the UPN for the identity

The following screenshot from ISE 3.3 patch 2 shows an example Authentication Policy used for this flow. This policy uses values in the Certificate ‘Subject – OU’ as a matching condition to differentiate from sessions using TEAP(EAP-TLS) with Traditional AD. The ‘Subject – OU’ attribute is a unique static value defined in the Intune Configuration Profile for both the Device and User certificate to provide this differentiation.

Screenshot 2024-06-06 at 9.09.10 AM.png

 

The following screenshot shows example Authorization Policies used for the User and Device sessions. The policy uses similar matching conditions to those used in the Authentication Policy in addition to the (optional) MDM Compliance status conditions for both the User and Device as well as a Group match for the User account in Entra ID (also optional).

Screenshot 2024-06-06 at 8.54.30 AM.png

 

The following image shows example Live Logs from ISE 3.3 patch 2 for the flow described in this use case.

Screenshot 2024-06-06 at 9.28.39 AM.png

As with the above examples, it is important to reiterate that neither the Device nor User credential is not authenticated by any Identity Store and the Compliance state is checked using the GUID presented in the certificate.

If the certificate is somehow compromised, both the Entra ID UPN and the GUID will also be compromised. This could allow a threat actor to gain network access using the certificate. In the event of a lost device and/or a compromised certificate, the Device should be retired or deleted from Intune immediately and the certificates should be revoked.

 

Entra Joined Device and AD User with TEAP(EAP-TLS) and EAP Chaining

Due to the fix implemented by bugID CSCwd34467 in ISE 3.2 patch 5 and 3.3 patch 1, it is also now possible to use the TEAP protocol and EAP Chaining feature described above for authorization of sessions involving Entra Joined Devices (not joined to Traditional AD) and Traditional Active Directory User accounts using TEAP(EAP-TLS). The EAP Chaining results can be combined with other conditions described above (i.e. User Group/Attribute matches, Intune Registration/Compliance status) in the Authorization Policy.

The following diagram illustrates the flow that can be used for both the Device and User sessions in this use case.

Screenshot 2024-06-07 at 12.23.26 PM.png

This flow has the following characteristics, caveats, and limitations:

  • A minimum of ISE 3.2 patch 5 or 3.3 patch 1 is required for the bug fix
  • The Windows supplicant is configured for 'User or Computer Authentication' with the necessary Computer and User TEAP(EAP-TLS) protocol settings
  • While not shown in this example, use of Intune Registration/Compliance status as a condition of Authorization is also supported as reflected in the above use cases

 The following screenshot from ISE 3.3 patch 2 shows example Authentication Policies used for this flow. For the User session, and Identity Source Sequence (ISS_AD_Cert) is used to capture the AD Username from the certificate Subject Common Name to use for identity and check that Username against Active Directory.

Screenshot 2024-06-07 at 12.28.19 PM.png

 

The following screenshot shows example Authorization Policies used for the User and Device sessions. The policy uses similar matching conditions to those used in the Authentication Policy in addition to the (optional) MDM Compliance status conditions for both the User and Device as well as a Group match for the User account in AD.

Screenshot 2024-06-07 at 12.32.27 PM.png

 

As with the above examples, the Device credential is not validated by any Identity Store and the Compliance state is checked using the GUID presented in the Device certificate.

If the Device certificate is somehow compromised, the GUID will also be compromised. This could allow a threat actor to gain network access using the certificate. In the event of a lost device and/or a compromised certificate, the Device should be retired or deleted from Intune immediately and the certificate should be revoked.

 

Entra Joined Device with TEAP(EAP-TLS) and AD User with TEAP(MSCHAPv2) and EAP Chaining

Due to the fix implemented by bugID CSCwd34467 in ISE 3.2 patch 5 and 3.3 patch 1, it is also now possible to use the TEAP protocol and EAP Chaining feature described above for authorization of sessions involving Entra Joined Devices (not joined to Traditional AD) and Traditional Active Directory User accounts using a combination of TEAP(EAP-TLS) and TEAP(EAP-MSCHAPv2). The EAP Chaining results can be combined with other conditions described above (i.e. User Group/Attribute matches, Intune Registration/Compliance status) in the Authorization Policy.

The following diagram illustrates the flow that can be used for both the Device and User sessions in this use case.

Screenshot 2024-06-06 at 11.12.41 AM.png 

This flow has the following characteristics, caveats, and limitations:

  • A minimum of ISE 3.2 patch 5 or 3.3 patch 1 is required for the bug fix
  • The Windows supplicant is configured for 'User or Computer Authentication' with the necessary Computer TEAP(EAP-TLS) and User TEAP(MSCHAPv2) protocol settings
  • While not shown in this example, use of Intune Registration/Compliance status as a condition of Authorization is also supported as reflected in the above use cases
  • Use of MSCHAPv2 (in the User session for this example) requires disabling Credential Guard
  • The user must login to Windows using their AD password; they cannot use Windows Hello logins with MSCHAPv2 authentication as ISE needs the username and password from the Windows supplicant to authenticate the User against AD.

The following screenshot from ISE 3.3 patch 2 shows example Authentication Policies used for this flow.

Screenshot 2024-06-06 at 11.36.35 AM.png

 

The following screenshot shows example Authorization Policies used for the User and Device sessions. The policy uses similar matching conditions to those used in the Authentication Policy in addition to the (optional) MDM Compliance status conditions for both the User and Device as well as a Group match for the User account in AD.

Screenshot 2024-06-06 at 11.40.02 AM.png

 

The following image shows example Live Logs from ISE 3.3 patch 2 for the flow described in this use case.

Screenshot 2024-06-06 at 11.41.53 AM.png

 

As with the above examples, the Device credential is not validated by any Identity Store and the Compliance state is checked using the GUID presented in the Device certificate.

If the Device certificate is somehow compromised, the GUID will also be compromised. This could allow a threat actor to gain network access using the certificate. In the event of a lost device and/or a compromised certificate, the Device should be retired or deleted from Intune immediately and the certificate should be revoked.

 

Entra ID Multi-User Scenario

After some additional discussions with customers, it was determined that the above flow would be relevant for a scenario in which multiple Entra ID Users needed to login to the same Entra Joined Device. When a new Entra ID User logs into an Entra Joined Device, the Windows OS (not the supplicant) must authenticate the credentials against Entra ID. This process happens during the Windows Computer state, therefore network connectivity in this state is required.

Upon successful authentication of the new user, the User's profile is loaded and the desktop is presented. It is important to note, however, that the Intune User Certificate Profiles are not installed immediately as part of the Windows User Profile. If the supplicant is configured for 'User or Computer Authentication' it will attempt to initiate an 802.1x session for the new User. Since there is no User certificate installed yet, this will result in an authentication failure. This results in a 'catch-22' scenario in which there is no network connectivity due to the lack of User certificate, and the User certificate cannot be enrolled due to lack of network connectivity.

The following diagram illustrates the flow and 802.1x failure described in this scenario.

Screenshot 2023-11-03 at 11.48.28 am.png

As such, the supplicant should be configured for 'Computer Authentication' for this multi-user scenario to mitigate the User authentication failure. However, this will result in the inability to provide differentiated authorization for the users using this Computer. As the User credential is not being provided by the supplicant, this will also result in no visibility of the User associated with this session.

 

Mixed Entra Joined Device & Traditional AD User Scenario with EAP-TLS

Depending on the current state of the Entra ID and Traditional AD environment, a combination of the above flows is also possible. Take the following scenario, for example:

  • Windows 10 PCs joined to the organisation's Traditional AD domain
    • Currently using TEAP(EAP-TLS) with EAP Chaining
    • Certificates enrolled using Group Policy
  • Corporate AD User accounts synchronised with Entra ID

  • Windows 11 PCs being deployed
    • Entra ID Joined (not Hybrid or joined to Traditional AD)
    • Intune Managed
    • Certificates enrolled using Intune; unique Subject OU used in the template to provide differentiation in ISE policies

 

The following diagram illustrates the flow used for this scenario.

Screenshot 2023-12-11 at 5.08.43 pm.png

 

This flow has the following caveats and limitations:

  • Windows supplicant configured for EAP-TLS with 'User or Computer' authentication
  • Device Authentication is based purely on a valid/trusted certificate presented by the endpoint
  • User Authentication is performed against the organisation's Traditional AD
  • Device Authorization is based only on the trusted certificate (with Subject OU = IntuneDevice) and (optional) Intune compliance
  • User Authorization is based on AD Group membership, the certificate Subject OU (IntuneUser) and (optional) Intune compliance
  • For Intune compliance, the certificate used for the both the User and Computer state must be enrolled via an Intune Configuration Profile so the GUID is present in the SAN field.
  • As there is no interaction with Entra ID, this specific flow can technically be used with ISE version 3.1 and above.

 

The following screenshot shows an example Authentication Policy used for this flow. This policy uses values in the Certificate ‘Subject – OU’ as a matching condition to differentiate from the current Windows 10 sessions using TEAP(EAP-TLS). The ‘Subject – OU’ attribute is a unique static value defined in the Intune Configuration Profile to provide this differentiation.

 

Screenshot 2023-12-19 at 10.30.20 am.png

 

The following screenshot shows an example Authorization Policy used for this flow. The policy uses similar matching conditions to those used in the Authentication Policy in addition to the MDM Compliance status conditions.

 

Screenshot 2023-12-19 at 10.36.48 am.png

 

The Intune compliance check is used for both the Computer and User session. This was done to provide for the scenario in which a User is already logged in when the Windows 11 endpoint is connected to the network. In that scenario, there would be no Computer session involved unless/until the User logs out.

 

Summary

The following table summarises the available options at the time of this writing for Computer/User Authentication and Intune MDM Compliance with ISE when using Traditional AD versus Entra ID.

Screenshot 2024-06-06 at 11.52.19 AM.png

Comments
Romzy
Cisco Employee
Cisco Employee

Brilliant doc @Greg Gibbs;

Attaching the config & troubleshoot guide for EAP-TLS with Azure.

kmorris78
Level 1
Level 1

I have AzureAD joined machines that I want to be able to connect to our network. Does this mean I still need an AD CS to create the certificate that the end user client will present to ISE in order to authenticate via EAP-TLS?

Andreas Foerby
Level 1
Level 1

@kmorris78 I have used SCEPman in several AzureAD w. Intune deployments to issue certificates to the devices. It works like a charm.

Just remember to include the devicename as Subject Alternative Names in the certificates, and then use "SAN" as the identity in ISE - otherwise you will get the UUID as identity which make it a bit harder to locate the correct device(s) when troubleshooting or going through the RADIUS Live Log. 

Jason Mauai
Level 1
Level 1

I have not found any specific valid reason for an Azure AD Joined Device would require connectivity to the corporate network in the Computer state”

 

What about for unattended remote access? Or is it not common practice to AADJ a device that’s always on the corporate network?

Greg Gibbs
Cisco Employee
Cisco Employee

@Jason Mauai, what or whom would need unattended remote access and for what reasons? If the company is moving everything to Azure AD as part of a cloud-first (or cloud-only) strategy, wouldn't all of the tools used for management of the PC also be cloud-based? If so, those management operations could be done when the PC has any internet connection (home, hotspot, etc).

I'm not aware of any organisations these days where users leave their laptops locked up and connected to the network in the office, and you wouldn't likely have permanent desktops that were AADJ sitting in the office.

If your organisation does have some specific requirement for this unattended remote access, can you share that information?

Jason Mauai
Level 1
Level 1

@Greg Gibbs totally agree with you on the laptops. I was mainly referring to permanent desktops in office, but we're also new to cloud-only AADJ so I wasn't sure if AAD joining permanent office desktops was a thing.

P333EVS1
Level 1
Level 1

excellent article thanks for the info.

I have a question. We are in the process of linking our Cisco ISE 3.1 (patch 5) with Intune/Azure AD. We are in a shared Tenancy so i have no access to Intune or Azure to configure what we need, but that is getting sorted.

Is it possible to query an Intune Scope group? for example what I am trying to do is Wireless auth based on if the device is in a scope group and the user authenticates using mschap then its a corp device and corp user - give access to our corp network.

then if the device isnt in a scope group but user authenticates using mschap then BYOD device and corp user give access to restricted wireless.

Because i havent got Cisco ISE linked with Intune yet I cant visualise what i need. Or is Cisco ISE only able to query - does device exist in Intune yes/no?

ipagliani
Level 1
Level 1

Ciao,

what a fantastic article !!! I tested in my lab the scenario. Thanks yoo for sharing.

I have a question regarding Anyconnect VPN integration: In order to test it with Intune do I need to authenticate the client with certificate and then use the GUID for lookup ? Is it right ? 

What I need is to validate that the client is managed by intune.

Grazie

akusimo
Cisco Employee
Cisco Employee

If I'm authentication devices joined to Azure AD using certificate, since authentication of the devices via AAD is not possible, can ISE still perform certificate validation using OSCP/CRL (if configured) during authentication?

 

 

 

 

hslai
Cisco Employee
Cisco Employee

@akusimo Yes, ISE authenticates the client certificates based on the certificates and settings in its trusted certificates.

Greg Gibbs
Cisco Employee
Cisco Employee

@ipagliani, with certificate-based VPN connections, the VPN headend terminates the SSL tunnel. ISE only sees a RADIUS request with the PAP protocol from the VPN headend, so it will never see the certificate. As such, ISE cannot perform GUID-based MDM compliance checks for VPN connections at this time.

See the following link shared above in the document for limitations/guidance related to VPN connections.
https://www.cisco.com/c/en/us/support/docs/field-notices/724/fn72427.html

 

Greg Gibbs
Cisco Employee
Cisco Employee

Questions on this page are getting difficult to track. For any further questions, please open a new community post and reference this document as background.

oron.yaniv
Level 1
Level 1

Hi @Greg Gibbs , wonderful article.
question if I may:

today we are using EAP-PEAP (MSCHAPv2) with Windows native supplicant (Machine Auth).
for compliancy, we are using the Anyconnect posture module.

we are looking to integrate Intune as an MDM (for MacOS and Windows machines), for authentication and compliancy.
for windows machines, we did not decided yet if the authentication part will be against on-prem AD or intunes, however, we want to replace Anyconnect with Intune compliancy. so the decision, if an endpoint is compliant/not compliant, will reach from intune attribute.

so, the question is for the authentication part (maybe its influenced by the needs of compliance from Intunes), I saw from the last table you shared in the article that only EAP-TLS / GUID is supported to as a query method between ISE and Intune.

so, do we need to change the authentication method from EAP-MSCHAPv2 to EAP-TLS on windows machines?

 

thanks,

 

Greg Gibbs
Cisco Employee
Cisco Employee

@oron.yaniv... yes, you would need to authenticate the Windows computers (and/or Users) using EAP-TLS.

oron.yaniv
Level 1
Level 1

@Greg Gibbs  thank you.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: