Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Activer la journalisation du débogage
L’une des premières étapes à suivre pour résoudre un problème avec le module Az PowerShell consiste à activer la journalisation du débogage.
Pour activer la journalisation du débogage par commande, spécifiez le paramètre Débogage.
Get-AzResource -Name 'DoesNotExist' -Debug
Pour activer la journalisation du débogage pour une session PowerShell entière, définissez la valeur de la variable DebugPreference sur Continue.
$DebugPreference = 'Continue'
Problème connu : l’installation des modules Az à partir de MAR échoue
Lors de l’installation de certains modules PowerShell Az à partir du registre d’artefacts Microsoft (MAR) à l’aide de PSResourceGet, vous pouvez rencontrer une erreur telle que :
Install-PSResource: Package(s) 'Az.Keyvault' could not be installed from repository 'MAR'.
Note
En guise de solution de contournement temporaire, installez le module à partir d’un autre référentiel, tel que le PowerShell Gallery, jusqu’à ce que le problème soit résolu.
Pour plus d’informations, consultez Bugfix pour comparer le nom du chemin d’accès du fichier pour déterminer la correspondance exacte.
Résolution des problèmes d’authentification multifacteur (MFA)
Échecs de connexion interactifs
Si vous rencontrez des erreurs lors de l’exécution d’Azure PowerShell applets de commande qui créent, modifient ou suppriment des ressources, le problème peut être dû à une stratégie d’accès conditionnel Microsoft Entra ID qui nécessite une authentification multifacteur (MFA).
Ces erreurs se produisent généralement lorsque l’authentification multifacteur est requise par la stratégie, mais qu’elle n’est pas appliquée lors de la connexion.
Authentification indisponible pour SharedTokenCacheCredential
Cette erreur peut s’afficher lors de l’utilisation de :
- Az Module PowerShell version 14.2.0 ou antérieure
- Module PowerShell Az.Accounts 5.1.1 ou version antérieure
SharedTokenCacheCredential authentication unavailable. Token acquisition failed for user
someone@contoso.com. Ensure that you have authenticated with a developer tool that supports Azure
single sign on.
Effectuez une mise à niveau vers les versions suivantes ou une version ultérieure pour recevoir des messages d’erreur plus informatifs et des détails de stratégie :
- Az Module PowerShell : version 14.3.0 ou ultérieure
- Module Az.Accounts : version 5.2.0 ou ultérieure
La ressource a été refusée par la politique
Cette erreur se produit dans les versions de module plus récentes (Az 14.3.0+ et Az.Accounts 5.2.0 +), où l’authentification multifacteur est requise par l’accès conditionnel pour des opérations spécifiques.
Resource was disallowed by policy. Users must use MFA for Create operation.
Users must authenticate with multi-factor authentication to create or update resources.
Run the cmdlet below to authenticate interactively; additional parameters may be added as needed.
Connect-AzAccount -Tenant (Get-AzContext).Tenant.Id -ClaimsChallenge "<claims-challenge-token>"
Options de résolution
Demandez à votre administrateur Azure d’appliquer l’authentification multifacteur lors de la connexion. Cela permet à votre session de répondre aux exigences d’accès conditionnel sans étapes supplémentaires.
Si l’application de l’authentification multifacteur lors de la connexion n’est pas possible, utilisez le paramètre ClaimsChallenge pour s’authentifier de manière interactive :
Connect-AzAccount -Tenant (Get-AzContext).Tenant.Id -ClaimsChallenge "<claims-challenge-token>"
Pour plus d’informations, consultez La planification de l'authentification multifactorielle obligatoire pour Azure et d'autres portails d'administration
Erreur ROPC : en raison d’une modification de configuration apportée par votre administrateur
Vous utilisez le flux ROPC (Resource Owner Password Credential) lors de la connexion à Azure à l’aide d’un mot de passe. Cette méthode d’authentification ne prend pas en charge l’authentification multifacteur. Voici un exemple :
Connect-AzAccount -Credential $Credential
Si le compte d’utilisateur nécessite l’authentification multifacteur, la commande échoue avec l’erreur suivante :
Connect-AzAccount : UsernamePasswordCredential authentication failed: Response status code does not
indicate success: 400 (BadRequest). See the troubleshooting guide for more information
https://aka.ms/azsdk/net/identity/usernamepasswordcredential/troubleshoot
solution : Utiliser une méthode d’authentification compatible avec l’authentification multifacteur.
Avertissement interlocataire : Échec de l’authentification du locataire
Si vous avez accès à plusieurs locataires et que l’une d’entre elles nécessite l’authentification multifacteur, Azure PowerShell peut afficher l’avertissement suivant :
WARNING: Unable to acquire token for tenant '00000000-0000-0000-0000-000000000000' with error
'Authentication failed against tenant 00000000-0000-0000-0000-000000000000. User interaction is
required. This may be due to the conditional access policy settings such as multi-factor
authentication (MFA). If you need to access subscriptions in that tenant, please rerun
'Connect-AzAccount' with additional parameter '-TenantId 00000000-0000-0000-0000-000000000000.'
Azure PowerShell tente de se connecter avec le premier locataire trouvé lors de la connexion. Si ce locataire applique l’authentification multifacteur, la vérification peut échouer. Pour éviter ce problème, spécifiez explicitement le locataire cible à l’aide du paramètre TenantId :
Connect-AzAccount -TenantId 00000000-0000-0000-0000-000000000000
Cela garantit que l’authentification est effectuée pour le locataire correct, ce qui réduit les risques d’échecs liés à l'authentification multifacteur.
Messages d’annonce dans les scénarios d’automatisation
Lors de la connexion à Azure avec Azure PowerShell, les messages d'annonce sont affichés à l'aide du flux d'informations de PowerShell pour les empêcher de modifier la sortie basée sur l'objet retournée. Même si nous avons fait tous les efforts pour nous assurer que les messages d’annonce n’ont pas d’impact sur votre expérience, ils peuvent tout de même affecter l’utilisation dans certains scénarios d’automatisation. Si vous rencontrez des problèmes, nous vous recommandons de supprimer le flux d’informations dans ces scénarios :
Connect-AzAccount -Subscription '<subscription name or id>' -InformationAction Ignore
Gestionnaire de comptes web (WAM)
- La méthode de connexion interactive ne peut pas ouvrir de fenêtre pour WAM et retourne l’erreur suivante : Authentification annulée par l’utilisateur.
- Azure PowerShell applets de commande ne peuvent pas s'exécuter après la connexion avec un nom d'utilisateur et un mot de passe ou un code d'appareil.
- La fenêtre contextuelle WAM n’affiche pas l’option Compte professionnel ou scolaire.
- La méthode de connexion interactive ne peut pas ouvrir une fenêtre WAM dans la console Windows PowerShell ISE.
La solution de contournement pour ces problèmes consiste à désactiver WAM :
Update-AzConfig -EnableLoginByWam $false
- La fenêtre contextuelle WAM pour sélectionner un compte n’est pas facile à trouver. Réduisez les autres fenêtres pour localiser la fenêtre contextuelle.
Installation
Cette section contient la liste des solutions aux problèmes courants qui se produisent lors de l’installation du module Az PowerShell.
Coexistence d’Az et AzureRM
Avertissement
Nous ne prenons pas en charge l’installation des modules AzureRM et Az PowerShell dans Windows PowerShell 5.1 en même temps.
Dans un scénario où vous devez installer à la fois le module AzureRM et Az PowerShell sur le même système Windows :
- AzureRM doit être installé uniquement dans l’étendue utilisateur actuelle de Windows PowerShell 5.1.
- Installez le module Az PowerShell dans PowerShell 7.2 ou une version ultérieure.
Avertissement
Le module AzureRM PowerShell a été officiellement déconseillé depuis le 29 février 2024. Les utilisateurs sont invités à migrer d’AzureRM vers le module Az PowerShell pour garantir une prise en charge et des mises à jour continues.
Il est possible que le module AzureRM fonctionne encore, mais il ne fait plus l’objet de maintenance ni de support. L’utilisateur peut continuer à s’en servir s’il le souhaite, à ses propres risques. Consultez nos ressources sur la migration pour obtenir des conseils sur la transition vers le module Az.
Visual Studio
Les versions antérieures de Visual Studio peuvent installer Azure PowerShell dans le cadre de la charge de travail de développement Azure, qui installe le module AzureRM. Azure PowerShell peut être supprimé à l’aide du programme d’installation Visual Studio ou en utilisant « Désinstaller » dans Programmes et fonctionnalités. Si vous avez déjà installé PowerShell 7.x, il peut être nécessaire d’installer manuellement le module Az PowerShell.
Le proxy bloque la connexion
Si vous recevez des erreurs de Install-Module indiquant que le PowerShell Gallery est inaccessible, vous êtes peut-être derrière un proxy. Les différents systèmes d’exploitation et environnements réseau ont des exigences propres pour configurer un proxy à l’échelle du système. Contactez votre administrateur système pour vos paramètres de proxy et pour savoir comment les configurer pour votre environnement.
PowerShell lui-même peut ne pas être configuré pour utiliser ce proxy automatiquement. Avec PowerShell 5.1 et ultérieur, configurez la session PowerShell pour utiliser un proxy avec les commandes suivantes :
$webClient = New-Object -TypeName System.Net.WebClient
$webClient.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials
Si vos informations d’identification du système d’exploitation sont configurées correctement, cette configuration route les demandes PowerShell via le proxy. Pour conserver cette configuration entre les sessions, ajoutez les commandes à votre profil PowerShell.
Pour installer le package, votre proxy doit autoriser les connexions HTTPS sur www.powershellgallery.com.
Référence d’objet non définie sur une instance d’un objet
Le message « object reference not set to an instance of an object » signifie que vous faites référence à un objet null ou à une ressource Azure qui n'existe pas ou que vous n'avez pas les autorisations d'accès.
$resourceId = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/<resource-group-name>/providers/Microsoft.Web/sites/<webapp-name>/privateEndpointConnections/<endpoint-name>'
Get-AzPrivateEndpointConnection -ResourceId $resourceId
Get-AzPrivateEndpointConnection: Object reference not set to an instance of an object.
Vous pouvez utiliser l’applet de commande Get-AzResource pour vérifier que la ressource Azure spécifiée existe.
Get-AzResource -ResourceId $resourceId
Problèmes d’autorisation avec les applets de commande AzAD
Le module Az PowerShell utilise microsoft API Graph. L’administration ou la gestion des ressources dans Azure avec le module Az PowerShell nécessite les mêmes autorisations que l’exécution de la tâche identique à partir du portail Azure ou de tout autre outil en ligne de commande Azure. Pour des questions spécifiques sur les autorisations, consultez la référence des autorisations Microsoft Graph.
paramètres de requête Microsoft Graph
Les applets de commande AzAD sous Az.Resources prennent désormais en charge les paramètres de requête et les paramètres de requête de recherche. Pour plus d’informations sur la syntaxe, consultez les liens précédemment référencés.
Get-AzAdGroupMember ne retourne pas les principaux de service
En raison des limitations de l'API Graph actuel, les entités de service ne sont pas retournées par Get-AzAdGroupMember dans Az 7.x. Pour contourner ce problème, Invoke-AzRestMethod pouvez être utilisé avec la version bêta de Microsoft API Graph.
L’exemple suivant demande le module Az PowerShell. Remplacez myGroupName sur la première ligne par le nom de votre groupe.
$Group = Get-AzADGroup -DisplayName myGroupName
((Invoke-AzRestMethod -Uri "https://graph.microsoft.com/beta/groups/$($Group.id)/members").Content |
ConvertFrom-Json).value |
Select-Object -Property DisplayName, Id, @{label='OdataType';expression={$_.'@odata.type'}}
Commande trouvée mais impossible à charger
Le message suivant est retourné par PowerShell lorsque vous essayez d’exécuter l’une des commandes Az PowerShell.
Connect-AzAccount: The 'Connect-AzAccount' command was found in the module 'Az.Accounts', but the module could not be loaded. For more information, run 'Import-Module Az.Accounts'.
Ce message se produit lorsque les modules Az et AzureRM PowerShell sont installés sur le même système Windows et qu’ils existent dans le $env :PSModulePath pour la même version de PowerShell.
Important
Quand AzureRM est installé dans l'étendue AllUsers de Windows PowerShell, il est installé dans un emplacement qui fait partie du $env:PSModulePath pour PowerShell 7. Ce n’est pas pris en charge en raison de conflits entre les modules AzureRM et Az PowerShell.
Az et AzureRM peuvent coexister sur le même système Windows, mais uniquement si AzureRM est installé dans l’étendue CurrentUser de Windows PowerShell et Az installés dans PowerShell 7. Pour plus d’informations, consultez Installer le module Az PowerShell.
Avertissement
Le module AzureRM PowerShell a été officiellement déconseillé depuis le 29 février 2024. Les utilisateurs sont invités à migrer d’AzureRM vers le module Az PowerShell pour garantir une prise en charge et des mises à jour continues.
Il est possible que le module AzureRM fonctionne encore, mais il ne fait plus l’objet de maintenance ni de support. L’utilisateur peut continuer à s’en servir s’il le souhaite, à ses propres risques. Consultez nos ressources sur la migration pour obtenir des conseils sur la transition vers le module Az.
Sur MacOS, une erreur est retournée si l’autorisation KeyChain échoue
Lorsque vous exécutez Azure PowerShell sur MacOS, vous pouvez rencontrer un message d’erreur lors de la tentative de connexion à votre compte Azure à partir d’une session PowerShell.
DeviceCodeCredential authentication failed: Persistence check failed. Reason: KeyChain authorization/authentication failed. .Error code: -25293. OS error code -25293.
Pour contourner ce problème, vous pouvez désactiver le stockage des informations d’identification entre les sessions en exécutant la commande suivante. Après avoir fait ce changement, toutefois, vous devez exécuter Connect-AzAccount chaque fois que vous démarrez une nouvelle session PowerShell.
Disable-AzContextAutosave
La connexion pour ce site n’est pas sécurisée
Lorsque votre navigateur par défaut est Microsoft Edge, vous pouvez rencontrer l’erreur suivante lors de la tentative de connexion à Azure de manière interactive avec Connect-AzAccount : « La connexion pour ce site n’est pas sécurisée. » Pour résoudre ce problème, visitez edge://net-internals/#hsts dans Microsoft Edge. Ajoutez localhost sous « Supprimer la stratégie de sécurité de domaine », puis cliquez sur Supprimer.
Erreur du domaine vérifié de l’IdentifierUri du principal du service
L’erreur Les valeurs de la propriété IdentifierUris doivent utiliser un domaine vérifié de l’organisation ou de son sous-domaine s’affiche lors de l’exécution de New-AzADServicePrincipal ou de New-AzADApplication.
En raison du changement cassant Microsoft Entra nécessitant AppId URI dans les applications monolocataires pour exiger l’utilisation du schéma par défaut ou des domaines vérifiés vous devez mettre à niveau le ModuleAz.Resources vers la version 4.1.0 ou ultérieure pour continuer à utiliser les applets de commande New-AzADServicePrincipal ou New-AzADApplication.
Vous pouvez également mettre à niveau vers la version 6.0 ou ultérieure du module Az PowerShell.
Chronologie
L’exigence est entrée en vigueur le 15 octobre 2021.
Versions impactées
Les versions suivantes de Azure PowerShell sont affectées par le changement cassant AzureAD :
- Module PowerShell Az.Resources version 3.5.1-preview ou inférieure.
- Module Az PowerShell version 5.9.0 ou antérieure.
Si vous rencontrez toujours des problèmes après la mise à niveau, n’hésitez pas à ouvrir une issue.
Solution de contournement
Si vous ne pouvez pas faire la mise à niveau vers les modules PowerShell décrits ci-dessus, vous pouvez suivre ces étapes pendant la création d’un principal de service :
- Si nécessaire, addez votre nom de domaine personnalisé à l’aide de centre d’administration Microsoft Entra
- Créer une application avec un IdentifierUri accepté
- Créer un principal de service faisant référence à cette application
Autres problèmes
Si vous rencontrez un problème de produit avec Azure PowerShell non répertorié dans cet article ou si vous avez besoin d’aide supplémentaire, fichier un problème sur GitHub.