Windows Autopilot with Private Access Prelogon
Windows Autopilot with Private Access Prelogon
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 Azure Active Directory (Azure AD) or Active Directory
- 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
.
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 helpsNetskope 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.
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 AD 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 Azure AD 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 Azure AD 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
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.
 |
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 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:
The following steps below 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 >Devices and click Client Configurations. Click on the appropriate Client Configuration, and enable Prelogon for Private Apps. Create an arbitrary prelogon username, like
autopilot@prelogon.netskope.com.This prelogon username is used as a service account inside Netskope tenant and should not be provisioned nor synchronized with Azure Active Directory. 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 applications. 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 https://docs.netskope.com/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-<tenant-name>.goskope.com token=<org-id 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 thenCreate.
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 a Private Apps definition for Active Directory services according to this article: https://docs.netskope.com/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 https://docs.netskope.com/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 Access. In the Source section, select the user you created earlier (
autopilot@prelogon.netskope.com). In the Private App dropdown list, select the earlier created Private Application definitions 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.
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.
This section covers an optional but highly recommended set of steps required for machine certificates generation, signing, distribution and enforcement, which improves security and reduces risks associated with unauthorized access over a prelogon tunnel. Your Active Directory Certificate Services shoud be already installed and integrated with other Active Directory components. If the process of generation and distribution of machine certificates is already established, some of the steps below may be skipped. The following steps are required to enable machine certificates generation and deployment
- Install Microsoft Intune Certificate Connector. Installation prerequisites as well as administration and lifecycle recommendations can be found in this Microsoft article: https://docs.microsoft.com/en-us/mem/intune/protect/certificate-connector-overview. During the installation process, you need to enable the following features: PKCS, PKCS imported certificates and Certificate revocation.
- After successful installation and integration with Azure AD/Intune, you need to verify successful registration with Intune. In the Intune UI, go to Tenant administration > Connectors and tokens > Certificate connectors to ensure the Certificate connector is present in the list and its status is active.
- Create a Certificate template in Active Directory CA. In Windows CA, go to and right-click on Certificate Template and click Manage.
- Right-click on the Workstation Authentication template and then click Duplicate Template. On the General tab, change the template name, for example, to
Autopilot. On the Request Handling tab, enable Allow private key to be exported.
- On the Security tab, click Add > Object Types, enable Computers, and then click OK.
- In the form Enter the object name to select, enter the computer name with the installed Intune Certificate Connector, click Check Names, and then click OK.
- Highlight the selected object on the top part of the dialog box and enable the Allow permissions for Read and Enroll.
- On the Subject Name tab select Supply in the request and click OK, Apply, and OK.
- Close the Certificate Templates Console window and right-click on the right pane of Certificate Templates section. Select New > Certificate Template to Issue. Select the just created template from the list and click OK.
- Export the CA certificate from Active Directory CA. In Windows CA, go to and right-click the CA name and select Properties.
- On the General tab, make sure Certificate #0 is highlighted and click View Certificate. Click on Details and Copy to File.
- Click Next, select Base-64 encoded X.509 (.CER) , and click Next. Specify a filename and path for export, click Next, and then click Finish.
- Add a CA certificate into Intune for deployment into enrolled devices. In the Intune UI, go to Devices – Windows – Devices > Windows > Configuration Profiles and click Create profile. In the Platform dropdown list, select Windows 8.1 and later, and in the Profile type dropdown list, select Trusted certificate and then click Create.
- Provide a name for configuration profile, like Autopilot CA cert, click Next, upload CA certificate exported in a previous step, and then select Destination store Computer certificate store – Root. Click Next, make an assignment with the appropriate group to be used for Autopilot deployment. Click Next and Create.
- Create a configuration profile in Intune triggering machine certificate generation for enrolled devices. In Intune UI proceed to Devices – Windows – Configuration Profiles – Create profile. In the Platform dropdown list, select Windows 10 and later, and in Profile type dropdown list, select Templates. In the Template name dropdown list, select PKCS certificate and click Create. Provide a name for the configuration profile, like Autopilot machine cert, and then click Next. Enter these configuration details:
- Key Storage Provider (KSP): Enroll to a Trusted Platform Module (TPM) KSP in present, otherwise a software KSP.
- Certification authority: FQDN of the server where the CA is hosted.
- Certification authority name: CA name, mentioned in step 3 of these instructions.
- Certificate template name: Template name created in step 3 of these instructions. Note that template name is case-sensitive.
- Certificate type:
Device - Subject name format:
CN={{FullyQualifiedDomainName}}. Other format options can be used. Options can be described in this Microsoft article https://docs.microsoft.com/en-us/mem/intune/protect/certificates-pfx-configure#subject-name-format - Subject alternative name: DNS and value
{{FullyQualifiedDomainName}}. Other options can be used as described in the Microsoft article mentioned above.
- Click Next and make an assignment with the appropriate group to be used for Autopilot deployment. Click Next, Next, and then Create.
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.
