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

  • Article

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 à 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 :

Un privilège requis n’est pas détenu par le client.

Cause : les autorisations AD sont insuffisantes

Ce problème se produit car vous ne disposez pas des 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

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

L’erreur système 5 s’est produite. 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.

Remarque

Cette erreur peut être due à des problèmes autres que des autorisations incorrectes au niveau du partage. Pour plus d’informations sur d’autres causes et solutions possibles, consultez Résoudre les problèmes de connectivité et d’accès Azure Files.

Solution

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

  • services de domaine Active Directory (AD DS) consultez Attribuer 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 ont été synchronisés à partir d’AD DS vers 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 des autorisations de niveau partage sont attribuées ne sont pas des groupes « cloud uniquement » non pris en charge.

  • Microsoft Entra Domain Services consultez Attribuer des autorisations au niveau du partage.

Erreur AadDsTenantNotFound lors de l’activation de l’authentification Microsoft Entra Domain Services pour Azure Files « Impossible de localiser les locataires actifs avec l’ID de locataire Microsoft Entra tenant-id »

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 Microsoft Entra locataire de l’abonnement associé.

Solution

Activez Microsoft Entra Domain Services sur le locataire Microsoft Entra de l’abonnement sur lequel votre compte de stockage est déployé. Vous avez besoin de privilèges d’administrateur du locataire Microsoft Entra pour créer un domaine managé. 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 des partages de fichiers Azure avec des informations d’identification AD

Étapes de diagnostics auto-diagnostics

Tout d’abord, vérifiez que vous avez suivi les étapes pour activer Azure Files’authentification AD DS.

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

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 v0.1.2+ version. Vous devez exécuter cette applet de commande avec un utilisateur AD disposant d’une 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 ces vérifications dans l’ordre et fournit des conseils pour les défaillances :

  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 nom de principal de service approprié. Si le SPN n’est pas correctement configuré, exécutez l’applet Set-AD de commande retournée dans l’applet de commande 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 à un domaine à AD, reportez-vous à Joindre un ordinateur à un domaine pour obtenir des instructions de jointure de domaine.
  4. CheckPort445Connectivity: vérifiez que le port 445 est ouvert pour la connexion SMB. Si le port 445 n’est pas ouvert, reportez-vous à l’outil de résolution des problèmes AzFileDiagnostics pour connaître les problèmes de connectivité avec Azure Files.
  5. CheckSidHasAadUser: vérifiez que l’utilisateur AD connecté est synchronisé avec Microsoft Entra ID. Si vous souhaitez rechercher si un utilisateur AD spécifique est synchronisé avec Microsoft Entra ID, vous pouvez spécifier et -UserName-Domain dans les paramètres d’entrée. Pour un SID donné, il vérifie si un utilisateur Microsoft Entra est associé.
  6. CheckAadUserHasSid: vérifiez que l’utilisateur AD connecté est synchronisé avec Microsoft Entra ID. Si vous souhaitez rechercher si un utilisateur AD spécifique est synchronisé avec Microsoft Entra ID, vous pouvez spécifier et -UserName-Domain dans les paramètres d’entrée. Pour un utilisateur Microsoft Entra donné, il vérifie son SID. Pour exécuter cette case activée, vous devez fournir le -ObjectId paramètre, ainsi que l’ID d’objet de l’utilisateur Microsoft Entra.
  7. CheckGetKerberosTicket: tentative d’obtention d’un ticket Kerberos pour se 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 la récupération du ticket.
  8. CheckStorageAccountDomainJoined: vérifiez si l’authentification AD a été activée et si les propriétés AD du compte sont renseignées. 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. (Pris en charge sur AzFilesHybrid v0.2.3+ version)
  10. CheckUserFileAccess: vérifiez si l’identité AD dispose de l’autorisation de répertoire/fichier appropriée (listes de contrôle d’accès 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 case activée, vous devez fournir le -FilePath paramètre, ainsi que le chemin du fichier monté auquel vous souhaitez déboguer l’accès. (Pris en charge sur AzFilesHybrid v0.2.3+ version)
  11. CheckAadKerberosRegistryKeyIsOff: vérifiez si la clé de Registre Kerberos Microsoft Entra 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. 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 le partage de fichiers est monté sur X:et que vous souhaitez uniquement exécuter le case activée lié aux autorisations au niveau du fichier (listes de contrôle d’accès 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 configurer les autorisations au niveau du répertoire/fichier (ACL Windows) avec Windows Explorateur de fichiers

Symptôme

Vous pouvez rencontrer l’un des symptômes décrits ci-dessous lorsque vous essayez de configurer des listes de contrôle d’accès Windows avec Explorateur de fichiers sur un partage de fichiers monté :

  • Après avoir cliqué sur Modifier l’autorisation sous l’onglet Sécurité, l’Assistant Autorisation ne se charge pas.
  • Lorsque vous essayez de sélectionner un nouvel utilisateur ou un nouveau groupe, l’emplacement du domaine n’affiche pas le domaine AD DS approprié.
  • Vous utilisez plusieurs forêts AD et recevez 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. Vérifiez que les contrôleurs de domaine Active Directory sont disponibles, puis réessayez de sélectionner 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.

Erreurs lors de l’exécution de l’applet de commande 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 qui détient le rôle FSMO maître RID n’est pas disponible ou a été supprimé du domaine et restauré à partir de la 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é donné »

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

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

Azure Files prend en charge le chiffrement Kerberos AES-256 pour l’authentification AD DS à partir du module AzFilesHybrid v0.2.2. AES-256 est la méthode de chiffrement recommandée, et 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 powerShell ci-dessous. Si vous n’avez pas encore activé l’authentification AD DS sur votre compte de stockage, suivez ces instructions.

Importante

Si vous utilisiez précédemment le chiffrement RC4 et mettez à jour le compte de stockage pour utiliser AES-256, vous devez exécuter klist purge sur le client, puis remonter le partage de fichiers pour obtenir de nouveaux tickets Kerberos avec AES-256.

$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 revenir en arrière, sauf si vous souhaitez régénérer les deux mots de passe.

L’identité de l’utilisateur ayant précédemment l’attribution de rôle Propriétaire ou Contributeur dispose toujours d’un accès à la clé de compte de stockage

Les rôles Propriétaire et Contributeur du compte de stockage permettent de répertorier 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 conteneurs d’objets blob, les tables et les files d’attente, et 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 prendre en compte que les utilisateurs supprimés des rôles Propriétaire ou Contributeur peuvent continuer à conserver l’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 basculant l’accès de l’une à l’autre au fur et à mesure qu’elles sont pivotées. Il existe deux types de clés partagées que le compte de stockage fournit : 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 Windows Server Active Directory Scénarios.

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

Accédez au compte de stockage souhaité dans le Portail Azure. Dans la table des matières du compte de stockage souhaité, sélectionnez Clés d’accès sous le titre Sécurité + mise en réseau . Dans le volet Clé d’accès , sélectionnez Pivoter la clé au-dessus de la clé souhaitée.

Capture d’écran montrant le volet « Touche d’accès ».

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

Après avoir activé Microsoft Entra’authentification 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 procédant comme suit.

  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 dont le nom correspond à [Compte de stockage] $storageAccountName.file.core.windows.net.
  5. Sélectionnez Autorisations d’API dans le volet gauche.
  6. Sélectionnez Ajouter des autorisations en bas de la page.
  7. Sélectionnez Accorder le consentement administrateur pour « DirectoryName ».

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

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

Erreur - Accorder le consentement administrateur désactivé

Dans certains cas, Microsoft Entra’administrateur peut désactiver la possibilité d’accorder le consentement administrateur à Microsoft Entra applications. Voici la capture d’écran de ce à quoi cela peut ressembler dans le Portail Azure.

Capture d’écran montrant le panneau « Autorisations configurées » affichant un avertissement indiquant que certaines actions peuvent être désactivées en raison de vos autorisations.

Si c’est le cas, demandez à votre administrateur Microsoft Entra d’accorder le consentement 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 demande 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 Microsoft Entra’authentification Kerberos, vous pouvez rencontrer cette erreur si les conditions suivantes sont remplies :

  1. Vous utilisez la fonctionnalité bêta/préversion 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 pas de date de début ou a une date de début antérieure au 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 inférieure à 365,5 jours.

Il n’existe actuellement aucune solution de contournement pour 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é Microsoft Entra l’authentification Kerberos par le biais d’étapes manuelles d’évaluation limitée. 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 l’application nouvellement créée. 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 Microsoft Entra ID

Si vous avez précédemment activé Microsoft Entra l’authentification Kerberos par le biais d’étapes d’évaluation 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 peuvent plus obtenir de tickets Kerberos pour le partage de fichiers.

Pour atténuer ce problème, vous avez deux options : soit faire pivoter le mot de passe du principal de service dans Microsoft Entra tous les six mois, soit 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 du fichier à 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 de niveau 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 Microsoft Entra’authentification Kerberos, lorsque vous tentez de monter un partage de fichiers via net use ou une autre méthode, le client est invité à entrer des informations d’identification. L’utilisateur tapera probablement ses informations d’identification dans, mais les informations d’identification sont rejetées.

Cause

Cela est dû au fait que le client SMB a essayé d’utiliser Kerberos mais a échoué. Il revient donc à l’utilisation de l’authentification NTLM et Azure Files ne prend pas en charge l’utilisation de l’authentification NTLM pour les informations d’identification de domaine. Le client ne peut pas obtenir de ticket Kerberos pour le compte de stockage, car le nom de domaine complet de liaison privée n’est inscrit auprès d’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 l’identificateurUris requis à l’objet d’application à l’aide de la Portail Azure en procédant comme suit.

  1. Ouvrez Microsoft Entra ID.

  2. Sélectionnez inscriptions d'applications dans le volet gauche.

  3. Sélectionnez Toutes les applications.

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

  5. Sélectionnez Manifeste dans le volet gauche.

  6. Copiez et collez le contenu existant afin d’avoir 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 instance, 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"
],

    Vous devez ensuite modifier le identifierUris champ 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 le nouvel identificateurUris.

  9. Mettez à jour toutes les références DNS internes pour pointer vers la liaison privée.

  10. Réessayez de monter le partage.

AADSTS50105 d’erreur

La requête 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 sont spécifiquement autorisés (affectés) à l’application. L’utilisateur connecté « {EmailHidden} » est bloqué, car il n’est pas un membre direct d’un groupe avec accès, ni un accès directement attribué 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 Microsoft Entra journaux de connexion affichent une erreur même si des utilisateurs ou des groupes sont affectés à l’application.

Solution

Ne sélectionnez pas Affectation requise pour Microsoft Entra application pour le compte de stockage, car nous ne remplissons 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

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.