Résoudre les problèmes liés à Azure RBAC
Cet article décrit certaines solutions courantes pour les problèmes liés au contrôle d’accès en fonction du rôle Azure (Azure RBAC).
Attributions de rôles Azure
Symptôme : l'option Ajouter une attribution de rôle est désactivée
Vous ne pouvez pas attribuer un rôle dans le portail Microsoft Azure sur le contrôle d'accès (IAM) car l'option Ajouter> Ajouter une attribution de rôle est désactivée.
Cause
Vous êtes actuellement connecté avec un utilisateur qui n'a pas l'autorisation d'attribuer des rôles à l'étendue sélectionnée.
Solution
Vérifiez que vous êtes actuellement connecté avec un utilisateur auquel a été attribué un rôle disposant de l'autorisation Microsoft.Authorization/roleAssignments/write, tel que l'Administrateur de l'Access Control basé sur les rôles, pour l'étendue à laquelle vous essayez d'attribuer le rôle.
Symptôme : les rôles ou les principaux ne sont pas répertoriés
Lorsque vous essayez d'attribuer un rôle dans le portail Microsoft Azure, certains rôles ou principaux ne sont pas répertoriés. Par exemple, sous l'onglet Rôle , vous verrez un ensemble réduit de rôles.
Ou, dans le volet Sélectionner des membres, vous verrez un ensemble réduit de principaux.
Cause
Il existe des restrictions sur les attributions de rôles que vous pouvez ajouter. Par exemple, vous êtes limité dans les rôles que vous pouvez attribuer ou dans les principaux auxquels vous pouvez attribuer des rôles.
Solution
Affichez les rôles qui vous sont attribués. Vérifiez s'il existe une condition qui limite les attributions de rôles que vous pouvez ajouter. Pour plus d'informations, consultez Déléguer la gestion des accès Azure à d'autres personnes.
Symptôme : Impossible d’attribuer un rôle
Vous n'arrivez pas à attribuer un rôle, et vous recevez un message d'erreur similaire à celui qui précède :
Failed to add {securityPrincipal} as {role} for {scope} : The client '{clientName}' with object id '{objectId}' does not have authorization or an ABAC condition not fulfilled to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/{subscriptionId}/Microsoft.Authorization/roleAssignments/{roleAssignmentId}' or the scope is invalid. If access was recently granted, please refresh your credentials.
Cause 1
Vous êtes actuellement connecté avec un utilisateur qui n’a pas l’autorisation d’attribuer des rôles à l’étendue sélectionnée.
Solution 1
Vérifiez que vous êtes actuellement connecté avec un utilisateur auquel a été attribué un rôle disposant de l'autorisation Microsoft.Authorization/roleAssignments/write, tel que l'Administrateur de l'Access Control basé sur les rôles, pour l'étendue à laquelle vous essayez d'attribuer le rôle.
Cause 2
Il existe des restrictions sur les attributions de rôles que vous pouvez ajouter. Par exemple, vous êtes limité dans les rôles que vous pouvez attribuer ou dans les principaux auxquels vous pouvez attribuer des rôles.
Solution 2
Affichez les rôles qui vous sont attribués. Vérifiez s'il existe une condition qui limite les attributions de rôles que vous pouvez ajouter. Pour plus d'informations, consultez Déléguer la gestion des accès Azure à d'autres personnes.
Symptôme : Impossible d’attribuer un rôle à l’aide d’un principal de service avec Azure CLI
Vous utilisez un principal de service pour attribuer des rôles avec Azure CLI et vous recevez l'erreur suivante :
Insufficient privileges to complete the operation
Supposons, par exemple, que vous avez un principal de service auquel le rôle Propriétaire a été attribué et que vous tentez de créer l’attribution de rôle suivante en tant que principal de service à l’aide d’Azure CLI :
az login --service-principal --username "SPNid" --password "password" --tenant "tenantid"
az role assignment create --assignee "userupn" --role "Contributor" --scope "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}"
Cause
Il est probable qu'Azure CLI recherche l'identité du destinataire dans Microsoft Entra ID. De même, il se peut que le principal de service ne puisse pas lire Microsoft Entra ID par défaut.
Solution
Il existe deux façons de résoudre cette erreur. La première consiste à attribuer au principal de service le rôle Lecteurs de répertoire afin qu’il puisse lire les données dans l’annuaire.
La deuxième consiste à créer l’attribution de rôle à l’aide du paramètre --assignee-object-id au lieu de --assignee. En utilisant --assignee-object-id, Azure CLI ignore la recherche Microsoft Entra. Vous devez obtenir l'ID d'objet de l'utilisateur, du groupe ou de l'application auquel vous souhaitez attribuer le rôle. Pour plus d’informations, consultez Attribuer des rôles Azure en utilisant Azure CLI.
az role assignment create --assignee-object-id 11111111-1111-1111-1111-111111111111 --role "Contributor" --scope "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}"
Symptôme : l'attribution d'un rôle à un nouveau principal échoue dans certains cas
Vous créez un nouvel utilisateur, un nouveau groupe ou un nouveau principal de service, et vous essayez immédiatement d'attribuer un rôle à ce principal. Or, il arrive que l'attribution des rôles échoue. Vous recevez un message d'erreur similaire à celui qui précède :
PrincipalNotFound
Principal {principalId} does not exist in the directory {tenantId}. Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group. See https://aka.ms/docs-principaltype
Cause
La raison est probablement un retard de réplication. Le principal du service est créé dans une région. Toutefois, l'attribution de rôle peut s'effectuer dans une autre région, qui n'a pas encore répliqué le principal.
Solution 1
Si vous créez un nouvel utilisateur ou un nouveau principal de service à l'aide de l'API REST ou du modèle ARM, définissez la propriété principalType lorsque vous créez l'attribution de rôle à l'aide de l'API Attributions de rôle – Créer.
| principalType | apiVersion |
|---|---|
User |
2020-03-01-preview ou ultérieur |
ServicePrincipal |
2018-09-01-preview ou ultérieur |
Pour plus d’informations, consultez Attribuer des rôles Azure à l’aide de l’API REST ou Attribuer des rôles Azure à un nouveau principal de service à l’aide de modèles Azure Resource Manager.
Solution 2
Si vous créez un nouvel utilisateur ou un nouveau principal de service à l'aide d'Azure PowerShell, attribuez la valeur User ou ServicePrincipal au paramètre ObjectType lorsque vous créez l'attribution de rôle à l'aide de New-AzRoleAssignment. Les mêmes restrictions relatives à la version de l'API sous-jacente de la Solution 1 s'appliquent toujours. Pour plus d’informations, consultez Attribuer des rôles Azure en utilisant Azure PowerShell.
Solution 3
Si vous créez un nouveau groupe, patientez quelques minutes avant de créer l'attribution de rôle.
Symptôme - L’attribution de rôle de modèle ARM retourne l’état BadRequest
Lorsque vous essayez de déployer un fichier Bicep ou modèle ARM qui attribue un rôle à un principal de service, vous obtenez l’erreur suivante :
Tenant ID, application ID, principal ID, and scope are not allowed to be updated. (code: RoleAssignmentUpdateNotPermitted)
Par exemple, si vous créez une attribution de rôle pour une identité managée, puis supprimez l’identité managée et la recréez, la nouvelle identité managée a un ID de principal différent. Si vous essayez de déployer à nouveau l’attribution de rôle et d’utiliser le même nom d’attribution de rôle, le déploiement échoue.
Cause
L'attribution du rôle name n'est pas unique. De plus, elle est perçue comme une mise à jour.
Les attributions de rôles sont identifiées de manière unique par leur nom, qui est un identificateur global unique (GUID). Vous ne pouvez pas créer deux attributions de rôles portant le même nom, même dans différents abonnements Azure. Vous ne pouvez pas non plus modifier les propriétés d’une attribution de rôle existante.
Solution
Fournissez une valeur unique idempotente pour l’attribution de rôle name. Une bonne pratique consiste à créer un GUID qui utilise l’étendue, l’ID du principal et l’ID du rôle ensemble. Il est judicieux d’utiliser la fonction guid() pour vous aider à créer un GUID déterministe pour vos noms d’attributions de rôle, comme dans cet exemple :
resource roleAssignment 'Microsoft.Authorization/roleAssignments@2020-10-01-preview' = {
name: guid(resourceGroup().id, principalId, roleDefinitionId)
properties: {
roleDefinitionId: roleDefinitionId
principalId: principalId
principalType: principalType
}
}
Pour plus d’informations, consultez Créer des ressources Azure RBAC en utilisant Bicep.
Symptôme : Attributions de rôle avec identité introuvable
Dans la liste des attributions de rôles pour le Portail Azure, vous remarquez que le principal de sécurité (utilisateur, groupe, principal de service ou identité gérée) est répertorié comme Identité introuvable avec un type Inconnu.
Si vous listez cette attribution de rôle avec Azure PowerShell, vous pourrez voir un DisplayName vide et SignInName, ou une valeur de Unknown pour ObjectType. Par exemple, Get-AzRoleAssignment retourne une attribution de rôle similaire à ce qui suit :
RoleAssignmentId : /subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/22222222-2222-2222-2222-222222222222
Scope : /subscriptions/11111111-1111-1111-1111-111111111111
DisplayName :
SignInName :
RoleDefinitionName : Storage Blob Data Contributor
RoleDefinitionId : ba92f5b4-2d11-453d-a403-e96b0029c9fe
ObjectId : 33333333-3333-3333-3333-333333333333
ObjectType : User
CanDelegate : False
De même, si vous répertoriez cette attribution de rôle à l’aide d’Azure CLI, principalName est vide à l’écran. Par exemple, az role assignment list retourne une attribution de rôle similaire à ce qui suit :
{
"canDelegate": null,
"id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/22222222-2222-2222-2222-222222222222",
"name": "22222222-2222-2222-2222-222222222222",
"principalId": "33333333-3333-3333-3333-333333333333",
"principalName": "",
"roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/ba92f5b4-2d11-453d-a403-e96b0029c9fe",
"roleDefinitionName": "Storage Blob Data Contributor",
"scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
"type": "Microsoft.Authorization/roleAssignments"
}
Cause 1
Vous avez récemment invité un utilisateur lors de la création d’une attribution de rôle, et ce principal de sécurité se trouve encore dans le processus de réplication entre les régions.
Solution 1
Patientez quelques instants, puis actualisez la liste des attributions de rôles.
Cause 2
Vous avez supprimé un principal de sécurité qui avait une attribution de rôle. Si vous attribuez un rôle à un principal de sécurité, puis que vous supprimez ce principal de sécurité sans d’abord supprimer l’attribution de rôle, le principal de sécurité sera répertorié comme Identité introuvable avec un type Inconnu.
Solution 2
Il n’est pas un problème de conserver ces attributions de rôle pour lesquelles le principal de sécurité a été supprimé. Si vous le souhaitez, vous pouvez supprimer ces attributions de rôle en utilisant les étapes similaires aux autres attributions de rôle. Pour plus d’informations sur la procédure de suppression d’attributions de rôle, consultez Supprimer des attributions de rôle.
Dans PowerShell, si vous essayez de supprimer les attributions de rôles à l'aide de l'ID d'objet et du nom de définition de rôle alors que plusieurs attributions de rôle correspondent à vos paramètres, le message d'erreur suivant s'affiche : The provided information does not map to a role assignment. Voici un exemple du message d’erreur :
PS C:\> Remove-AzRoleAssignment -ObjectId 33333333-3333-3333-3333-333333333333 -RoleDefinitionName "Storage Blob Data Contributor"
Remove-AzRoleAssignment : The provided information does not map to a role assignment.
At line:1 char:1
+ Remove-AzRoleAssignment -ObjectId 33333333-3333-3333-3333-333333333333 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Remove-AzRoleAssignment], KeyNotFoundException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Resources.RemoveAzureRoleAssignmentCommand
Si ce message d’erreur s’affiche, prenez soin de spécifier également les paramètres -Scope ou -ResourceGroupName.
PS C:\> Remove-AzRoleAssignment -ObjectId 33333333-3333-3333-3333-333333333333 -RoleDefinitionName "Storage Blob Data Contributor" - Scope /subscriptions/11111111-1111-1111-1111-111111111111
Symptôme : Impossible de supprimer la dernière attribution du rôle propriétaire
Vous tentez de supprimer la dernière attribution du rôle Propriétaire pour un abonnement et vous voyez l’erreur suivante :
Cannot delete the last RBAC admin assignment
Cause
La suppression de la dernière attribution de rôle Propriétaire pour un abonnement n'est pas prise en charge afin d'éviter que l'abonnement ne devienne orphelin.
Solution
Si vous voulez annuler votre abonnement, consultez Annulation de votre abonnement Azure.
Vous êtes autorisé à supprimer la dernière attribution de rôle Propriétaire (ou Administrateur d'accès utilisateur), dans l'étendue de l'abonnement, si vous êtes administrateur général du locataire ou administrateur classique (administrateur de services fédérés ou coadministrateur) pour l'abonnement. Dans ce cas, il n'y a aucune contrainte pour la suppression. Toutefois, si l’appel provient d’un autre principal, vous ne pourrez pas supprimer la dernière attribution du rôle Propriétaire au niveau de l’abonnement.
Symptôme : l'attribution de rôle n'est pas modifiée après le déplacement d'une ressource
Cause
Si vous déplacez une ressource à laquelle un rôle Azure est affecté directement (ou est affecté à une ressource enfant de cette ressource), l’attribution de rôle n’est pas déplacée et devient orpheline.
Solution
Après avoir déplacé une ressource, vous devez recréer l’attribution de rôle. Finalement, l'attribution de rôle orpheline sera automatiquement supprimée, mais il est recommandé de supprimer l'attribution de rôle avant de déplacer la ressource. Pour plus d'informations sur le déplacement des ressources, consultez Déplacer des ressources vers un nouveau groupe de ressources ou un nouvel abonnement.
Symptôme : Les changements d’attribution de rôle ne sont pas détectés
Vous avez récemment ajouté ou mis à jour une attribution de rôle, mais les modifications ne sont pas détectées. Vous pourriez voir le message Status: 401 (Unauthorized).
Cause 1
Azure Resource Manager met parfois en cache des données et des configurations pour améliorer les performances.
Solution 1
Lorsque vous attribuez des rôles ou supprimez des attributions de rôle, un délai de 10 minutes maximum peut être nécessaire avant que les modifications soient prises en compte. Si vous utilisez le portail Microsoft Azure, Azure PowerShell ou Azure CLI, vous pouvez forcer une actualisation de vos modifications d'attribution de rôle en vous déconnectant et en vous reconnectant. Si vous apportez des modifications d'attribution de rôle à l'aide d'appels d'API REST, vous pouvez forcer une actualisation en actualisant votre jeton d'accès.
Cause 2
Vous avez ajouté des identités managées à un groupe et affecté un rôle à ce groupe. Les services principaux pour les identités gérées conservent un cache par URI de ressource pendant environ 24 heures.
Solution 2
Les modifications de l’appartenance à un rôle ou un groupe d’une identité managée peuvent prendre plusieurs heures avant de prendre effet. Pour plus d’informations, consultez Limitation de l’utilisation des identités managées pour l’autorisation.
Symptôme : les changements d'attribution de rôles au niveau du groupe d'administration ne sont pas détectés.
Vous avez récemment ajouté ou mis à jour une attribution de rôle à la portée du groupe d'administration. Cependant, les modifications ne sont pas détectées.
Cause
Azure Resource Manager met parfois en cache des données et des configurations pour améliorer les performances.
Solution
Lorsque vous attribuez des rôles ou supprimez des attributions de rôle, un délai de 10 minutes maximum peut être nécessaire avant que les modifications soient prises en compte. Si vous ajoutez ou supprimez une attribution de rôle intégrée à la portée du groupe d'administration et que le rôle intégré est doté de DataActions, l'accès au plan de données peut ne pas être mis à jour pendant plusieurs heures. Cela s’applique uniquement à l’étendue du groupe d’administration et au plan de données. Les rôles personnalisés avec DataActions ne peuvent pas être attribués au niveau de l’étendue du groupe d’administration.
Symptôme : les attributions de rôles pour les modifications de groupe d'administration ne sont pas détectées
Vous avez créé un nouveau groupe d'administration enfant et l'attribution de rôles sur le groupe d'administration parent n'est pas détectée pour le groupe d'administration enfant.
Cause
Azure Resource Manager met parfois en cache des données et des configurations pour améliorer les performances.
Solution
L'attribution de rôle du groupe d'administration enfant peut prendre jusqu'à 10 minutes. Si vous utilisez le portail Azure, Azure PowerShell ou Azure CLI, vous pouvez forcer une actualisation de vos modifications d’attribution de rôle en vous déconnectant et en vous reconnectant. Si vous apportez des modifications d’attribution de rôle à l’aide d’appels d’API REST, vous pouvez forcer une actualisation en actualisant votre jeton d’accès.
Symptôme - La suppression des attributions de rôles à l’aide de PowerShell prend plusieurs minutes
Vous utilisez la commande Remove-AzRoleAssignment pour supprimer une attribution de rôle. Vous utilisez ensuite la commande Get-AzRoleAssignment pour vérifier que l’attribution de rôle a été supprimée pour un principal de sécurité. Par exemple :
Get-AzRoleAssignment -ObjectId $securityPrincipalObject.Id
La commande Get-AzRoleAssignment indique que l'attribution de rôle n'a pas été supprimée. Toutefois, si vous attendez 5 à 10 minutes et exécutez à nouveau Get-AzRoleAssignment, le résultat indique que l’attribution de rôle a été supprimée.
Cause
L’attribution de rôle a été supprimée. Toutefois, pour améliorer les performances, PowerShell utilise un cache lorsqu’il répertorie les attributions de rôles. Il peut y avoir un délai d’environ 10 minutes pour que le cache soit actualisé.
Solution
Au lieu de répertorier les attributions de rôles pour un principal de sécurité, répertoriez toutes les attributions de rôles dans l’étendue de l’abonnement et filtrez la sortie. Par exemple, la commande suivante :
$validateRemovedRoles = Get-AzRoleAssignment -ObjectId $securityPrincipalObject.Id
Peut être remplacé par cette commande :
$validateRemovedRoles = Get-AzRoleAssignment -Scope /subscriptions/$subId | Where-Object -Property ObjectId -EQ $securityPrincipalObject.Id
Rôles personnalisés
Symptôme : impossible de mettre à jour ou de supprimer un rôle personnalisé
Vous ne pouvez pas mettre à jour ou supprimer un rôle personnalisé existant.
Cause 1
Vous êtes actuellement connecté avec un utilisateur qui n'est pas autorisé à mettre à jour ou à supprimer des rôles personnalisés.
Solution 1
Vérifiez que vous êtes actuellement connecté avec un utilisateur auquel a été attribué un rôle disposant de l'autorisation Microsoft.Authorization/roleDefinitions/write, tel que Administrateur de l'accès utilisateur.
Cause 2
Le rôle personnalisé inclut un abonnement dans des étendues assignables. De plus, cet abonnement est en mode désactivé.
Solution 2
Réactivez l'abonnement désactivé et mettez à jour le rôle personnalisé si nécessaire. Pour plus d’informations, consultez Réactiver un abonnement Azure désactivée.
Symptôme : Impossible de créer ou de mettre à jour un rôle personnalisé
Lorsque vous essayez de créer ou de mettre à jour un rôle personnalisé, vous obtenez une erreur similaire à la suivante :
The client '<clientName>' with object id '<objectId>' has permission to perform action 'Microsoft.Authorization/roleDefinitions/write' on scope '/subscriptions/<subscriptionId>'; however, it does not have permission to perform action 'Microsoft.Authorization/roleDefinitions/write' on the linked scope(s)'/subscriptions/<subscriptionId1>,/subscriptions/<subscriptionId2>,/subscriptions/<subscriptionId3>' or the linked scope(s)are invalid
Cause
Cette erreur indique généralement que vous n'avez pas d'autorisations sur une ou plusieurs étendues attribuables dans le rôle personnalisé.
Solution
Essayez ce qui suit :
- Passez en revue Qui peut créer, supprimer, mettre à jour ou afficher un rôle personnalisé et vérifier que vous avez des autorisations pour créer ou mettre à jour le rôle personnalisé pour toutes les étendues attribuables.
- Si vous n'avez pas d'autorisations, demandez à votre administrateur de vous attribuer un rôle ayant l'action
Microsoft.Authorization/roleDefinitions/write, par exemple Administrateur de l'accès utilisateur dans la portée de l'étendue assignable. - Vérifiez que toutes les étendues attribuables dans le rôle personnalisé sont valides. Si ce n’est pas le cas, supprimez les étendues attribuables non valides.
Pour plus d’informations, consultez les tutoriels sur les rôles personnalisés à l’aide du Portail Azure, d’Azure PowerShell ou d’Azure CLI.
Symptôme : Impossible de supprimer un rôle personnalisé
Vous ne parvenez pas à supprimer un rôle personnalisé, et vous recevez le message d'erreur suivant :
There are existing role assignments referencing role (code: RoleDefinitionHasAssignments)
Cause
Certaines affectations de rôle utilisent toujours le rôle personnalisé.
Solution
Supprimez les attributions de rôles qui utilisent le rôle personnalisé et essayez de supprimer à nouveau le rôle personnalisé. Pour plus d’informations, consultez Rechercher des attributions de rôles pour supprimer un rôle personnalisé.
Symptôme : Impossible d’ajouter plusieurs groupes d’administration comme étendue attribuable
Lorsque vous essayez de créer ou de mettre à jour un rôle personnalisé, vous ne pouvez pas ajouter plusieurs groupes d’administration comme étendue attribuable.
Cause
Vous ne pouvez définir qu’un seul groupe d’administration dans AssignableScopes pour un rôle personnalisé.
Solution
Définissez un groupe d’administration dans les AssignableScopes de votre rôle personnalisé. Pour plus d’informations sur les rôles personnalisés et les groupes d’administration, consultez Organiser vos ressources avec des groupes d’administration Azure.
Symptôme : Impossible d’ajouter des actions de données à un rôle personnalisé
Lorsque vous essayez de créer ou de mettre à jour un rôle personnalisé, vous ne pouvez pas ajouter d’actions de données, ou le message suivant s’affiche :
You cannot add data action permissions when you have a management group as an assignable scope
Cause
Vous essayez de créer un rôle personnalisé avec des actions de données et un groupe d'administration comme étendue attribuable. Les rôles personnalisés avec DataActions ne peuvent pas être attribués au niveau de l’étendue du groupe d’administration.
Solution
Créez le rôle personnalisé avec un ou plusieurs abonnements comme étendue attribuable. Pour plus d’informations sur les rôles personnalisés et les groupes d’administration, consultez Organiser vos ressources avec des groupes d’administration Azure.
Accès refusé ou erreurs d’autorisations
Symptôme - L’autorisation a échoué
Lorsque vous essayez de créer une ressource, vous recevez le message d’erreur suivant :
The client with object id does not have authorization to perform action over scope (code: AuthorizationFailed)
Cause 1
Vous êtes actuellement connecté avec un utilisateur qui n'a pas l'autorisation d'écriture sur la ressource au niveau de l'étendue sélectionnée.
Solution 1
Vérifiez que vous êtes actuellement connecté avec un utilisateur disposant d'un rôle disposant de l'autorisation d'écriture sur la ressource au niveau de l'étendue sélectionnée. Par exemple, pour gérer les machines virtuelles dans un groupe de ressources, vous devez disposer du rôle Contributeur de machines virtuelles sur le groupe de ressources (ou l’étendue parente). Afin d’obtenir la liste des autorisations pour chaque rôle intégré, consultez Rôles intégrés Azure.
Cause 2
L'utilisateur actuellement connecté dispose d'une attribution de rôle avec les critères suivants :
- Le rôle inclut une action de données Microsoft.Storage
- L'attribution de rôle inclut une condition ABAC qui utilise des opérateurs de comparaison GUID
Solution 2
À l'heure actuelle, il n'est pas possible d'avoir une attribution de rôle avec une action de données Microsoft.Storage et une condition ABAC qui utilise un opérateur de comparaison GUID. Voici quelques options pour résoudre cette erreur :
- Si le rôle est un rôle personnalisé, supprimez toutes les actions de données Microsoft.Storage
- Modifiez la condition d'attribution de rôle afin qu'elle n'utilise pas d'opérateurs de comparaison GUID
Symptôme : l'autorisation de l'utilisateur invité a échoué
Lorsqu'un utilisateur invité tente d'accéder à une ressource, il obtient un message d'erreur similaire à celui qui précède :
The client '<client>' with object id '<objectId>' does not have authorization to perform action '<action>' over scope '<scope>' or the scope is invalid.
Cause
L'utilisateur invité n'a pas d'autorisations d'accès à la ressource dans l'étendue sélectionnée.
Solution
Vérifiez que l'utilisateur invité se voit attribuer un rôle avec les autorisations les moins privilégiées pour la ressource dans l'étendue sélectionnée. Pour plus d’informations, Attribuer des rôles Azure aux utilisateurs externes avec le portail Azure.
Symptôme : Impossible de créer une demande de support
Lorsque vous essayez de créer ou de mettre à jour un ticket d’assistance, vous obtenez le message d’erreur suivant :
You don't have permission to create a support request
Cause
Vous êtes actuellement connecté avec un utilisateur qui n'est pas autorisé à créer des demandes de support.
Solution
Vérifiez que vous êtes actuellement connecté avec un utilisateur auquel est attribué un rôle qui possède l'autorisation Microsoft.Support/supportTickets/write, tel que Contributeur à la demande de support.
Des fonctionnalités Azure sont désactivées
Symptôme : Certaines fonctionnalités d’application web sont désactivées
Un utilisateur dispose d’un accès en lecture à une application web et certaines fonctionnalités sont désactivées.
Cause
Si vous accordez un accès utilisateur en lecture à une application web, certaines fonctionnalités sont désactivées, ce que vous n’avez peut-être pas prévu. Les fonctionnalités de gestion suivantes exigent un accès en écriture à une application web et ne sont pas disponibles en lecture seule.
- Commandes (comme start, stop, etc.)
- Modification de paramètres tels que la configuration générale, les paramètres de mise à l’échelle, les paramètres de sauvegarde et les paramètres d’analyse
- Accès aux informations d’identification de publication et autres informations secrètes, telles que les paramètres d’application et les chaînes de connexion
- Diffusion de journaux d’activité
- Configuration des journaux de ressources
- Console (invite de commandes)
- Déploiements actifs et récents (pour le déploiement continu Git local)
- Estimation de dépense
- Tests web
- Réseau virtuel (accessible à un lecteur uniquement si un réseau virtuel a été précédemment configuré par un utilisateur avec accès en écriture).
Solution
Attribuez le rôle Contributeur ou un autre rôle intégré Azure avec des autorisations d’écriture pour l’application web.
Symptôme : Certaines ressources d’application web sont désactivées
Un utilisateur dispose d’un accès en écriture à une application web et certaines fonctionnalités sont désactivées.
Cause
Les applications web sont compliqués par la présence de quelques ressources différentes qui interagissent. Voici un groupe de ressources classique avec plusieurs sites web :
En conséquence, si vous accordez à un utilisateur le seul accès à l’application web, la plupart des fonctionnalités du volet Site web dans le portail Azure sont désactivées.
Les éléments suivants requièrent l’accès en écriture au plan App Service qui correspond à votre site web :
- Affichage du niveau tarifaire de l’application web (Gratuit ou Standard)
- Configuration de mise à l'échelle (le nombre d'instances, la taille de la machine virtuelle, les paramètres de mise à l'échelle automatique)
- Quotas (stockage, bande passante, UC)
Les éléments suivants requièrent l’accès en écriture à l’ensemble du Groupe de ressources qui contient le site web :
- Certificats et liaisons TLS/SSL (les certificats TLS/SSL peuvent être partagés entre différents sites dans le même groupe de ressources et emplacement)
- Règles d'alerte
- Paramètres de mise à l'échelle automatique
- Composants Application Insights
- Tests web
Solution
Attribuez un rôle intégré Azure avec des autorisations d’écriture pour le plan App Service ou le groupe de ressources.
Symptôme : Certaines fonctionnalités de machine virtuelle sont désactivées
Un utilisateur a accès à une machine virtuelle et certaines fonctionnalités sont désactivées.
Cause
Comme pour les applications web, certaines fonctionnalités du volet de la machine virtuelle exigent un accès en écriture à la machine virtuelle ou à d’autres ressources du groupe de ressources.
Les machines virtuelles sont associées aux noms de domaine, réseaux virtuels, comptes de stockage et règles d'alerte.
Les éléments suivants nécessitent l’accès en écriture à la machine virtuelle :
- Points de terminaison
- Adresses IP
- Disques
- Extensions
Les éléments suivants requièrent l’accès en écriture à la machine virtuelle, ainsi qu’au groupe de ressources (avec le nom de domaine) auxquels ils appartiennent :
- Groupe à haute disponibilité
- Jeu d'équilibrage de la charge
- Règles d'alerte
Si vous ne pouvez accéder à aucune de ces vignettes, demandez l’accès Collaborateur au groupe de ressources à votre administrateur.
Solution
Attribuez un rôle intégré Azure avec des autorisations d’écriture pour la machine virtuelle ou le groupe de ressources.
Symptôme : Certaines fonctionnalités d’application de fonction sont désactivées
Un utilisateur a accès à une application de fonction et certaines fonctionnalités sont désactivées. Par exemple, un lecteur peut cliquer sur l’onglet Fonctionnalités de plateforme, puis cliquez sur Tous les paramètres pour afficher certains paramètres liés à une application de fonction (semblable à une application Web), mais il ne peut pas modifier ces paramètres.
Cause
Certaines fonctionnalités de Azure Functions nécessitent un accès en écriture. Par exemple, si un utilisateur se voit attribuer le rôle de Lecteur, il ne pourra pas visualiser les fonctions d'une application de fonction. Le portail affiche (Pas d'accès).
Solution
Attribuez un rôle intégré Azure avec des autorisations d’écriture pour l’application de fonction ou le groupe de ressources.
Transfert d’un abonnement vers un autre répertoire
Symptôme : Toutes les attributions de rôles sont supprimées après le transfert d’un abonnement
Cause
Lorsque vous transférez un abonnement Azure vers un autre répertoire Microsoft Entra, toutes les attributions de rôles sont définitivement supprimées du répertoire de la source de données Microsoft Entra. En revanche, elles ne sont pas migrées vers le répertoire Microsoft Entra cible.
Solution
Vous devez recréer vos attributions de rôle dans le répertoire cible. Vous devez également recréer manuellement les identités managées pour les ressources Azure. Pour plus d'informations, consultez Transférer un abonnement Azure vers un autre répertoire Microsoft Entra et FAQ sur les problèmes connus liés aux identités managées.
Symptôme : Impossible d’accéder à l’abonnement après le transfert d’un abonnement
Solution
Si vous êtes un administrateur général Microsoft Entra et que vous n'avez pas accès à un abonnement après qu'il ait été transféré d'un répertoire à l'autre, utilisez la bascule Gestion de l'accès aux ressources Azure pour élever temporairement votre niveau d'accès afin d'obtenir l'accès à l'abonnement.
Administrateurs d’abonnement classiques
Important
Les ressources et les administrateurs classiques vont être mis hors service le 31 août 2024. À compter du 3 avril 2024, vous ne pourrez plus ajouter de nouveaux coadministrateurs. Cette date a été récemment prorogée. Supprimez les coadministrateurs inutiles et utilisez Azure RBAC pour un contrôle d’accès affiné.
Pour plus d’informations, consultez Administrateurs d’abonnement Azure Classic.