Azure Virtual Desktop using external identities part 2
External Identities in preview for Azure Virtual Desktop part 2.
Hi, welcome back! In part 1 we discussed External Identities and the limitations and possibilities of this new Preview feature within Azure Virtual Desktop. In part 2, we will of course talk about building a test into the technical setup that makes this preview possible.
Let's be clear right away, building this preview feature in Azure Virtual Desktop is good to try and test and ideal for setting up some proof of concepts, but it is certainly not yet suitable for use in production environments.
The limitations of the functionality are to great to incorporate into production environments, but it is certainly a good and promising step forward.
What do we need to set this up.
What do we need to set up a session host for External Identities? This is a good question and is actually not difficult to answer, because the configuration is not much different from setting up an Entra Joined Azure Virtual Desktop environment.
More information can be found in this article, i mention this article because this has the most simularities with the same prerequisites for building a Hostpool with External Identities.
- Single Sign-On configuration is needed.
- Virtual Machine User Login role must be assigned to users or group to grant login access to the session hosts.
- Add targetisaadjoined:i:1 to the properties of the host pool so that it knows you are using entra joined session hosts.
- In a hostpool, only one configuration setting can be used, so an entra joined host cannot be in the same pool as a domain joined session host, otherwise it will not work.
But what exactly do you need to start this Azure Virtual Desktop as an External Identity?
That's a very good question because the Microsoft documentation indicates that the Windows APP is suitable for this, but in practice I find that the app cannot handle the redirect properly and I can only get it to work in the browser using https://windows.cloud.microsoft/. Microsoft has now added a new rule to the documentation stating that a registry tweak is required to get the Windows app working, the documentation states the following:
However, I haven't been able to get this to work yet. I expect that this will be made possible in the upcoming weeks with some updates for the Windows APP, but for now I am using the browser.
I have put the registry settings below, so if you can get this to work let me know!
New-Item -Path "HKLM:\SOFTWARE\Microsoft\WindowsApp\Flights" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WindowsApp\Flights" -Name "EnableIdSignInUx" -Value 1 -Type DWord
A browser can be used to log in to Azure Virtual Desktop, but you will need a few extra things to ensure you are directed to the right environment.
I'm not entirely sure why, but I suspect it has to do with the existing profile your organization is linked to. However, even private browsers don't solve this problem. As a workaround, you will need to include the workspace objectID and application objectID in the URL. I will show you how to do this.
What are the settings you need to have to login succesfully?
As I mentioned in part 1, there are things you need to take into account, which are of course also described in Microsoft's documentation.
- SSO must be enabled on the host pool.
- Session hosts must have at least Win11 Multi Session 24H2 installed.
- Virtual machine login user role needs to be applied.
- Entra joined session hosts.
- targetisaadjoined needs to be enabled.
Below are a few screenshots showing the most important settings of the hostpool and sessionhosts:
sso enabled hostpool:
targetisaadjoined needs to be enabled in the properties:
virtual machine login needs to be set on the resource group:
Do we need to do something else to login?
Yes! let me explain. I'm writing my blog based on an existing host pool. To give my external identity access, I first need to send it an invitation in Entra ID. Once it's accepted, the external identity need to be added to the application group through a direct assignment or linked Entra ID group.
Normally, Azure Virtual Desktop will be available to regular users in your own organization within the Windows APP or browser, but with an external identity, this does not happen immediately. I will demonstrate this for you.
I invited a dummy user to my own tenant and added the necessary permissions. When everyting is being accepted, I start the Windows APP and log in using the Dummy guest, I then get an error message:
When I try it now with a browser and go to https://windows.cloud.microsoft/webclient/avd and try to log in, using the dummy guest account, I will not see a desktop and will receive the almost the same error message:
At this moment, apart from the registry key mentioned by Microsoft, I have not yet found a working solution for the Windows APP, but there is a solution for the browser.
We need to add some additional information in the url. We do this by including the workspaceobjectIDs, applicationgroupobjectIDs and TenantID in the Azure Virtual Desktop URL. The commands you can use in PowerShell to get this information are part of the Az.DesktopVirtualization Module.
- Connect and authenticate using your credentials in Powershell.
connect-azaccount
- Find the Application Group objectID
Get-Azwvddesktop -resourcegroupname "rg-pof-avd-test-weu" -applicationgroupname "vdag-pof-avd-weu"
- Find the Workspace objectID
Get-AzWvdWorkspace | FT Name, FriendlyName, ObjectId
- Check your TenantID
Your URL looks like the below one, the only thing you need to fill in is the TenantID in the below URL and change the application and workspace ID's with the one you are using.
URL will be in this format: https://windows.cloud.microsoft/webclient/avd/workspaceid/applicationgroupid/tenantid
- When you use the URL you will see that it connects to the Azure Virtual Desktop:
Sign in and you will have an desktop:
Things to keep in mind.
I hope you realize that this is not yet ready for production, but it is certainly a good start. FSLogix, for example, is not supported at this time, but there are ways to get this working, such as configuring FSLogix with the use of a SAS token under a system account, I will give that information in part 3 of this blogpost series.
However, for suppliers, third parties, contractors and customers, this solution will be perfectly suited to help them access an environment in a secure and effective manner.
To wrap things up.
You will certainly have to wait a while before this functionality is ready for production, but it is definitely promising. At this point, there are already some use cases you could consider implementing this feature.
Thanks for reading my blog, and see you next time!