Session Overview: Join us for a comprehensive six-part series designed to transform how you approach application onboarding. By treating your deployment workflow as a "speedrun", we provide the essential tactics to cut through technical complexity, s...
Site-to-Site IKEv2 IPSec VPN Implementation Introduction IKEv2 Proposal IKEv2 Policy IKEv2 Keyring IKEv2 Profile Crypto MAP Verification Introduction IPSec VPNs would normally use I...
Installation, Deployment & Initial Setup Configure Firewall for Secure Web Appliance Install Secure Web Appliance on Microsoft Hyper-V Install Secure Web Appliance on VMware ESXi Secure Web Appliance Initial Setup Use Secure Web Appliance Best Practi...
Date/Time: Thursday, May 28th, 2026 from 12:00 PM - 1:30 PM EDTOverview: Universal Zero Trust Access (ZTA) is a security framework that enforces consistent "never trust, always verify" policies for all users and devices, regardless of their location ...
Date/Time: Wednesday, May 20th, 2026 from 11:00 AM - 2:00 PM EDTOverview: Join our webinar series to discover how strategic Cisco Secure Firewall integrations can transform your security operations. We will begin by exploring how integrating Secure F...
Implementing IKEv2 VRF aware SVTI Introduction Lab Topology IKEv2 vrf Configuration Verification Introduction A Frontdoor VRF (FVRF) is called internet can be defined on the ou...
OverviewThis guide walks through deploying Cisco Secure Client to Windows endpoints using Microsoft Configuration Manager (SCCM). It leverages the pre-deployment package method to enable a fully silent installation, without requiring any user interac...
With the increasing popularity of IPSec VPN deployments on the Internet, there is often a need to understand the exact IPSec and other tunnel encapsulation overhead in order to determine the fragmentation boundary conditions for optimal MTU/MSS tunin...
Deploying Cisco Secure Client on macOS via MDM/EMM Using the Headend Deployment PackageOverview When deploying Cisco Secure Client on Windows via MDM/EMM, administrators use the Pre-Deployment Package — it contains the individual MSI files that MDM p...
Organizations managing Cisco Identity Services Engine environments typically evolve through several stages of operational maturity.Understanding these stages helps organizations identify where they are today and what improvements are needed to reach ...
Preface Part 1 Introduction Log Analytics Time Window Banners Basic Information War Room - Predict and Prevent RADIUS Timelion RADIUS Top Talkers Top Authentication Protocol Load Balancer - Analysis and Investigation RADIUS by ISE Server Unauthorized...
Introduction Summary Workaround Affected Products & Fixed Software References The Portuguese version of this Article can be found at: Vulnerabilidade que afeta o Cisco ISE (CVE-2026-20147 & 20148) . For an offline or printed cop...
Introduction Summary Workaround Affected Products & Fixed Software References The Portuguese version of this Article can be found at: Vulnerabilidade que afeta o Cisco ISE (CVE-2026-20180 & 20186) . For an offline or printed copy...
Introduction Summary Workaround Affected Products & Fixed Software References The Portuguese version of this Article can be found at: Vulnerabilidade que afeta o Cisco ISE (CVE-2026-20136) . For an offline or printed copy of this ...
Introduction Summary Workaround Affected Products & Fixed Software References The Portuguese version of this Article can be found at: Vulnerabilidade que afeta o Cisco ISE (CVE-2026-20132) . For an offline or printed copy of this d...
Linked at https://cs.co/ise-autopilot
For an offline or printed copy of this document, simply choose ⋮ Options > Printer Friendly Page.
You may then Print, Print to PDF or copy and paste to any other document format you like.
With the rollout of Windows 11 for managed fleets, many customers are transitioning from traditional on-premises deployment models, such as Configuration Manager, to cloud-based solutions like Windows Autopilot. In environments utilizing Network Access Control (NAC) solutions, like Cisco Identity Services Engine (ISE), to restrict network access to authenticated and authorized endpoints, it is essential to understand the associated limitations, constraints, and process flows.
This document aims to provide detailed information on these flows, along with guidance and options for ensuring the necessary network access to complete the build processes. The information herein is based on various testing and analysis performed in a lab environment.
Microsoft Autopilot is a suite of tools designed to simplify and automate the deployment and management of new Windows 10 and Windows 11 devices. It allows IT departments to configure devices from the cloud, reducing the complexity and time involved in setting up new hardware.
Key Features:
Benefits:
More information on Windows Autopilot can be found at the following link:
https://learn.microsoft.com/en-us/autopilot/
At the time of this writing, Microsoft defines the following different Autopilot solutions:
The former solution (Windows Autopilot device preparation) only supports a user-driven mode, while the latter (Windows Autopilot) supports the following modes:
A comparison between the different Autopilot solutions can be found at the following link:
https://learn.microsoft.com/en-us/autopilot/device-preparation/compare
While the Windows Autopilot device preparation solution is the more recent solution released by Microsoft, it only offers a user-driven mode. From my experience, most Enterprise customers I have worked with still favour the Pre-provisioned mode, which gives the IT organization greater control over the initial stages of the build process.
As such, this document will focus mainly on the details and constraints around the Windows Autopilot Pre-provisioned mode with Entra Joined (not Hybrid Joined) Windows 10/11 devices.
As stated in the Microsoft documentation referenced above, all Autopilot solutions except for the Autopilot device preparation method require a prior step of device registration. This device registration involves uploading the device hash to the customer’s Intune tenant which is typically done by the OEM vendor from which the Windows computer was purchased.
The hash can also be exported from an existing system and imported into Intune via CSV file. See the following document for information on this procedure.
Manually register devices with Windows Autopilot
The hardware hash contains various details about the device, but MAC Address information for Wired/Wireless interfaces is not included currently and there appear to be no plans to do so.
For more information about the hardware hash, see the following link:
Demystifying Windows Autopilot hardware hash and Autopilot diagnostic tools
With the Pre-provisioned mode, the build process is separated into two stages; the Technician flow and the User flow.
The Technician flow is performed by internal IT staff or a vendor to stage the device for handover to the end user. During this stage, the device is registered with Entra ID and Intune and any device level Configuration Profile and Application policies are pushed to the device by Intune. Upon completion, the technician will be presented with a Reseal button which will power off the machine for delivery to the end user.
The User flow is performed by the end user. Upon powering on the pre-provisioned device, the user is prompted to connect to the network and setup the device for work or school. At this stage, the user enters their Entra ID username and password, and user level device setup and account setup processes commence. When the setup processes are completed, depending on the policies defined in Entra ID, the user can be prompted for MFA and to setup Windows Hello for Business factors like PIN and/or face sign in. Once these processes are completed, the user is presented with the Windows desktop.
The following challenges have been identified throughout testing of the Autopilot Pre-Provisioned flows in a lab environment with restricted access to the Wired and Wireless networks using Cisco ISE.
With the challenges described above and various current industry limitations, the following solution is likely the best option to facilitate Autopilot builds with a moderate level of security.
During the initial Technician stage, an Open SSID would be used to provide Wireless connectivity to the required cloud-based services. This Open SSID would use an ISE Portal flow to redirect the Technician to provide their Entra ID credentials (and optional MFA) via SAML integration between ISE and Entra ID.
In traditional Wireless architectures, client traffic for this Open SSID could be tunnelled out to an Anchor Wireless Controller in a DMZ (similar to a common Wireless Guest flow) or dropped onto an internal VLAN/VRF where necessary segmentation and other compensating security controls and monitoring could be implemented. Such security controls might include solutions like Next Generation Firewalls, Content Security Filtering, DNS Security solutions, SASE/SSE, etc.
In Software Defined Access (SDA) Fabric-enabled Wireless architectures, the client traffic for this Open SSID could be dropped onto an internal VLAN/VN that is segmented from other corporate networks and Security Group Tags (SGTs) and other compensating security controls and monitoring could be implemented.
Depending on the environment, broadcasting of this Open SSID could also be restricted to Access Points in specific locations where the initial build processes are expected to take place.
Once authorized on the Open SSID, the following build processes (among others) would take place during the Technician stage:
Upon completion of the device-level build operations, the Technician will Reseal the device for delivery to the end user.
Upon receipt of the Pre-provisioned device, the end user would power it on and complete the remaining build processes.
The first step would be connecting to a wireless network. As the Wifi Profile and Device identity certificate were provisioned during the Technician stage, the user would be able to connect to the Corporate Wifi network that is secured by 802.1x. The Authentication would use TEAP(EAP-TLS) with the Device credential presented in the Device certificate. The Device should also be Compliant with Intune policies as this stage (depending on how the Compliance policies are defined), so an additional MDM Registration and/or Compliance check could be performed (optionally) by ISE as a condition for Authorization.
Upon a successful Authorization, the Autopilot process completes the Device setup processes and continues to the User setup processes. During the User setup processes, Windows restarts and prompts the user for login credentials.
At this stage, Windows transitions from the Computer state to the User state and initiates the User 802.1x process. As the User certificate has likely not yet been enrolled by Intune (this process can take some time), the session will be Authenticated using TEAP(EAP-TLS) with the Device certificate and Authorized by ISE using the ‘User failed and machine succeeded’ EAP Chaining result.
This conditional state is intended to provide network connectivity until Intune has completed the User certificate provisioning, so an aggressive (for example, 10 minutes) re-authentication timer could be applied to the session.
Once the User certificate is enrolled by Intune, the next re-authentication (or disconnect/reconnect) event will result in Authentication of both the User and Device, with a ‘User and machine both succeeded’ EAP Chaining result.
The following diagram illustrates the proposed process flow described above. As illustrated in the diagram, Authentication of the User and Device sessions is based purely on a valid and trusted certificate due to limitations described in the following article.
Cisco ISE with Microsoft Active Directory, Entra ID, and Intune
The flows used for this solution mainly involve the AAA, 802.1x, and Guest features covered under the ISE 3.x Essentials tier licensing.
If the optional MDM Registration and/or Compliance checks are included as conditions for Authorization, this would require the Premier tier licensing for the MDM Compliance feature set.
For more information on ISE licensing, see the Cisco ISE Licensing Guide.
This section documents the example components and configurations used to define and test this proposed solution in a lab environment.
The following components were used for this lab setup.
** Note: This solution requires ISE version 3.2+ as it leverages the REST ID authorization flow
The configuration examples in this document are specific to this proposed solution for Autopilot. General configuration of these components in not included, nor is the setup for ADCS and the Intune Certificate Connector.
The Entra ID and Intune configurations for the Autopilot Pre-provisioned use case are based on Microsoft’s step by step tutorial found here:
https://learn.microsoft.com/en-us/autopilot/tutorial/pre-provisioning/azure-ad-join-workflow
This lab example is also roughly based on configuration used for a prior solution documented at the link below, which is why some of the configuration items herein use a ‘BYOD’ reference.
The following example configuration items are defined for this solution:
The general configuration of the WLC to use ISE for AAA is based on the following guide:
ISE and Catalyst 9800 Series Integration Guide
A Pre-Auth URL Filter is configured to allow the client to connect to the Microsoft login domains while the session is in the URL Redirect state.
Example:
The URL Filter configured above can be applied using one of two methods:
This example uses the static method to apply the URL Filter to the Wireless Policy Profile.
Example:
For this example, I have created both a permissive transit ACL and URL Redirect ACL that Cisco ISE will reference in the Authorization Profiles.
This is a basic ACL permitting all traffic from the client. This is not required, but I prefer to apply an ACL to validate that the WLC is applying session attributes sent by ISE.
|
Action |
Source IP |
Destination IP |
Protocol |
Source Port |
Destination Port |
|
permit |
any |
any |
ip |
None |
None |
Example:
This is the URL Redirect ACL that will be referenced by ISE and applied to the client for the Portal flow.
The ‘deny’ entries indicate that the traffic will be exempted from redirection and ‘None’ can be considered ‘any’ port.
The ACL exempts DNS traffic and traffic to/from the ISE PSNs from redirection to allow the client to resolve the ISE PSN FQDNs to connect to the Portal.
|
Action |
Source IP |
Destination IP |
Protocol |
Source Port |
Destination Port |
|
deny |
any |
any |
udp |
None |
eq domain |
|
deny |
any |
any |
udp |
eq domain |
None |
|
deny |
any |
< ISE PSN IP > |
ip |
None |
None |
|
deny |
< ISE PSN IP > |
any |
ip |
None |
None |
|
permit |
any |
any |
tcp |
None |
eq www |
|
permit |
any |
any |
tcp |
None |
eq 443 |
The ACL above can be refined to restrict traffic to only the ports necessary on the ISE PSNs. See the following guide for more details.
Configure Central Web Authentication (CWA) on Catalyst 9800 WLC and ISE
** NOTE: The last entry ensures that HTTPS (tcp/443) traffic is redirected in this example as it was found to cause issues with the redirection to the Microsoft login page without this rule defined.
Example:
This example solution uses the following configuration items:
The following Groups were configured in Entra ID for this lab environment.
These Security Groups can be configured in either Entra ID or Intune using either static or dynamic membership as per your specific environment.
For this lab, the ESP and DP Groups were configured using dynamic membership rules as per the following Microsoft document.
Pre-provision Microsoft Entra join: Create a device group
The following steps were taken to configure the SAML IdP integration between ISE and Entra ID.
Navigate to Administration > Identity Management > External Identity Sources > SAML Id Providers and click Add
Input the Provider Id Name and optional Description values and click Submit.
** NOTE: At the time of this writing, ISE cannot create more than one SAML Id Provider with the same Azure tenant ID.
Navigate to Policy > Policy Elements > Results > Authentication > Allowed Protocols and click Add
Example:
Input the Name and optional Description, select only the Process Host Lookup option, and click Submit.
Example:
Follow the steps above to add a new Allowed Protocols list.
Input the Name and optional Description, enable Allow TEAP, enable all settings under the Allow EAP-TLS section as well as any other setting required for your environment, and click Submit.
Example:
Create an EIG that will be used within the Guest Type and Portal configurations. This EIG will not be used within the ISE policies.
Navigate to Administration > Identity Management > Groups > Endpoint Identity Groups and click Add.
Input the Name and optional Description and click Submit.
Example:
This Guest Type will be associated with the new Guest Portal.
Navigate to Work Centers > Guest Access > Portals & Components > Guest Types and click Create.
Input the Guest Type Name and optional Description.
Example:
Under the Login Options section, select the Endpoint Identity Group previously created.
Example:
Configure all other preferred settings and click Save.
Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals. Create a new Sponsored Guest Portal or select an existing one.
Input the Portal Name and optional Description.
Example:
In the Portal Settings section, select the SAML IdP from the ‘Authentication method’ drop-down list and the Guest Type from the ‘Employees using this portal as guests…’ drop-down list.
Example:
Configure all other preferred settings and click Save.
Navigate to Administration > Identity Management > External Identity Sources > SAML Id Providers and Edit the IdP.
Select the Service Provider Info tab and click Export.
Example:
Save and extract the zip file and open the XML file in a text editor. Record the following attribute values:
Example:
<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://CiscoISE/2ef056ac-9494-467d-ad42-e8efbc3f6826">
...snip...
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ise33-1.ise.trappedunderise.com:8443/portal/SSOLoginResponse.action" index="0"/></md:SPSSODescriptor></md:EntityDescriptor>
In the Microsoft Entra admin center (https://entra.microsoft.com), navigate to Identity > Applications > Enterprise applications
Click on New Application
Click on Create your own application
Name the application and ensure the Non-gallery option is selected. Click Create.
Example:
Navigate to Manage > Users and groups
Click on Add user/group
Under Users and groups, click on the link for None selected. Click the Autopilot User group created earlier and click Select.
Example:
Once added, click on the group name and record the Object ID value as this will be needed for the ISE configuration in later steps
Example:
Navigate to Manage > Single sign-on
In the Basic SAML Configuration section, click Edit.
Paste the entityID and Location values recorded from XML file earlier in Step 6 and click Save.
Example:
In the Attributes & Claims section, click Edit.
Click on Add a group claim
You should see the group claim added under Additional claims section
Example:
Close the window and you should now see the groups claim added with a value of user.groups
Example:
In the SAML Certificates section, click the Download link for the Federation Metadata XML and save the file.
Example:
Navigate to Administration > Identity Management > External Identity Sources > SAML Id Providers
Select the SAML IdP and click on the Identity Provider Config tab.
Click the Choose File button and select the Federation Metadata XML file downloaded from Entra ID in the previous step.
Select the Groups tab and input the following URI for the Group Membership Attribute
** NOTE: The above URI can be seen in the screenshot above for the Additional Claims in the Entra ID SAML configuration
Click the Add button.
For the ‘Name in Assertion’ field, paste the Object ID copied from Entra ID in the previous step and input a unique value for the ‘Name in ISE’ field. Click OK.
Example:
Select the Attributes tab and click Add.
Input the following values and click OK.
Note that the URI below can also be seen in the screenshot above for the Additional Claims in the Entra ID SAML configuration.
A different attribute (like emailaddress) could be used for the username in ISE if your environment is configured appropriately.
Example:
** NOTE: You may see a warning when pasting in the URI above. This is due to ISE automatically trying to copy the same URI into the ‘Name in ISE’ field. Click OK as this warning can be ignored.
Select the Advanced Settings tab
Under the Identity Attribute, select the Attribute radio button and select the available claims schema from the drop-down.
Select the same schema from the Email attribute drop-down. Click Save.
Example:
In this lab example, ISE is configured to perform an MDM Compliance check as a condition for Authorization for both the Device and User sessions. Configuration on both Entra ID and ISE is required for this integration and this section describes the configuration that was used.
This section can be skipped if you do not intend to use the Intune Registration and/or Compliance checks as conditions in your Authorization Policies.
Use of this feature requires ISE Premier licenses, and this example configuration is based on the following document.
Integrate MDM and UEM Servers with Cisco ISE
In the Microsoft Entra admin center (https://entra.microsoft.com), navigate to Identity > Applications > App registrations
Click New registration
Input the Name for the application
In the Supported Account Types area, click the Accounts in this organizational directory only radio button and click Register
Example:
Connect to the ISE Primary Policy Admin Node (PAN) GUI and navigate to Administration > System > Certificates > Certificate Management > System Certificates
Select the certificate from the Primary PAN that is used by the Admin function and click Export
Example:
Select the Export Certificate Only radio button, click Export, and save the file to a secure location
With the certificate selected, click on the View button
Example:
Locate the SHA1 Fingerprint value and record it for use in a following step
Example:
Repeat the above steps for the Secondary PAN and any RADIUS PSN nodes in your environment that will service authorization requests that include the MDM Registration/Compliance checks.
In the Entra App Registration, click the Certificates & Secrets blade
Select the Certificates tab and click the Upload certificate button
Navigate to the certificate file exported from ISE in the prior step, leave the Description field blank, and click Add
** Note: The Description field must match the Subject of the certificate. If the Description field is left blank in this step, the Subject content will automatically be copied into the Description field when uploaded.
Example:
Expand the Thumbprint and Description columns in the table and ensure that the Thumbprint matches the SHA1 Fingerprint copied from ISE in the prior step. Ensure that the Description matches the Subject values in the Admin certificate from ISE.
Example:
Example Subject from the ISE Admin Certificate:
Repeat the above steps for the Secondary PAN and any RADIUS PSN nodes in your environment that will service authorization requests that include the MDM Registration/Compliance checks.
Under the Manage section, Select the API Permissions blade
Click the Add a permission button
Select Intune
Select Application Permissions
Use the search bar to locate and select the get_device_compliance permission and click Add permissions
Click the Add a permission button again
Select Microsoft Graph and Application Permissions
Use the search bar to locate and select the Application.Read.All permission and click Add permissions
Remove any other default permissions and click Grant admin consent for <tenant>
Example:
Select the Overview blade, and record the value of the Application (client) ID for later use:
Example:
Click the Endpoints button
Record the value for the OAuth 2.0 token endpoint (v2) for later use
Example:
At the time of this writing, the Intune certificates are signed by the DigiCert Global Root G2 Public Certificate Authority.
As this solution requires ISE version 3.2+ for the REST ID authorization flow, this Root CA should already exist in the ISE Trusted Certificates store by default.
If you need to confirm this, you can find the link to download this Root CA certificate from the following link and compare it to what is installed in the Administration > Certificates > Certificate Management > Trusted Certificates section in the ISE Primary PAN.
In the ISE Primary PAN, navigate to Administration > Network Resources > External MDM and click Add
** NOTE: Other options are possible for the Device Identifier but, for this solution, ISE will retrieve the GUID (Intune Hardware Identifier) from the SAN URI field of the Device/User certificate presented for EAP-TLS and use that value to perform the API call against Intune for Registration/Compliance checks.
Example:
Click the Test Connection button to ensure that the connection is successful and click OK
Upon the successful test, set the Status to Enabled and click Save
In the Microsoft Intune admin center, navigate to the Devices > Device Onboarding > Enrollment blade
Select the Windows tab, scroll down to the Windows Autopilot section and click the Enrollment Status Page link
Click Create
On the Basics tab, provide the Name and (optional) Description and click Next
Example:
On the Settings tab, define the settings appropriate for your environment and click Next
Example:
On the Assignments tab, click Add Groups and select the Group(s) to which you want the ESP Profile assigned and click Next
Example:
On the Scope tags tab, select any tags necessary for your environment (optional) and click Next
On the Review + create tab, confirm the settings are correct and click Create
Example:
Navigate back to the Enrollment page, scroll down to the Windows Autopilot section and click the Deployment Profiles link
Click Create Profile and select Windows PC
On the Basics tab, provide the Name and (optional) Description and click Next
Example:
On the Out-of-box experience (OOBE) tab, define the settings appropriate for your environment and click Next
NOTE: This solution uses the pre-provisioned flows, so the Allow pre-provisioned deployment setting must set to Yes
Example:
On the Scope tags tab, select any tags necessary for your environment (optional) and click Next
On the Assignments tab, under the Included groups section, click Add Groups and select the Group(s) to which you want the Deployment Profile assigned and click Next
Example:
On the Review + create tab, confirm the settings are correct and click Create
Example:
Navigate back to the Enrollment page, scroll down to the Windows Autopilot section and click the Devices link
Here you can verify the Devices already known to Autopilot (via the OEM or other methods) and Import new devices manually if needed as per the Microsoft documentation for Manually register devices with Windows Autopilot.
In this example, I have manually registered the Surface Go device being used for testing this solution.
Example:
This example uses a simple Compliance Policy to verify that the Windows Firewall is enabled. If your Compliance Policy is more complicated, it may take time for Intune to mark the device as Compliant.
This section can be skipped if you do not intend to use the Intune Registration and/or Compliance checks as conditions in your Authorization Policies or if you already have a Compliance Policy created and assigned to the Autopilot devices.
In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Compliance blade
Click Create policy
Select the Platform type for Windows 10 and later and click Create
On the Basics tab, provide the Name and (optional) Description and click Next
Example:
On the Compliance Settings tab, expand the System security section, locate the Device Security > Firewall option, select Require and click Next
Example:
On the Actions for noncompliance tab, define any required actions and click Next
On the Scope tags tab, select any tags necessary for your environment (optional) and click Next
On the Assignments tab, under the Included groups section, click Add Groups and select the Group(s) to which you want the Deployment Profile assigned and click Next
Example:
On the Review + create tab, confirm the settings are correct and click Create
Example:
A Trusted Certificate Profile is created to deploy the Root CA certificate from the Corporate PKI (ADCS) to the trust store on the Autopilot Device.
In this example, the same Root CA was used to sign the ISE EAP certificate as well as the Device/User certificates that will be enrolled on the Autopilot Device.
In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Configuration blade
Click Create and select New Policy
On the Basics tab, provide the Name and (optional) Description and click Next
Example:
On the Configuration settings tab, browse to the CA certificate you want to upload. This certificate would need to be downloaded either from your PKI or exported from the ISE Trusted Certificates store (if it was uploaded there)
For the Destination store setting, select Computer certificate store – Root from the drop-down box
Example:
On the Scope tags tab, select any tags necessary for your environment (optional) and click Next
On the Assignments tab, under the Included groups section, click Add Groups and select the Group(s) to which you want the Deployment Profile assigned and click Next
Example:
On the Applicability Rules tab, define any rules necessary for your environment (optional) and click Next
On the Review + create tab, confirm the settings are correct and click Create
Example:
Repeat the above steps to add any other required Trusted Certificates used in your environment
This lab example uses PKCS Certificate Profiles for both User and Device certificates. These Profiles use the Intune Certificate Connector to request certificates from the on-prem PKI (ADCS) on behalf of the Device/User using the PKCS method.
If your environment used SCEP instead of the PKCS method, configure the appropriate SCEP Certificate Profiles for the Device/User certificates using the settings appropriate to your environment.
** NOTE: This example solution uses PKCS Profiles. The same solution will work with SCEP Profiles, assuming your environment supports and is configured properly for SCEP/NDES.
In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Configuration blade
Click Create and select New Policy
On the Basics tab, provide the Name and (optional) Description and click Next
Example:
On the Configuration settings tab, define the settings appropriate for your requirements and environment
For the Certificate type, ensure Device is selected from the drop-down box
For this example, the following settings are defined as they will be used within ISE policies later in this document:
Example:
On the Scope tags tab, select any tags necessary for your environment (optional) and click Next
On the Assignments tab, under the Included groups section, click Add Groups and select the Group(s) to which you want the Deployment Profile assigned and click Next
Example:
On the Applicability Rules tab, define any rules necessary for your environment (optional) and click Next
On the Review + create tab, confirm the settings are correct and click Create
Example:
In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Configuration blade
Click Create and select New Policy
On the Basics tab, provide the Name and (optional) Description and click Next
Example:
On the Configuration settings tab, define the settings appropriate for your requirements and environment
For the Certificate type, ensure Device is selected from the drop-down box
For this example, the following settings are defined as they will be used within ISE policies later in this document:
Example:
On the Scope tags tab, select any tags necessary for your environment (optional) and click Next
On the Assignments tab, under the Included groups section, click Add Groups and select the Group(s) to which you want the Deployment Profile assigned and click Next
Example:
On the Applicability Rules tab, define any rules necessary for your environment (optional) and click Next
On the Review + create tab, confirm the settings are correct and click Create
Example:
A Wifi Profile is configured for the Device to enable 802.1x with TEAP(EAP-TLS). This will be used during the User stage of the build and the final state to connect to the Corporate SSID.
As Intune does not natively support TEAP Wifi Profiles at the time of this writing, the following procedure was used to configure TEAP(EAP-TLS) on another Windows 11 PC, export that configuration, and import it into Intune.
https://learn.microsoft.com/en-us/mem/intune/configuration/wi-fi-settings-import-windows-8-1
** NOTE: The Windows 11 supplicant supports features that are not supported by Windows 10. If you have both Windows 10 and 11 endpoints, you may need to create separate profiles for each OS type.
Navigate to Control Panel > Network and Internet > Network and Sharing Center
Click on Set up a new connection or network
Select Manually connect to a wireless network and click Next
Specify the SSID name and select the Security type of WPA-2 Enterprise from the drop-down box. Ensure the Start this connection automatically option is selected and click Next
Example:
Click the Change connection settings link
Click the Security tab
Select the network authentication method of Microsoft: Tunnel EAP from the drop-down box and click Advanced Settings
Example:
Enable the tick box for Specify authentication mode and ensure User or computer authentication is selected in the drop-down box. Ensure that the Enable single sign on for this network is disabled and click OK
In the TEAP properties, define the following settings:
Example:
Under the Primary authentication method, click Configure
In the Smart Card or other Certificate Properties, define the following settings:
Example:
Click the Advanced button
Enable the tick box for Configure Certificate Selection > Certificate Issuer and select your Root and/or Intermediate CAs (depending on your preference and environment) and click OK
Example:
Repeat the steps above for the Secondary authentication method and click OK to close out of all windows.
Open the Windows Command Prompt and type the following to export the Wifi settings for the profile created above in XML format.
** NOTE: The folder location must already exist, or the command will return an error
netsh wlan export profile name="<name>” key=clear folder=c:\Wifi
Example:
Copy the XML file to a location that can be accessed for upload to Intune
In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Configuration blade
Click Create and select New Policy
On the Basics tab, provide the Name and (optional) Description and click Next
Example:
On the Configuration settings tab, input the Connection name (must be the same as the connection name defined in the Wifi settings during the previous step)
Browse to the XML file exported in the previous step and click Next
Example:
On the Scope tags tab, select any tags necessary for your environment (optional) and click Next
On the Assignments tab, under the Included groups section, click Add Groups and select the Group(s) to which you want the Deployment Profile assigned and click Next
Example:
On the Review + create tab, confirm the settings are correct and click Create
Example:
This example solution assumes a moderate to advanced understanding and familiarity with Cisco ISE and uses the following configuration items:
In ISE, navigate to Administration > Identity Management > External Identity Sources > Certificate Authentication Profile and click Add
Specify the Name and (optional) Description for the CAP
Ensure [not applicable] is selected for the Identity Store and the Subject – Common Name option is selected for the Use Identity From - Certificate Attribute.
** NOTE: The above setting informs ISE to use the value in the Subject CN for identity as this is where the UPN variable was defined in the Intune PKCS Profile. If you used a different location for the UPN (like SAN – Other Name), that location must be specified in the CAP configuration
Example:
Click Apply
This example solution uses the following Authorization Profiles:
Navigate to Policy > Policy Elements > Results > > Authorization > Authorization Profiles and configure each of the Profiles
Configure the following settings and click Save
Example:
Configure the following settings and click Save
Example:
** NOTE: If the decision was made to use a dynamic URL Filter assigned by ISE instead of statically configured in the WLAN Policy on the WLC, the following Advanced Attribute Settings will also need to be included in this AuthZ Profile.
Example:
Configure the following settings and click Save
Configure the following settings and click Save
Configure the following settings and click Save
** NOTE: This AuthZ Profile will be used for the temporary state after the build in which the User certificate has not yet been enrolled by Intune. The Reauthentication Timer of 10 minutes is intended to force the User authentication when the User Certificate is available to the supplicant.
Example:
Two Policy Sets are configured for this example; one for the Build SSID flows and one for the Corporate SSID flows.
Navigate to Policy > Policy Sets, add the Policy Set configurations and click Save
Examples:
Define the Authentication Policies for this Policy Set. As there are no other expected matching conditions, the Default Authentication Policy is used.
This Policy Set will be used for the Open SSID, so use the Internal Endpoints with the option for If User not found = CONTINUE
Example:
Define the Authorization Policies for this Policy Set.
Example:
Click Save
Define the Authentication Policies for this Policy Set.
Note that the following matching conditions are used to differentiate from other flows:
Example:
Define the Authorization Policies for this Policy Set.
Example:
This section includes screenshots taken during various stages of the build flow to verify the expected behaviour.
The following screenshot shows the ISE Live Logs for the initial connection to the ‘iselabbuild’ Open SSID and SAML Guest Portal flow.
The following screenshot shows the view from Intune for the Configuration Profiles applied to the Device at the point of the Reseal.
The following screenshot shows the ISE Live Logs for the User stage of the Autopilot build. At this point, Authentication and Authorization is based only on the Device certificate.
The following screenshots show the ISE Detailed Live Logs for this stage of the Autopilot build
The following screenshot shows the Wireless client session details on the WLC, specifically showing the 600 second Re-Authentication Timeout applied by ISE based on the selected Authorization Policy.
The following screenshot shows the ISE Live Logs for the session after the User certificate has been enrolled by Intune and the re-authentication has resulted in both the User and Device authentication with EAP Chaining.
The following screenshot shows the Wireless client session details on the WLC, specifically showing the change in Re-Authentication Timeout.
The following screenshots show the ISE Detailed Live Logs for this stage of the Autopilot build
The following screenshot shows the Device Summary information in Intune after the User stage of the Autopilot build was completed
The following screenshot shows the assigned Device Compliance Policies in Intune
The following screenshot shows the assigned Device Configuration Profiles in Intune after the User stage of the build was completed
.png "rwehe"){kind=avatar}
