Elevate AVD and Windows 365 access with insider tips for IGEL OS

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. At first glance, this offers a broad result; let’s say that you want to restrict access to your AVD environment to Linux OS only, 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 1^st/3^rd 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 1^st-party AppID is an AppID created by Microsoft and trusted by every tenant in Azure by default.
• A 3^rd-party AppID is an AppID created by partners and supplied with their 3^rd-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 rule sets will then grant access to backend services.  The IGEL AVD Client is predefined, with a 1^st-party AppID, while the IGEL Windows 365 App is predefined with a 3^rd-party AppID.

IGEL AVD Client comes with a 1^st-party AppID
As the IGEL AVD Client comes with a 1^st-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.

Consent required for IGEL Windows 365 App
The IGEL Windows 365 App, though, comes with a predefined 3^rd-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 reference 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
3. 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 IGEL AVD Client
   Don’t worry; the AppID you see on the screen has already been deleted 😊
4. Click your new App
5. 
   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
6. Request API permissions
   
   1. Select Delegated Permissions
   2. Make sure that Access – Access Windows Virtual Desktop  is checked
   3. Click Add permissions
7. The result should look like this:
   
8. 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
      
      
   2. 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
   
   
3. 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.

Stay tuned to Fred’s Tips & Tricks blogs for the latest in IGEL with Microsoft AVD and Windows 365.

#WindowsintheCloud #identityaccessmanagment #IGELOS #azurevirtualdesktop #windows365 #euc #daas