Activer la connexion par clé de sécurité sans mot de passe à des ressources locales à l’aide de Microsoft Entra ID

  • Article

Cette rubrique explique comment activer l’authentification sans mot de passe aux ressources locales pour les environnements avec des périphériques exécutant Windows 10 version 2004 ou ultérieure. Les périphériques peuvent être joints à Microsoft Entra ou à Microsoft Entra hybride. Cette fonctionnalité d’authentification sans mot de passe fournit une authentification unique (SSO) directe auprès de ressources locales quand vous utilisez des clés de sécurité compatibles avec Microsoft ou avec l’approbation au niveau du cloud Windows Hello Entreprise.

Utiliser l’authentification unique pour se connecter à des ressources locales à l’aide de clés FIDO2

Microsoft Entra ID peut émettre des ticket-granting tickets (TGT) Kerberos pour un ou plusieurs de vos domaines Active Directory. Cette fonctionnalité permet aux utilisateurs de se connecter à Windows avec des informations d’identification modernes telles que des clés de sécurité FIDO2 pour accéder à des ressources Active Directory traditionnelles. Les tickets de service Kerberos et l’autorisation continuent d’être contrôlés par vos contrôleurs de domaine Active Directory locaux.

Un objet serveur Kerberos Microsoft Entra est créé dans votre instance Active Directory locale, puis publié en toute sécurité sur Microsoft Entra ID. L’objet n’est associé à aucun serveur physique. Il s’agit simplement d’une ressource que Microsoft Entra ID peut utiliser afin de générer des TGT Kerberos pour votre domaine Active Directory.

Diagramme montrant comment obtenir un TGT à partir de Microsoft Entra ID et d’Active Directory Domain Services.

  1. L’utilisateur se connecte à un appareil Windows 10 avec une clé de sécurité FIDO2 et s’authentifie auprès de Microsoft Entra ID.

  2. Microsoft Entra ID recherche dans l’annuaire une clé de serveur Kerberos correspondant au domaine Active Directory local de l’utilisateur.

    Microsoft Entra ID génère un TGT Kerberos pour le domaine Active Directory local de l’utilisateur. Le TGT comprend uniquement le SID de l’utilisateur, et aucune donnée d’autorisation.

  3. Le TGT est renvoyé au client avec le jeton d’actualisation principal (PRT, Primary Refresh Token) Microsoft Entra de l’utilisateur.

  4. L’ordinateur du client contacte un contrôleur de domaine Active Directory local et échange le TGT partiel contre un TGT entièrement formé.

  5. L’ordinateur du client disposant à présent d’un PRT Microsoft Entra et d’un TGT Active Directory complet, il peut accéder aux ressources cloud et locales.

Prérequis

Avant de commencer à suivre les procédures décrites dans cet article, votre organisation doit suivre les instructions de la rubrique Activer la connexion par clé de sécurité sans mot de passe à des appareils Windows 10.

Vous devez également respecter la configuration système suivante :

  • Les appareils doivent exécuter Windows 10 version 2004 ou ultérieure.

  • Vos contrôleurs de domaine Windows Server doivent exécuter Windows Server 2016 ou une version ultérieure et avoir des correctifs installés pour les serveurs suivants :

  • AES256_HMAC_SHA1 doit être activé lorsque la stratégie Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos est configurée sur les contrôleurs de domaine.

  • Disposez des informations d'identification nécessaires pour effectuer les étapes du scénario :

    • Un utilisateur Active Directory qui est membre du groupe Administrateurs du domaine pour un domaine et membre du groupe Administrateurs de l’entreprise pour une forêt. Appelé $domainCred.
    • Utilisateur Microsoft Entra membre du rôle Administrateur général. Appelé $cloudCred.

  • Les utilisateurs doivent avoir les attributs Microsoft Entra ID suivants renseignés via Microsoft Entra Connect :

    • onPremisesSamAccountName (accountName dans Entra Connect)
    • onPremisesDomainName (domainFQDN dans Entra Connect)
    • onPremisesSecurityIdentifier (objectSID dans Entra Connect)

    Entra Connect synchronise ces attributs par défaut. Si vous modifiez les attributs à synchroniser, sélectionnez accountName, domainFQDN et objectSID pour la synchronisation.

Scénarios pris en charge

Le scénario de cet article prend en charge l’authentification unique dans les deux cas suivants :

  • Ressources Cloud telles que Microsoft 365 et d’autres applications compatibles avec SAML(Security Assertion Markup Language).
  • Ressources locales et authentification intégrée Windows auprès des sites web. Les ressources peuvent inclure des sites web et des sites SharePoint qui requièrent une authentification IIS, et/ou des ressources qui utilisent l’authentification NTLM.

Scénarios non pris en charge

Les scénarios suivants ne sont pas pris en charge :

  • Déploiement de Windows Server joint à Active Directory Domain Services (AD DS) (appareils locaux uniquement).
  • Scénarios RDP (Remote Desktop Protocol), VDI (Virtual Desktop Infrastructure) et Citrix en utilisant une clé de sécurité.
  • S/MIME en utilisant une clé de sécurité.
  • Exécuter en tant que en utilisant une clé de sécurité.
  • Connexion à un serveur en utilisant une clé de sécurité.

Installez le module AzureADHybridAuthenticationManagement

Le module AzureADHybridAuthenticationManagement fournit des fonctionnalités de gestion FIDO2 pour les administrateurs.

  1. Ouvrez une invite PowerShell à l’aide de l’option Exécuter en tant qu’administrateur.

  2. Installez 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

Remarque

  • Le module AzureADHybridAuthenticationManagement utilise le module AzureADPreview PowerShell pour fournir des fonctionnalités de gestion Microsoft Entra avancées. Si le module Azure Active Directory PowerShell est déjà installé sur votre ordinateur local, l’installation décrite ici risque d’échouer en raison d’un conflit. Pour éviter tout conflit au cours de l’installation, veillez à inclure l’indicateur d’option « -AllowClobber ».
  • Vous pouvez installer le module AzureADHybridAuthenticationManagement sur tout ordinateur à partir duquel vous pouvez accéder à votre contrôleur de domaine Active Directory local, sans dépendre de la solution de Microsoft Entra Connect.
  • Le module AzureADHybridAuthenticationManagement est distribué à l’aide de PowerShell Gallery. PowerShell Gallery est le référentiel central pour le contenu PowerShell. Vous pouvez y trouver des modules PowerShell utiles contenant des commandes PowerShell et des ressources de Desired State Configuration (DSC).

Créer un objet serveur Kerberos

Les administrateurs utilisent le module AzureADHybridAuthenticationManagement pour créer un objet serveur Kerberos Microsoft Entra dans leur répertoire local.

Exécutez les étapes suivantes dans chaque domaine et forêt de votre organisation contenant des utilisateurs Microsoft Entra :

  1. Ouvrez une invite PowerShell à l’aide de l’option Exécuter en tant qu’administrateur.
  2. Exécutez les commandes PowerShell suivantes pour créer un objet serveur Kerberos Microsoft Entra dans votre domaine Active Directory local et dans votre locataire Microsoft Entra.

Sélectionner Azure Cloud (la valeur par défaut est Azure Commercial)

La cmdlet Set-AzureADKerberosSever utilise par défaut les points de terminaison cloud commerciaux. Si vous configurez Kerberos dans un autre environnement cloud, vous devez définir la cmdlet pour utiliser le cloud spécifié.

Pour obtenir la liste des clouds disponibles et la valeur numérique nécessaire à la modification, exécutez ce qui suit :
Get-AzureADKerberosServerEndpoint

Exemple de sortie :

Current Endpoint = 0(Public)
Supported Endpoints:
   0 :Public
   1 :China
   2 :Us Government

Notez la valeur numérique à côté de votre environnement cloud souhaité.

Pour définir ensuite l’environnement cloud souhaité, exécutez ce qui suit :
(Exemple : Cloud du gouvernement des États-Unis)
Set-AzureADKerberosServerEndpoint -TargetEndpoint 2

Exemple 1 : demander toutes les informations d’identification

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory global administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Global Administrators group for Azure AD.'

# Enter a domain administrator username and password.
$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.'

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Exemple 2 : demander des informations d’identification cloud

Notes

Si vous utilisez une machine jointe à un domaine avec un compte disposant de privilèges d’administrateur de domaine, vous pouvez ignorer le paramètre « -DomainCredential ». Si le paramètre « -DomainCredential » n’est pas fourni, les informations d’identification de connexion Windows actuelles sont utilisées pour accéder à votre contrôleur de domaine Active Directory local.

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter an Azure Active Directory global administrator username and password.
$cloudCred = Get-Credential

# Create the new Azure AD Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
# Use the current windows login credential to access the on-premises AD.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred

Exemple 3 : demander toutes les informations d’identification à l’aide de l’authentification moderne

Notes

Si votre organisation protège la connexion par mot de passe et applique des méthodes d’authentification modernes telles que l’authentification multifacteur, FIDO2 ou une technologie de carte à puce, vous devez utiliser le paramètre -UserPrincipalName avec le nom d’utilisateur principal d’un administrateur général.

  • Remplacez contoso.corp.com dans l’exemple suivant par le nom de votre domaine Active Directory local.
  • Remplacez administrator@contoso.onmicrosoft.com dans l’exemple suivant par le nom d’utilisateur principal (UPM) d’un administrateur général.
# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Enter a domain administrator username and password.
$domainCred = Get-Credential

# Create the new Azure AD 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 Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Exemple 4 : demander des informations d’identification cloud à l’aide de l’authentification moderne

Notes

Si vous travaillez sur une machine jointe à un domaine avec un compte disposant de privilèges d’administrateur de domaine et que votre entreprise protège la connexion par mot de passe et applique des méthodes d’authentification modernes telles que l’authentification multifacteur, FIDO2 ou la technologie de carte à puce, vous devez utiliser le paramètre -UserPrincipalName avec le nom d’utilisateur principal (UPN) d’un administrateur global. Vous pouvez ignorer le paramètre « -DomainCredential ». > - Dans l’exemple suivant, remplacez administrator@contoso.onmicrosoft.com par l’UPN d’un administrateur général.

# Specify the on-premises Active Directory domain. A new Azure AD
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN

# Enter a UPN of an Azure Active Directory global administrator
$userPrincipalName = "administrator@contoso.onmicrosoft.com"

# Create the new Azure AD 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 Azure AD.
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Affichage et vérification du serveur Kerberos Microsoft Entra

Vous pouvez afficher et vérifier le serveur Kerberos Microsoft Entra que vous venez de créer à 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)

Cette commande génère les propriétés du serveur Kerberos Microsoft Entra. Vous pouvez examiner les propriétés pour vérifier que tout est en ordre.

Remarque

L’exécution de la commande sur un autre domaine en fournissant les informations d’identification au format du domaine\nom d’utilisateur établit une connexion via NTLM, puis échoue. Toutefois, l’utilisation du format userprincipalname pour l’administrateur de domaine garantit que la liaison RPC au contrôleur de domaine est tentée grâce à l’utilisation correcte de Kerberos. Si les utilisateurs se trouvent dans le groupe de sécurité Utilisateurs protégés dans Active Directory, procédez comme suit pour résoudre le problème : connectez-vous en tant qu’utilisateur d’un autre domaine dans ADConnect et n’entrez pas de « -domainCredential ». Le ticket Kerberos de l’utilisateur actuellement connecté est utilisé. Vous pouvez confirmer en exécutant whoami /groups pour valider le fait que l’utilisateur dispose des autorisations requises dans Active Directory pour exécuter la commande précédente.

Propriété Description
id ID unique de l’objet contrôleur de domaine AD DS. Cet ID est parfois appelé emplacement ou ID de branche.
DomainDnsName Nom de domaine DNS du domaine Active Directory.
ComputerAccount Objet compte d’ordinateur de l’objet serveur Kerberos Microsoft Entra (le contrôleur de domaine)
UserAccount Objet compte d’utilisateur désactivé contenant la clé de chiffrement du TGT du serveur Kerberos Microsoft Entra Le nom de domaine de ce compte est CN=krbtgt_AzureAD,CN=Users,<Domain-DN>.
KeyVersion Version de clé de la clé de chiffrement du TGT du serveur Kerberos Microsoft Entra La version est attribuée lors de la création de la clé. La version est ensuite incrémentée à chaque rotation de la clé. Les incréments sont basés sur les métadonnées de réplication et probablement supérieurs à un. Par exemple, la KeyVersion initiale pourrait être 192272. À la première rotation de la clé, la version peut passer à 212621. L’élément important à vérifier est que la KeyVersion de l’objet local et la CloudKeyVersion de l’objet cloud sont identiques.
KeyUpdatedOn Date et heure auxquelles la clé de chiffrement du TGT du serveur Kerberos Microsoft Entra a été mise à jour ou créée
KeyUpdatedFrom Contrôleur de domaine où la clé de chiffrement du TGT du serveur Kerberos Microsoft Entra a été mise à jour pour la dernière fois
CloudId ID de l’objet Microsoft Entra. Doit correspondre à l’ID de la première ligne de la table.
CloudDomainDnsName DomainDnsName de l’objet Microsoft Entra. Doit correspondre à DomainDnsName à partir de la deuxième ligne de la table.
CloudKeyVersion KeyVersion de l’objet Microsoft Entra. Doit correspondre à KeyVersion à partir de la cinquième ligne de la table.
CloudKeyUpdatedOn KeyUpdatedOn de l’objet Microsoft Entra. Doit correspondre à KeyUpdatedOn à partir de la sixième ligne de la table.

Faire pivoter la clé du serveur Kerberos Microsoft Entra

Les clés krbtgt de chiffrement du serveur Kerberos Microsoft Entra doivent être régulièrement pivotées. Il est recommandé de suivre la planification utilisée pour la rotation de toutes les autres clés krbtgt du contrôleur de domaine Active Directory.

Avertissement

D’autres outils peuvent opérer la rotation des clés krbtgt. Toutefois, vous devez utiliser les outils mentionnés dans ce document pour faire pivoter les clés krbtgt de votre serveur Kerberos Microsoft Entra. Cela garantit que les clés sont à jour à la fois dans l’Active Directory local et dans Microsoft Entra ID.

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred -RotateServerKey

Supprimer le serveur Kerberos Microsoft Entra

Si vous souhaitez revenir à la dernière version du scénario et supprimer le serveur Kerberos Microsoft Entra tant de l’Active Directory local que de Microsoft Entra ID, exécutez la commande suivante :

Remove-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

Scénarios multiforêt et multidomaine

L’objet serveur Kerberos Microsoft Entra est représenté dans Microsoft Entra ID en tant qu’objet KerberosDomain. Chaque domaine Active Directory local est représenté en tant qu’objet KerberosDomain unique dans Microsoft Entra ID.

Imaginons que votre organisation dispose d’une forêt Active Directory avec deux domaines, contoso.com et fabrikam.com. Si vous choisissez d’autoriser Microsoft Entra ID à émettre des TGT Kerberos pour l’ensemble de la forêt, deux objets KerberosDomain se trouvent dans Microsoft Entra ID—un objet KerberosDomain pour contoso.com et l’autre pour fabrikam.com. Si vous avez plusieurs forêts Active Directory, il existe un objet KerberosDomain pour chaque domaine dans chaque forêt.

Suivez les instructions fournies dans Créer un objet serveur Kerberos dans chaque domaine et forêt de votre organisation contenant des utilisateurs Microsoft Entra.

Comportement connu

Si votre mot de passe a expiré, la connexion à l’aide de FIDO est bloquée. L’objectif est que les utilisateurs réinitialisent leur mot de passe avant de se connecter à l’aide de FIDO. Ce comportement s’applique également à la connexion utilisateur synchronisée locale hybride avec l’approbation Kerberos cloud Windows Hello Entreprise.

Résolution des problèmes de commentaires

Si vous rencontrez des problèmes ou si vous souhaitez partager des commentaires sur cette fonctionnalité de connexion par clé de sécurité sans mot de passe, partagez via l’application Hub de commentaires Windows en procédant comme suit :

  1. Lancez le Hub de commentaires et assurez-vous que vous êtes connecté.
  2. Soumettez des commentaires en sélectionnant les catégories suivantes :
    • Catégorie : Sécurité et confidentialité
    • Sous-catégorie : FIDO
  3. Pour capturer des journaux, utilisez l’option Recréer mon problème.

FAQ sur la connexion par clé de sécurité sans mot de passe

Conseil

Les étapes décrites dans cet article peuvent varier légèrement en fonction du portail de départ.

Voici quelques réponses aux questions fréquemment posées sur la connexion sans mot de passe :

La connexion par clé de sécurité sans mot de passe fonctionne-t-elle dans mon environnement local ?

La fonctionnalité ne fonctionne pas dans un environnement AD DS purement local.

Mon organisation exige une authentification à deux facteurs pour accéder aux ressources. Que puis-je faire pour prendre en charge cette exigence ?

Les clés de sécurité sont disponibles dans différents facteurs de forme. Contactez le fabricant officiel de l’appareil pour discuter de la façon dont ses appareils peuvent être activés à l’aide d’un code confidentiel ou d’une caractéristique biométrique comme deuxième facteur.

Les administrateurs peuvent-ils configurer des clés de sécurité ?

Nous travaillons sur cette fonctionnalité pour la publication en disponibilité générale de cette fonctionnalité.

Où puis-je trouver des clés de sécurité conformes ?

Pour plus d’informations sur les clés de sécurité conformes, consultez Clés de sécurité FIDO2.

Que puis-je faire si je perds ma clé de sécurité ?

Pour supprimer une clé de sécurité inscrite, connectez-vous à myaccount.microsoft.com, puis accédez à la page Informations de sécurité.

Que puis-je faire si je ne parviens pas à utiliser la clé de sécurité FIDO immédiatement après la création d’une machine jointe à Microsoft Entra hybride ?

Si vous effectuez une nouvelle installation de machine jointe à Microsoft Entra hybride, après le processus de jonction de domaine et de redémarrage, vous devez vous connecter avec un mot de passe et attendre la synchronisation de la stratégie avant de pouvoir utiliser la clé de sécurité FIDO pour vous connecter.

  • Vérifiez votre état actuel en exécutant dsregcmd /status dans une fenêtre d’invite de commandes, puis assurez-vous que les états AzureAdJoined et DomainJoined affichent OUI.
  • Ce délai de synchronisation est une limitation connue des appareils joints à un domaine et n’est pas spécifique de FIDO.

Que se passe-t-il si je ne parviens pas à effectuer l’authentification unique auprès de ma ressource réseau NTLM après m’être connecté avec FIDO et avoir obtenu une invite d’informations d’identification ?

Assurez-vous qu’un nombre suffisant de contrôleurs de domaine sont corrigés pour répondre dans les temps afin de servir votre demande de ressource. Pour déterminer si un contrôleur de domaine exécute la fonctionnalité, exécutez nltest /dsgetdc:contoso /keylist /kdc, puis examinez la sortie.

Notes

Le commutateur /keylist dans la commande nltest est disponible dans le client Windows 10 v2004 et versions ultérieures.

Les clés de sécurité FIDO2 fonctionnent-elles dans une connexion Windows quand un contrôleur de domaine en lecture seule est présent dans l’environnement hybride ?

Une connexion Windows par FIDO2 recherche un contrôleur de domaine accessible en écriture pour échanger le TGT de l’utilisateur. Tant que vous disposez d’au moins un contrôleur de domaine accessible en écriture par site, la connexion fonctionne correctement.

Étapes suivantes

En savoir plus sur l’authentification sans mot de passe