As a security professional, you might want a list of vulnerabilities per asset under your purview to assess risk and begin the remediation process. With Kenna Security APIs, you’ll be able to extract the asset and its vulnerability data. This blog wi...
Knowledge Base Articles
In this morning’s email, you receive a request from your CSO for a report of the vulnerability risks per company site. The CEO wants to run a competition to see which IT site managers can reduce the vulnerability risk the most within the next month a...
According to a 2020 IBM study, enterprises are using over 45 different security tools on average. That number feels like a bit of an understatement based on my own experience working with enterprise security organizations! With so many different sour...
Automation is the one of the keys to a successful DevOps department. There are many workflow engines, like the one in Cisco’s SecureX. This blog discusses one way to automate launching connector runs. Why automate connector runs? One reason is becaus...
I have discussed risk meter creation in a past blog; but what do you do with risk meters once they are created? In the Kenna Security (now Cisco) GUI, the risk meters have a score and are shown with a nice graphic. This score is created by looking a...
I started looking at our “Asset Group Reporting” APIs. After reading their descriptions, I decided to write down some notes about what they’re reporting. API Units Dates? Structure Historical Mean Time To Remediate by Risk Level Days No low, medium,...
Since this is my first blog of 2022, I would like to wish you a prosperous New Year. As you might recall, I published a blog on Risk Meter Reports using Python in November 2021. That blog discussed two Risk Meter or Asset Group reports, "Historical ...
Recently some developers have been asking about vulnerability management (VM) custom fields attached to vulnerabilities. In attempting to answer their questions, it was discovered the API documentation was incorrect. Now the documentation has been fi...
Greetings. It has been a while since my last blog, but I have been focused on improving the Kenna API documentation. Instead of presenting the code, I wrote this blog will cover some of the Kenna API documentation updates. Of course, there will be...
Greetings. Let's jump right to it. This blog will discuss: How to upload a file to a connector A new Python CSV to Kenna (now Cisco) Data Importer (KDI) JSON Uploading a File to a Connector As you might recall from the previous blog, Automating Conne...
Kenna Security (now Cisco) released the new Kenna.VM (now Cisco Vulnerability Management) Premier tier offering on November 15th. One of the features in the Premier tier is a Cisco Talos zero day vulnerability intelligence integration. This is discus...
CVSS v3 scores are now returned in the "List and Show Vulnerabilities" APIs. Also CVSS v3 fields can be searched with the "Search Vulnerabilities" API and build a Risk Meter. Of course, I feel that the Kenna Risk Score is a better number to use to re...
I heard from our software consulting engineers that our customers would like a risk meter that scores CISA vulnerabilities. So here is my implementation. First off, CISA stands for Cybersecurity & Infrastructure Security Agency. You know it has to b...
The Cisco Document Team has posted an article. This document describes how to configure and verify Firepower Threat Defense (FTD) High Availability (Active/Standby failover) on a FPR9300 device. Know of something that needs documenting? Share a new d...
According to a 2020 IBM study, enterprises are using over 45 different security tools on average. That number feels like a bit of an understatement based on my own experience working with enterprise security organizations! With so many different sour...
.png "rwehe"){kind=avatar}
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.
- Introduction
- What is Windows Autopilot?
- Autopilot Solutions
- Device Registration
- Autopilot Pre-provisioned Mode
- Challenges
- Proposed Solution
- Technician Stage
- User Stage
- Example Process Flow
- ISE Licensing
- Lab Environment Setup
- Components
- Wireless Controller Configuration
- URL Filter Configuration
- Update Policy Profile
- ACL Configuration
- Transit ACL Configuration
- Redirect ACL Configuration
- Entra ID & Intune Configuration
- Entra ID Groups
- SAML IdP Integration
- ISE SAML Id Provider Configuration
- ISE Policy Elements
- Create an Allowed Protocols list for MAB (if one is not already created)
- Create an Allowed Protocols list for 802.1x TEAP (if one is not already created)
- Create an Endpoint Identity Group (EIG)
- Create a Guest Type
- Configure the Guest Portal
- Entra ID SAML SSO Configuration
- Export the SAML IdP info from ISE
- Register the Enterprise Application
- Complete the SAML Configuration in ISE
- Configure the SAML IdP settings
- ISE and Intune MDM integration (Optional)
- Register the Application for Intune MDM Integration
- Export the ISE Admin Certificates
- Complete the App Registration Configuration
- Upload the ISE Admin Certificates
- Configure the API Permissions
- Trusted Certificate Requirements for Intune
- ISE Configuration for Intune MDM Integration
- Intune Autopilot Enrollment Status Page (ESP)
- Intune Autopilot Deployment Profile
- Intune Autopilot Devices
- Intune Compliance Policy (Optional)
- Intune Configuration Profile for Trusted Certificate(s)
- Intune Configuration Profile for PKCS/SCEP Certificates
- Device PKCS Certificate Profile
- User PKCS Certificate Profile
- Intune Configuration Profile for Wifi
- Windows 11 Supplicant Configuration
- Export the Wifi Settings
- Create the Intune Wifi Profile
- ISE Configuration
- Certificate Authentication Profile (CAP)
- Authorization Profiles
- AuthZ Profile - AuthZ-Wireless-Build
- AuthZ Profile - AuthZ-Wireless-Build-Redirect
- AuthZ Profile - AuthZ-Wireless-EntraID-Device-MDM-Compliant
- AuthZ Profile - AuthZ-Wireless-EntraID-User-MDM-Compliant
- AuthZ Profile - AuthZ-Wireless-EntraID-User-Failed
- Policy Sets
- Authentication and Authorization Policies
- Wireless Autopilot Build
- Wireless Corp
- Lab Verification
- Technician Stage
- User Stage – No User Certificate
- User Stage – User Certificate Enrolled
Introduction
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.
What is Windows Autopilot?
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:
- User-Driven Setup: End-users can initiate the setup process themselves, reducing the need for IT intervention.
- Pre-Configuration: Devices can be pre-configured with necessary settings, applications, and policies before they even reach the end-user.
- Zero-Touch Deployment: Devices can be shipped directly to users and automatically configured as soon as they connect to the internet.
- Seamless Integration: Works seamlessly with Microsoft Intune and other Microsoft 365 services for unified endpoint management.
Benefits:
- Reduced Deployment Time: Streamlines the setup process, enabling devices to be ready for use faster.
- Lower IT Overhead: Minimizes the need for IT staff to manually configure each device.
- Enhanced User Experience: Users can get up and running quickly with minimal technical support.
- Consistency and Compliance: Ensures all devices are configured according to organizational policies and standards.
- Flexibility: Supports remote and hybrid work models by allowing devices to be set up anywhere with an internet connection.
More information on Windows Autopilot can be found at the following link:
https://learn.microsoft.com/en-us/autopilot/
Autopilot Solutions
At the time of this writing, Microsoft defines the following different Autopilot solutions:
- Windows Autopilot device preparation
- Windows Autopilot
The former solution (Windows Autopilot device preparation) only supports a user-driven mode, while the latter (Windows Autopilot) supports the following modes:
- User-driven
- Pre-provisioned
- Self-deploying
- Existing devices
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.
Device Registration
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
Autopilot Pre-provisioned Mode
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.
Challenges
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.
- Limited information about the device is provided by either the hardware hash or current Microsoft Graph API endpoints
- In the Technician stage, there is no ability to connect to a Wired/Wireless network via 802.1x
- In the Technician stage, only basic Wireless connectivity options such as Pre-Shared Key (PSK) or Open SSIDs are supported. Captive portal-based flows are supported with these SSID types.
- The use of MAC Address based allow listing is difficult as the Wireless MAC Address is not known in advance.
- Most Windows PCs these days use docks/dongles for Wired interfaces, so any MAC Address based allow listing would follow the dock/dongle.
- Based on packet captures taken during the Autopilot flows, there are DNS queries made to 60+ different unique domain FQDNs, including recursive DNS queries that resolve to Content Delivery Networks (CDNs). This makes filtering based on URLs extremely difficult.
Proposed Solution
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.
Technician Stage
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:
- Perform the Entra ID Join operation and enrol the device with Intune
- Push Trusted Certificate profiles for Root and Intermediate certificate trust chains
- Push SCEP/PKCS Profile for Device identity certificate
- Push Wifi Profile for Corporate SSID using 802.1x and TEAP(EAP-TLS) with ‘User or Computer Authentication’ mode
- Deploy any device-level Apps defined as per Intune policies
Upon completion of the device-level build operations, the Technician will Reseal the device for delivery to the end user.
User Stage
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.
Example Process Flow
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
ISE Licensing
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.
Lab Environment Setup
This section documents the example components and configurations used to define and test this proposed solution in a lab environment.
Components
The following components were used for this lab setup.
- Cisco Catalyst 9800-CL Wireless Controller version 17.12.3
- Cisco Identity Services Engine version 3.3 patch 3
- Microsoft Surface Go 3 tablet
- Windows 11 Pro 22H2
- Active Directory Certificate Services (ADCS) on Server 2019 version 1809
- Intune Certificate Connector
- Entra ID and Intune tenants
** 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.
Wireless Controller Configuration
The following example configuration items are defined for this solution:
- URL Filter
- Transit and URL Redirect ACLs
- Open SSID with MAC Filtering and NAC configuration
- Secure SSID with NAC configuration
- WLAN Tags and Policies
The general configuration of the WLC to use ISE for AAA is based on the following guide:
ISE and Catalyst 9800 Series Integration Guide
- As this solution only involves Windows devices, however, there is no Webauth Parameter Map configured for this solution.
URL Filter Configuration
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.
- Navigate to the Configuration > Security > URL Filters page and click Add
- Specify the List Name
- Select the Type of PRE-AUTH from the drop-down list
- Ensure the Action is set as PERMIT
- Input the following URLs in the text box and click Apply to Device
- aadcdn.msauth.net
- login.microsoftonline.com
- aadcdn.microsoftonline-p.com
Example:
Update Policy Profile
The URL Filter configured above can be applied using one of two methods:
- Statically applied to the Policy Profile
- Dynamically assigned by ISE
This example uses the static method to apply the URL Filter to the Wireless Policy Profile.
- Navigate to the Configuration > Tags & Profiles > Policy page
- Select the Policy for the Open SSID that will be used for the Technician stage of the build
- Select the Access Policies tab and use the drop-down box to select the URL Filter next to the Pre Auth option
- Click Update & Apply to Device
Example:
ACL Configuration
For this example, I have created both a permissive transit ACL and URL Redirect ACL that Cisco ISE will reference in the Authorization Profiles.
Transit ACL Configuration
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.
- Navigate to the Configuration > Security > ACL page and click Add
- Specify the ACL Name and ensure the ACL Type is IPv4 Extended
- Define the ACL entries as per the following table and click Apply to Device
|
Action |
Source IP |
Destination IP |
Protocol |
Source Port |
Destination Port |
|
permit |
any |
any |
ip |
None |
None |
Example:
Redirect ACL Configuration
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.
- Navigate to the Configuration > Security > ACL page and click Add
- Specify the ACL Name and ensure the ACL Type is IPv4 Extended
- Define the ACL entries as per the following table and click Apply to Device
|
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:
Entra ID & Intune Configuration
This example solution uses the following configuration items:
- Entra ID Groups
- SAML IdP Integration
- (Optional) Entra ID App Registration for Intune MDM integration
- Intune Autopilot Deployment Profile
- Intune Autopilot Enrollment Status Page
- Intune Compliance Policy
- Intune Configuration Profile for Trusted Certificate(s)
- Intune Configuration Profile for PKCS/SCEP Certificates
- Intune Configuration Profile for Wifi Profile
Entra ID Groups
The following Groups were configured in Entra ID for this lab environment.
- TUI Autopilot Build Users
- Group associated with the App Registration for SAML
- Members of this group will be limited to users executing the Technician stage of the Autopilot build
- TUI Autopilot Deployment Profile
- Group associated with the Autopilot Deployment Profile (DP)
- Members of this group will be the Devices built using Autopilot
- This group will be used to assign the relevant Device Configuration Profiles in Intune
- TUI ESP Default
- Group associated with the Autopilot Enrollment Status Page (ESP)
- Members of this group will be limited to users executing the Technician stage of the Autopilot build
- Entra Only Users
- Group associated with the User Configuration Profiles in Intune
- Members of this group will be the end users of the Windows Devices
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
SAML IdP Integration
The following steps were taken to configure the SAML IdP integration between ISE and Entra ID.
- Create a SAML Id Provider in ISE
- Create the ISE policy elements
- Create the ISE portal elements
- Export the ISE SAML Service Provider info
- Create the Enterprise application in Entra ID
- Complete the SAML IdP configuration in ISE
- Configure the ISE Policy Sets and Policies
ISE SAML Id Provider Configuration
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.
ISE Policy Elements
Create an Allowed Protocols list for MAB (if one is not already created)
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:
Create an Allowed Protocols list for 802.1x TEAP (if one is not already created)
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 Endpoint Identity Group (EIG)
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:
Create a Guest Type
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.
Configure the Guest Portal
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.
Entra ID SAML SSO Configuration
Export the SAML IdP info from ISE
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:
- entityID
- AssertionConsumerService Locations
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>
Register the Enterprise Application
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
- Select the Security groups radio button
- Select Group ID in the Source attribute drop-down
- Click Save
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:
Complete the SAML Configuration in ISE
Configure the SAML IdP settings
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.
- Name in Assertion = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
- Type = STRING
- Name in ISE = username
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:
ISE and Intune MDM integration (Optional)
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
Register the Application for Intune MDM Integration
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:
Export the ISE Admin Certificates
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.
Complete the App Registration Configuration
Upload the ISE Admin Certificates
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.
Configure the API Permissions
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:
Trusted Certificate Requirements for Intune
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.
ISE Configuration for Intune MDM Integration
In the ISE Primary PAN, navigate to Administration > Network Resources > External MDM and click Add
- Input the Name and optional Description for the MDM connection
- From the Authentication Type drop-down list, choose OAuth – Client Credentials
- In the Auto Discovery URL field, enter https://graph.microsoft.com
- In the Client ID field, enter the Application (client) ID value recorded from the App Registration in the prior steps
- In the Token Issuing URL field, enter the OAuth 2.0 token endpoint (v2) value recorded in the prior steps
- In the Token Audience field, enter https://api.manage.microsoft.com//.default
- Enter the desired values for the Polling Interval and Time Interval For Compliance Device ReAuth Query fields
- Under the Device Identifier section, ensure that the option for Cert – SAN URI, GUID is enabled at the highest priority
** 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
Intune Autopilot Enrollment Status Page (ESP)
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:
Intune Autopilot Deployment Profile
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:
Intune Autopilot Devices
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:
Intune Compliance Policy (Optional)
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:
Intune Configuration Profile for Trusted Certificate(s)
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
- Select the Platform type for Windows 10 and later
- In the Profile type drop-down box, select Templates
- Select the template for Trusted certificate and click Create
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
Intune Configuration Profile for PKCS/SCEP Certificates
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.
Device PKCS Certificate Profile
** 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
- Select the Platform type for Windows 10 and later
- In the Profile type drop-down box, select Templates
- Select the template for PKCS certificate and click Create
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:
- Subject Common Name = {{DeviceName}}
- This is a variable used within Intune to automatically populate the Device DisplayName
- Subject OU = TUI Entra Joined Device
- This is a static value that will be used as a matching condition in ISE Authentication/Authorization Policies to differentiate between other use cases
- Subject Alternative Name (SAN) URI = ID:Microsoft Endpoint Manager:GUID:{{DeviceId}}
- This is used by ISE to identify the GUID for MDM Registration/Compliance checks
- This exact string must be used for the MDM checks to work properly
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:
User PKCS Certificate Profile
In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Configuration blade
Click Create and select New Policy
- Select the Platform type for Windows 10 and later
- In the Profile type drop-down box, select Templates
- Select the template for PKCS certificate and click Create
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:
- Subject Common Name = {{UserPrincipalName}}
- This is a variable used within Intune to automatically populate the UPN
- The UPN must be used within either the CN or SAN field and ISE must use this value as identity to perform Authorization lookups against Entra ID using the REST ID function
- Subject OU = EntraID Users
- This is a static value that will be used as a matching condition in ISE Authentication/Authorization Policies to differentiate between other use cases
- Subject Alternative Name (SAN) URI = ID:Microsoft Endpoint Manager:GUID:{{DeviceId}}
- This is used by ISE to identify the GUID for MDM Registration/Compliance checks
- This exact string must be used for the MDM checks to work properly
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:
Intune Configuration Profile for Wifi
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
Windows 11 Supplicant Configuration
** 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:
- Identity privacy
- anonymous or another preferred value for your environment
- Connect to these servers
- This field is left blank for this example
- If you choose to define this, ensure you follow the syntax guidance by from Microsoft
- Trusted Root Certificate Authorities
- Ensure that your Root CA is selected
- Primary (User) and Secondary (Computer) authentication methods set to Microsoft: Smart Card or other certificate (EAP-TLS)
Example:
Under the Primary authentication method, click Configure
In the Smart Card or other Certificate Properties, define the following settings:
- Use a certificate on the computer
- Use simple certificate selection (Recommended)
- Verify the server’s identity by validating the certificate
- Connect to these servers
- This field is left blank for this example
- If you choose to define this, ensure you follow the syntax guidance by from Microsoft
- Trusted Root Certificate Authorities
- Ensure that your Root CA is selected
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.
Export the Wifi Settings
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
Create the Intune Wifi Profile
In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Configuration blade
Click Create and select New Policy
- Select the Platform type for Windows 8.1 and later
- In the Profile type drop-down box, select Wifi and click Create
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:
ISE Configuration
This example solution assumes a moderate to advanced understanding and familiarity with Cisco ISE and uses the following configuration items:
- Certificate Authentication Profile (CAP)
- Authorization Profiles
- Policy Sets
- Authentication and Authorization Policies
Certificate Authentication Profile (CAP)
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
Authorization Profiles
This example solution uses the following Authorization Profiles:
- AuthZ-Wireless-Build
- AuthZ-Wireless-Build-Redirect
- AuthZ-Wireless-EntraID-Device-MDM-Compliant
- AuthZ-Wireless-EntraID-User-MDM-Compliant
- AuthZ-Wireless-EntraID-User-Failed
Navigate to Policy > Policy Elements > Results > > Authorization > Authorization Profiles and configure each of the Profiles
AuthZ Profile - AuthZ-Wireless-Build
Configure the following settings and click Save
- Access Type = ACCESS_ACCEPT
- Common Tasks
- Airespace-ACL-Name = ACL-ALLOW-ALL
Example:
AuthZ Profile - AuthZ-Wireless-Build-Redirect
Configure the following settings and click Save
- Access Type = ACCESS_ACCEPT
- Common Tasks
- Web Redirection = Centralized Web Auth
- ACL = ACL-AP-REDIRECT (as configured earlier on the WLC)
- Value = Autopilot Build Portal (as configured earlier in ISE)
- Web Redirection = Centralized Web Auth
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.
- Advanced Attributes Settings
- Cisco: cisco-av-pair = url-filter-preauth=<URL Filter name>
Example:
AuthZ Profile - AuthZ-Wireless-EntraID-Device-MDM-Compliant
Configure the following settings and click Save
- Access Type = ACCESS_ACCEPT
- Common Tasks
- Airespace-ACL-Name = ACL-ALLOW-ALL
AuthZ Profile - AuthZ-Wireless-EntraID-User-MDM-Compliant
Configure the following settings and click Save
- Access Type = ACCESS_ACCEPT
- Common Tasks
- Airespace-ACL-Name = ACL-ALLOW-ALL
AuthZ Profile - AuthZ-Wireless-EntraID-User-Failed
Configure the following settings and click Save
- Access Type = ACCESS_ACCEPT
- Common Tasks
- Airespace-ACL-Name = ACL-ALLOW-ALL
- Reauthentication Timer = 600 seconds
** 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:
Policy Sets
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:
Authentication and Authorization Policies
Wireless Autopilot Build
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
Wireless Corp
Define the Authentication Policies for this Policy Set.
Note that the following matching conditions are used to differentiate from other flows:
- TEAP – this is a saved condition with the following attributes
- Network Access·EapTunnel EQUALS TEAP
- CERTIFICATE·Issuer - Common Name EQUALS TUI-DC1-CA
- This attribute matches the Issuer CN in the certificate presented by the client
- The issuer of this certificate is the On-Prem ADCS
- CERTIFICATE·Subject - Organization Unit EQUALS [TUI Entra Joined Device OR EntraID Users]
- These are the values defined earlier in this document within the Intune PKCS Profiles
Example:
Define the Authorization Policies for this Policy Set.
- Note that similar matching conditions as above are used to differentiate from other session flows.
Example:
Lab Verification
This section includes screenshots taken during various stages of the build flow to verify the expected behaviour.
Technician Stage
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.
User Stage – No User Certificate
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.
User Stage – User Certificate Enrolled
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
Cisco Employee