Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

[Active Directory] Différence entre Get-ADUser et Get-ADObject

Dans les scripts Active Directory, la récupération d’informations sur les comptes utilisateurs repose très souvent sur la cmdlet Get-ADUser. Simple à utiliser et bien intégrée aux besoins courants, elle est généralement le premier choix pour interroger des objets de type utilisateur. Cependant, dans certains scénarios d’audit ou d’automatisation avancée, cette cmdlet peut rapidement montrer ses limites.

Get-ADUser est une cmdlet spécialisée, conçue exclusivement pour les objets strictement typés User. Elle repose sur un schéma d’attributs prédéfini et masque une partie de la complexité du modèle Active Directory. Cette abstraction facilite l’écriture de scripts simples, mais elle restreint l’accès à certains attributs spécifiques ou étendus, notamment ceux issus de schémas personnalisés ou de configurations particulières.

Lors de travaux d’audit, il est possible de constater que certains objets ne sont pas remontés ou que certains attributs ne sont tout simplement pas accessibles via Get-ADUser. C’est notamment le cas pour des objets hybrides, des comptes atypiques, ou lorsque des filtres LDAP complexes sont nécessaires pour affiner les résultats.

À l’inverse, Get-ADObject permet d’interroger n’importe quel objet Active Directory, sans restriction de type. Cette cmdlet s’appuie directement sur des filtres LDAP et offre un accès complet aux attributs du schéma, y compris les attributs personnalisés ou rarement utilisés. Elle nécessite en revanche une meilleure compréhension de la structure Active Directory et du langage LDAP.

Dans les scripts nécessitant davantage de précision et de flexibilité, l’utilisation de Get-ADObject avec un paramètre -LDAPFilter s’avère souvent plus adaptée. Elle permet de cibler précisément les objets recherchés, qu’il s’agisse d’utilisateurs, de contacts, d’objets système ou de comptes non standards.

Le choix entre Get-ADUser et Get-ADObject dépend donc du contexte. Pour des scripts simples et lisibles, Get-ADUser reste parfaitement appropriée. En revanche, pour des scripts d’audit, de reporting ou d’automatisation avancée, Get-ADObject offre une souplesse indispensable et permet de concevoir des scripts plus génériques, robustes et réutilisables.

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

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

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