Résoudre Azure Files problèmes d’authentification et d’autorisation basés sur l’identité (SMB)

Cet article répertorie les problèmes courants liés à l’utilisation de partages de fichiers Azure SMB avec l’authentification basée sur l’identité. Il fournit également les causes possibles et les solutions de ces problèmes. L’authentification basée sur l’identité n’est actuellement pas prise en charge pour les partages de fichiers Azure NFS.

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

Erreur lors de l’exécution du module AzFilesHybrid

Lorsque vous essayez d’exécuter le module AzFilesHybrid, vous pouvez recevoir l’erreur suivante :

le client ne dispose pas d’un privilège qui est obligatoire.

Cause : les autorisations AD sont insuffisantes

Ce problème se produit parce que vous n’avez pas les autorisations Active Directory (AD) requises pour exécuter le module.

Solution

Reportez-vous aux privilèges AD ou contactez votre administrateur AD pour fournir les privilèges requis.

Erreur 5 lors du montage d’un partage de fichiers Azure

Quand vous essayez de monter un partage de fichiers, vous pouvez recevoir l’erreur suivante :

Erreur système 5. L’accès est refusé.

Cause : les autorisations au niveau du partage sont incorrectes

Si les utilisateurs finaux accèdent au partage de fichiers Azure à l’aide de services de domaine Active Directory (AD DS) ou de l’authentification Microsoft Entra Domain Services, l’accès au partage de fichiers échoue avec l’erreur « Accès refusé » si les autorisations au niveau du partage sont incorrectes.

Solution

Vérifiez que les autorisations sont configurées correctement :

• Active Directory Domain Services (AD DS), voir Assigner des autorisations au niveau du partage.

  Les attributions d’autorisations au niveau du partage sont prises en charge pour les groupes et les utilisateurs qui sont synchronisés entre AD DS et Microsoft Entra ID à l’aide de Microsoft Entra Connect Sync ou de la synchronisation cloud Microsoft Entra Connect. Vérifiez que les groupes et les utilisateurs auxquels les autorisations au niveau du partage sont attribuées ne sont pas des groupes « cloud uniquement » non pris en charge.

• Microsoft Entra Domain Services, veuillez consulter la section Attribuer des autorisations au niveau du partage.

Erreur AadDsTenantNotFound lors de l’activation de l’authentification des services de domaine Microsoft Entra pour Azure Files « Impossible de localiser les locataires actifs avec l’ID de locataire Microsoft Entra »

Cause

L’erreur AadDsTenantNotFound se produit lorsque vous essayez d’activer l’authentification Microsoft Entra Domain Services pour Azure Files sur un compte de stockage où Microsoft Entra Domain Services n’est pas créé sur le locataire Microsoft Entra de l’abonnement associé.

Solution

Activez les services de domaine Microsoft Entra sur le locataire Microsoft Entra de l’abonnement où votre compte de stockage est déployé. Vous avez besoin des privilèges d’administrateur du locataire Microsoft Entra pour créer un domaine géré. Si vous n’êtes pas l’administrateur du locataire Microsoft Entra, contactez l’administrateur et suivez les instructions pas à pas pour créer et configurer un domaine managé Microsoft Entra Domain Services.

Impossible de monter Azure Files avec les informations d’identification AD

Étapes des autodiagnostics

Tout d’abord, assurez-vous que vous avez suivi les quatre étapes permettant d’activer l’authentification AD DS Azure Files.

Ensuite, essayez de monter un partage Azure Files avec la clé de compte de stockage. Si le partage ne parvient pas à monter, téléchargez AzFileDiagnostics pour vous aider à valider l’environnement en cours d’exécution du client. AzFileDiagnostics peut détecter des configurations client incompatibles susceptibles de provoquer un échec d’accès pour Azure Files, fournir des conseils prescriptifs sur la réparation automatique et collecter les traces de diagnostic.

Troisièmement, vous pouvez exécuter l’applet Debug-AzStorageAccountAuth de commande pour effectuer un ensemble de vérifications de base sur votre configuration AD avec l’utilisateur AD connecté. Cette applet de commande est prise en charge sur AzFilesHybrid 0.1.2 et versions ultérieures. Vous devez exécuter cette applet de commande avec un utilisateur AD disposant de l’autorisation de propriétaire sur le compte de stockage cible.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

L’applet de commande effectue dans l’ordre les vérifications, puis fournit des conseils en cas d’échec :

1. CheckADObjectPasswordIsCorrect: vérifiez que le mot de passe configuré sur l’identité AD qui représente le compte de stockage correspond à celui de la clé kerb1 ou kerb2 du compte de stockage. Si le mot de passe est incorrect, vous pouvez exécuter Update-AzStorageAccountADObjectPassword pour réinitialiser le mot de passe.
2. CheckADObject: vérifiez qu’il existe un objet dans Active Directory qui représente le compte de stockage et a le spN correct (nom du principal de service). Si le SPN n’est pas correctement configuré, exécutez la commande Set-AD cmdlet AD retournée la commande cmdlet de débogage pour configurer le SPN.
3. CheckDomainJoined: vérifiez que l’ordinateur client est joint à AD. Si votre ordinateur n’est pas joint à AD, reportez-vous aux instructions de jointure d’un ordinateur à un domaine pour obtenir des instructions de jointure de domaine.
4. CheckPort445Connectivity: vérifiez si le port 445 est ouvert pour la connexion SMB. Si le port 445 n’est pas ouvert, reportez-vous à l’outil de dépannage AzFileDiagnostics pour les problèmes de connectivité avec Azure Files.
5. CheckSidHasAadUser: vérifiez si l’utilisateur AD connecté est synchronisé avec l’ID Microsoft Entra. Si vous souhaitez rechercher si un utilisateur AD spécifique est synchronisé avec l’ID Microsoft Entra, vous pouvez spécifier les -UserName paramètres d’entrée et -Domain les paramètres d’entrée. Pour un SID donné, il vérifie s’il existe un utilisateur Microsoft Entra associé.
6. CheckAadUserHasSid: vérifiez si l’utilisateur AD connecté est synchronisé avec l’ID Microsoft Entra. Si vous souhaitez rechercher si un utilisateur AD spécifique est synchronisé avec l’ID Microsoft Entra, vous pouvez spécifier les -UserName paramètres d’entrée et -Domain les paramètres d’entrée. Pour un utilisateur Microsoft Entra donné, il vérifie son SID. Pour exécuter cette vérification, vous devez fournir le -ObjectId paramètre, ainsi que l’ID d’objet de l’utilisateur Microsoft Entra.
7. CheckGetKerberosTicket: essayez d’obtenir un ticket Kerberos pour vous connecter au compte de stockage. S’il n’existe pas de jeton Kerberos valide, exécutez l’applet klist get cifs/storage-account-name.file.core.windows.net de commande et examinez le code d’erreur pour déterminer la cause de l’échec de récupération de ticket.
8. CheckStorageAccountDomainJoined: vérifiez si l’authentification AD est activée et que les propriétés AD du compte sont remplies. Si ce n’est pas le cas, activez l’authentification AD DS sur Azure Files.
9. CheckUserRbacAssignment: vérifiez si l’identité AD dispose de l’attribution de rôle RBAC appropriée pour fournir des autorisations au niveau du partage pour accéder à Azure Files. Si ce n’est pas le cas, configurez l’autorisation au niveau du partage. (Prise en charge sur AzFilesHybrid 0.2.3 et versions ultérieures).
10. CheckUserFileAccess: vérifiez si l’identité AD dispose de l’autorisation de répertoire/fichier appropriée (ACL Windows) pour accéder à Azure Files. Si ce n’est pas le cas, configurez l’autorisation au niveau du répertoire/fichier. Pour exécuter cette vérification, vous devez fournir le -FilePath paramètre, ainsi que le chemin d’accès du fichier monté auquel vous souhaitez déboguer l’accès. (Prise en charge sur AzFilesHybrid 0.2.3 et versions ultérieures).
11. CheckAadKerberosRegistryKeyIsOff: vérifiez si la clé de Registre Microsoft Entra Kerberos est désactivée. Si la clé est activée, exécutez à reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 partir d’une invite de commandes avec élévation de privilèges pour la désactiver, puis redémarrez votre ordinateur. (Pris en charge sur AzFilesHybrid v0.2.9+ version)

Si vous souhaitez simplement exécuter une sous-sélection des vérifications précédentes, vous pouvez utiliser le -Filter paramètre, ainsi qu’une liste de vérifications séparées par des virgules à exécuter. Par exemple, pour exécuter toutes les vérifications liées aux autorisations de niveau partage (RBAC), utilisez les applets de commande PowerShell suivantes :

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Si vous avez monté le partage de fichiers sur X:, et si vous souhaitez uniquement exécuter la vérification liée aux autorisations au niveau du fichier (ACL Windows), vous pouvez exécuter les applets de commande PowerShell suivantes :

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

Impossible de monter des partages de fichiers Azure avec Microsoft Entra Kerberos

Étapes des autodiagnostics

Tout d’abord, vérifiez que vous avez suivi les étapes pour activer l’authentification Microsoft Entra Kerberos.

Ensuite, vous pouvez exécuter l’applet Debug-AzStorageAccountAuth de commande pour effectuer un ensemble de vérifications de base. Cette applet de commande est prise en charge pour les comptes de stockage configurés pour l’authentification Microsoft Entra Kerberos, sur AzFilesHybrid v0.3.0+ version.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

L’applet de commande effectue dans l’ordre les vérifications, puis fournit des conseils en cas d’échec :

1. CheckPort445Connectivity: vérifiez si le port 445 est ouvert pour la connexion SMB. Si le port 445 n’est pas ouvert, utilisez l’outil de résolution des problèmes AzFileDiagnostics pour les problèmes de connectivité avec Azure Files.
2. CheckAADConnectivity: Recherchez la connectivité Entra. Les montages SMB avec l’authentification Kerberos peuvent échouer si le client ne peut pas contacter Entra. Si cette vérification échoue, cela indique qu’il existe une erreur réseau (peut-être un problème de pare-feu ou de VPN).
3. CheckEntraObject: Vérifiez qu’il existe un objet dans l’Entra qui représente le compte de stockage et a le nom de principal de service approprié (SPN). Si le SPN n’est pas correctement configuré, désactivez et réactivez l’authentification Entra Kerberos sur le compte de stockage.
4. CheckRegKey: vérifiez si la clé de CloudKerberosTicketRetrieval Registre est activée. Cette clé de Registre est requise pour l’authentification Entra Kerberos.
5. CheckRealmMap: vérifiez si l’utilisateur a configuré des mappages de domaine qui joindreaient le compte à un autre domaine Kerberos que KERBEROS.MICROSOFTONLINE.COM.
6. CheckAdminConsent: vérifiez si le principal du service Entra a reçu le consentement administrateur pour les autorisations Microsoft Graph requises pour obtenir un ticket Kerberos.
7. CheckWinHttpAutoProxySvc: recherche le service de découverte automatique du proxy web WinHTTP (WinHttpAutoProxySvc) requis pour l’authentification Microsoft Entra Kerberos. Son état doit être défini sur Running.
8. CheckIpHlpScv: recherchez le service d’assistance IP (iphlpsvc) requis pour l’authentification Microsoft Entra Kerberos. Son état doit être défini sur Running.
9. CheckFiddlerProxy: vérifiez si un proxy Fiddler qui empêche l’authentification Microsoft Entra Kerberos existe.
10. CheckEntraJoinType: vérifiez si l’ordinateur est joint à un domaine Entra ou un domaine Entra hybride joint. Il s’agit d’un prérequis pour l’authentification Microsoft Entra Kerberos.

Si vous souhaitez simplement exécuter une sous-sélection des vérifications précédentes, vous pouvez utiliser le -Filter paramètre, ainsi qu’une liste de vérifications séparées par des virgules à exécuter.

Impossible de configurer des autorisations au niveau des répertoires/fichiers (listes de contrôle d’accès Windows) avec l’Explorateur de fichiers Windows

Symptôme

Vous pouvez être confronté à l’un des symptômes décrits ci-dessous quand vous tentez de configurer des listes de contrôle d’accès Windows avec l’Explorateur de fichiers sur un partage de fichiers monté :

• Quand vous cliquez sur Modifier l’autorisation sous l’onglet Sécurité, l’Assistant Autorisation ne se charge pas.
• Quand vous essayez de sélectionner un nouvel utilisateur ou un nouveau groupe, l’emplacement du domaine n’affiche pas le bon domaine AD DS.
• Vous utilisez plusieurs forêts AD et obtenez le message d’erreur suivant : « Les contrôleurs de domaine Active Directory requis pour rechercher les objets sélectionnés dans les domaines suivants ne sont pas disponibles. Assurez-vous que les contrôleurs de domaine Active Directory sont disponibles et essayez de sélectionner à nouveau les objets. ».

Solution

Nous vous recommandons de configurer des autorisations au niveau du répertoire/fichier à l’aide d’icacls au lieu d’utiliser Windows Explorateur de fichiers.

Impossible d’afficher UserPrincipalName (UPN) d’un propriétaire de fichier/répertoire dans Explorateur de fichiers

Symptôme

Explorateur de fichiers affiche l’identificateur de sécurité (SID) d’un propriétaire de fichier/répertoire, mais pas l’UPN.

Cause

L’Explorateur de fichiers appelle directement une API RPC vers le serveur (Azure Files) pour traduire le SID en UPN. Azure Files ne prend pas en charge cette API. Par conséquent, l’UPN n’est pas affiché.

Solution

Sur un client joint à un domaine, utilisez la commande PowerShell suivante pour afficher tous les éléments d’un répertoire et leur propriétaire, y compris UPN :

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Erreurs lors de l’exécution de la cmdlet join-AzStorageAccountForAuth

Erreur : « Le service d’annuaire n’a pas pu allouer un identificateur relatif »

Cette erreur peut se produire si un contrôleur de domaine titulaire du rôle FSMO du maître RID n’est pas disponible ou a été supprimé du domaine, puis restauré à partir d’une sauvegarde. Vérifiez que tous les contrôleurs de domaine sont en cours d’exécution et disponibles.

Erreur : « Impossible de lier les paramètres positionnels, car aucun nom n’a été fourni »

Cette erreur est probablement déclenchée par une erreur de syntaxe dans la Join-AzStorageAccountforAuth commande. Vérifiez la commande pour les fautes d’orthographe ou les erreurs de syntaxe et vérifiez que la dernière version du module AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases) est installée.

Prise en charge de l’authentification AD DS locale Azure Files pour le chiffrement Kerberos AES-256

Azure Files prend en charge le chiffrement Kerberos AES-256 pour l’authentification AD DS commençant avec le module AzFilesHybrid v0.2.2. AES-256 est la méthode de chiffrement recommandée. Il s’agit de la méthode de chiffrement par défaut à partir du module AzFilesHybrid v0.2.5. Si vous avez activé l’authentification AD DS avec une version de module inférieure à v0.2.2, vous devez télécharger le dernier module AzFilesHybrid et exécuter le script PowerShell suivant. Si vous n’avez pas encore activé l’authentification AD DS sur votre compte de stockage, vous pouvez suivre ces instructions.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Dans le cadre de la mise à jour, l’applet de commande fait pivoter les clés Kerberos, ce qui est nécessaire pour basculer vers AES-256. Il n’est pas nécessaire de faire pivoter vers l’arrière, sauf si vous souhaitez régénérer les deux mots de passe.

L’identité utilisateur ayant auparavant le rôle de propriétaire ou de collaborateur dispose toujours d’un accès à la clé de compte de stockage

Les rôles Propriétaire et Collaborateur du compte de stockage vous accordent la possibilité d’énumérer les clés de compte de stockage. La clé de compte de stockage permet un accès complet aux données du compte de stockage, notamment les partages de fichiers, les objets blob, les tables et les files d’attente. Il fournit également un accès limité aux opérations de gestion Azure Files via les API de gestion héritées exposées via l’API FileREST. Si vous modifiez les attributions de rôles, vous devez considérer que les utilisateurs supprimés des rôles Propriétaire ou Contributeur peuvent continuer à avoir accès au compte de stockage via des clés de compte de stockage enregistrées.

Solution 1

Vous pouvez résoudre ce problème facilement en faisant pivoter les clés de compte de stockage. Nous vous recommandons de faire pivoter les clés une par une, en passant d’un accès à l’autre lorsque les clés sont pivotées. Il existe deux types de clés partagées fournies par le compte de stockage : les clés de compte de stockage, qui fournissent un accès super administrateur aux données du compte de stockage, et les clés Kerberos, qui fonctionnent comme un secret partagé entre le compte de stockage et le contrôleur de domaine Windows Server Active Directory pour les scénarios Windows Server Active Directory.

Pour faire pivoter les clés Kerberos d’un compte de stockage, consultez Mettre à jour le mot de passe de l’identité de votre compte de stockage dans AD DS.

$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key1"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key2"

RESOURCE_GROUP_NAME="<resource-group>"
STORAGE_ACCOUNT_NAME="<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "primary"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "secondary"

Définir les autorisations de l’API sur une application nouvellement créée

Après avoir activé l’authentification Microsoft Entra Kerberos, vous devez accorder explicitement le consentement administrateur à la nouvelle application Microsoft Entra inscrite dans votre locataire Microsoft Entra pour terminer votre configuration. Vous pouvez configurer les autorisations d’API à partir du portail Azure en effectuant ces étapes.

1. Ouvrez Microsoft Entra ID.
2. Sélectionnez Inscriptions d’applications dans le volet gauche.
3. Sélectionnez Toutes les applications dans le volet droit.
4. Sélectionnez l’application avec le nom correspondant [Compte de stockage] $storageAccountName.file.core.windows.net.
5. Dans le volet gauche, sélectionnez Autorisations d’API.
6. En bas de la page, sélectionnez Ajouter des autorisations.
7. Sélectionner Accorder un consentement d’administrateur pour « NomRépertoire »

Erreurs potentielles lors de l’activation de l’authentification Microsoft Entra Kerberos pour les utilisateurs hybrides

Vous pouvez rencontrer les erreurs suivantes lors de l’activation de l’authentification Microsoft Entra Kerberos pour les comptes d’utilisateurs hybrides.

Erreur : Accord du consentement administrateur désactivé

Dans certains cas, l’administrateur Microsoft Entra peut désactiver la possibilité d’accorder le consentement de l’administrateur aux applications Microsoft Entra. Voici une capture d’écran de ce que cela ressemble dans le Portail Azure.

Si c’est le cas, demandez à votre administrateur Microsoft Entra d’accorder le consentement de l’administrateur à la nouvelle application Microsoft Entra. Pour rechercher et afficher vos administrateurs, sélectionnez Rôles et administrateurs, puis Administrateur d’application cloud.

Erreur : « Échec de la requête adressée à Azure AD Graph avec le code BadRequest »

Cause 1 : une stratégie de gestion des applications empêche la création d’informations d’identification

Lorsque vous activez l’authentification Microsoft Entra Kerberos, vous pouvez rencontrer cette erreur si les conditions suivantes sont remplies :

1. Vous utilisez la fonctionnalité d’évaluation/bêta des stratégies de gestion des applications.
2. Vous (ou votre administrateur) avez défini une stratégie à l’échelle du locataire qui :
   • N’a aucune date de début ou n’a pas de date de début avant le 1er janvier 2019.
   • Définit une restriction sur les mots de passe du principal de service, qui interdit les mots de passe personnalisés ou définit une durée de vie maximale de mot de passe de moins de 365,5 jours.

Il n’existe actuellement aucun moyen de contourner cette erreur.

Cause 2 : Une application existe déjà pour le compte de stockage

Vous pouvez également rencontrer cette erreur si vous avez précédemment activé l’authentification Microsoft Entra Kerberos via des étapes d’aperçu manuelles limitées. Pour supprimer l’application existante, le client ou son administrateur informatique peut exécuter le script suivant. L’exécution de ce script supprime l’ancienne application créée manuellement, et permet à la nouvelle expérience de créer et de gérer automatiquement la nouvelle application. Après avoir lancé la connexion à Microsoft Graph, connectez-vous à l’application Outils en ligne de commande Microsoft Graph sur votre appareil et accordez des autorisations à l’application.

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

Erreur : le mot de passe du principal de service a expiré dans l’ID Microsoft Entra

Si vous avez déjà activé l’authentification Microsoft Entra Kerberos via des étapes d’aperçu manuelles limitées, le mot de passe du principal de service du compte de stockage est défini pour expirer tous les six mois. Une fois le mot de passe expiré, les utilisateurs ne pourront pas obtenir de tickets Kerberos au partage de fichiers.

Pour atténuer ce problème, vous avez deux options : faire pivoter le mot de passe du principal de service dans Microsoft Entra tous les six mois, ou suivre ces étapes pour désactiver Microsoft Entra Kerberos, supprimer l’application existante et reconfigurer Microsoft Entra Kerberos.

Veillez à enregistrer les propriétés de domaine (domainName et domainGUID) avant de désactiver Microsoft Entra Kerberos, car vous en aurez besoin lors de la reconfiguration si vous souhaitez configurer des autorisations au niveau du répertoire et des fichiers à l’aide de Windows Explorateur de fichiers. Si vous n’avez pas enregistré les propriétés de domaine, vous pouvez toujours configurer des autorisations au niveau du répertoire/fichier à l’aide d’icacls comme solution de contournement.

1. Désactiver Microsoft Entra Kerberos
2. Supprimer l’application existante
3. Reconfigurer Microsoft Entra Kerberos via le Portail Azure

Une fois que vous avez reconfiguré Microsoft Entra Kerberos, la nouvelle expérience crée et gère automatiquement l’application nouvellement créée.

Erreur 1326 : le nom d’utilisateur ou le mot de passe est incorrect lors de l’utilisation d’une liaison privée

Si vous vous connectez à un compte de stockage via un point de terminaison privé/une liaison privée à l’aide de l’authentification Microsoft Entra Kerberos, lors de la tentative de montage d’un partage de fichiers via net use ou d’une autre méthode, le client est invité à entrer des informations d’identification. L’utilisateur va probablement saisir ses informations d'identification, mais celles-ci seront rejetées.

Cause

Cela est dû au fait que le client SMB a essayé d’utiliser Kerberos, mais a échoué. Il utilise donc l’authentification NTLM qui n’est pas prise en charge par Azure Files en ce qui concerne des informations d'identification de domaine. Le client ne peut pas obtenir de ticket Kerberos sur le compte de stockage, car le nom de domaine complet de liaison privée n’est inscrit à aucune application Microsoft Entra existante.

Solution

La solution consiste à ajouter le nom de domaine complet privateLink à l’application Microsoft Entra du compte de stockage avant de monter le partage de fichiers. Vous pouvez ajouter la propriété identifierUris requise à l’objet d’application à l’aide du Portail Azure en procédant comme suit.

1. Ouvrez Microsoft Entra ID.

2. Sélectionnez Inscriptions d’applications dans le volet gauche.

3. Sélectionner Toutes les applications.

4. Sélectionnez l’application avec le nom correspondant [Compte de stockage] $storageAccountName.file.core.windows.net.

5. Sélectionnez Manifeste dans le volet de gauche.

6. Copiez et collez le contenu existant afin de disposer d’une copie en double.

7. Modifiez le manifeste JSON. Pour chaque <storageAccount>.file.core.windows.net entrée, ajoutez une entrée correspondante <storageAccount>.privatelink.file.core.windows.net . Par exemple, si votre manifeste a la valeur suivante pour identifierUris:

   "identifierUris": [
       "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
       "HOST/<storageaccount>.file.core.windows.net",
       "CIFS/<storageaccount>.file.core.windows.net",
       "HTTP/<storageaccount>.file.core.windows.net"
   ],
   

   Ensuite, vous devez modifier le identifierUris champ en procédant comme suit :

   "identifierUris": [
       "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
       "HOST/<storageaccount>.file.core.windows.net",
       "CIFS/<storageaccount>.file.core.windows.net",
       "HTTP/<storageaccount>.file.core.windows.net",
   
       "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
       "HOST/<storageaccount>.privatelink.file.core.windows.net",
       "CIFS/<storageaccount>.privatelink.file.core.windows.net",
       "HTTP/<storageaccount>.privatelink.file.core.windows.net"
   ],
   

8. Passez en revue le contenu et sélectionnez Enregistrer pour mettre à jour l’objet d’application avec la nouvelle propriété identifierUris.

9. Mettez à jour toutes les références DNS internes pour qu’elles pointent vers la liaison privée.

10. Réessayez de monter le partage.

Erreur AADSTS50105

La demande a été interrompue par l’erreur suivante AADSTS50105 :

Votre administrateur a configuré l’application « Nom de l’application d’entreprise » pour bloquer les utilisateurs, sauf s’ils disposent d’un accès spécifique (affecté) à l’application. L’utilisateur connecté « {EmailHidden} » est bloqué, car il ne s’agit pas d’un membre direct d’un groupe ayant accès, ni d’accès directement affecté par un administrateur. Contactez votre administrateur pour attribuer l’accès à cette application.

Cause

Si vous configurez « affectation requise » pour l’application d’entreprise correspondante, vous ne pourrez pas obtenir de ticket Kerberos, et les journaux de connexion Microsoft Entra affichent une erreur même si les utilisateurs ou les groupes sont affectés à l’application.

Solution

Ne sélectionnez pas Affectation requise pour l’application Microsoft Entra pour le compte de stockage, car nous ne remplissez pas les droits dans le ticket Kerberos retourné au demandeur. Pour plus d’informations, consultez Erreur AADSTS50105 : l’utilisateur connecté n’est pas affecté à un rôle pour l’application.

Voir aussi

• Dépanner Sauvegarde Azure
• Résoudre les problèmes de performances Azure Files
• Résoudre les problèmes de connectivité d’Azure Files (SMB)
• Résoudre les problèmes généraux Azure Files SMB sur Linux
• Résoudre les problèmes généraux Azure Files NFS sur Linux
• Résoudre les problèmes de synchronisation de fichiers Azure

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.