Windows 365 or Azure Virtual Desktop and Netskope Client - Best Practices

In order to ensure the correct functioning of the Azure Virtual Desktop or Windows 365 machine when deploying the Netskope Agent on it we have to take care of some Steering Exceptions:

1. MANDATORY: Destination Location Steering Exceptions for Azure Virtual Desktop RDGateways IPs (Remote Desktop Gateways service tags related IPs)

2. OPTIONAL: Destination Location Steering Exceptions for Azure Virtual Desktop Monitoring IPs (Azure Monitor service tags related IPs)

3. OPTIONAL: Application/Process (Certificate Pinned Application) Steering Exceptions for Azure Virtual Desktop agents running on the Virtual Desktop

Destination Location Steering Exceptions

Microsoft provides a Json file with all the Azure destinations at the address: https://www.microsoft.com/en-us/download/details.aspx?id=56519

Unfortunately though this list contains all the destinations used by the Azure infrastructure, divided by “Service Tags” (services). As we definitely don’t want to exclude all the Azure destination from the steering we must only take the destinations involved with the Virtual Desktop infrastructure.

The Service Tags we must consider for the steering exclusions are the following:

1. The IP addresses of the Virtual Desktop Gateways that can be found under the “WindowsVirtualDesktop” Service Tag.

2. To the above we must additionally add the traffic destined to the IPs 169.254.169.254/32 and 168.63.129.16/32 (these 2 addresses are common for AVD and Windows 365 deployments)

3. The IP addresses of the monitoring traffic that can be found under the “AzureMonitor” Service Tag.

All the above Service Tags (and IPs) are mentioned on the article: https://docs.microsoft.com/en-us/azure/virtual-desktop/safe-url-list

To use the Python script:

1. Download the latest Json file from the Microsoft Website at the address: Azure IP Ranges and Service Tags – Public Cloud

1. Place the Json file and the Python script under the same folder, and rename the Json file as “AzureIPs.json”

2. Run the Python script from a privileged command prompt (tested both on MAC and Windows machines)

3. Verify the content of the file “AzureWVD.csv” that should have been created on the same folder. It be a 2-lines file where the first line starts with "AzureWVD" and the second with "AzureMonitor"

Once we have the CSV, in order to create the desired steering exceptions with it do the following:

1. On the Netskope UI select “Policies” - “Network Locations”

2. Select “New Network Location” - “Multiple Objects”

3. Upload the file “AzureWVD.csv”

4. Verify the newly created “AzureWVD” and “AzureMonitor” network location to see if they contain the imported IPs

5. Apply the changes clicking on “Apply changes”

6. Open the Netskope Setting UI and navigate to “Security Cloud Platform” - “Steering Configuration”, select the Steering Configuration (by default the “Default tenant config”) and select the “EXCEPTIONS” tab

7. Select “New Exception” - “Destination Location”

8. Select the “AzureWVD” destination location.

9. OPTIONALLY, if you want to exclude from steering the Virtual Desktop Agent traffic for monitoring purposes select the “AzureMonitor” destination location too. By default we don’t recommend to exclude this traffic to avoid excluding too many destinations that may be used or repurposed in the future for more activities that we would like to monitor.

10. Select “Treat like local IP address” and provide a description like “Microsoft Azure VDI”

11. Click “Save”

OPTIONAL - Application Steering Exceptions

Azure Virtual Desktops are installed with an Azure agent that runs several services performing many connections to different Azure services for different purposes. Excluding these agents from the traffic steering will ensure that the Azure communications performed by the agent won’t flow through Netskope. That said excluding the Azure agents traffic may lead to some loss of visibility as there can be some activities performed by the Azure agents we’d like to monitor. It’s not fully clear to us what potential activities the agents could perform, so we don’t recommend to exclude them from the steering, and we recommend to include the following exceptions only if the customer wants to send to Netskope the bare minimum of Azure traffic.

This optional second step is to configure a series of exclusions for specific Azure Virtual Desktop processes that run on the machine. Despite those are not properly Certificate Pinned Applications, as their traffic can technically be inspected, we can treat them as such to allow a bypass based on the service rather than sources/destinations.

The list of processes that we want optionally to exclude from steering is the following:

1. WindowsAzureGuestAgent.exe: Azure VM Agent service
2. WaAppAgent.exe: Azure RD Agent service
3. WindowsAzureNetAgent.exe: Azure Network Agent service
4. WindowsAzureTelemetryService.exe: Azure Telemetry Service
5. metricsextension.native.exe: Azure Monitor Agent
6. rdagentbootloader.exe: Azure Agent Bootloader

In order to create the Steering Exceptions

1. On the Netskope Settings UI navigate to “Security Cloud Platform” - “Steering Configuration”, select the Steering Configuration (by default the “Default tenant config”) and select the “EXCEPTIONS” tab
2. Click on “New Exception” and select “Certificate Pinned Application”
3. Click on the field “Certificate Pinned App = None” and select the “+” button to add the Application
4. On the “New Certificate Pinned Application” window select “Windows” as “PLATFORM” and starting from the first application from the list above fill the “DEFINITION” field with the service name and the “APPLICATION NAME” field on top with the description and click “Save”
5. At this point select the newly created application on the “Certificate Pinned App” field and write “*” (star) as “Custom Apps Domains” to include all the traffic that the application would generate, then optionally provide a description like “Microsoft Azure VDI”, and lastly click “Save”
6. Repeat the steps above for all the 6 processes listed above

Please also note that this procedure effectively removes the current steering bypass and a new one must be created !

In order to update the “AzureWVD” and “AzureMonitor” Network Destination lists do the following:

1. Download the latest Json file from the Microsoft Website at the address:Azure IP Ranges and Service Tags – Public Cloud

1. Place the Json file and the Python script under the same folder, and rename the Json file as “AzureIPs.json”

2. Run the Python script from a privileged command prompt (tested both on MAC and Windows machines)

3. Verify the content of the file “AzureWVD.csv” that should have been created on the same folder. It be a 2-lines file where the first line starts with "AzureWVD" and the second with "AzureMonitor"

Once we have the CSV, in order to create the desired steering exceptions with it do the following:

1. In the Netskope UI select “Policies” - “Network Locations”

2. Select “New Network Location” - “Multiple Objects”

3. Upload the file “AzureWVD.csv”. You’ll notice that the UI seems to indicate there are duplicated entries for “AzureVWD” and “AzureMonitor”. This is ok, the new ones will actually overwrite the old ones upon Applying the config !

4. Verify the newly created “AzureWVD” and “AzureMonitor” network location to see if they contain the newly imported IPs

5. Apply the changes clicking on “Apply changes”. You will notice that the duplicated entries will disappear as the new lists will overwrite the old ones

6. We must re-create the Steering Exceptions as the previous ones would be deleted upon the destination Location overwrite !

7. Open the Netskope Setting UI and navigate to “Security Cloud Platform” - “Steering Configuration”, select the Steering Configuration (by default the “Default tenant config”) and select the “EXCEPTIONS” tab

8. Select “New Exception” - “Destination Location”

9. Select the “AzureWVD” destination location.

10. OPTIONALLY, if you want to exclude from steering the Virtual Desktop Agent traffic for monitoring purposes select the “AzureMonitor” destination location too. By default we don’t recommend to exclude this traffic to avoid excluding too many destinations that may be used or repurposed in the future for more activities that we would like to monitor.

11. Select “Treat like local IP address” and provide a description like “Microsoft Azure VDI”

12. Click “Save”