Lukas Schönbächler · Juillet 2026 · 7 min de lecture
Pourquoi c’est important
- Dans un environnement hybride (Microsoft 365 dans le cloud, Active Directory on-premises), passer au sans mot de passe avec FIDO2 ou Windows Hello for Business casse le Kerberos classique : pas de mot de passe, pas de ticket, pas d’intranet, pas de partage de fichiers. Cloud Kerberos Trust est la réponse de Microsoft.
- Microsoft Entra Kerberos transforme votre tenant en un second royaume Kerberos qui émet un TGT partiel ; vos contrôleurs de domaine on-premises l’échangent ensuite contre le vrai ticket.
- Le gain, c’est un véritable sans mot de passe : aucun mot de passe à la connexion ni en coulisses, pendant que les applications intranet et les partages de fichiers continuent de fonctionner.
- Il n’existe que sur Windows et macOS. Sur Android, il n’y a aucun client Kerberos, et la documentation de Microsoft elle-même recommande d’installer un client SSO tiers.
- Hypergate Authenticator est ce client : un SSO Kerberos natif pour Android et iOS, sans mot de passe grâce aux certificats (PKINIT), face aux mêmes contrôleurs de domaine auxquels votre parc Windows fait déjà confiance.
Votre entreprise déploie des clés FIDO2 ou Windows Hello for Business. La connexion fonctionne, Microsoft 365 fonctionne, tout le monde est content. Puis quelqu’un ouvre le portail intranet et, au lieu de la page, se retrouve avec une erreur d’authentification.
C’est le problème que Cloud Kerberos Trust vise à résoudre, et il se situe pleinement dans l’environnement hybride : Microsoft 365 et Entra ID dans le cloud, Active Directory qui fait toujours tourner les sites intranet sur IIS, les applications derrière AD FS et les partages de fichiers on-premises. Le Kerberos classique dérive la clé de l’utilisateur à partir d’un mot de passe. Supprimez le mot de passe et le contrôleur de domaine n’a plus rien pour construire un ticket : tout ce qui s’authentifie avec Kerberos cesse alors de fonctionner pour cet utilisateur. Cette seule lacune a bloqué plus de projets sans mot de passe que n’importe quelle question de licence.
Ce qu’est réellement Microsoft Entra Kerberos
Microsoft Entra Kerberos transforme votre tenant Entra ID en un second royaume Kerberos, KERBEROS.MICROSOFTONLINE.COM, qui coexiste avec le royaume Active Directory de votre environnement on-premises. Entra ID peut alors émettre lui-même des tickets Kerberos. Microsoft l’a introduit en 2021, et « cloud Kerberos trust » est le modèle de déploiement qui l’utilise pour la connexion Windows Hello for Business et FIDO2.
Lorsqu’un utilisateur se connecte à une machine Windows jointe à Entra ou jointe en mode hybride, l’appareil obtient un Primary Refresh Token (PRT) d’Entra ID. En même temps que le PRT, Entra ID délivre deux tickets Kerberos :
- Un TGT cloud pour le royaume
KERBEROS.MICROSOFTONLINE.COM. Celui-ci sert aux ressources cloud qui parlent Kerberos, principalement Azure Files et Azure SQL Managed Instance. - Un TGT partiel pour votre domaine AD on-premises. Il contient le SID de l’utilisateur et rien d’autre. Aucune appartenance à un groupe, aucun PAC.
Le TGT partiel, c’est la partie intéressante. Seul, il ne donne accès à rien. Le client Windows l’apporte à un contrôleur de domaine on-premises et l’échange contre un TGT complet, avec les appartenances aux groupes. À partir de là, tout fonctionne comme avant : le client demande des tickets de service, l’intranet se charge et le partage de fichiers s’ouvre.
Figure 1 : le cloud n’émet qu’un ticket partiel. Ce sont vos propres contrôleurs de domaine qui le transforment en accès réel, et c’est pourquoi la visibilité réseau vers un DC reste indispensable.
Pour rendre cet échange possible, vous créez un objet serveur Microsoft Entra Kerberos dans votre AD. Techniquement, c’est un objet contrôleur de domaine en lecture seule (RODC), et Entra ID utilise sa clé pour signer les TGT partiels que vos vrais DC accepteront ensuite. Les listes d’autorisation et de refus de l’objet RODC déterminent quels utilisateurs peuvent recourir au mécanisme, et Microsoft recommande un refus par défaut assorti de groupes d’autorisation explicites.
Ce dont vous avez besoin
Les prérequis sont courts mais stricts, et ils décrivent exactement la configuration hybride que la plupart des entreprises établies exploitent déjà :
- Des identités hybrides. Les utilisateurs doivent exister dans l’AD on-premises et être synchronisés vers Entra ID via Entra Connect.
- L’objet serveur Entra Kerberos dans l’AD, créé avec le module PowerShell
AzureADHybridAuthenticationManagement. - Windows 10 2004 ou une version ultérieure, joint à Entra ou hybride.
- Des contrôleurs de domaine corrigés pour le cloud trust, et joignables depuis le client. L’échange du TGT partiel contre un TGT complet se fait face à un vrai DC : la visibilité réseau vers un contrôleur de domaine reste donc nécessaire pour les ressources on-premises. Cloud Kerberos Trust supprime le mot de passe, pas la dépendance réseau.
Ce dernier point surprend. Le cloud émet le ticket partiel, mais ce sont vos DC qui font le gros du travail pour tout ce qui est on-premises.
À quoi ça sert
Trois scénarios concentrent l’essentiel des usages réels.
La connexion véritablement sans mot de passe dans un environnement hybride est l’argument phare. Un utilisateur se connecte avec une clé FIDO2 ou Windows Hello et atteint quand même tout ce que Kerberos protège : les sites intranet sur IIS avec authentification Windows, les applications derrière AD FS et les partages de fichiers SMB. Aucun mot de passe à la connexion, aucun mot de passe stocké ou saisi en coulisses, et le parc historique continue de fonctionner. C’est ce qui permet réellement à une organisation hybride de supprimer le mot de passe plutôt que de simplement le masquer. Vous évitez aussi le déploiement d’un certificat sur chaque client qu’exigeait l’ancien modèle de certificate trust.
Azure Files est le deuxième. Entra ID émet directement des tickets de service pour cifs/<account>.file.core.windows.net, si bien que les VM et les clients joints à Entra peuvent monter des partages de fichiers Azure sans passer par un DC. Les conteneurs de profil FSLogix pour Azure Virtual Desktop en sont le cas courant. Une réserve à connaître avant de concevoir votre architecture autour : les stratégies d’accès conditionnel qui exigent la MFA doivent exclure le compte de stockage, car le flux Kerberos ne peut pas satisfaire une revendication MFA.
L’authentification Windows vers Azure SQL Managed Instance est le troisième, utile lorsque vous migrez d’anciennes charges de travail de bases de données vers Azure et que les chaînes de connexion présument une authentification intégrée.
Là où ça s’arrête
Voici la partie sur laquelle les guides de déploiement s’attardent peu. Tout le mécanisme repose sur des composants qui n’existent que sur certaines plateformes. Les tickets sont récupérés par la pile d’identifiants de Windows (CloudAP, la même tuyauterie qui gère le PRT) ou, depuis Platform SSO, par macOS. Il n’existe aucun protocole public permettant à autre chose de les demander. Un client Kerberos standard ne peut pas envoyer un AS-REQ à Entra ID et récupérer un TGT ; l’émission des tickets est soudée au PRT.
| Plateforme | Entra Kerberos / cloud Kerberos trust | Client Kerberos classique |
|---|---|---|
| Windows 10 (2004+) / 11, joint à Entra ou hybride | Oui | Intégré |
| macOS avec Platform SSO | Oui | Intégré |
| iOS / iPadOS | Non | Extension Kerberos SSO d’Apple, via MDM |
| Linux | Non | krb5 / SSSD |
| Android | Non | Rien d’intégré : Hypergate Authenticator |
Tous les « Non » de cette colonne ne se valent pas. iOS embarque l’extension Kerberos Single Sign-on d’Apple, que votre MDM peut configurer pour récupérer des tickets auprès de vos contrôleurs de domaine on-premises à la manière classique, avec un mot de passe ou un certificat. Linux porte krb5 et SSSD depuis des décennies. Ni l’un ni l’autre ne peut dialoguer avec le KDC cloud d’Entra ID, mais face à un DC joignable, ils font le travail.
Android fait figure d’exception : aucun client Kerberos dans le système. Rien à configurer, aucune solution de repli. Alors dès qu’un téléphone ou un scanner Android durci dans un entrepôt a besoin d’atteindre vos ressources protégées par Kerberos, ni cloud Kerberos trust ni la plateforme n’ont quoi que ce soit à proposer. Microsoft le dit d’ailleurs, dans un endroit inattendu : le guide d’installation du client Global Secure Access sur Android précise que « pour activer une expérience de single sign-on (SSO) Kerberos, installez et configurez un client SSO tiers ». Le tunnel vers votre réseau appartient à Microsoft ; la partie Kerberos sur Android est explicitement l’affaire de quelqu’un d’autre.
Combler le trou sur Android
Soyons transparents : ce travail, c’est notre produit. Hypergate Authenticator est un client Kerberos pour Android et iOS. Il obtient des tickets auprès de vos contrôleurs de domaine existants, à l’aide de certificats (PKINIT) ou de mots de passe, et remet des jetons SPNEGO aux navigateurs et applications gérés de la même façon que Windows le fait nativement : l’intranet sur IIS, les applications derrière AD FS, tout ce qui attend un ticket. Avec les certificats, le mobile devient lui aussi véritablement sans mot de passe : le même résultat que votre parc Windows vient d’atteindre grâce à cloud Kerberos trust, et votre EMM sait déjà les distribuer. Sur Android, il comble un trou que la plateforme laisse ouvert ; sur iOS, il vous offre une seule configuration et un seul comportement pour les deux moitiés du parc mobile, au lieu de maintenir séparément l’extension d’Apple.
Et quand la ressource dont vos utilisateurs mobiles ont réellement besoin est le partage de fichiers lui-même, Hypergate Files s’appuie sur le même SSO Kerberos : un explorateur de fichiers mobile géré pour vos partages SMB, afin que le scanner de l’entrepôt et la tablette de terrain ouvrent les mêmes partages que montent vos postes de travail, sans invite de mot de passe.
Figure 2 : les deux chemins aboutissent aux contrôleurs de domaine que vous exploitez déjà. Cloud Kerberos Trust couvre le parc de postes de travail ; Hypergate couvre le mobile, face à la même infrastructure.
Les deux approches se complètent plutôt qu’elles ne s’opposent. Cloud Kerberos Trust couvre votre parc Windows et Mac. Un client Kerberos mobile couvre tout le reste, face à la même infrastructure que vous exploitez déjà. Si vous déployez Entra Private Access comme chemin réseau, la combinaison est simple : publiez vos DC à travers le tunnel, et le client mobile s’authentifie au travers.
En résumé
Cloud Kerberos Trust vaut la peine d’être déployé si vous exploitez un environnement hybride et voulez une connexion Windows véritablement sans mot de passe sans casser deux décennies d’infrastructure protégée par Kerberos. C’est un pont bien conçu, et nettement moins pénible que le modèle de certificate trust qu’il remplace en grande partie. Abordez-le simplement en connaissant ses contours : identités hybrides uniquement, joignabilité des DC toujours requise pour l’accès on-premises, exclusions MFA pour Azure Files, et pas d’Entra Kerberos sur autre chose que Windows ou macOS. iOS et Linux peuvent se rabattre sur leurs clients Kerberos classiques. Android, non, et pour lui vous devrez chercher un client Kerberos. La documentation de Microsoft le dit sans détour.
Vous déployez cloud Kerberos trust ?
Votre parc Windows obtient un Kerberos sans mot de passe. Hypergate Authenticator apporte le même SSO silencieux et sans mot de passe à Android et iOS, et Hypergate Files met vos partages SMB sur ces appareils, le tout face aux mêmes contrôleurs de domaine, déployé via l’EMM que vous exploitez déjà.
