PowerShell LastLogon, accountExpires auslesen und konvertieren

[Beginner18 0]

Moin,

 

ich habe ein kleines und wahrscheinlich leicht zu lösendes Problem.

(Zumindest für Leute die einen guten Durchblick in PowerShell haben)

 

Ich möchte die Properties LastLogon und accountExpires von AD-Usern auslesen und in ein Datum konvertiert haben.

In meinem Script konnte ich bereits das Datum von LastLogon auslesen und konvertieren, jedoch ist dieses um ein paar Tage nach hinten verschoben. Bei accountExpires habe ich noch keine großen Fortschritte gemacht.

Dazu habe ich zwei scripte geschrieben, beim Oberen ist das Problem mit dem LastLogon und beim unteren habe ich noch ein Versuch unternommen ein Ergebnis für accountExpires zu bekommen nur stehe da leider auf dem Schlauch.

 

Import-Module ActiveDirectory

Get-ADUser -Filter {Name -like "Mueller"} -Properties * |

Select -Property GivenName,

Name,

@{n='LastLogon';e={[DateTime]::FromFileTime($_.LastLogon)}},

accountExpires,

Enabled,

samaccountname,

DistinguishedName,

Department

#Export-CSV "H:\Alle_ADUser"

 

 

Import-Module ActiveDirectory

$benutzers = Get-ADUser -Filter {Name -like "Mueller"} -Properties * |

Select -Property GivenName,

Name,

@{n='LastLogon';e={[DateTime]::FromFileTime($_.LastLogon)}},

Enabled,

samaccountname,

Department,

DistinguishedName

　

foreach($benutzer in $benutzers)

{$test = $benutzer.accountExpires

[datetime]::FromFileTime([int64]$test)}

#Export-CSV "H:\Alle_ADUser"

 

Danke schonmal im Voraus !

 

 

 

[testperson 1.692]

Hi,

 

nimm doch "einfach" die Properties LastLogonDate sowie AccountExpirationDate?

 

Gruß

Jan

[Beginner18 0]

Hallo Jan,

 

der Tipp mit AccountExpirationDate war super, Danke!

Jedoch das LastLogonDate ist ebenfalls um ein paar Tage nach verschoben.

Also wenn ich meinen eigenen Benutzer dafür nehme wird mein LastLogonDate auf den 24.2.17 ausgegeben.

Deshalb habe ich LastLogon genommen und wollte die Zahl konvertieren.

Hast du da noch einen Tipp?

 

Gruß

Jannes

[testperson 1.692]

Hi,

 

da fällt mir grade auf, LastLogon wird nicht repliziert und gibt dir nur den Wert für den abgefragten DC zurück. LastLogonTimestamp wird repliziert, hinkt allerdings ca. 14 Tage hinterher und entspricht damit dem LastLogonDate.

Daher: Wozu benötigst du die Daten denn?

 

Gruß

Jan

[Beginner18 0]

Hallo,

 

ich möchte das genaue LastLogon Datum haben, damit ich "tote" User, die sich mehr als 90 Tage nicht angemeldet haben, aus der AD entfernen kann.

 

Gruß

Jannes

[testperson 1.692]

In dem Fall würde ich das LastLogonDate nehmen und die Konten erst nach 104 Tagen entfernen.

Ansonsten müsstest du alle DCs nach dem LastLogon abfragen oder die EventLogs aller DCs durchsuchen.

[NilsK 2.940]

Moin,

 

ich möchte das genaue LastLogon Datum haben, damit ich "tote" User, die sich mehr als 90 Tage nicht angemeldet haben, aus der AD entfernen kann.

 

genau dafür ist lastLogonTimestamp da. Du brauchst ja gar nicht das genaue Datum, sondern eben gerade nur ein ungefähres. Es interessiert dich ja nicht, ob der User heute um 10:20 oder um 8:46 sich angemeldet hat, sondern ob das schon mehr als x Tage her ist.

 

https://blogs.technet.microsoft.com/heyscriptingguy/2010/01/27/dandelions-vcr-clocks-and-last-logon-times-these-are-a-few-of-our-least-favorite-things/

 

Noch einfacher wäre übrigens OldCmp von Joe Richards: http://www.joeware.net/freetools/tools/oldcmp/index.htm

 

@testperson: 104 Tage sind nicht nötig, wenn man 90 Tage meint. Die 14 Tage muss man nicht draufschlagen - alles, was älter als 14 Tage ist, ist akkurat.

 

Gruß, Nils

bearbeitet 1. März 2017 von NilsK

[blub 115]

Finger weg vom LastLogonTimeStamp 

 

Theoretisch:

https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

 

Praktisch

http://www.mcseboard.de/topic/205328-aktualisierung-lastlogontimestamp-problemk%C3%BCndigung/

[NilsK 2.940]

Moin,

 

Finger weg vom LastLogonTimeStamp

 

nein. Deine Vorbehalte sind nachvollziehbar, aber für die meisten Szenarien gar nicht zutreffend - unter anderem für das hier diskutierte.

 

Wenn man lastLogonTimestamp für das nutzt, wofür es entworfen wurde, ist es die beste Variante.

 

Gruß, Nils

[blub 115]

zwei Gründe aus dem oben verlinkten Blog:

 

Summary

LastLogonTimeStamp might not always be updated by an actual Logon. S4u2Self requests for access checks can update the attribute

 

 

Moin,nein. Deine Vorbehalte sind nachvollziehbar, aber für die meisten Szenarien gar nicht zutreffend - unter anderem für das hier diskutierte.

 

In welchen Szenarien trifft denn S4uSelf zu und wann nicht?

[NilsK 2.940]

Moin,

 

das haben wir seinerzeit ja schon diskutiert. LastLogonTimestamp wurde für "unscharfe" Abfragen entworfen, vor allem für die typische Frage "welche User- bzw. welche Computerkonten werden nicht mehr verwendet?". Dafür reicht die Genauigkeit in praktisch allen Fällen aus.

 

Als Sicherheitselement war es nie gedacht, daher ist die Kritik daran zwar sachlich richtig, aber eben doch meist unpassend.

 

Gruß, Nils

[blub 115]

Lies dir doch bitte den Blog mal durch!

 

Der S4uSelf Mechanismus führt dazu, dass Userkonten und Maschinenkonten ihren LastLogonTimeStamp updaten, obwohl niemand die Konten benutzt bw. die zugehörigen User bzw. Maschinen schon längst nicht mehr existieren. d.h. ein uralt, seit ewigen Zeiten, unbenutzter, und sogar disabled Account bekommt trotzdem einen aktuellen Zeitstempel durch das System.

 

 

Dafür reicht die Genauigkeit in praktisch allen Fällen aus.

das hat mit Genauigkeit überhaupt nichts zu tun!

 

Man kann bei der Verwendung des LLTS durch Laien davon ausgehen, dass irgendwann die Panik aufkommt, weil ein disabled Useraccount oder Maschinenaccount einen aktuellen Zeitstempel hat. (siehe das zitierte Praxisbeispiel). Deswegen "Finger Weg von dieser Property", die hat keine zuverlässige Aussagekraft.

 

Der Blog ist nicht ganz einfach zu verstehen, aber der Sachverhalt ist detalliert beschrieben. Das hat nichts, aber auch gar nichts mit "den meisten Szenarien" ode "unpassender Kritik" zu tun, sondern mit Kerberos Mechanismen. Den Blog lesen und verstehen muss man! (zumindest das bereits zitierte Summary am Ende)

[NilsK 2.940]

Moin,

 

danke, ich habe den Blog gelesen. Und verstanden. Ganz sicher. Du musst mir keine Unwissenheit unterstellen, wenn ich anderer Meinung bin. Irgendwann ist auch mal gut.

 

Dass bei der Abfrage "welche Konten wurden seit 90 Tagen nicht verwendet?" ein paar Konten wegen des beschriebenen Mechanismus durchs Raster fallen, ist unerwünscht - da sind wir uns einig. Und sicher war es beim Design des Attributs auch nicht im Blick, ist also - auch da sind wir uns einig - ein funktionaler Fehler.

 

Trotzdem sehe ich es nicht so, dass das Attribut und der Use Case damit nicht nutzbar wären. In den allermeisten Umgebungen tritt das in dem Blog beschriebene Problem gar nicht auf. Ich habe das bei Kunden sehr oft durch Plausibilitäts-Vergleiche überprüft. Und, wie gesagt: Der Use Case, für den das Ganze entworfen wurde - Aufräumen - funktioniert auch mit der Ungenauigkeit, die das beschriebene Problem erzeugt. Mehr als Ungenauigkeit ist es dann nämlich nicht.

 

Von jeder anderen Verwendung des Attributs und jeder weiter gehenden Interpretation der Werte rate ich ab, schon immer.

 

Gruß, Nils