Raise the level of security for your AVD and Windows 365 access – Make sure that ONLY your managed IGEL OS endpoints can access your environment – This is the Why and How!

By Fredrik Brattstig @virtualbrat

18 April 2024
Before we start, If you fall asleep while reading this blog and forget to finish reading til the end, you will miss the whole point! Information here will be very valuable for your company going forward.

When running your desktop workloads in the cloud, a piece of good advice will be to make sure that access is restricted to only the ones YOU want to be able to access your environment. You can achieve that by using conditional and contextual access. Looking at conditional access in Entra, you can limit access for specific platforms. It’s a rough limiter at first look; let’s say that you want to restrict access to your AVD environment to only Linux OSes, which means that no operating system other than Linux can access your resources. Well, that is still a pretty broad range of clients. You can then start limiting based on conditions using scripting to identify factors of your clients. IGEL is working on enabling Intune registration of IGEL OS clients, but let’s say that you want to take it to the next level already now. Let’s say that you really want to control the fact that ONLY your managed IGEL OS endpoints can access your AVD/Windows 365 resources. You can do that today, even without IGEL OS having Intune or conditional access capabilities. To build some understanding:

Entra Enterprise Applications and AppID registrations and 1st/3rd party AppIDs

An AppID in Entra represents how a client identifies itself when connecting to Entra services. AppIDs are then used to control user/group access and what permissions the app will have within an Azure tenant. AppIDs are categorized into 1st-party and 3rd-party AppIDs. A 1st-party AppID is an AppID created by Microsoft and trusted by every tenant in Azure by default. A 3rd-party AppID is an AppID created by partners and supplied with their 3rd-party applications, though customers can also register custom, unique AppIDs in their own tenant.

When it comes to Microsoft Entra, specifically looking at the use case of Azure Virtual Desktop (AVD) and Windows 365 (W365), client applications will present their AppID on the connection, and rulesets will then grant access to backend services.  The IGEL AVD Client is predefined, with a 1st-party AppID, while the IGEL Windows 365 App is predefined with a 3rd-party AppID.

As the IGEL AVD Client comes with a 1st-party AppID, it is trusted by any Azure Tenant and has the appropriate permissions in the tenant to access the backend services. From an admin perspective, no configuration is needed in Entra to allow the IGEL AVD Client to connect to AVD sessions. The IGEL Windows 365 App, though, comes with a predefined 3rd-party AppID that is not, by default, trusted by any tenants in Azure. This leads to a tenant admin needing to grant access for the AppID to be used by the owned tenant. This process is called consent. While consenting to the AppID, tenant admins will grant AppID access to the backend services. The consent process of the IGEL Windows 365 App is described in the IGEL Knowledgebase here:
https://kb.igel.com/cpc/1.1.90/en/troubleshooting-user-gets-prompt-need-admin-approval-on-igel-windows-365-startup-119880136.html

And referenced to Microsoft documentation here:
https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/user-admin-consent-overview

Registering your own Entra App Registration and assign its AppID to IGEL AVD Client

Entra admins can register unique intra-tenant Entra Applications, choose to set the permissions needed, and then consent to access on behalf of the company.
The new custom AppID can then be assigned to the IGEL AVD Client as an identifier, allowing you to ensure that all your managed IGEL OS endpoints connect to your AVD environment using a unique AppID. When writing this article, the IGEL Windows 365 App, with its 3rd party AppID, has a fixed AppID in the code, but that will change soon, and you will be able to add your custom AppID to the IGEL Windows 365 App too.

Let me show you how to create your own AppID in the Azure Portal:

  1. Log in to portal.azure.com with an Entra admin account that has the rights to manage App Registrations and Enterprise Applications
  2. Navigate to Microsoft Entra ID->App Registrations and click New Registration
  1. Name the application
  2. Redirect URI: set it to Public Client/native (mobile.. with the value https://www.wvd.microsoft.com/webclient
  3. Click Register to create the App
  1. Now your new App will be visible:

Pay attention to the Application (client) ID, as this is going to be needed when setting the AppID for the IGEL AVD Client
Don’t worry; the AppID you see on the screenshot has already been deleted 🙂

  1. Click you new App
  1. Click Add a Permission
  2. Select APIs my organization uses and type Azure Virtual Desktop in the filter box
  3. Select Azure Virtual Desktop
  1. Request API permissions
  1. Select Delegated Permissions
  2. Make sure that User Access – Access Windows Virtual Desktop in checked
  3. Click Add permissions
  1. The result should look like this:
  1. Now go to Microsoft Entra ID -> Enterprise Applications and select your App
    1. Click Grant admin consent for %tenant% – Walk through the guide that pops up with the end goal to Accept
  1. This is how it should look when ready!

You have successfully created a custom AppID, with the appropriate rights to access Azure Virtual Desktop, that we can assign to our IGEL OS AVD Client. Here is how that is done:

  1. Open the IGEL Setup on the local machine or the profile with the designated AVD session
  2. Goto System->Registry->App->AVD-> Sessions->%youravdsession%->Options->Workspace-0->client-app-id
  1. Set the Workspace Client Application Identifier to the Application ID of your new custom App registration

Cool! Now you have an Entra Enterprise app that is unique to your company and that the IGEL AVD Client uses to identify itself when connecting.  

But is this it??!? You might wonder.

Of course not!!! Let us look at the next chapter:

The Holy Grail (or any other preferred artifact)!

All the above information doesn’t look very useful at first look, but listen to this, this is when it all comes together:

The AppID that you have created is unique to our organization, and it should be treated as a company secret, in my opinion. The next step I practiced in my Azure tenant was to disable the Microsoft 1st-party AppID for the Azure Virtual Desktop Client. Disabling the 1st-party client access will remove the possibility of using ANY AVD client, whether it is Windows, Mac, Android, iOS, Linux, or even the HTML5 Web Client. After disabling the 1st-party client, ONLY my managed IGEL OS Endpoints, running the IGEL AVD Client with my custom AppID, can access my AVD environment. This is what everyone is looking for; organizations are trying to limit access to AVD resources, I’d argue that this is Conditional Access 2.0!
Make sure that you understand how to remove access to get to that information for your users. There should be a very limited number of people who know  the custom AppID!

Another thing to note: If you try to connect the IGEL AVD Client to a different tenant, the Azure login pages will clearly state the AppID trying to connect. If you want to protect your AppID, you can lock the IGEL AVD Client to specific domain names; this means you disallow the IGEL AVD Client to connect anywhere other than your designated Entra domain.

This is why the custom AppID is a company secret and will allow you to limit access to your AVD resources to ONLY your managed IGEL OS endpoints. You do not have to spend time making your conditional access policies complex, with inclusions and exclusions, etc. I’d argue that the solution in this article, together with Trusted IPs and MFA for external users, will make your environment rock solid!
Remember, even though we have created and applied a secret AppID, conditional access can still be used if you want the combination in the mix.

By the way, do you want to know how to disable the 1st-party AVD clients?

  1. In Azure Portal, Search for Azure Virtual Desktop Client:
  1. Select under Microsoft Entra ID, the Azure Virtual Desktop Client Service Principal
  1. In the Azure Virtual Desktop Client blade:
  1. Go to Properties and Select “No” for ‘Enabled for users to sign-in?’

That’s it!
(Don’t worry; you can enable usage of the 1st-party clients again if you, for any reason, need to do so)

If you happen to use a mix of IGEL OS and Windows endpoints, for example, that all need access to your AVD environment, the right answer is not be to enable the 1st-party clients again but try to figure out how to change the AppID Windows AVD client (or any other OS’es AVD client) identifies themselves as. I know how it is done 😊

That’s it for today. Now enjoy your super secure access control, relax, and continue using IGEL!

/Fred