Configurer un cloud de confiance sur AD DS local et Microsoft Entra ID pour accéder à Azure Files

De nombreuses organisations veulent utiliser l’authentification basée sur l’identité pour les partages de fichiers SMB Azure dans des environnements qui s’étendent sur Azure Active Directory Domain Services (AD DS) local et Microsoft Entra ID (anciennement Azure Active Directory), mais ne respectent pas les conditions préalables de domaine ou de système d’exploitation nécessaires.

Dans ces scénarios, les clients peuvent activer l’authentification Kerberos Microsoft Entra pour les identités utilisateur hybrides, puis établir un trust de confiance entre leurs services AD DS local et Microsoft Entra ID pour accéder aux partages de fichiers SMB en utilisant leur informations d’identification locales. Cet article explique le fonctionnement d’un cloud de confiance et fournit des instructions pour la configuration et la validation. Il inclut également les étapes permettant de faire pivoter une clé Kerberos pour votre compte de service dans Microsoft Entra ID et un objet domaine approuvé, ainsi que la procédure de suppression d’un objet domaine approuvé et de tous les paramètres Kerberos, si vous le souhaitez.

Cet article se concentre sur l’authentification des identités utilisateur hybrides, qui sont des identités AD DS locales synchronisées avec Microsoft Entra ID en tirant parti de Microsoft Entra Connect ou de la synchronisation cloud Microsoft Entra Connect. Les identités uniquement cloud ne sont pas prises en charge pour Azure Files actuellement.

S’applique à

Type de partage de fichiers	SMB	NFS
Partages de fichiers Standard (GPv2), LRS/ZRS
Partages de fichiers Standard (GPv2), GRS/GZRS
Partages de fichiers Premium (FileStorage), LRS/ZRS

Scénarios

Les scénarios suivants sont des exemples dans lesquels vous voudrez peut-être configurer un cloud de confiance :

• Vous avez un service AD DS local traditionnel, mais vous ne pouvez pas l’utiliser pour l’authentification, car vous n’avez pas de connectivité réseau sans entrave aux contrôleurs de domaine.

• Vous avez commencé à migrer vers le cloud, mais vous avez actuellement des applications s’exécutant encore sur un service AD DS local traditionnel.

• Certains ou l’ensemble des ordinateurs de votre client ne respectent pas aux exigences de système d’exploitation pour l’authentification Kerberos Microsoft Entra.

autorisations

Pour effectuer les étapes présentées dans cet article, vous avez besoin de ce qui suit :

• Un nom d’utilisateur et un mot de passe d’administrateur Active Directory locaux
• Nom d’utilisateur et mot de passe de compte Administrateur général Microsoft Entra

Prérequis

Avant d’implémenter le flux entrant d’authentification basée sur la confiance, vérifiez d’abord que les conditions préalables suivantes sont remplies :

Activer l’authentification Kerberos Microsoft Entra

Si vous avez déjà activé l’authentification Kerberos Microsoft Entra sur votre compte de stockage, vous pouvez ignorer cette étape et passer à Créer et configurer l’objet domaine approuvé Kerberos Microsoft Entra.

Vous pouvez activer l’authentification Microsoft Entra Kerberos sur Azure Files pour les comptes d’utilisateur hybrides via le Portail Azure, PowerShell ou Azure CLI.

Set-AzStorageAccount -ResourceGroupName <resourceGroupName> -StorageAccountName <storageAccountName> -EnableAzureActiveDirectoryKerberosForFile $true

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot

Set-AzStorageAccount -ResourceGroupName <resourceGroupName> -StorageAccountName <storageAccountName> -EnableAzureActiveDirectoryKerberosForFile $true -ActiveDirectoryDomainName $domainName -ActiveDirectoryDomainGuid $domainGuid

az storage account update --name <storageaccountname> --resource-group <resourcegroupname> --enable-files-aadkerb true

$domainInformation = Get-ADDomain
$domainGuid = $domainInformation.ObjectGUID.ToString()
$domainName = $domainInformation.DnsRoot

az storage account update --name <storageAccountName> --resource-group <resourceGroupName> --enable-files-aadkerb true --domain-name <domainName> --domain-guid <domainGuid>

Accorder le consentement administrateur au nouveau principal de service

Après avoir activé l’authentification Microsoft Entra Kerberos, vous devez accorder explicitement le consentement administrateur à la nouvelle application Microsoft Entra inscrite dans votre tenant Microsoft Entra. Ce principal de service est généré automatiquement et n’est pas utilisé pour l’autorisation sur le partage de fichiers. Par conséquent, n’apportez pas de modifications au principal de service autres que celles décrites ici. Si vous le faites, vous risquez d’obtenir une erreur.

Vous pouvez configurer les autorisations d’API à partir du portail Azure en procédant comme suit :

1. Ouvrez Microsoft Entra ID.
2. Dans le menu de service, sous Gérer, sélectionnez Inscriptions d’applications.
3. Sélectionner Toutes les applications.
4. Sélectionnez l’application avec le nom correspondant [Compte de stockage] <your-storage-account-name>.file.core.windows.net.
5. Dans le menu de service, sous Gérer, sélectionnez Autorisations d’API.
6. Sélectionnez Octroyer le consentement administrateur pour [Directory Name] afin d’accorder le consentement pour les trois autorisations d’API demandées (openid, profil et User.Read) à tous les comptes dans l’annuaire.
7. Sélectionnez Oui pour confirmer.

Désactiver l’authentification multifacteur sur le compte de stockage

Microsoft Entra Kerberos ne prend pas en charge l’utilisation de MFA pour accéder aux partages de fichiers Azure configurés avec Microsoft Entra Kerberos. Vous devez exclure l’application Microsoft Entra représentant votre compte de stockage de vos stratégies d’accès conditionnel MFA si elles sont valables pour toutes les applications.

L’application de compte de stockage doit avoir le même nom que le compte de stockage dans la liste d’exclusions d’accès conditionnel. Lorsque vous recherchez l’application de compte de stockage dans la liste d’exclusion d’accès conditionnel, recherchez : [Compte de stockage] <your-storage-account-name>.file.core.windows.net

N’oubliez pas de remplacer <your-storage-account-name> par la valeur appropriée.

Pour obtenir des conseils sur la désactivation de l’authentification multifacteur, consultez les rubriques suivantes :

• Ajouter des exclusions pour les principaux de service des ressources Azure
• Créer une stratégie d’accès conditionnel

Affecter des autorisations au niveau du partage

Lorsque vous activez l’accès basé sur l’identité, vous devez déterminer pour chaque partage quels utilisateurs et quels groupes ont accès à ce partage particulier. Une fois qu’un(e) utilisateur(-trice) ou un groupe est autorisé à accéder à un partage, les ACL de Windows (également appelées autorisations NTFS) sur les fichiers et répertoires individuels prennent le relais. Cela permet un contrôle précis des autorisations, comme un partage SMB sur un serveur Windows.

Pour définir des autorisations au niveau du partage, suivez les instructions fournies dans Affecter des autorisations au niveau du partage à une identité.

Configurer des autorisations au niveau de l’annuaire et des fichiers

Une fois que les autorisations au niveau du partage sont en place, vous pouvez attribuer des autorisations au niveau du répertoire/fichier à l’utilisateur ou au groupe. Cela nécessite l’utilisation d’un appareil avec une connectivité réseau non bloquée à un AD local.

Pour configurer des autorisations au niveau de l’annuaire et des fichiers, suivez les instructions fournies dans Configurer des autorisations au niveau de l’annuaire et des fichiers sur SMB.

Créer et configurer l’objet de domaine de confiance Microsoft Entra Kerberos

Pour créer et configurer l’objet domaine approuvé Kerberos Microsoft Entra, vous utiliser le module PowerShell Gestion des authentifications hybrides Azure AD. Ce module permet aux organisations d’identité hybride d’utiliser des informations d’identification modernes pour leurs applications et d’activer Microsoft Entra ID pour qu’il devienne la source approuvée pour les authentifications locale et cloud.

Configurer l’objet Domaine approuvé

Vous allez utiliser le module PowerShell de gestion des authentifications hybrides Azure AD pour configurer un objet domaine approuvé dans le domaine AD local et enregistrer les informations de confiance avec Microsoft Entra ID. Cela crée une relation de confiance avec l’AD local, ce qui permet à Microsoft Entra ID de faire confiance à cet AD local.

Vous devez uniquement configurer l’objet domaine approuvé une fois par domaine. Si vous l’avez déjà effectué pour ce domaine, vous pouvez ignorer cette section et passer à Configurer les clients pour récupérer des tickets Kerberos.

Installez le module de gestion des authentifications PowerShell Azure AD Hybride

1. Démarrez une session Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Installez le module de gestion des authentifications PowerShell Azure AD Hybride à l’aide du script suivant. Le script :

   • Active TLS 1.2 pour la communication.
   • Installe le fournisseur du package NuGet.
   • Inscrit le référentiel PSGallery.
   • Installe le module PowerShellGet.
   • Installe le module de gestion des authentifications PowerShell Azure AD Hybride.
     • Le module PowerShell de gestion des authentifications hybrides Azure AD utilise le module AzureADPreview qui fournit des fonctionnalités de gestion Microsoft Entra avancées.
     • Pour vous protéger contre des conflits d’installation inutiles avec le module Azure AD PowerShell, cette commande inclut l’indicateur d’option -AllowClobber.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Install-PackageProvider -Name NuGet -Force

if (@(Get-PSRepository | ? {$_.Name -eq "PSGallery"}).Count -eq 0){
    Register-PSRepository -DefaultSet-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
}

Install-Module -Name PowerShellGet -Force

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Créer l’objet Domaine approuvé

1. Démarrez une session Windows PowerShell avec l’option Exécuter en tant qu’administrateur.

2. Définissez les paramètres communs. Personnalisez le script ci-dessous avant de l’exécuter.

   • Définissez le paramètre $domain sur votre nom de domaine Active Directory local.
   • Lorsque cela est demandé par Get-Credential, saisissez un nom d’utilisateur et un mot de passe d’administrateur Active Directory locaux.
   • Définissez le paramètre $cloudUserName sur le nom d’utilisateur d’un compte privilégié d’administrateur général pour l’accès au cloud de Microsoft Entra.

   Remarque

   Si vous souhaitez utiliser votre compte de connexion Windows actuel pour accéder à Active Directory local, vous pouvez ignorer l’étape où les informations d’identification sont affectées au paramètre $domainCred. Si vous adoptez cette approche, n’incluez pas le paramètre -DomainCredential dans les commandes PowerShell qui suivent cette étape.

   $domain = "your on-premesis domain name, for example contoso.com"
   
   $domainCred = Get-Credential
   
   $cloudUserName = "Azure AD user principal name, for example admin@contoso.onmicrosoft.com"
   

3. Vérifiez les paramètres Kerberos actuels du domaine.

   Exécutez la commande suivante pour vérifier les paramètres Kerberos actuels de votre domaine :

   Get-AzureAdKerberosServer -Domain $domain `
       -DomainCredential $domainCred `
       -UserPrincipalName $cloudUserName
   

   Si c’est la première fois que vous appelez une commande Microsoft Entra Kerberos, vous devez demander à accéder au cloud Microsoft Entra.

   • Entrez le mot de passe de votre compte d’administrateur général Microsoft Entra.
   • Si votre organisation utilise d’autres méthodes d’authentification modernes telles que l’authentification multifacteur de Microsoft Entra ou une carte à puce, suivez les instructions requises pour vous connecter.

   Si c’est la première fois que vous configurez les paramètres Microsoft Entra Kerberos, la cmdlet Get-AzureAdKerberosServer affiche des informations vides, comme dans l’exemple de sortie suivant :

   ID                  :
   UserAccount         :
   ComputerAccount     :
   DisplayName         :
   DomainDnsName       :
   KeyVersion          :
   KeyUpdatedOn        :
   KeyUpdatedFrom      :
   CloudDisplayName    :
   CloudDomainDnsName  :
   CloudId             :
   CloudKeyVersion     :
   CloudKeyUpdatedOn   :
   CloudTrustDisplay   :
   

   Si votre domaine prend déjà en charge l’authentification FIDO, la cmdlet Get-AzureAdKerberosServer affiche des informations sur le compte de service Microsoft Entra, comme dans l’exemple de sortie suivant. Le champ CloudTrustDisplay retourne une valeur vide.

   ID                  : XXXXX
   UserAccount         : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com
   ComputerAccount     : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com
   DisplayName         : XXXXXX_XXXXX
   DomainDnsName       : contoso.com
   KeyVersion          : 53325
   KeyUpdatedOn        : 2/24/2024 9:03:15 AM
   KeyUpdatedFrom      : ds-aad-auth-dem.contoso.com
   CloudDisplayName    : XXXXXX_XXXXX
   CloudDomainDnsName  : contoso.com
   CloudId             : XXXXX
   CloudKeyVersion     : 53325
   CloudKeyUpdatedOn   : 2/24/2024 9:03:15 AM
   CloudTrustDisplay   :
   

4. Ajoutez l’objet Domaine approuvé.

   Exécutez le cmdlet PowerShell Set-AzureAdKerberosServer pour ajouter l’objet Domaine approuvé. Assurez-vous d’inclure le paramètre -SetupCloudTrust. S’il n’existe aucun compte de service Microsoft Entra, cette commande crée un compte de service Microsoft Entra. Cette commande ne créera l’objet de domaine approuvé demandé que s’il existe déjà un compte de service Microsoft Entra.

   Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName -DomainCredential $domainCred -SetupCloudTrust
   

   Remarque

   Sur une forêt de plusieurs domaines, pour éviter l’erreur LsaCreateTrustedDomainEx 0x549 lors de l’exécution de la commande sur un domaine enfant :

   1. Exécutez la commande sur le domaine racine (avec le paramètre -SetupCloudTrust).
   2. Exécutez la même commande sur le domaine enfant sans le paramètre -SetupCloudTrust.

   Après avoir créé l’objet domaine approuvé, vous pouvez vérifier le Paramètres Kerberos mis à jour à l’aide du cmdlet PowerShell Get-AzureAdKerberosServer, comme indiqué à l’étape précédente. Si le cmdlet Set-AzureAdKerberosServer a été exécuté avec succès avec le paramètre -SetupCloudTrust, le champ CloudTrustDisplay doit maintenant retourner Microsoft.AzureAD.Kdc.Service.TrustDisplay, comme dans l’exemple de sortie suivant :

   ID                  : XXXXX
   UserAccount         : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com
   ComputerAccount     : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com
   DisplayName         : XXXXXX_XXXXX
   DomainDnsName       : contoso.com
   KeyVersion          : 53325
   KeyUpdatedOn        : 2/24/2024 9:03:15 AM
   KeyUpdatedFrom      : ds-aad-auth-dem.contoso.com
   CloudDisplayName    : XXXXXX_XXXXX
   CloudDomainDnsName  : contoso.com
   CloudId             : XXXXX
   CloudKeyVersion     : 53325
   CloudKeyUpdatedOn   : 2/24/2024 9:03:15 AM
   CloudTrustDisplay   : Microsoft.AzureAD.Kdc.Service.TrustDisplay
   

   Notes

   Les clouds souverains Azure nécessitent la définition de la propriété TopLevelNames, qui est définie sur windows.net par défaut. Les déploiements du cloud souverain Azure de SQL Managed Instance utilisent un autre nom de domaine de niveau supérieur, par exemple usgovcloudapi.net pour Azure US Government. Définissez votre objet de domaine approuvé sur ce nom de domaine de niveau supérieur à l’aide de la commande PowerShell suivante : Set-AzureADKerberosServer -Domain $domain -DomainCredential $domainCred -CloudCredential $cloudCred -SetupCloudTrust -TopLevelNames "usgovcloudapi.net,windows.net". Vous pouvez utiliser le paramètre avec la commande PowerShell suivante : Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName | Select-Object -ExpandProperty CloudTrustDisplay.

Configurer les clients pour récupérer des tickets Kerberos

Identifiez votre ID de tenant Microsoft Entra et utilisez une stratégie de groupe pour configurer le ou les ordinateurs client à partir desquels vous voulez monter/utiliser des partages de fichiers Azure. Vous devez le faire sur chaque client sur lequel Azure Files sera utilisé.

Définissez sur « Activé » cette stratégie de groupe sur le ou les clients : Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

1. Déployez le paramètre de Stratégie de groupe suivant sur les ordinateurs clients à l’aide du flux entrant basé sur la confiance :

   1. Modifiez le paramètre de stratégie Administrative Templates\System\Kerberos\Specify KDC proxy servers for Kerberos clients.

   2. Sélectionnez Enabled.

   3. Sous Options, sélectionnez Afficher.... La boîte de dialogue Afficher le contenu s’ouvre.

      

   4. Définissez les paramètres des serveurs proxy KDC à l’aide des mappages comme suit. Insérez votre ID de locataire Microsoft Entra dans l’espace réservé your_Azure_AD_tenant_id. Remarquez qu’il y a un espace après https et avant le / de fermeture dans le mappage des valeurs.

      Nom de la valeur	Valeur
      KERBEROS.MICROSOFTONLINE.COM	<https login.microsoftonline.com:443:your_Azure_AD_tenant_id/kerberos />

      

   5. Sélectionnez OK pour fermer la boîte de dialogue « Afficher le contenu ».

   6. Sélectionnez Appliquer dans la boîte de dialogue « Spécifier les serveurs proxy KDC pour les clients Kerberos ».

Faire pivoter la clé Kerberos

Vous pouvez effectuer une rotation périodique de la clé Kerberos pour le compte de service Microsoft Entra créé et l’objet Domaine approuvé à des fins de gestion.

Set-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName -SetupCloudTrust `
   -RotateServerKey

Une fois la clé pivotée, la propagation de la clé modifiée entre les serveurs KDC Kerberos prend plusieurs heures. En raison de ce délai de distribution des clés, vous pouvez effectuer une rotation de la clé une fois dans les 24 heures. Si vous avez besoin d’effectuer une autre rotation de la clé dans les 24 heures (par exemple, après avoir créé l’objet de domaine approuvé), vous pouvez ajouter le paramètre -Force :

Set-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName -SetupCloudTrust `
   -RotateServerKey -Force

Supprimer l’objet Domaine approuvé

Vous pouvez supprimer l’objet Domaine approuvé ajouté à l’aide de la commande suivante :

Remove-AzureADKerberosServerTrustedDomainObject -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName

Cette commande supprime uniquement l’objet Domaine approuvé. Si votre domaine prend en charge l’authentification FIDO, vous pouvez supprimer l’objet de domaine approuvé tout en conservant le compte de service Microsoft Entra requis pour le service d’authentification FIDO.

Supprimer tous les paramètres Kerberos

Vous pouvez supprimer le compte de service Microsoft Entra et l’objet Domaine approuvé à l’aide de la commande suivante :

Remove-AzureAdKerberosServer -Domain $domain `
   -DomainCredential $domainCred `
   -UserPrincipalName $cloudUserName

Étape suivante

• Monter un partage de fichiers Azure