Traditionally IT administrators spend a lot of time on building and customizing OS images, compatibility testing with various device makes and models etc. Every device typically goes through a re-imaging process with additional pre and post validation to make sure it is ready for use in the field. This process implies major cost and time effort.
Windows Autopilot is a collection of Microsoft technologies working in concert that help to simplify and streamline the bulk deployment, setup, and configuration of Windows 10/11 devices in organization to ensure they are provisioned and locked down according to corporate standards. Autopilot also can be used for device reset, repurpose and recovery.
 |
Windows Autopilot enables customers to:
- Recognize company owned devices and associate them with appropriate enrollment workflows and configuration profiles.
- Automatically join devices to Entra ID.
- Auto-enroll devices into MDM services such as Intune.
- Customize Out of Box Experience (OOBE) content specific to the organization.
More information about Microsoft Autopilot can be found here: https://docs.microsoft.com/en-us/mem/autopilot/windows-autopilot
.
How does Device Prelogon Access Work
A Prelogon connection operates on a machine-level context, therefore traditional interactive authentication methods won’t be available. The Netskope Client gets preconfigured and rolled out with a tenant identification token. This token helps Netskope Private Access to process incoming requests based on the policies configured in your Netskope UI. Factor that the token is shared across the entire Netskope tenant and its accidental or malicious loss may result in unauthorized access to Active Directory and/or other resources exposed for prelogon connectivity.
Netskope highly recommends enabling a safeguard mechanism against accidental token loss or disclosure. This safeguard mechanism represents an additional authentication factor which can be extracted from the machine context for validation of the machine certificate.
The Autopilot enrollment process may include an additional phase that will trigger machine certificate generation, signing by Active Directory CA, and distribution to the enrolled devices via Intune. Eventually the device that just completed the Autopilot enrollment process will have a unique machine certificate which will be mandatory for origination of prelogon tunnel.
 |
Netskope performs cryptographic validation of the machine certificate to ensure it is not forged and is issued by the trusted internal enterprise CA (such as Active Directory Certificate Authority). The prelogon tunnel will be established only after successful validation.
Windows Autopilot Hybrid Entra ID
Many organizations heavily rely on on-premises Active Directory capabilities, such as a Group policy, authentication (Kerberos and NTLM), and file sharing services (SMB, DFS). While there is a desire to adopt modern device management framework such as Autopilot, it is important to retain an existing set of technologies and ensure its compatibility with on-premises active directory infrastructure.
There are a few different types of Windows Autopilot profiles aiming to address different deployment scenarios. This article is covering the Autopilot type Hybrid Entra Join. In this scenario, Autopilot adds the device to an on-premises active directory and performs device enrollment into Intune.
 |
The above high level architecture diagram illustrates critical components required to enable Autopilot Hybrid Entra Join. More information about prerequisites and deployment steps can be found in this Microsoft article: https://docs.microsoft.com/en-us/mem/autopilot/windows-autopilot-hybrid
Secure Connectivity to an On-premises AD via Netskope
One of the biggest benefits of Autopilot based enrollment is an accelerated timeline for the user to onboard with their IT-issued endpoint(s) in their possession. Devices can be shipped to users right from the manufacturer, bypassing centralized IT organization. A user just needs to unbox the device, connect to power and the local Wi-Fi network, enter corporate credentials, and the Autopilot process will take it from there.
The result of the Autopilot enrollment process would be a fully provisioned hardened device ready for business use. It will not have any local accounts configured; a user must use domain credentials as the only way to access a device. There are no cached credentials on the device after the enrollment is complete, therefore there must be connectivity to Active Directory at the time of initial login. For field based devices this represents an architectural challenge which Netskope Private Access (NPA) is uniquely positioned to solve.
Devices with a pre-installed Netskope Client would be enabled to access Active Directory services in a secure least privilege manner via Netskope Private Access (NPA). A Netskope client with necessary configuration parameters can be installed by Intune as a part of the Autopilot enrollment process.
 |
After successful Autopilot enrollment, a user is presented with the standard Windows login screen. At this point user context and permissions is not yet known (because a user has not logged in yet), so Netskope Private Access establishes a Prelogon tunnel specifically designed for accessing critical infrastructure services out of the machine-level context.
 |
After successful authentication, the Netskope Client collects the user’s identity and switches into user tunnel mode, which opens broader access to enterprise applications and services.
 |
Configure Windows Autopilot
This document assumes your Windows Autopilot implementation is already operational. Validating correctness of device enrollment through the Autopilot process while local connectivity to Active Directory is present is recommended. Subsequent steps described in this document will enable the same Autopilot experience for the device in the field. Detailed instructions on how Autopilot should be configured are available on the Microsoft documentation portal:
https://docs.microsoft.com/en-us/mem/autopilot/windows-autopilot-hybrid
https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/demonstrate-deployment-on-vm
User Accounts Enrollment and Provisioning with Netskope
User accounts associated with Autopilot deployment should be synchronized with the Netskope UI so that user provisioning and enrollment can be enabled. More information about specific configure steps can be found in this Microsoft article:
Deploy the Netskope Client via Intune
The following steps are required to include Netskope client deployment as a part of Autopilot deployment process:
- Enable prelogon in the Netskope Tenant. In the Netskope UI, go to Settings > Security Cloud Platform > Netskope Client > Client Configurations. Click on the appropriate Client Configuration, and enable Prelogon for Private App Segments. Create an arbitrary prelogon username, like
autopilot@prelogon.netskope.com.This prelogon username is used as a service account inside the Netskope tenant and should not be provisioned nor synchronized with Entra ID. It will be automatically added to the list of users in the Netskope UI and can be used for configuration of real-time access policies for private apps. Large scale deployment may include several Client Configurations associated with specific Groups or OU, and they will have individual prelogon usernames.
- Click Save.
- Add the Netskope Client in to Intune. Refer to the specific configuration steps described and this article /en/microsoft-intune.html. In order to enable Autopilot, use an additional argument with the prelogon username appended so the entire command line argument string looks like this:
host=addon-corp.goskope.com token=<org ID> enrollauthtoken=<Authentication Token> enrollencryptiontoken=<Encryption Token> prelogonuser=autopilot@prelogon.netskope.com /qn
- Click Next. Make an assignment with the appropriate group to be used for Autopilot deployment. Click Next and then Create.
Configure Netskope Private Access for Windows Autopilot
The section explains how to configure Netskope Private Access to enable Autopilot enrollment for devices in the field. Performing thorough testing for a test group of users before a full deployment is recommended.
- Create Apps Definitions for Active Directory services according to this article: /en/netskope-private-access-for-microsoft-active-directory-domain-services.html
- If a Distributed File System (DFS) is expected to be used by users enrolled into Autopilot, associating DFS configuration objects with prelogon user accounts is recommended. More information about DFS configuration forNetskope Private Access can be found in the article /en/netskope-private-access-for-smb-and-dfs-services.html
- Create a Private Access Policy. In the Netskope UI, go to Policies > Real-time Protection> New Policy and select Private App Segment Access. In the Source section, select the user you created earlier (
autopilot@prelogon.netskope.com). For Destination, in the Private App Segment dropdown list, select the App Definitions created previously corresponding to Active Directory Services.
- Provide a name for the policy and click Save. Make a decision about policy placement according to the existing hierarchy. More broad access control policies should be towards the bottom of the policy table. If you change the order of the policies, click Save again.
- Click Apply Changes.
After completion of the above steps, full enrollment for devices in the field should be operational.
Security Considerations for Prelogon Connectivity
Autopilot deployment implies supporting connectivity to Active Directory services at the time when user context is not yet known. The above configuration relies on access control based on prelogon username and org-id token. If those values get compromised, malicious actors could use them to gain unrestricted access to Active Directory services. The Netskope Client can be downloaded on the internet and installed with the above installation parameters, which would pave a way for potential attackers to enumerate Active Directory configuration objects, attempt to exploit known vulnerabilities, perform password brute force attacks, and many other undesired activities. Remediation of such an attack could be challenging as changing a prelogon username would not be considered as a strong measure.
Based on this factor, Netskope considers a pair of prelogon username and org-id token as just identification parameters. Netskope Private Access supports strong authentication for prelogon and Autopilot use cases that can be implemented based on cryptographic validation of unique device machine certificates.
For secure generation and distribution of machine certificates please refer to your Microsoft documentation for SCEP deployments.
Netskope Private Access Enforcement-based Machine Certificates
After configuration for machine certificate generation, signing and distribution within Intune and Autopilot is complete, you need to modify Netskope Private Access configuration in order to perform validation and enforcement.
In the Netskope UI, go to Settings > Security Cloud Platform > Netskope Client > Devices and click Client Configurations. Click on the appropriate Client Configuration, and in the Device Certificate Authority section, upload the CA certificate. When finished, click Save.
The above configuration instructs the Netskope Client, as well as the Netskope Management Plane (MP), to perform cryptographic validation of the machine certificate associated with the device enrolled through Autopilot. The Netskope client performs analysis of machine certificate properties, validity period, revocation status (if enabled in Netskope console and exposed for the Netskope MP to access).
Additionally, Netskope client encrypts an arbitrary dataset with the use of the private key stored on the device, and will forward it to the MP along with non-encrypted hashed dataset. The Netskope MP performs dataset decryption with the public key and compares the resulting values. If the two values match, the result is successful cryptographic validation.