Azure Virtual Desktop est souvent présenté comme une solution offrant un Single Sign-On “natif”. Dès que l’on sort d’un environnement cloud-only pour entrer dans un contexte hybride, les mécanismes d’authentification deviennent toutefois plus complexes, et parfois déroutants. Entre Microsoft Entra ID, Active Directory, Kerberos, PRT, Seamless SSO et Cloud Kerberos Trust, il est facile de confondre des briques aux noms proches, mais qui n’interviennent ni au même moment ni au même niveau.
Dans un précédent article, j’avais détaillé la mise en place du SSO Azure Virtual Desktop dans un environnement cloud-only.
Dans cet article, j’ai volontairement changé de contexte pour travailler sur un environnement hybride. L’objectif de cet article est de répondre aux trois questions suivantes :
- Clarifier les mécanismes d’authentification (PRT, Seamless SSO, Kerberos, etc.)
- Montrer pas à pas pourquoi certaines étapes sont indispensables pour obtenir un SSO réellement transparent dans AVD.
- A quoi sert le Seamless SSO disponible dans Entra Connect Sync ?
Avant d’aborder la configuration et les tests, il est utile de poser le cadre : comprendre quels mécanismes d’authentification sont utilisés, à quel moment, et pourquoi certains fonctionnent seuls alors que d’autres doivent être combinés.
Cette FAQ a pour objectif de lever les confusions les plus fréquentes autour des tokens, du Kerberos, et du Single Sign-On dans un environnement Microsoft Entra hybride.
Quels sont les tokens utilisés par Microsoft Entra ID ?
Microsoft Entra ID utilise plusieurs types de tokens, chacun ayant un rôle précis :
- Primary Refresh Token (PRT)
- Jeton long terme
- Spécifique à l’appareil
- Sert à demander d’autres tokens
- Utilisé par Windows (WAM – Web Account Manager)
- Access Token
- Jeton court terme
- Présenté aux applications (API, Office, AVD…)
- Contient les claims utilisateur
- Refresh Token
- Permet de renouveler un Access Token
- Généralement géré automatiquement par le système
Qu’est-ce que le Primary Refresh Token (PRT) ?
Dans le monde de Microsoft, le PRT est un jeton émis par Microsoft Entra ID lorsqu’un appareil est Microsoft Entra Joined ou Microsoft Entra Hybrid Joined.
Un jeton d’actualisation principal (PRT) est un artefact clé de l’authentification Microsoft Entra dans les versions prises en charge de Windows, iOS/macOS, Android et Linux. Un PRT est un artefact sécurisé spécialement émis aux répartiteurs de jetons microsoft pour activer l’authentification unique (SSO) sur les applications utilisées sur ces appareils.
Le PRT est stocké localement sur la machine et sert de jeton racine pour :
- obtenir des tokens d’accès OAuth 2.0
- s’authentifier automatiquement aux services cloud Microsoft
- éviter toute ressaisie de mot de passe pour les applications modernes
Concrètement, le PRT permet :
- l’ouverture automatique de session dans Edge
- l’authentification transparente à Office, Teams, OneDrive
- l’utilisation de Windows App / Azure Virtual Desktop web
Point important : le PRT n’est pas Kerberos et ne permet pas, à lui seul, d’ouvrir une session Windows sur une machine Active Directory.
Pourquoi le PRT ne suffit-il pas pour Azure Virtual Desktop en mode Hybride ?
Dans un environnement Azure Virtual Desktop en mode Hybride, il y a deux niveaux d’authentification distincts :
- Accès au service AVD (broker / portail)
→ Authentification Microsoft Entra ID
→ Le PRT suffit - Ouverture de la session Windows sur le session host
→ Authentification Active Directory
→ Un TGT Kerberos est obligatoire
Dans un environnement Microsoft Entra Hybrid Joined, le PRT est présent, mais le TGT Kerberos n’est pas automatiquement délivré par Entra.
Cela permet de comprendre pourquoi une seconde authentification Active Directory est fréquemment observée dans de nombreux environnements AVD, après une première authentification Entra.
Qu’est-ce qu’un TGT Kerberos Active Directory ?
Le Ticket Granting Ticket (TGT) est un jeton Kerberos délivré par un contrôleur de domaine Active Directory.
Il est obtenu :
- lors de l’ouverture de session Windows
- après une authentification réussie auprès de l’AD
Le TGT permet ensuite :
- d’accéder aux ressources Active Directory
- d’obtenir des tickets de service (CIFS, LDAP, HTTP, etc.)
- d’ouvrir une session Windows locale ou distante
Sans TGT Kerberos, l’ouverture d’une session Active Directory n’est pas possible.
Qu’est-ce que Microsoft Entra Kerberos (Cloud Kerberos Trust) ?
Microsoft Entra Kerberos est le mécanisme qui permet à Microsoft Entra ID de :
- générer un TGT Kerberos Active Directory
- à partir d’une authentification cloud
- sans nécessiter ADFS
Techniquement :
- un objet Kerberos spécial est créé dans l’Active Directory
- les clés sont synchronisées avec Microsoft Entra ID
- Entra devient capable d’émettre un TGT valide pour l’AD
C’est l’élément nécessaire pour obtenir un SSO complet dans AVD en environnement hybride.
Pourquoi la jointure hybride améliore l’expérience SSO ?
Avec Microsoft Entra Hybrid Join :
- l’appareil est reconnu par Entra
- un PRT est délivré
- les applications cloud utilisent un SSO moderne
En ajoutant Microsoft Entra Kerberos :
- Entra peut aussi délivrer un TGT AD
- Windows peut ouvrir la session sans redemande de mot de passe
On comprend alors que la combinaison du PRT et d’un TGT Kerberos est nécessaire pour obtenir un SSO transparent dans Azure Virtual Desktop.
À quoi sert la case “Single sign-on” dans Entra Connect ?
La case Single sign-on dans Microsoft Entra Connect active ce qu’on appelle Seamless SSO.
Seamless SSO repose sur :
- Kerberos
- le compte AD AZUREADSSOACC
- le site autologon.microsoftazuread-sso.com
Son objectif est volontairement limité :
- éviter la saisie du mot de passe AD
- lors d’une authentification navigateur vers Entra ID
- sur une machine AD-only
Il est important de distinguer Seamless SSO des autres mécanismes :
- ne crée PAS de PRT
- ne remplace PAS Microsoft Entra Kerberos
- ne supprime PAS tous les écrans de login
Pour se donner une meilleure idée de cette fonctionnalité SSO spécifique, nous la testerons dans la dernière étape de cet article.
Mais commençons d’abord par tester la mise en place du single sign-on complet pour un environnement AVD de mode hybride, dont les procédures officielles sont disponibles ici et là :
- Etape 0 – Configuration de base
- Etape I – Test sans configuration SSO
- Etape II – Configuration SSO du pool d’hotes AVD
- Etape III – Création d’un objet serveur Kerberos
- Etape IV – Activation de l’authentification Microsoft Entra pour RDP
- Etape V – Activation du SSO d’Entra Connect Sync
Etape 0 – Configuration de base :
Dans mon environnement de test, j’ai déjà configuré certains composants.
- Un environnement Active Directory
- Microsoft Entra Connect configuré avec
- Password Hash Synchronization (PHS)
- sans Single sign-on,
- avec Hybrid Joined pour les machines Windows 10/11
- Synchronisation de l’OU des utilisateurs AVD
- Synchronisation de l’OU des machines hôtes AVD
- Un environnement Azure Virtual Desktop avec deux machines virtuelles jointes à AD :
Notre environnement AVD en mode hybride est en place, commençons par un premier test.
Etape I – Test sans configuration SSO :
Avant d’aller plus loin, j’effectue déjà un premier test de connexion d’un utilisateur AVD depuis le portail web :
Une authentification AD est demandée lors de l’ouverture de la session Windows, c’est un comportement normal à ce stade car rien n’est configuré :
La commande dsregcmd /status sert à afficher l’état d’enregistrement de l’appareil auprès d’Entra ID et, concernant le PRT (Primary Refresh Token), elle fournit des informations de diagnostic sur sa présence et son état :
- AzureAdPrt : YES / NO : Indique si un PRT est présent sur la machine pour l’utilisateur
- AzureAdPrtUpdateTime : Date/heure du dernier rafraîchissement du PRT
- AzureAdPrtExpiryTime : Date/heure d’expiration du PRT
- AzureAdPrtAuthority : Autorité qui a émis le token (généralement login.microsoftonline.com).
Concernant la partie des tickets, voici ce que l’on peut aussi en déduire :
- OnPremTgt : NO : cela indique si la session utilisateur courante ne possède pas Ticket Granting Ticket Kerberos émis par un contrôleur de domaine AD.
- CloudTgt : YES : indique la présence d’un TGT Kerberos cloud, émis par Entra ID.
Comme on peut le constater, le PRT émis via Entra fonctionne bien pour les services Cloud, mais l’ouverture de session et l’accès à certaines ressources gérées par l’AD pourraient être restreints dans la situation actuelle.
Commençons étape par étape les changements pour arriver à une configuration complète.
Etape II – Configuration SSO du pool d’hotes AVD :
Sur le portail Azure, comme l’indique la documentation Microsoft, j’effectue la configuration SSO du host pool Azure Virtual Desktop afin d’activer “Microsoft Entra authentication for single sign-on” :
J’effectue un nouveau test avec mon utilisateur :
À ce stade, une authentification AD est encore demandée lors de l’ouverture de la session Windows :
Etape III – Création d’un objet serveur Kerberos :
Sur le serveur AD, comme l’indique la documentation Microsoft, je commence par installer le module AzureADHybridAuthenticationManagement :
# First, ensure TLS 1.2 for PowerShell gallery access.
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12
# Install the AzureADHybridAuthenticationManagement PowerShell module.
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
Pour créer l’objet Kerberos Server nécessaire au Cloud Kerberos Trust, j’ai choisi l’exemple 4 de la documentation Microsoft :
- Cet exemple exploite l’authentification moderne basée sur le User Principal Name (UPN) sans exiger de mot de passe AD explicite.
- Il s’intègre parfaitement dans un environnement hybride sécurisé avec MFA et politiques d’accès conditionnel
- Il évite les écueils des méthodes utilisant NTLM ou des identifiants AD en clair.
# Specify the on-premises Active Directory domain. A new Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter a UPN of a Hybrid Identity Administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"
# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Open an interactive sign-in prompt with given username to access the Microsoft Entra ID.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalNameJe lance donc le script à la suite du précédent, en prenant soin de remplacer l’UPN par un administrateur général ou hybride :
Je vérifie le serveur Microsoft Entra Kerberos nouvellement créé à l’aide de la commande suivante :
# When prompted to provide domain credentials use the userprincipalname format for the username instead of domain\username
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential (get-credential)
Enfin je constate la présence krbtgt_AzureAD utilisé par les DC pour signer les TGT Kerberos. Il s’agit d’une séparation cryptographique claire avec krbtgt dans le cadre de Kerberos émis depuis Entra :
J’effectue un nouveau test avec mon utilisateur :
Une fois le Cloud Kerberos Trust et l’authentification RDP Microsoft Entra activés, la seconde authentification Active Directory disparaît et est remplacée par un simple message de consentement Allow Remote Desktop connection :
Entra veut un consentement explicite de l’utilisateur. Ce message ne correspond pas à une authentification supplémentaire, mais à une demande de confiance entre l’utilisateur et le session host :
Si l’utilisateur clique sur Oui, ce consentement sera conservé 30 jours et ne pourra pas mémoriser plus de 15 hôtes.
L’Étape suivante consiste donc à supprimer définitivement le popup en déclarant les session hosts comme appareils de confiance dans Microsoft Entra ID.
Etape IV – Activation de l’authentification Microsoft Entra pour RDP :
Commençons par autoriser Microsoft Entra dans l’authentification pour Windows sur le tenant. Pour cela, j’utilise Azure Cloud Shell depuis le portail Azure :
J’importe les deux modules Microsoft Graph suivants, puis je me connecte avec le compte au permissions appropriées :
Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"
Je récupère l’ID d’objet pour le principal du service de connexion au Windows Cloud :
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id
Je modifie la propriété isRemoteDesktopProtocolEnabled sur True :
If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}
Je vérifie que la propriété isRemoteDesktopProtocolEnabled est correctement définie :
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId
Afin de masquer la boîte de dialogue en configurant la liste des hôtes AVD approuvés, je créé un groupe dans Entra ID contenant les hôtes de sessions :
J’utilise une requête dynamique pour ajouter automatiquement mes prochains hôtes dans le groupe :
Enfin, toujours dans la même session d’Azure Cloud Shell, j’ajoute l’ID de groupe à une propriété sur le principal du service SSO Windows Cloud Login.
$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<Group object ID>"
$tdg.DisplayName = "<Group display name>"
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $WCLspId -BodyParameter $tdgEnfin, je vérifie la bonne assignation du groupe :
J’effectue un nouveau test avec mon utilisateur :
Cette fois l’authentification passe sans encombre. Un TGT Kerberos AD DS (on-premises) est maintenant présent dans la session.
Cela permet d’observer que :
- La machine est Hybrid Entra ID Joined
- Le PRT est valide
- Le Kerberos cloud fonctionne
- Le Kerberos AD DS fonctionne
- Les deux mondes coexistent simultanément dans la même session
Cette sortie correspond à un état hybride cohérent, où les mécanismes cloud et on-premises coexistent.
Pour finir, je vous propose de tester l’impact du Seamless SSO présent et configurable dans Entra Connect Sync.
Etape V – Activation du SSO d’Entra Connect Sync :
Pour cela, je décide de rajouter une troisième machine AVD :
Celle-ci est bien présente dans l’Active Directory :
Mais elle n’est pas présente dans Entra ID :
Pour ne pas perturber mes tests, je décide donc de bloquer la connexion aux deux autres VMs AVD :
J’effectue un test avec mon utilisateur :
Comme aucune configuration hybride n’est en place pour cette machine AVD, il n’y a pas de ticket TGT Kerberos émis par Entra ID, donc la seconde authentification AD est logique :
Une fois dans la session Windows, dsregcmd nous affiche les informations suivantes :
- La machine est jointe uniquement à Active Directory on-premises
- Elle n’est pas jointe à Entra ID
- Elle n’est pas Hybrid Join
- Aucun PRT
- Aucun SSO cloud
- Aucune authentification Entra ID
- Une tentative d’Entra ID Join / Hybrid Join a eu lieu
- Elle a échoué côté Entra ID
- La machine AVD n’existe pas ou n’est pas reconnu dans le tenant
L’ouverture de la page d’authentification d’Office 365 dans Microsoft Edge me montre d’ailleurs aucune connexion SSO :
Je décide donc d’activer la fonctionnalité SSO dans Entra Connect Sync :
Une fois la configuration terminée, je constate la création de AZUREADSSOACC en tant que compte ordinateur créé dans Active Directory :
Ce dernier est créé automatiquement lors de l’activation de Seamless Single Sign-On (Seamless SSO) avec Entra ID. Le compte est utilisé par Entra ID pour :
- établir une relation de confiance Kerberos avec l’AD on-prem
- permettre le SSO sans saisie de mot de passe depuis des postes domain-joined vers Entra ID
J’effectue donc un nouveau test avec mon utilisateur :
Dans ce contexte, il est logique que l’authentification AD soit toujours demandée :
Une fois la session Windows ouverte, comme Seamless SSO fonctionne via l’adresse autologon.microsoftazuread-sso.com, je décide de la rajouter en tant qu’URL de l’Intranet local.
Pour cela, j’ouvre inetcpl.cpl :
Je clique sur Site dans Intranet local :
Je clique sur Avancée :
Je rajoute l’URL suivante :
https://autologon.microsoftazuread-sso.com
Toujours dans Intranet Local, je coche Connexion automatique avec le nom d’utilisateur et le mot de passe actuels :
Quelques minutes plus tard, j’ouvre Microsoft Edge et je constate l’authentification automatique de mon compte Cloud correspondant :
La présence du ticket HTTP/autologon.microsoftazuread-sso.com dans le cache Kerberos confirme que le mécanisme Seamless SSO est bien actif. Ce ticket, émis par le contrôleur de domaine à destination de Microsoft Entra ID, permet une authentification navigateur sans saisie de mot de passe.
klist
Il est important de noter que ce mécanisme n’est pas celui utilisé pour l’ouverture de session Windows dans Azure Virtual Desktop, qui repose sur un TGT Kerberos distinct délivré via Microsoft Entra Kerberos (krbtgt_AzureAD).
Conclusion
À travers ces différents tests et configurations, on constate que le Single Sign-On dans Azure Virtual Desktop hybride ne repose pas sur un mécanisme unique, mais sur une combinaison cohérente de plusieurs briques d’authentification.
Le PRT permet une authentification fluide aux services cloud, mais il ne suffit pas à lui seul pour ouvrir une session Windows dans un contexte Active Directory. C’est bien l’association du Hybrid Join, du Cloud Kerberos Trust et de l’authentification Microsoft Entra pour RDP qui permet d’aligner les mondes cloud et on-premises, et d’obtenir une expérience utilisateur réellement transparente dans AVD.
Comprendre ces mécanismes permet non seulement d’éviter des configurations incomplètes, mais aussi d’expliquer pourquoi certains scénarios fonctionnent “presque”, tout en continuant à demander une authentification supplémentaire.
