Comment valider les informations d’identification d’un utilisateur Active Directory à l’aide de PowerShell

Déterminer les identifiants utilisateur dans PowerShell peut s’avérer complexe, surtout si vous souhaitez les vérifier avant d’exécuter certaines actions. Il est frustrant que votre script s’exécute sans détecter une authentification invalide, ce qui peut entraîner des dysfonctionnements ou des refus d’accès. L’astuce consiste à mettre en place un système de vérification de la validité du nom d’utilisateur et du mot de passe juste avant toute opération sensible. Ainsi, vous obtenez un retour immédiat et évitez les erreurs ultérieures.

Utiliser PowerShell pour tester les identifiants Active Directory sans recourir au module PowerShell dédié (un avantage certain car il fonctionne sur n’importe quelle machine Windows, même au sein d’un groupe de travail) est assez simple une fois la technique maîtrisée. Le principe est de tenter de créer un DirectoryEntryobjet avec le nom d’utilisateur et le mot de passe fournis. Si l’opération réussit (c’est-à-dire sans erreur et avec un nom valide renvoyé), les identifiants sont probablement corrects.

Comment vérifier les informations d’identification d’un utilisateur Active Directory dans PowerShell

Méthode 1 : Validation d’identifiants de base avec DirectoryEntry

Cette méthode permet de vérifier la validité d’un nom d’utilisateur et d’un mot de passe sur votre domaine sans nécessiter de modules supplémentaires. Elle convient pour une validation rapide, notamment dans un environnement de domaine. Si les identifiants sont corrects, le script renvoie « Vrai », sinon il renvoie « Faux ».

Sur certaines configurations, cela peut générer une erreur si les informations d’identification sont invalides ; il est donc judicieux de l’encapsuler dans un bloc try-catch, mais pour simplifier, voici l’idée principale :

$creds = Get-Credential Function Test-ADCreds { param ($username, $password) try { return (New-Object DirectoryServices. DirectoryEntry "", $username, $password).psbase.name -ne $null } catch { return $false } } Test-ADCreds -username $creds. UserName -password $creds. GetNetworkCredential().Password

Il suffit d’exécuter ce script, de saisir vos identifiants de domaine et de vérifier s’il renvoie « Vrai ». Si c’est le cas, vos identifiants sont valides. Sinon, cela signifie que le nom d’utilisateur ou le mot de passe est incorrect, ou que le compte est verrouillé ou désactivé. Notez que ce script fonctionne même sur les machines où le module Active Directory n’est pas installé, car il n’en dépend pas : il utilise uniquement des classes. NET natives.

Méthode 2 : Connexion à un domaine ou un serveur LDAP spécifique

Si vous utilisez un contrôleur de domaine ou une machine hors de votre domaine (ou si vous souhaitez effectuer une authentification auprès d’un serveur LDAP spécifique), vous devrez spécifier directement la chaîne LDAP. Voici ce qui est un peu étrange : vous devrez modifier le chemin LDAP pour qu’il pointe vers votre domaine ou votre contrôleur de domaine, comme ceci :

(New-Object System. DirectoryServices. DirectoryEntry 'LDAP://DC=woshub, DC=loc', $username, $password).psbase.name -ne $null

Ou, si vous vous connectez via IP, c’est similaire :

(New-Object System. DirectoryServices. DirectoryEntry 'LDAP://192.168.100.10', $username, $password).psbase.name -ne $null

Ainsi, vous pouvez vérifier les identifiants sur différents serveurs ou dans des configurations réseau variées. N’oubliez pas que si l’utilisateur appartient au groupe Utilisateurs protégés, vous devrez probablement utiliser l’en-tête UserPrincipalName (au format de l’adresse e-mail) domain\username. Kerberos prend le relais si la configuration est correcte ; il est plus sûr et plus fiable que NTLM dans certains cas.

Car bien sûr, Windows a tendance à compliquer les choses inutilement, mais avec cette approche, vous pouvez vérifier les identifiants sans avoir besoin de nombreux modules supplémentaires.