1. Introduction
2. Single Sign-On
   1. Pre-Requisites
      1. Supported OS
      2. Kerberos Server Object
   2. Configuration
      1. Kerberos Server Object
      2. Enable Single Sign-On
   3. Testing
   4. Caveats
3. In-Session Authentication
   1. Pre-Requisites
   2. Testing
4. Conclusion

Introduction

One of the bugbears that many customers had with AVD, in the beginning, was the multiple login prompts and the lack of true Single Sign-On.

This is something that Microsoft has been looking into and the functionality for Azure AD Single Sign-On is actually in Preview at the moment.

This blog will look at the process to enable AAD SSO for authentication into the AVD environment and show the end-user experience.

I will also touch on the use of In-session passwordless authentication (another impressive preview feature!) to allow the use of Security Keys and Windows Hello for Business passwordless options within AVD sessions.

Single Sign-On

Pre-Requisites

Now in order to configure this there are a few pre-requisites that we need to look at.

Supported OS

Firstly, the session hosts must be running on one of the following OS versions

• Windows 11 Enterprise single or multi-session with 2022-10 Cumulative Updates for Windows 11 (KB5018418) or later installed.
• Windows 10 Enterprise single or multi-session, versions 20H2 or later with the 2022-10 Cumulative Updates for Windows 10 (KB5018410) or later installed.
• Windows Server 2022 with the 2022-10 Cumulative Update for Microsoft server operating system (KB5018421) or later installed.

Kerberos Server Object

In order for Single Sign-On to function we need to create a Kerberos Server Object. However, this is only required in the following circumstances:

• Sessions Hosts are Hybrid Joined
• Session Hosts are Azure AD-Joined and the environment contains Active Directory Domain Controllers

This Kerberos Server Object is created inside our Active Directory and published to Azure Active Directory.

This object is then used by Azure AD to generate Kerberos Ticket Granting tickets (TGTs) for your domain.

When a user logs in to Azure AD, this Kerberos Server Object is used to generate a partial TGT for the customer’s Active Directory domain. The TGT is returned to the user along with the Azure AD Primary Refresh Token.

The client then contacts Active Directory and trades the partial TGT for a fully formed TGT.

The user now has access to both Cloud-based resources via the Azure AD PRT and also On-Premises resources via the TGT.

Configuration

Kerberos Server Object

In order to create this object we need to install the AzureADHybridAuthenticationManagement PowerShell module

Install-Module -Name AzureADHybridAuthenticationManagement

We now need to create the object itself. The command itself is very simple and you just need to pass a few credentials and the domain name.

The below script will prompt for the logins as needed:

$domain = “<domain name>”

$cloudcreds = Get-Credential -Message “Please enter relevant Azure AD Global Administrator Account details”
$domainCreds = Get-Credential -Message “Please enter Active Directory Domain Admin details”

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCreds -DomainCredential $domainCreds

Once created you can check the Kerberos Server Object with the below command:

Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCreds -DomainCredential $domainCreds

Enable Single Sign-On

So with the pre-reqs sorted and the Kerberos Server Object created, we need to configure the Session Hosts to use Single Sign-On.

Thankfully this is an easy step. We basically just need to add a specific setting to the RDP properties of the Host Pool.

The setting we want can be set either via the GUI or manually by adding an entry to the Advanced settings (this is useful if you are running automated deployments)

Let’s go to the Host Pool in the Azure Portal and jump over to RDP Properties

Under the Connection information tab, there is an option for Azure AD authentication.

If we hover the mouse over the information icon, we can see this is the setting we want.

This setting will allow the Session Host to use Azure AD for Authentication and enable a single sign-on experience, exactly what we want.

Set this option to RDP will attempt to use Azure AD authentication to sign in to enable it.

Setting this will add Enablerdsaadauth:i:1 to the Advanced settings.

If you are setting the RDP properties by code, you can simply add this to your scripts to automate the setting.

Testing

So we have now set up the base configuration to allow Single Sign-On we need to test!

I’m going to open my Remote Desktop client and attempt to open the Test Desktop

The first time I attempt to open the Windows 10 GPU (AD) desktop I will see an Azure AD login prompt like below:

Because I have FIDO2 enabled on my account it will prompt me to Sign in with Windows Hello or a security key.

I’ll enter my Security Key PIN and then touch the security key when prompted.

You should then see a dialog asking you to Allow remote desktop connection. Click Yes to allow the session host to access your account and complete the sign-in.

You will be prompted with this message each time you connect to a new Session Host.

Azure AD will remember up to 15 hosts for 30 days before prompting again.

And then just like magic, it will log straight into the Session Host.

Subsequent logins will not need to be authenticated after the initial login.

Caveats

Obviously, as with any preview feature, using this feature comes with a caveat.

Due to the way Azure AD SSO works there is a limitation with regards to locking the remote AVD session.

As the Windows Lock screen doesn’t support Azure AD Authentication tokens or passwordless authentication methods the AVD remote session cannot be unlocked using Azure AD.

This causes a situation where when the remote session is locked the session will be disconnected and the user will receive a message like the one below:

In-Session Authentication

Also in preview is In-session passwordless authentication which provides the ability to use Windows Hello for Business and Security Keys within the AVD session

Pre-Requisites

Again there are requirements that the Session Host and Local Machine are running specific OS versions.

• Windows 11 Enterprise single or multi-session with 2022-10 Cumulative Updates for Windows 11 (KB5018418) or later installed.
• Windows 10 Enterprise single or multi-session, versions 20H2 or later with the 2022-10 Cumulative Updates for Windows 10 (KB5018410) or later installed.
• Windows Server 2022 with the 2022-10 Cumulative Update for Microsoft server operating system (KB5018421) or later installed.

If this requirement is met then Passwordless authentication will be enabled automatically.

With In-session passwordless authentication all WebAuthn requests are redirected to your local machine. This then allows you to use any Security Keys attached locally, or use Windows Hello for Business for passwordless authentication.

Testing

So we have the suitable OS on both our local machine and Session Hosts, it’s time to test and see the user experience. I will be testing using Passwordless Authentication via a FIDO2 security key.

First I will make sure my FIDO2 key is plugged into my laptop.

Then, let’s load up a Desktop Session and open up a Web Browser and open a suitable site.

For testing let’s use https://portal.azure.com

I’ll enter details for the user associated with my FIDO2 key, and click Next

The browser will automatically determine that I can use my security key, and provide the standard prompts to use the security key attached to my local machine!

I’ll provide my pin and then the physical factor by touching the key and it will continue the login experience.

I’ll say No to not stay logged in and then I’m in using a complete passwordless experience.

Conclusion

So there we have it. AVD using Azure AD SSO.

It’s definitely a step in the right direction and is really easy to set up which is a bonus.

I did experience an issue with a login loop at first. A customary search of the internet showed another person had the same issue, and it was caused weirdly by the user being a domain admin?!

I removed the user from the Domain Admins group and mysteriously it started working?

But overall it’s a great feature that once in General Availability will surely be configured across most environments.

The in-session passwordless authentication is also great, allowing me to use my FIDO2 key plugged into my local machine with no additional configuration.