Buy or Renew
Buy or Renew

Security Knowledge Base

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article

“Webinar

 
Labels

Knowledge Base Articles

Create a new article

The PIX Firewall 500 series does not pass PAT traffic. SSH and Telnet connections fail in the PIX with software version 6.x

What is PAT?PAT is a concept used in networking. It can be defined as a feature of a given network device with which the device translates the TCP or UDP communications that are made between the hosts on a private and host on a public network. PAT fi...

TCC_2 by • Level 10
  • 1562 Views
  • 0 comments
  • 0 Helpful votes

Unable to get event logs on CS-MARS from Microsoft Windows 2003 server with a SNARE client

Core issueIn this issue, CS-MARS fails to get logs from Microsoft Windows 2003 server as the default port for SNARE client is 6161, but it needs to be port 514 in order to communicate with CS-MARS.ResolutionIn order to resolve this issue, verify that...

TCC_2 by • Level 10
  • 1941 Views
  • 0 comments
  • 0 Helpful votes

Unable to login to the CS-MARS through SSH or the GUI and the "ORA-12541: TNS:no listener" error message appears

Core issueThis issue is due to the presence of Cisco bug ID CSCse99322.Oracle listener saves its logs to the listener.log file. When this issue occurs, the listener stops once the file reaches the operating system limit of 2 GB. As a consequence, no ...

TCC_2 by • Level 10
  • 2376 Views
  • 0 comments
  • 0 Helpful votes

How to configure the IDS Sensor signature with IDM from getting triggered due to internal addresses

ResolutionThis can be achieved by editing the signature.Complete these steps in order to edit the signature from the Intrusion Detection System (IDS) Device Manager (IDM):Go to Signature Configuration.Search by ID.Edit the required signature (for exa...

TCC_2 by • Level 10
  • 129 Views
  • 0 comments
  • 0 Helpful votes

An SMTP server behind the PIX is being used as a relay agent. Can the PIX block this access?

Core issueNeed to block access from Simple Mail Transfer Protocol (SMTP) server being used as a relay agent.ResolutionNo. The PIX cannot block this access without blocking all e-mails from being sent from the mail server. Each mail server has an opti...

TCC_2 by • Level 10
  • 934 Views
  • 0 comments
  • 0 Helpful votes
Load more
Getting Started

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

Top Contributors
Featured Article

Cisco ISE and Microsoft Windows Autopilot

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

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

Autopilot pre-prov flow.png

 

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.

ISE BYOD Flow Using Entra ID

 

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.

 

  1. Navigate to the Configuration > Security > URL Filters page and click Add
  2. Specify the List Name
  3. Select the Type of PRE-AUTH from the drop-down list
  4. Ensure the Action is set as PERMIT
  5. Input the following URLs in the text box and click Apply to Device
  • aadcdn.msauth.net
  • login.microsoftonline.com
  • aadcdn.microsoftonline-p.com

 

Example:

wlc dark url filter create.png

 

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.

 

  1. Navigate to the Configuration > Tags & Profiles > Policy page
  2. Select the Policy for the Open SSID that will be used for the Technician stage of the build
  3. Select the Access Policies tab and use the drop-down box to select the URL Filter next to the Pre Auth option
  4. Click Update & Apply to Device

 

Example:
wlc dark url filter apply.png

 

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.

 

  1. Navigate to the Configuration > Security > ACL page and click Add
  2. Specify the ACL Name and ensure the ACL Type is IPv4 Extended
  3. 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:
wlc dark acl name allow all.png
wlc dark acl content allow all.png

 

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.

 

  1. Navigate to the Configuration > Security > ACL page and click Add
  2. Specify the ACL Name and ensure the ACL Type is IPv4 Extended
  3. 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:
wlc dark acl name redirect.png
wlc dark acl content redirect.png

 

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.

 

  1. Create a SAML Id Provider in ISE
  2. Create the ISE policy elements
  3. Create the ISE portal elements
  4. Export the ISE SAML Service Provider info
  5. Create the Enterprise application in Entra ID
  6. Complete the SAML IdP configuration in ISE
  7. 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

saml idp config.png

 

Input the Provider Id Name and optional Description values and click Submit.

Example:
saml idp name.png

** 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:
allowed prots mab add.png

 

Input the Name and optional Description, select only the Process Host Lookup option, and click Submit.

 

Example:
allowed prots mab.png

 

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:
GregGibbs_0-1738714771847.pngallowed prots teap.png

 

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. 

eig add.png

 

Input the Name and optional Description and click Submit.

 

Example:
eig autopilot devices.png

 

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.

guest types.png

 

Input the Guest Type Name and optional Description.

 

Example:
guest type autopilot build.png

 

Under the Login Options section, select the Endpoint Identity Group previously created.

 

Example:
guest type eig.png

 

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:
autopilot build portal name.png

 

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:
autopilot portal settings.png

 

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:
ise saml export.png

 

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
 

entra enterprise apps.png

 

Click on New Application

new application.png

 

Click on Create your own application

create app.png

 

Name the application and ensure the Non-gallery option is selected. Click Create.

Example:

enterprise app name.png

 

Navigate to Manage > Users and groups

app users and groups.png

 

Click on Add user/group
 

add user_group.png

 

Under Users and groups, click on the link for None selected. Click the Autopilot User group created earlier and click Select.

Example:

add auto pilot group.png

 

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:

group object id.png

 

Navigate to Manage > Single sign-on

manage SSO.png

 

In the Basic SAML Configuration section, click Edit.

basic saml config edit.png

 

Paste the entityID and Location values recorded from XML file earlier in Step 6 and click Save.

Example:

saml identifiers.png

 

In the Attributes & Claims section, click Edit.

attributes and claims edit.png

 

Click on Add a group claim

add group claim.png

 

  • Select the Security groups radio button
  • Select Group ID in the Source attribute drop-down
  • Click Save
security groups claim.png

 

You should see the group claim added under Additional claims section

Example:

additional claims.png

 

Close the window and you should now see the groups claim added with a value of user.groups

Example:

groups added.png

 

In the SAML Certificates section, click the Download link for the Federation Metadata XML and save the file. 

Example:

saml certs.png

 

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.

saml import.png

 

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.

saml idp groups.png

 

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:

saml idp add group.png

 

Select the Attributes tab and click Add.

saml idp attributes add.png

 

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:

add attribute values.png

 

** 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.

 

add warning.png

 

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:

idp advanced settings.png

 

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

mdm app registration new.png

 

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:

mdm app registration name.png

 

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:

pan admin cert export view.png

 

Select the Export Certificate Only radio button, click Export,  and save the file to a secure location

export cert only.png

 

With the certificate selected, click on the View button

Example:

pan admin cert export view.png

 

Locate the SHA1 Fingerprint value and record it for use in a following step

Example:

cert sha1 fingerprint.png

 

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

entra app certs and secrets.png

 

Select the Certificates tab and click the Upload certificate button

entra upload cert.png

 

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:

cert upload file.png

 

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:

entra cert example.png

 

Example Subject from the ISE Admin Certificate:

ise admin cert subject.png

 

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

entra api permissions.png

 

Click the Add a permission button

entra add api permission.png

 

Select Intune

intune apis.png

 

Select Application Permissions

intune app permissions.png

 

Use the search bar to locate and select the get_device_compliance permission and click Add permissions

intune compliance permissions.png

 

Click the Add a permission button again

Select Microsoft Graph and Application Permissions

intune app permissions.png

 

Use the search bar to locate and select the Application.Read.All permission and click Add permissions

app read all permission.png

 

Remove any other default permissions and click Grant admin consent for <tenant>

Example:

grant admin consent.png

 

Select the Overview blade, and record the value of the Application (client) ID for later use:

Example:

mdm app overview.png

 

Click the Endpoints button

endpoints button.png

 

Record the value for the OAuth 2.0 token endpoint (v2) for later use

Example:

oauth token endpoint.png

 

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.

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

 

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:

ise mdm 1.png
ise mdm 2.png

ise mdm device id.png

 

Click the Test Connection button to ensure that the connection is successful and click OK

ise mdm connect success.png

 

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

intune enrollment.png

 

Select the Windows tab, scroll down to the Windows Autopilot section and click the Enrollment Status Page link

windows autopilot options.png

 

Click Create

esp create.png

 

On the Basics tab, provide the Name and (optional) Description and click Next

Example:

esp profile basics.png

 

On the Settings tab, define the settings appropriate for your environment and click Next

Example:

esp profile settings.png

 

On the Assignments tab, click Add Groups and select the Group(s) to which you want the ESP Profile assigned and click Next

Example:

esp profile assignments.png

 

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:

esp config 1.png
esp config 2.png

 

Intune Autopilot Deployment Profile

Navigate back to the Enrollment page, scroll down to the Windows Autopilot section and click the Deployment Profiles link

intune dp.png

 

Click Create Profile and select Windows PC

dp create profile.png

 

On the Basics tab, provide the Name and (optional) Description and click Next  

Example:

dp basics.png

 

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:

dp oobe 1.png
dp oobe 2.png

 

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:

dp groups.png

 

On the Review + create tab, confirm the settings are correct and click Create

Example:

dp review 1.pngdp review 2.png

 

Intune Autopilot Devices

Navigate back to the Enrollment page, scroll down to the Windows Autopilot section and click the Devices link

autopilot devices.png

 

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:

autopilot device surface.png

 

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

intune compliance policy.png

 

Click Create policy

create policy.png

 

Select the Platform type for Windows 10 and later and click Create
 create policy win.png

 

On the Basics tab, provide the Name and (optional) Description and click Next

Example:
policy basics.png


On the Compliance Settings tab, expand the System security section, locate the Device Security > Firewall option, select Require and click Next

Example:

firewall required.png

 

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:

policy assign.png

 

On the Review + create tab, confirm the settings are correct and click Create

Example:

policy review 1.png

policy review 2.png

 

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

device config.png

 

Click Create and select New Policy

create new policy.png

 

  • 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

 

trusted cert platform.png

 

On the Basics tab, provide the Name and (optional) Description and click Next

Example:

trusted cert basics.png

 

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:

trusted cert config settings.png

 

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:

trusted cert assign.png

 

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:

trusted cert review 1.png
trusted cert review 2.png

 

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

device config.png

 

Click Create and select New Policy

create new policy.png

 

  • 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

 

pkcs cert platform.png

 

On the Basics tab, provide the Name and (optional) Description and click Next

Example:

pkcs cert basics device.png

 

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:

pkcs cert config device 1.png
pkcs cert config device 2.png

 

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:

pkcs cert assign device.png

 

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:

pkcs cert device review 1.pngpkcs cert device review 2.png

 

User PKCS Certificate Profile

In the Microsoft Intune admin center, navigate to the Devices > Manage Devices > Configuration blade

device config.png

 

Click Create and select New Policy

create new policy.png

 

  • 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

 

pkcs cert platform.png

 

On the Basics tab, provide the Name and (optional) Description and click Next

Example:

pkcs cert basics user.png

 

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:

pkcs cert user config 1.png
pkcs cert user config 2.png

 

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:

pkcs cert user assign.png

 

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:

pkcs cert user review 1.png
pkcs cert user review 2.png

 

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

win11 setup new connection.png

Select Manually connect to a wireless network and click Next

win11 manual wifi.png

 

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:

win11 wifi name.png

 

Click the Change connection settings link

win11 change settings.png

 

Click the Security tab

Select the network authentication method of Microsoft: Tunnel EAP from the drop-down box and click Advanced Settings 

Example:

win11 adv settings.png

 

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

win11 user or computer.png

 

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:

win11 teap settings.png

 

Under the Primary authentication method, click Configure 

win11 teap primary config.png

 

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:

win11 teap user settings.png

 

Click the Advanced button

win11 teap user settings adv.png

 

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:

win11 teap user cert selection.png

 

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:

win11 wifi export.png

 

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

device config.png

 

Click Create and select New Policy 

create new policy.png

 

  • Select the Platform type for Windows 8.1 and later
  • In the Profile type drop-down box, select Wifi and click Create

 

intune wifi profile create.png

 

On the Basics tab, provide the Name and (optional) Description and click Next

Example:

intune wifi profile basics.png

 

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:

intune wifi profile config settings.png

 

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:

GregGibbs_1-1738723665377.png

 

On the Review + create tab, confirm the settings are correct and click Create

Example:

intune wifi profile review 1.png
intune wifi profile review 2.png

 

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

ise cap add.png

 

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:

ise cap config.png

 

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 wireless build name.png

authz profile wireless build acl.png

 

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)

Example:

authz profile build redirect.png

** 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:

ise authZ profile build redirect url filter.png

 

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:

auth profile reauth.png

 

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:

ise policy set build.pngise policy set corp.png

 

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:

ise build authc policy.png

 

Define the Authorization Policies for this Policy Set.

Example:

ise build authz policy.png

 

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:

ise corp authc policy.png

 

Define the Authorization Policies for this Policy Set.

  • Note that similar matching conditions as above are used to differentiate from other session flows.

 

Example:

ise corp authz policy.png

 

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.

ise live logs tech stage.png

 

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. 

ise live logs user failed stage.png

 

The following screenshots show the ISE Detailed Live Logs for this stage of the Autopilot build

user failed stage detail logs 1.png
user failed stage detail logs 2.png

 

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.
 

wlc reauth timer user failed.png

 

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.
 

ise live logs user cert enrolled.png

 

The following screenshot shows the Wireless client session details on the WLC, specifically showing the change in Re-Authentication Timeout.
 

wlc reauth timer user cert enrolled.png

 

The following screenshots show the ISE Detailed Live Logs for this stage of the Autopilot build
 

user stage detail logs 1.png
user stage detail logs 2.pnguser stage detail logs 3.png
user stage detail logs 4.png
user stage detail logs 5.png
user stage detail logs 6.png

 

The following screenshot shows the Device Summary information in Intune after the User stage of the Autopilot build was completed
 

intune device summary.png

 

The following screenshot shows the assigned Device Compliance Policies in Intune
 

intune device compliance.png

 

The following screenshot shows the assigned Device Configuration Profiles in Intune after the User stage of the build was completed
 

intune device config.png

 

Greg Gibbs
Cisco Employee
Cisco Employee