Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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 appareils peuvent être rejoints à Microsoft Entra ou rejoints de manière hybride à Microsoft Entra. Cette fonctionnalité d’authentification sans mot de passe fournit l’authentification unique transparente aux ressources locales lorsque vous utilisez des clés de sécurité compatibles avec Microsoft ou avec l’approbation Windows Hello Entreprise Cloud.
Utiliser l’authentification unique pour se connecter à des ressources locales à l’aide de clés FIDO2
Microsoft Entra ID peut émettre des tickets TGT (tickets d'accès temporaire) 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 Microsoft Entra Kerberos est créé dans votre instance Active Directory locale, puis publié en toute sécurité sur l’ID Microsoft Entra à l’aide de Microsoft Entra Connect. 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.
L’utilisateur se connecte à un appareil Windows 10 avec une clé de sécurité FIDO2 et s’authentifie auprès de Microsoft Entra ID.
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.
Le TGT est renvoyé au client avec le jeton d'actualisation principal (PRT) Microsoft Entra de l'utilisateur.
L’ordinateur du client contacte un contrôleur de domaine Active Directory local et échange le TGT partiel contre un TGT entièrement formé.
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 les procédures décrites dans cet article, votre organisation doit suivre les instructions fournies dans Enable passkeys (FIDO2) pour votre organisation.
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 sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos la stratégie 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.
- Un utilisateur Microsoft Entra avec le rôle Hybrid Identity Administrators. Appelé $cloudCred.
Les utilisateurs doivent avoir les attributs Microsoft Entra suivants renseignés via Microsoft Entra Connect :
-
onPremisesSamAccountName
(accountName
dans Microsoft Entra Connect) -
onPremisesDomainName
(domainFQDN
dans Microsoft Entra Connect) -
onPremisesSecurityIdentifier
(objectSID
dans Microsoft Entra Connect)
Microsoft Entra Connect synchronise ces attributs par défaut. Si vous modifiez les attributs à synchroniser, veillez à sélectionner
accountName
,domainFQDN
, puisobjectSID
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écutez en tant que l’aide d’une clé de sécurité.
- Connexion à un serveur en utilisant une clé de sécurité.
Installer le module AzureADHybridAuthenticationManagement
Le AzureADHybridAuthenticationManagement
module fournit des fonctionnalités de gestion FIDO2 pour les administrateurs.
Ouvrez une invite PowerShell à l’aide de l’option Exécuter en tant qu’administrateur.
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
- À partir de la mise à jour 2.3.331.0, le module AzureADHybridAuthenticationManagement n’installe pas le module AzureADPreview.
- 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
AzureADHybridAuthenticationManagement
module est distribué via 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. L’objet doit être créé sur le serveur Microsoft Entra Connect ou sur un serveur sur lequel la dépendance Microsoft.Online.PasswordSynchronization.Rpc.dll est installée.
Exécutez les étapes suivantes dans chaque domaine et forêt de votre organisation contenant des utilisateurs Microsoft Entra :
- Ouvrez une invite PowerShell à l’aide de l’option Exécuter en tant qu’administrateur.
- 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-AzureADKerberosServer
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 en regard de votre environnement cloud souhaité.
Pour définir ensuite l’environnement cloud souhaité, exécutez ce qui suit :
(Exemple : Pour le cloud du gouvernement américain)
Set-AzureADKerberosServerEndpoint -TargetEndpoint 2
Conseil
Pour plus d’informations sur la comparaison des clouds commerciaux et souverains Azure, consultez : Différences entre les clouds souverains Azure commercial et Azure.
Exemple 1 : demander toutes les informations d’identification
# 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 an Azure Active Directory Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Hybrid Identity Administrators group for Microsoft Entra ID.'
# Enter a Domain Administrator username and password.
$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group and an Enterprise Admin for the forest.'
# Create the new Microsoft Entra ID Kerberos Server object in Active Directory
# and then publish it to Azure Active Directory.
Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred
Exemple 2 : invitation à saisir les informations d’identification cloud
Remarque
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 Microsoft Entra ID
# Kerberos Server object will be created in this Active Directory domain.
$domain = $env:USERDNSDOMAIN
# Enter an Azure Active Directory Hybrid Identity Administrator username and password.
$cloudCred = Get-Credential
# Create the new Microsoft Entra ID 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
Remarque
Si votre organisation se protège par une 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 (UPN) d’un administrateur d’identité hybride.
- 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 l’UPN d’un administrateur d’identité hybride.
# 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"
# Enter a Domain Administrator username and password.
$domainCred = Get-Credential
# 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 $userPrincipalName -DomainCredential $domainCred
Exemple 4 : demander des informations d’identification cloud à l’aide de l’authentification moderne
Remarque
Si vous travaillez sur une machine jointe à un domaine avec un compte disposant de privilèges d’administrateur de domaine et que votre organisation se protège par une 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 d’identité hybride. Vous pouvez ignorer le paramètre « -DomainCredential ».
> - Remplacez administrator@contoso.onmicrosoft.com
dans l’exemple suivant par l’UPN d’un administrateur d’identité hybride.
# 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 $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 sur un autre domaine en fournissant les informations d'identification au format domaine\nom d'utilisateur établit une connexion via NTLM, puis échoue. Toutefois, l'utilisation du format userprincipalname pour l'administrateur de domaine veillera à ce que la liaison RPC au contrôleur de domaine soit tentée en utilisant correctement 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’autre utilisateur de domaine dans ADConnect et ne fournissez pas « -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é | Descriptif |
---|---|
id | ID unique de l’objet contrôleur de domaine AD DS. Cet ID est parfois appelé son emplacement ou son ID de branche. |
Nom de domaine DNS | Nom de domaine DNS du domaine Active Directory. |
Compte Ordinateur | L'objet compte d'ordinateur de l'objet serveur Kerberos Microsoft Entra (le contrôleur de domaine). |
CompteUtilisateur | Objet de compte d'utilisateur désactivé qui contient la clé de chiffrement TGT du serveur Kerberos Microsoft Entra. Le nom de domaine de ce compte est CN=krbtgt_AzureAD,CN=Users,<Domain-DN> . |
VersionClé | Version de clé de la clé de chiffrement 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, keyVersion initiale peut être 192272. La première fois que la clé est pivotée, la version peut passer à 212621. La chose importante à vérifier est que KeyVersion pour l’objet local et CloudKeyVersion pour l’objet cloud sont identiques. |
CléMiseÀJourLe | Date et heure auxquelles la clé de chiffrement du TGT du serveur Kerberos Microsoft Entra a été mise à jour ou créée |
KeyUpdatedFrom | Le contrôleur de domaine où la clé de chiffrement TGT du serveur Kerberos Microsoft Entra a été mise à jour pour la dernière fois. |
CloudId | L'ID de l'objet Microsoft Entra. Doit correspondre à l’ID de la première ligne du tableau. |
CloudDomainDnsName | DomainDnsName provenant de l’objet Microsoft Entra. Doit correspondre au « DomainDnsName » de la deuxième ligne du tableau. |
Version de clé Cloud | KeyVersion de l’objet Microsoft Entra. Doit correspondre à KeyVersion de la cinquième ligne du tableau. |
CléDuNuageMiseÀJourLe | KeyUpdatedOn de l’objet Microsoft Entra. Doit correspondre à KeyUpdatedOn de la sixième ligne du tableau. |
Faire pivoter la clé du serveur Kerberos Microsoft Entra
Les clés krbtgt de chiffrement du serveur Microsoft Entra Kerberos doivent être pivotées régulièrement. Nous vous recommandons de suivre la même planification que celle que vous utilisez pour faire pivoter toutes les autres clés Krbtgt DC Active Directory.
Avertissement
Il existe d’autres outils qui peuvent faire pivoter les clés krbtgt . Toutefois, vous devez utiliser les outils mentionnés dans ce document pour faire pivoter les clés krbtgt de votre serveur Microsoft Entra Kerberos. 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 Microsoft Entra Kerberos 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 l’ID Microsoft Entra.
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, il existe deux objets KerberosDomain 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 de chaque forêt.
Suivez les instructions de créer un objet Kerberos Server dans chaque domaine et forêt de votre organisation qui contient 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 hybride locale synchronisée des utilisateurs avec la confiance Kerberos cloud Windows Hello for Business.
Résolution des problèmes et retour d'information
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 :
- Ouvrez le Hub de commentaires et vérifiez que vous êtes connecté.
- Soumettez des commentaires en sélectionnant les catégories suivantes :
- Catégorie : Sécurité et confidentialité
- Sous-catégorie : FIDO
- Pour capturer les logs, utilisez l’option Recréer mon problème .
FAQ sur la connexion par clé de sécurité sans mot de passe
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 formats. 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 les 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 au 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 installation propre d'un ordinateur hybride joint à Microsoft Entra, après le processus de jonction au domaine et de redémarrage, vous devez vous connecter à l'aide d'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
une fenêtre d’invite de commandes et vérifiez que les états AzureAdJoined et DomainJoined s’affichent comme 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 sur ma ressource réseau NTLM après m'être connecté avec FIDO et recevoir une demande d'identification ?
Assurez-vous qu’un nombre suffisant de contrôleurs de domaine sont mis à jour pour répondre à temps et traiter votre demande de ressources. Pour déterminer si un contrôleur de domaine exécute la fonctionnalité, exécutez nltest /dsgetdc:contoso /keylist /kdc
, puis examinez la sortie.
Remarque
Le commutateur /keylist
dans la commande nltest
est disponible dans le client Windows 10 v2004 et versions ultérieures.
Existe-t-il un nombre maximal de groupes par jeton pour Microsoft Entra Kerberos ?
Oui, vous pouvez avoir jusqu’à 1 010 groupes par jeton.
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.