This article explains how to enable prelogon for Windows endpoints to access resources prior to user authentication on the Windows endpoint. This functionality is commonly used to access domain controllers, allowing Windows endpoints to update and/or reset their passwords when expired. The following instructions assume NPA has been set up correctly and currently provides reachability to the AD DC.
Note
Prelogon is only supported on Windows devices.
There are two contexts in which an endpoint can establish a tunnel to NPA using the Netskope Client:
- In the prelogon context, the user has not yet authenticated to the Windows endpoint. The prelogon user is used to authenticate the device itself to NPA to facilitate limited access to resources.
- In the user tunnel context (sometimes referred to as postlogon), the user has authenticated to the Windows endpoint and logged on. The Netskope Client seamlessly assumes this authentication and evaluates all subsequent user-generated traffic against user policies.
Important
Be sure to evaluate existing access policies to prevent overexposure before prelogon is enabled. Do not use any user in a policy to prevent overexposure to prelogon.
Prerequisites
The requirements for using prelogon authentication are:
- Complete the recommended AD DS configuration following these instructions.
- Access to a Windows Endpoint with permissions to install the Client.
- Some device posture criteria are not applicable if the user is a prelogon user. You should consider additional controls such as device cert validation and/or CRL validation for prelogon access.
Important
Using Device Classification as a Criteria in policies with prelogon users assign to it will always show prelogon users as unmanaged.
Note
Always On Always Connected (AOAC) is enabled by default when Prelogon is enabled.
Use Cases
Purposes for using prelogon authentication include:
- Enable a first time user on Windows to join a domain as well as reset their password.
- Enable a PC to immediately mount network drives after boot up.
- Provide Always On Security, even when a user is not logged in.
Workflow
To use Prelogon authentication:
- Create or use a steering configuration.
- Configure the Netskope Client.
- Create a local user.
- Create Real-time protection policies.
Confirm the Steering Configuration for Prelogon Authentication
In order for the Netskope Client to steer traffic destined for Private Apps and servers, such as a domain controller, the correct steering method must be applied. If a configuration is already present and globally applicable, this setting can be modified by selecting the Edit button at the top right. Note that any change to this configuration will impact user traffic, limited to the scope of users/groups configured for these changes. We recommend to limit the scope of such changes in production environments. Ensure that the Client is configured to steer private apps:
- Go to Settings > Security Cloud Platform > Steering Configuration and open or create the configuration to be used for Prelogon Authentication.
- Confirm the user/user group.
- Specify the Netskope Client will steer private apps.
- Select and enable Private App Segments.
- Click Save.
Configure the Netskope Client for Prelogon Authentication
After completing the above steps, and have verified that the Client is able to authenticate successfully, the Client configuration should be tuned to meet the use case and user experience requirements of the environment in which it is being deployed.
The Client Configuration allows the Netskope cloud to push updated Client versions and behaviors to endpoints transparently. Prelogon functionality requires R94 or later.
- Go to Settings > Security Cloud Platform > Client Configurations and click New Client Configuration. Create the Device configuration to be used for Prelogon Authentication.
- Go to the Private App Segment tab to set Client behaviors regarding traffic handling. This is also where you can enable prelogon, and upload a PEM file with a CA certificate to authenticate against Clients if one is preferred. If the Device Certificate is issued by an Intermediate CA, then just the Issuing CA certificate needs to be uploaded, not the entire chain.
Note
To use PKI, additional work is required outside of the Netskope Admin Console. Each device authenticating to a Client Configuration with PKI enabled must have a device certificate available.
- Enable Prelogon for Private App Segments.
- Enter a prelogon username. Note the email address, which always ends with
@prelogon.netskope.com. This is used to select a local user for prelogon in a Real-time Protection policy.Note
The user needs to be different for each Client config. For example:
- Client Config1: user1@prelogon.netskope.com
- Client Config2: user2@prelogon.netskope.com
The Prelogon user configured through the Client configuration will be created as a member of the group to which the Client configuration is assigned.
For MSIEXEC command information, go to the Prelogon Connectivity list in the Netskope Client Deployment Commands section.
If Secure Enrollment is enabled, to enable prelogon and deploy the enroll the auth token/enroll encryption token with one msiexec command, use:
msiexec /I NSClient.msi host=<addon URL> token=<orgID> tenant=<tenant-name> domain=<tenant-domain-name> installmode=IDP mode=peruserconfig enrollauthtoken=<auth token> enrollencryptiontoken=<encryption token> prelogonuser=<user>@prelogon.netskope.com
When both Prelogon and Secure Enrollment are enabled, you must deploy the token regardless of the mode in which the Client was installed. Failing to do so will result in the Prelogon user being unable to be provisioned. - To use a device certification authority, click Select File to upload the certificates in PEM format.
- To validate the device certificate against a Certificate Revocation List, enable Validate URL. The URL used to validate the device comes from the CA certificate.
- Enable Start Prelogon tunnel when user tunnel disconnects. This enables the Client to always try to re-establish the prelogon tunnel when the user tunnel switches from connected to disconnected, even when the user disables the Client.
Note
If you enable this option, users will not be able to fully disable the Client while using prelogon. To allow users to fully disable the client, do not check this box.
If you enable this option and Periodic Re-authentication for Private Apps is also enabled, when re-authentication expires, the Prelogon tunnel will not establish.
- Click Save.
Create a Real-time Protection Policy for Prelogon Traffic
Add the local user that will be used for prelogon to a Real-time Protection policy, and ensure that user has access to the private app defined previously. This will ensure the prelogon user can join the domain prior to the user’s successful authentication against the Netskope cloud.
- Go to Policies > Real-time Policies and select Private App Segment Access from the New Policy dropdown list.
- For Source, select the user(s) with
@prelogon.netskope.comin the email address, and use Client for the Access Method. - For Destination (Private App Segment is preselected). Select the Private App Segment for prelogon users from the dropdown list.
- For Profile and Action, use Allow.
- For Set Policy, enter a policy name.
- Click Save.
Create a Real-time Protection Policy for User Tunnel Traffic
After prelogon is enabled, a device tunnel is established leveraging the local user configured in Netskope and deployed with the Client. When the user logs into the Windows machine, the user credentials are carried over and then applied so subsequent traffic traverses the user tunnel, under the assumed authentication of the user that has logged into the endpoint. This seamless transition allows users to receive additional access beyond their prelogon state, by enforcing a separate set of policies tied to the user’s domain authentication. An example of such a policy is illustrated below, with the additional access to PrivateAppTest being granted to two domain-joined users.
- Go to Policies > Real-time Policies and select Private App Segment Access from the New Policy dropdown list.
- For Source, select the users and use Client for the Access Method.
- For Destination (Private App Segment is preselected). Select the Private App Segment for user tunnel traffic from the dropdown list.
- For Profile and Action, use Allow.
- For Set Policy, enter a policy name.
- Click Save.
Prelogon Troubleshooting
This article describes the troubleshooting methodology for NPA Prelogon connectivity.
User Login
When a user cannot log in to Windows and device reboot does not help, an error similar to the image shown appears.
This error indicates that logon cannot be completed due to a lack of connectivity to Active Directory Domain Controllers. There are some common cases associated with the this error:
- A newly-provisioned device (for example, a brand new endpoint being onboarded via Windows Autopilot).
- A user’s password is expired and there are no other cached user profiles on the endpoint.
In both cases, there is a reliance on the NPA prelogon tunnel as a connectivity method to Active Directory. Due to observed behavior with a prelogon tunnel, a user can’t get access to the device and therefore cannot collect Netskope Client logs necessary for troubleshooting.
If another user’s cached profile is present or a local administrator account is configured, those credentials should be used to gain access to the device and collect Netskope Client logs. The following recommendations will guide the troubleshooting process in the event when it is not possible to logon to the device by any means.
Device Enrollment
Check device enrollment status. In the Netskope UI, go to Settings > Security Cloud Platform > Devices, click Add Filter and Show Pre-Logon Users, and select Yes. Other filter parameters can be used to narrow down the search, as well as the time period, at the top right corner.
Successfully enrolled devices within prelogon context will appear in the list with a _Prelogon suffix.
If an enrolled device is found in the list, the remainder of this section can be skipped.
If a device can’t be found in the list, it may indicate issues with the Netskope Client installation and/or enrollment. You will need to investigate the Netskope Client installation status and correctness of the configuration parameters. The following sections provide troubleshooting insights.
Research Netskope Client Installation Status
For Autopilot-driven deployments, Intune is able to report Netskope Client installation status. In the Intune UI, go to Devices > Windows > Device Name > Managed Apps, and in the Select User dropdown list, select Device without user.
In case of an unknown/failed installation status, we recommend that you manually reproduce the Netskope Client installation with the same command line arguments on a managed device. Managed device OS version and Netskope Client version should be mirroring the setup used within device management tools (like Autopilot, SCCM). You should be able to interface with the device directly without any device management tools. Information about successfully reproduced errors along with Netskope Client logs should be submitted to Netskope Support.
Research Correctness of Netskope Client Configuration Parameters
In order to successfully enroll within a prelogon context, the Netskope Client should be installed with certain command line parameters. You need to validate the correctness of those parameters and its syntax, as well as if they match with appropriate Netskope tenant configuration.
For Autopilot-driven deployments those arguments can be checked in the Intune UI. In the Intune UI. Go to Apps > Windows, select Netskope Client, and then click Properties. Validate the data and make sure there are no extra spaces, line skips, and other syntax issues. An example of the correct command line argument string is provided below.
host=addon-<tenant>.goskope.com token=<org-id token> prelogonuser=<user>@prelogon.netskope.com mode=peruserconfig /qn
More information about command-line arguments can be found here /en/netskope-client-for-windows.html.
Research Correctness of Netskope Tenant Configuration
We recommend that you examine the Prelogon configuration settings. In the Netskope UI, go to Settings > Security Cloud Platform > Devices and click on the appropriate Client Configuration.
Make sure that the prelogon username created in the Client Configuration matches with the one that is used within the command line parameters for the Netskope Client installation.
Attempt to Reproduce an Issue on a Managed Device
If all the above steps do not help you find a reason why the device can’t be enrolled, you will need to manually reproduce the Netskope Client installation with the same command line arguments on a managed device. You should be able to interface with the device directly without any management tools (like Autopilot, SCCM). After the installation, examine the status for Private Access by right-clicking Client Configuration.
If the status is reported as Private Access: Connected (User Tunnel), make sure the option Start pre-logon tunnel when user tunnel disconnects in the Client Configuration dialog is checked.
Disable the Netskope Client, and after a short while, check the Netskope Client configuration again. It should show the prelogon tunnel as connected.
If the prelogon tunnel state shows Disconnected or N/A, this confirms there is a problem on the managed device as well. Right-click on the Netskope Client and collect the logs bundle to share with Netskope Support.
Netskope Tenant Configuration for Prelogon
In the Netskope UI, go to Settings > Security Cloud Platform > App Definition >Private App Segments > Troubleshooter.
Select the required application from the dropdown list (like Active Directory), appropriate user name for prelogon Client Configuration and enrolled device, and then click Troubleshoot.
The Troubleshooter tool will evaluate the Netskope tenant configuration against a list of possible issues. List of the common issues are:
- For a given prelogon username, the Steering Configuration is not aligned with the Client Configuration.
- The Real-time Protection policy does not have the appropriate entries to allow connectivity to Active Directory resources.
- The Publisher can’t connect to Active Directory resources, or an incorrect Publisher is selected for a Private App.
- There are issues with machine certificate validation.
To learn more about the Troubleshooter tool, go to Private Access Troubleshooting.