Attributs Active Directory : Dernière connexion
Nov 3, 2022
Active Directory user objects possess a number of logon metadata attributes that are valuable for Active Directory audit reporting and administration. For example, they are commonly used to identify user accounts that have been inactive for a significant period, or as “stale” accounts.
Toutefois, chaque attribut de métadonnées de connexion présente des comportements uniques qui doivent être compris. Sinon, les organisations peuvent se retrouver avec des rapports qui sont au mieux déroutants, et au pire inexacts ou trompeurs.
Dernière connexion attribut AD
L'attribut Last-Logon contient une représentation Windows FileTime de la dernière fois qu'un contrôleur de domaine a authentifié avec succès l'utilisateur. C'est le grand-père des métadonnées de connexion utilisateur, étant présent depuis la première version d'Active Directory.
En utilisant la commande PowerShell ci-dessous, vous pouvez récupérer l'heure de dernière connexion et d'autres propriétés de l'utilisateur sur un contrôleur de domaine :
Get-ADUser -Filter * -Properties lastLogon | Select samaccountname, @{Name="lastLogon";Expression={[datetime]::FromFileTime($_.'lastLogon')}}
L'attribut Last-Logon est mis à jour chaque fois qu'un contrôleur de domaine traite avec succès une demande de connexion, donc il pourrait sembler qu'il offre le moyen parfait pour identifier avec précision les comptes d'utilisateurs obsolètes. Cependant, il y a une grande mise en garde qui doit être prise en compte.
AD Last-Logon n'est pas un attribut répliqué ; chaque contrôleur de domaine (DCs) maintient sa propre version de l'attribut pour un utilisateur spécifique. Ce comportement est intentionnel — l'augmentation du trafic de réplication nécessaire pour synchroniser cet attribut à travers les contrôleurs de domaine d'un réseau aurait été accablante, surtout à l'époque de son introduction il y a vingt ans. Mais ce comportement est aussi la raison pour laquelle il est nécessaire de faire attention lors de l'utilisation de cet attribut pour rapporter sur les comptes utilisateurs obsolètes.
Étant donné que Last-Logon n'est pas répliqué (les contrôleurs de domaine n'échangent pas cette information), les valeurs des attributs ne peuvent être interprétées que dans le contexte du contrôleur de domaine interrogé. C'est-à-dire que la valeur de l'attribut ne correspond pas nécessairement à la dernière fois que l'utilisateur s'est connecté, mais plutôt à la dernière fois que l'utilisateur s'est authentifié avec succès via le contrôleur de domaine en cours de vérification. De même, le fait que l'attribut ait une valeur nulle ne signifie pas nécessairement que l'utilisateur ne s'est jamais connecté ; cela peut signifier que le contrôleur de domaine qui a renvoyé la valeur n'a jamais traité de demande de connexion de cet utilisateur.
En résumé, bien que l'attribut Last-Logon puisse être utilisé pour l'audit lié aux connexions, un rapport précis nécessitera d'interroger chaque contrôleur de domaine capable de traiter les demandes de connexion pour identifier la valeur la plus récemment mise à jour pour un compte utilisateur spécifique. Alternativement, vous pouvez utiliser une solution de reporting tierce, comme discuté plus loin dans cet article.
Last-Logon-Timestamp
L'attribut Last-Logon-Timestamp contient une représentation Windows FileTime d'un moment récent où l'utilisateur s'est connecté à un domaine. Cet attribut utilisateur a été introduit avec Microsoft Windows Server 2003. Contrairement à l'ancien attribut Last-Logon, l'attribut Last-Logon-Timestamp est un attribut répliqué ; sa valeur pour un utilisateur spécifique est synchronisée sur chaque contrôleur de domaine. C'est une grande amélioration par rapport à l'attribut Last-Logon. Cela signifie que la meilleure façon d'identifier les comptes utilisateurs obsolètes est d'utiliser le Last-Logon-Timestamp, n'est-ce pas ? Eh bien, l'utilisation de cet attribut vient avec son propre avertissement.
Le piège avec l'attribut Last-Logon-Timestamp est qu'il n'est pas toujours mis à jour lorsqu'un contrôleur de domaine traite avec succès une demande de connexion. Au lieu de cela, l'attribut a une fréquence de mise à jour dynamique qui est limitée par la valeur de l'attribut ms-DS-Logon-Time-Sync-Interval, qui par défaut n'est pas défini et est considéré comme 14 jours. Il n'est pas courant que cet attribut ait été modifié, mais si vous êtes curieux, vous pouvez facilement identifier sa valeur réelle en utilisant le script PowerShell suivant :
$lastLogonReplicationInterval = (Get-ADDomain).LastLogonReplicationInterval
if( $lastLogonReplicationInterval )
{
Write-Host "ms-DS-Logon-Time-Sync-Interval is set to $($lastLogonReplicationInterval) days"
}
else {
Write-Host "ms-DS-Logon-Time-Sync-Interval is not set and will be treated as 14 days"
Dans un domaine avec la limite maximale de mise à jour par défaut de 14 jours, le Last-Logon-Timestamp est mis à jour uniquement lorsqu'un contrôleur de domaine traite avec succès une demande de connexion et que la période depuis la dernière mise à jour de l'attribut est supérieure à quelque part entre 9 et 14 jours. La variation de cette période est le résultat d'un pourcentage aléatoire qui est inclus dans la logique qui contrôle la fréquence de mise à jour. Ce comportement reflète un compromis entre limiter le trafic de réplication nécessaire pour maintenir cet attribut synchronisé à travers les contrôleurs de domaine d'un réseau et limiter la probabilité de devoir répliquer un nombre significatif d'utilisateurs qui ont eu leur Last-Logon-Timestamp mis à jour à peu près au même moment.
Voici un exemple simplifié de la logique qui contrôle la fréquence de mise à jour de l'attribut Last-Logon-Timestamp :
(Current Datetime – Last-Logon-Timestamp) ? (ms-DS-Logon-Time-Sync-Interval – (Random % * 5 days))
En pratique, l'attribut Last-Logon-Timestamp simplifiera l'audit et le reporting liés aux connexions. Le seul problème potentiel significatif concerne le reporting des utilisateurs inactifs. Lorsqu'il est utilisé pour identifier les utilisateurs inactifs, le seuil de péremption doit dépasser la valeur de l'intervalle ms-DS-Logon-Time-Sync-Interval du domaine suffisamment longtemps pour garantir que la réplication a pu propager toutes les mises à jour significatives.
LastLogonDate (PowerShell)
Ceux qui sont familiers avec PowerShell peuvent reconnaître LastLogonDate, mais vous ne pourrez pas le trouver dans le schéma du global catalog d'Active Directory. C'est parce que LastLogonDate est en fait une valeur calculée localement qui affichera la valeur répliquée de l'attribut Last-Logon-Timestamp dans un format convivial. Sans surprise, LastLogonDate possède tous les avantages et tous les inconvénients de l'attribut Last-Logon-Timestamp. Cependant, puisqu'il ne nécessite pas de conversion à partir de Windows DateTime, c'est la meilleure option pour la plupart des rapports d'audit liés aux connexions des utilisateurs.
Attribut de la dernière connexion interactive réussie d'Active Directory
L'attribut ms-DS-Last-Successful-Interactive-Logon-Time a été introduit dans Windows Server 2008, mais beaucoup de personnes ne le connaissent pas car il est désactivé par défaut. Lorsqu'il est activé, il contient la date et l'heure du dernier succès de connexion interactive d'un utilisateur. Bien que cela semble être une chose incroyablement utile à activer, il y a des raisons convaincantes de le laisser désactivé, que je vais expliquer dans un instant.
Si vous disposez d'un environnement de laboratoire et souhaitez expérimenter avec l'attribut ms-DS-Last-Successful-Interactive-Logon-Time, vous pouvez activer ce qui suit : Configuration de l'ordinateur ? Stratégies ? Modèles d'administration ? Composants Windows ? Options de connexion Windows ? Afficher les informations sur les connexions précédentes lors de la connexion de l'utilisateur GPO. Puis forcez une mise à jour de stratégie de groupe. N'activez pas ce paramètre dans un domaine de production pour le plaisir ; vous passerez un mauvais moment.
Le premier problème avec l'attribut ms-DS-Last-Successful-Interactive-Logon-Time est que sa valeur est mise à jour uniquement lorsqu'une connexion interactive est authentifiée (pensez aux connexions « Ctrl-Alt-Del »). Cela signifie que des activités d'authentification importantes telles que les connexions aux partages réseau et les authentifications LDAP ne déclencheront pas de mise à jour. Par conséquent, si vous utilisez cet attribut pour générer des rapports d'audit liés aux connexions, il est probable que vous obteniez des résultats inexacts. Par exemple, les rapports identifiant les comptes d'utilisateurs inactifs risquent de lister des comptes de service de domaine, qui sont généralement très actifs — mais de manières non-interactives. En bref, cet attribut rend le rapport des utilisateurs obsolètes vraiment simple et fiable, mais uniquement pour les comptes d'utilisateurs utilisés pour des sessions interactives.
Résumé
Si vous avez besoin de générer des rapports d'audit de Active Directory log, la meilleure approche est probablement d'agréger vos journaux d'événements de contrôleur de domaine et de les traiter. Bien que les journaux d'événements soient incroyablement bruyants, ils sont également incroyablement fiables et fournissent des informations historiques que Active Directory ne peut pas.
Si cela n'est pas possible, utilisez LastLogonDate. Ou, encore mieux, utilisez le cmdlet Search-ADAccount intégré au module PowerShell d'Active Directory pour obtenir les informations nécessaires et les exporter vers un fichier CSV :
Search-ADAccount -AccountInactive -DateTime ((Get-Date).AddDays(-30)) -UsersOnly | Select Name,LastLogonDate,DistinguishedName| Export-CSV c:psinactive_users.csv
La cmdlet Search-ADAccount utilise en réalité LastLogonDate en arrière-plan. Sa période d'inactivité par défaut est de 15 jours, ce qui devrait convenir dans la plupart des environnements. L'exemple ci-dessus inclut la syntaxe nécessaire pour remplacer la période d'inactivité par une valeur de 30 jours. Pour ceux qui préfèrent une approche systématisée, il existe des outils gratuits utiles tels que Netwrix Inactive User Tracker pour récupérer ces informations sans avoir à convertir des valeurs et analyser des fichiers csv.
Comment Netwrix peut-il aider ?
Examiner régulièrement la last logon date de chaque utilisateur dans Active Directory peut aider votre administrateur de domaine à détecter et supprimer les comptes obsolètes que les adversaires aimeraient compromettre et abuser. Mais ce n'est qu'une petite partie d'une stratégie de cybersécurité complète.
La solution Netwrix Active Directory Security Solution fournit des informations détaillées non seulement sur le dernier moment de connexion pour chaque compte utilisateur d'Active Directory, mais aussi sur toute l'activité dans Active Directory. Ses rapports préconstruits complets simplifient la logon monitoring. En particulier, le rapport User Accounts – Last Logon Time liste tous les comptes utilisateurs, activés et désactivés, avec le dernier moment de connexion pour chaque compte. En utilisant la fonction d'abonnement aux rapports, les administrateurs IT peuvent recevoir le rapport par courriel automatiquement selon le calendrier qu'ils déterminent, facilitant ainsi l'examen régulier conformément aux meilleures pratiques et leur permettant d'éliminer les vulnérabilités du système plus efficacement.
Netwrix Directory Manager
Simplifiez et sécurisez AD avec une gestion de groupe automatisée
FAQ
Quelle est la différence entre Lastlogon et lastLogonTimeStamp ?
Contrairement à l'attribut Last-Logon, l'attribut Last-Logon-Timestamp est un attribut répliqué ; sa valeur pour un utilisateur spécifique est synchronisée sur chaque contrôleur de domaine.
Comment est calculé lastLogonTimeStamp ?
Last-Logon-Timestamp (ou lastLogonTimeStamp) est enregistré par le DC lors de la connexion de l'utilisateur ; cependant, cet attribut n'est pas toujours mis à jour sur tous les DCs lorsqu'un contrôleur de domaine traite avec succès une demande de connexion.
Qu'est-ce que l'authentification interactive ?
L'authentification interactive est un processus au cours duquel un utilisateur est invité à saisir son identifiant et son mot de passe pour se connecter à un appareil. Les endroits les plus courants où se produit la connexion interactive sont l'écran de connexion Windows et l'écran de verrouillage Windows.
Partager sur
En savoir plus
À propos de l'auteur
Joe Dibley
Chercheur en sécurité
Chercheur en sécurité chez Netwrix et membre de l'équipe de recherche en sécurité de Netwrix. Joe est un expert en Active Directory, Windows et une grande variété de plateformes logicielles d'entreprise et de technologies, Joe étudie les nouveaux risques de sécurité, les techniques d'attaque complexes, ainsi que les atténuations et détections associées.
En savoir plus sur ce sujet
Lois sur la confidentialité des données par État : Différentes approches de la protection de la vie privée
Exemple d'analyse des risques : Comment évaluer les risques
Le Triangle CIA et son application dans le monde réel
Qu'est-ce que la gestion des documents électroniques ?
Analyse quantitative des risques : Espérance de perte annuelle