Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

[REX] Pourquoi Microsoft Graph PowerShell cesse de fonctionner après l’installation de PnP.PowerShell

par | 20 Jan 2026 | , ,

Dans un environnement PowerShell 7 dédié à l’administration Microsoft 365, il est fréquent d’installer les modules Microsoft.Graph et PnP.PowerShell. Pris séparément, ces modules fonctionnent correctement. En revanche, leur utilisation conjointe peut provoquer des erreurs inattendues.

Après l’installation de PnP.PowerShell, des commandes Microsoft Graph parfaitement valides peuvent échouer avec le message suivant :

Could not load type
‘Microsoft.Graph.Authentication.AzureIdentityAccessTokenProvider’
from assembly ‘Microsoft.Graph.Core’

Cette erreur n’est ni liée aux permissions Graph ni à l’authentification. Elle est causée par un conflit de dépendances .NET. PnP.PowerShell embarque ses propres versions des bibliothèques Microsoft Graph (Core, Authentication, Azure.Identity). Lors de l’import du module, ces DLL sont chargées en mémoire.

PowerShell ne fournit pas de mécanisme d’isolation des assemblies par module. La première version chargée d’une DLL est utilisée par toute la session. Ainsi, lorsque Microsoft.Graph PowerShell est exécuté dans la même session, il peut se retrouver à utiliser une version de Microsoft.Graph.Core trop ancienne, ne contenant pas les classes attendues.

Comment corriger le problème

La solution la plus simple consiste à fermer la session PowerShell et à relancer une session dédiée uniquement à Microsoft Graph. Si nécessaire, il est également recommandé de réinstaller le module Graph afin de s’assurer de la cohérence des versions :

Get-InstalledModule Microsoft.Graph* -AllVersions | Uninstall-Module -Force
Install-Module Microsoft.Graph -Force

Comment éviter le problème à l’avenir

La seule approche réellement fiable est de ne jamais utiliser Microsoft.Graph et PnP.PowerShell dans la même session PowerShell. Chaque module doit être exécuté dans une session distincte, avec des scripts séparés selon l’usage (Graph ou PnP).

Ce comportement n’est pas un bug des scripts ni une mauvaise configuration utilisateur. Il s’agit d’une limite structurelle du modèle de chargement des assemblies .NET dans PowerShell. Le connaître permet d’éviter des diagnostics inutiles et de concevoir des automatisations Microsoft 365 plus robustes.

ADFS – L’authentification WIA échoue avec l’erreur 0xc000035b

par | 16 Jan 2026 |

Lorsqu’une ferme ADFS est exposée sur Internet ou à des réseaux externes à l’entreprise, il est courant de déployer en frontal des serveurs reverse proxy (service WAP natif ou services tiers comme F5 BigIP ou Kemp Loadmaster) :

Dans ce cas, il est également relativement fréquent d’utiliser un certificat différent sur les équipements positionnés en frontal/DMZ de celui utilisé sur les serveurs de la ferme ADFS, en particulier lorsqu’il s’agit d’un certificat public.
Cette configuration peut néanmoins entrer en conflit avec la fonctionnalité Extended Protection for Authentication (EPA) lors d’une authentification intégrée Windows (WIA), puisqu’elle traite le reverse proxy/load balancer frontal comme une attaque Man in the Middle lorsque ce dernier ne dispose pas du même certificat.

Ce problème peut être un peu difficile à identifier au premier abord puisque coté client, le seul symptôme visible est un échec de l’authentification. Coté serveur ADFS on retrouve par contre l’évènement suivant dans le journal Sécurité : 

Audit Failure
ID : 4625
Failure reason : an error occured during logon
Status : 0xc000035b

Deux options s’offrent alors à nous pour résoudre le problème :
– Utiliser le même certificat SSL à la fois en DMZ et sur les serveurs de la ferme ADFS
– Désactiver la protection à l’aide de la commande powershell Set-ADFSProperties -ExtendedProtectionTokenCheck None

Set-AdfsSslCertificate échoue avec une erreur « Access is denied »

par | 16 Jan 2026 |

Lors d’une récente intervention chez un client, j’ai été amené à modifier le certificat externe d’une ferme ADFS.
Cette manipulation se fait normalement très simplement via l’import du certificat dans le magasin Personnel de chaque serveur de la ferme puis l’exécution de la commande Set-AdfsSslCertificate -Thumbprint XXXXXXXXXXXXXXXXXXXX mais j’ai cette fois ci rencontré un message d’erreur bizarre :

PS0317: One or more of AD FS servers returned errors during execution of command 'Set-AdfsSslCertificate'. Error information: PS0316: AD FS Server:
'localhost', Error: 'Connecting to remote server localhost failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.'.

L’invite de commande était pourtant bien ouverte en mode administrateur, localement sur le noeud primaire de la ferme ADFS et avec un compte du domaine disposant des permissions d’administrateur local et d’administrateur ADFS.

Après quelques recherches, il s’avère que c’est la présence de ce compte dans le groupe Active Directory Protected Users qui cause ce problème, probablement parce que « localhost » n’est pas un nom DNS ni un SPN valide pour une authentification Kerberos à laquelle les membres de Protected Users sont soumis.

Il aurait été possible de sortir temporairement l’utilisateur de ce groupe mais cela aurait entrainé une dégradation temporaire de la posture de sécurité ainsi qu’une alerte auprès du SOC; la solution qui a donc finalement été retenue à été l’utilisation du compte administrateur local géré par LAPS pour exécuter cette commande, cette fois sans encombre.

Derniers articles

Catégories

Archives

Auteurs/Autrices