Rechercher Des Comptes d’Utilisateurs Inactifs Dans Votre Domaine
Active Directory est un service d’annuaire qui conserve des informations sur les utilisateurs, les ordinateurs et les objets associés. Voici comment trouver des comptes d’utilisateurs inactifs.
C’est une base de données d’informations relationnelles qui a besoin d’être entretenue dans le temps pour être utile et pertinente. Les comptes d’un répertoire ne seront plus utilisés. Trouver ces comptes dans Active Directory n’est pas aussi facile qu’il n’y paraît à première vue. Parcourons la recherche de comptes d’utilisateurs inactifs et automatisons leur suppression.
Définir les critères de recherche
Définissons ce qui est nécessaire pour ce processus. Notre objectif est de localiser les comptes d’employés qui ne se sont pas connectés au réseau pendant une période prolongée. J’ai toujours utilisé 90 ou 120 jours comme une bonne mesure pour interroger l’inactivité, mais ce nombre peut être aussi faible que 14 jours. Vous devez décider ce qui convient à votre organisation. 90 jours donne un coussin assez grand pour permettre aux personnes de quitter le bureau pour des vacances, des urgences familiales ou des congés médicaux prolongés. Une fois que les comptes atteignent 90 jours d’inactivité, nous voulons désactiver ces comptes et les déplacer vers une unité d’organisation séparée.
Définir ce que nous recherchons en premier nous permet de construire un ensemble de règles simple à suivre. Notre jeu de règles ressemble à ceci:
- Recherchez et désactivez les comptes actifs qui n’ont aucune activité de connexion pendant 90 jours.
- Déplacez chaque compte désactivé dans le OU Utilisateurs désactivés
- Marquez chaque utilisateur désactivé avec un commentaire indiquant qu’un processus automatisé l’a désactivé.
Rechercher les propriétés d’inactivité du compte
Chaque compte utilisateur possède plusieurs attributs contenant des informations de connexion. Nous voulons trouver des attributs qui montrent la dernière heure de connexion. Si nous pouvons trouver ces attributs, nous pouvons les utiliser pour rechercher des comptes non connectés depuis une certaine date. Nous pouvons utiliser PowerShell pour afficher tous les jeux de règles et choisir un attribut avec lequel travailler.
Get-ADUser est l’applet de commande la plus utilisée pour afficher les informations utilisateur. Vous pouvez utiliser Get-ADObject et Search-ADAccount, mais Get-ADUser est la meilleure applet de commande pour notre tâche. Pour afficher toutes les propriétés de l’utilisateur, nous devons ajouter -properties* à la syntaxe de l’applet de commande. Si nous laissons cette syntaxe de côté, nous ne verrons que les propriétés par défaut, qui ne sont que de 10 propriétés.
Get-ADUser Michael_Kanakos -Properties *
Nous renvoyons une longue liste de champs de notre requête (plus de 150!). Nous pouvons rechercher des attributs contenant des mots particuliers en utilisant des caractères génériques. Cela nous aide à localiser les attributs qui peuvent être utiles pour notre tâche. Nous voulons trouver des informations de connexion, alors recherchons des attributs contenant le mot Connexion.
Une fois que nous avons dit à PowerShell d’obtenir toutes les propriétés, il serait utile de limiter la liste des propriétés pour n’afficher que les propriétés correspondant à la connexion au mot. Select-Object offre la possibilité de faire un match de wild-card et de limiter nos résultats. Le caractère | (appelé « le tuyau ») prend les résultats à gauche et les passe à Select-Object. Select-Object effectue ensuite la correspondance des wild-card, puis limite les résultats en fonction de nos critères de wild-card.
Get-ADUser username -Properties * | Select-Object *logon*
BadLogonCount : 0
lastLogon : 132181280348543735
LastLogonDate : 11/11/2019 9:08:45 PM
lastLogonTimestamp : 132179981259860013
logonCount : 328
LogonWorkstations :
MNSLogonAccount : False
SmartcardLogonRequired : False
Les résultats varieront un peu en fonction du niveau fonctionnel du domaine de l’Active Directory. Ma recherche renvoie huit attributs. Trois semblent prometteurs: LastLogon, LastLogonDate et LastLogonTimeStamp. Certaines des valeurs peuvent sembler un peu bizarres si vous ne savez pas comment Active Directory stocke les informations de date / heure dans certains attributs. Certaines informations de date sont des informations date-heure traditionnelles, et certaines sont enregistrées en tant que « ticks ». »
Les valeurs date-heure de PowerShell et de .NET Framework représentent les dates comme le nombre de ticks depuis le 1er janvier 0001 à 12h00. Les tiques sont égales à un dix millionième de seconde, ce qui signifie qu’il y a 10 000 tiques par milliseconde. Il existe des applets de commande mathématiques qui peuvent convertir les ticks en un format de date standard.
PowerShell affiche la coche réelle qui représente la date / heure. Si vous êtes à l’aise pour convertir des ticks au format de date, vous pouvez consulter ces champs dans l’utilisateur et les ordinateurs Active Directory ou le centre d’administration Active Directory. Dans les deux applications, les ticks sont représentés sous la forme d’un format heure-date.
ADUser-Logon-Properties
Attributs de connexion expliqués
Notre recherche a trouvé plusieurs propriétés qui affichent des informations de connexion date/heure. Deux propriétés ont la même date et la même heure et une non. Que se passe-t-il ici ?
La variance des informations date-heure est de conception et est en place pour protéger les DC contre l’écrasement du trafic de réplication en essayant de synchroniser toutes les informations de connexion. La propriété LastLogon se met à jour chaque fois que vous vous authentifiez, mais les données sont stockées sur le DC contre lequel vous vous êtes authentifié et ne sont pas répliquées sur les autres DC. Les propriétés LastLogonTimeStamp et LastLogonDate sont répliquées sur tous les DC, mais la réplication ne se produit que rarement.
Si nous regardons les dates, nous pouvons voir comment la réplication retardée pourrait affecter notre requête. Notez que LastLogonTimeStamp a en fait deux jours de retard dans cet exemple. Chaque fois qu’un utilisateur se connecte de manière interactive, touche un partage de fichiers réseau ou effectue d’autres activités nécessitant l’authentification du compte par le réseau, il stocke les informations de connexion dans Active Directory. Si les DC répliquaient ces données CHAQUE FOIS que quelqu’un touchait quelque chose sur le réseau, les DC pourraient être submergés dans un grand environnement. Le résultat est que certaines informations d’ouverture de session sont exactes mais non répliquées, et certaines informations d’ouverture de session se répliquent, mais seulement occasionnellement.
Pour nos besoins, nous n’avons pas besoin de l’horodatage EXACT de l’ouverture de session. Il nous suffit de trouver des comptes qui ne se sont pas connectés depuis longtemps (plus de 90 jours). Toute valeur peut être utile, même si la date est décalée de quelques jours. Si nous utilisons mes dates d’ouverture de session comme exemple, l’heure interrogée pourrait être 11/11 ou 11/13, selon la valeur que nous utilisons. Avance rapide de trois mois et supposons que je ne me suis plus jamais connecté. Une date serait signalée comme inactive pour plus de 90 jours, et un champ ne le serait pas. Mais si je configurais ce processus pour qu’il fonctionne mensuellement, j’attraperais le compte la prochaine fois que nous vérifierons. C’est la partie critique. Si nous le faisons régulièrement, nous pouvons utiliser l’un ou l’autre champ tant que nous vérifions constamment.
J’ai utilisé la propriété LastLogonDate pour deux raisons. Premièrement, c’est déjà une valeur de date, donc je n’ai pas à gérer la conversion de la valeur. Deuxièmement, c’est une valeur répliquée, et cela me facilite la vie. Si j’utilisais LastLogon, j’aurais des dates qui ne sont pas à jour pour les personnes qui s’authentifient auprès d’autres contrôleurs de domaine de mon réseau. Je devrais interroger le DC local pour que chaque utilisateur obtienne le dernier horodatage, et c’est beaucoup de travail à faire et pas très efficace.
Pour obtenir les informations sur un seul compte, le code est simple.
get-aduser Michael_Kanakos -properties LastLogonDate | Select-Object Name, LastLogonDate
Name LastLogonDate
---- -------------
mkanakos 11/11/2019 9:08:45 PM
Pour ce faire pour tous mes utilisateurs, il suffit d’un peu plus de code. Nous devons utiliser un filtre pour interroger tous les comptes d’utilisateurs.
Get-ADUser -filter * -properties LastLogonDate | Select-Object Name, LastLogonDate
Trouvons maintenant uniquement les comptes dont la date de connexion est supérieure à 90 jours. Nous avons besoin de la date actuelle enregistrée pour l’utiliser comme opérateur de comparaison.
$date = (get-date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $date} -properties LastLogonDate | Select-Object Name, LastLogonDate
Ce code récupère tous les utilisateurs qui ne se sont pas connectés depuis plus de 90 jours. Nous enregistrons la date il y a 90 jours dans une variable. Nous pouvons créer un filtre d’annonces pour trouver des connexions inférieures à cette date. Ensuite, nous devons ajouter l’exigence d’interroger uniquement les comptes actifs. Dans cet exemple, j’utilise le splatting pour rendre le code plus lisible car la syntaxe est très longue. Splatting AD applets de commande peut être délicat, j’ai donc également montré la version longue de la syntaxe sous l’exemple de splatting.
$date = (get-date).AddDays(-90)
$paramhash = @{
Filter = "LastLogonDate -lt $date -and Enabled -eq $true"
Properties = 'LastLogonDate'
}
$SelectProps = 'Name','LastLogonDate','Enabled','DistinguishedName'
$InactiveUsers = Get-Aduser @paramhash | Select-Object $SelectProps
$InactiveUsers = Get-ADUser -Filter {LastLogonDate -lt $date -and Enabled -eq $true} -properties LastLogonDate, DistinguishedName | Select-Object Name, LastLogonDate, Enabled, DistinguishedName
Cela nous donne nos utilisateurs inactifs qui sont activés. Nous enregistrons les résultats dans une variable pour les réutiliser. La propriété DistinguishedName est nécessaire plus tard. Une fois que nous avons trouvé les utilisateurs, nous pouvons travailler sur notre prochaine étape: la désactivation des comptes. Nous utilisons l’applet de commande Set-ADUser pour apporter des modifications au compte d’utilisateur AD.
$Today = Get-Date
$DisabledUsers = (
$InactiveUsers | Foreach-object {
Set-User $_.DistinguishedName -Enabled $false -Description "Acct disabled on $Today via Inactive Users script"}
)
Nous avons désactivé nos comptes d’utilisateurs. Il est temps de les déplacer vers une nouvelle unité d’unité. Pour notre exemple, nous utiliserons l’unité d’organisation nommée Disabled-Users. Le nom distinctif de cette unité d’organisation est « OU=Disabled-Users, DC=Contoso, DC=Com » Nous utilisons l’applet de commande Move-ADObject pour déplacer les utilisateurs vers l’unité d’organisation cible.
$DisabledUsers | ForEach-Object {
Move-ADObject $_.DistinguishedName -TargetPath "OU=Disabled-Users,DC=Contoso,DC=Com"}
Dans notre dernière étape, nous avons utilisé Move-ADObject pour déplacer les utilisateurs vers une nouvelle unité d’organisation. Nous avons maintenant le code de base nécessaire pour créer une tâche automatisée fiable et reproductible. Alors, quelle est la prochaine étape ? Cela dépend de vos besoins individuels. Ce code peut et doit être configuré pour s’exécuter automatiquement à la même heure tous les mois. Un moyen simple de le faire est de créer un travail planifié pour exécuter le code sur une base mensuelle.
Il y a plus que nous pourrions ajouter à ce code pour le rendre meilleur. Le code pour la vérification des erreurs et les champs d’informations supplémentaires sur l’utilisateur seraient deux ajouts utiles. La plupart des équipes exécutant ces types de tâches génèrent un rapport de ce qui a été désactivé pour que quelqu’un puisse l’examiner, de sorte que les champs supplémentaires varieront. Vous pouvez inclure plus de champs d’Active Directory pour rendre un rapport plus utile. Nous pourrions aller plus loin dans cette tâche en créant une autre tâche pour supprimer ces utilisateurs handicapés après 6 mois.
La résolution de demandes d’automatisation difficiles est beaucoup plus facile lorsque les tâches sont divisées en éléments gérables. Nous avons commencé avec des exigences et construit notre syntaxe en petites étapes; confirmant que chaque étape fonctionne avant d’essayer d’ajouter une autre variable. En faisant cela, nous avons rendu cette tâche facile à comprendre et, espérons-le, une excellente expérience d’apprentissage.