Wann läuft ein Maschinenaccount / Computerkonto ab? Gar nicht!

  • Article

Hallo, Fabian hier. Wir hören und lesen oft von Kunden, die nach einem Zeitraum X „ungenutzte“ Computerkonten per Script deaktivieren oder löschen und dann später in Probleme laufen, weil sich Clients nicht mehr authentifizieren können und damit auch keine Benutzeranmeldung mehr möglich ist.

Ein Aufräumvorgang ist grundsätzlich nicht verkehrt und sorgt für eine übersichtliche AD-Umgebung. Nur leider gibt es bei der Durchführung oft Missverständnisse in Bezug auf den Zeitraum, ab wann ein Computerkonto als „nicht aktiv“ gewertet werden sollte bzw. wann das „Computerkennwort abläuft“. Daher an dieser Stelle ein, zwei Zeilen dazu. Der zentrale Punkt bei diesem Thema ist der folgende:

Ein Computerkonto Kennwort läuft grundsätzlich erst einmal nie ab, wenn ein Client sich nicht an der Domäne authentifiziert.  

Computerkonten sind von den „normalen“ Kennwortrichtlinien ausgenommen – meldet sich ein Client also beispielsweise 3 Monate lange nicht am Unternehmensnetzwerk an, so ist das kein Problem. Der Client wird nach der Verbindung mit einem Domänencontroller seiner Domäne nach Aufbau des sicheren Kanals mittels des alten, immer noch gültigen Kennworts, die Kennwortänderung initiieren. Das passiert jedoch nicht unmittelbar nach dem Aufbau des sicheren Kanals, dazu später mehr in diesem Blog Eintrag.

Hat man nun vor diesem Zeitpunkt schon per Script bzw. automatisierten Task das Computerkonto als „stale“ deaktiviert oder gelöscht, weil das Computerkennwort für 90 Tage nicht geändert wurde (etwa mittels „dsquery computer –stalepwd 90 | dsmod computer –disabled yes“) oder weil es aufgrund des fehlenden Logons eines Clients keine Änderung des Attributs „lastLogonTimestamp“ mehr an dem Computerkonto gab („dsquery computer –inactive 90 | dsmod computer –disabled yes“), dann läuft man zwangsweise in Probleme, da sich der Client nicht mehr an der Domäne authentifizieren kann.

Es gibt die Möglichkeit, das Verhalten für die Kennwortänderungen zu beeinflussen. Hierzu kann bei Bedarf wie folgt vorgegangen werden:

  • Standardmäßig versuchen die Clients Ihr Computerkennwort alle 30 Tage innerhalb einer Domänenumgebung zu ändern. Dieses Verhalten läßt sich über eine Gruppenrichtlinie anpassen:  Computer Configuration\Windows
    Settings\Security Settings\Local Policies\Security Options --> "Domain member: Maximum machine account password age"

Der zugehörige Registrierungsschlüssel zu dieser Einstellung lautet:
Schlüssel: HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Wert: MaximumPasswordAge REG_DWORD 30
Mögliche Werte: 1 bis 1.000.000 (in Tagen)

Siehe dazu: MaximumPasswordAge  https://technet.microsoft.com/en-us/library/cc775452.aspx

Ist dieser Wert nach der letzten Kennwortänderung des Clients überschritten, wird der Client versuchen, sein Computerkennwort zu ändern. Bis er es geschafft hat wird das alte Computerkennwort verwendet.

  • Das Ändern des Computerkennworts läßt sich auch komplett deaktivieren. Dies würde ich jedoch nicht empfehlen, da dies die Sicherheit des Forests einschränken kann. Bisher habe ich persönlich nur einen Anwendungsfall gesehen, bei dem das Deaktivieren Sinn gemacht hat: In einer Testumgebung, in der mit Clientimages gearbeitet wurde. 

    Der entsprechende Registry Wert heißt:
    Schlüssel: HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
    Wert = DisablePasswordChange REG_DWORD 1

    Siehe dazu: 154501 How to disable automatic machine account password changes https://support.microsoft.com/default.aspx?scid=kb;EN-US;154501

  • Nachdem ein Client festgestellt hat, daß er sein Kennwort ändern muß, spielt noch ein anderer Prozess eine Rolle: Es gibt einen sogenannten „Workstation Scavenger“ (nicht zu verwechseln mit DNS Scavenging), der bestimmt, wie lange es nach dem Start des NETLOGON Dienstes auf dem Client dauert, bis der Client die Kennwortänderung falls nötig initiiert. Ist das maximale Kennwortalter zum Zeitpunkt des Durchlaufs noch nicht erreicht oder aber kein DC erreichbar, bestimmt das sogenannte „Scavenging Interval“, nach welcher Zeit ein erneutes Überprüfen des Kennwortalters oder der Verfügbarkeit eines DCs erfolgen soll. Standardmäßig sind 15 Minuten eingestellt.

    Sollte es notwendig sein, diesen Intervall zu ändern, kann man dies über den folgenden Registrierungsschlüssel erreichen:
    Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
    Wert : ScavengeInterval REG_DWORD 900
    Mögliche Werte: 60 bis 172800 Sekunden (also maximal 48 Stunden)

    Siehe dazu: ScavengeInterval  https://technet.microsoft.com/en-us/library/Cc957289.aspx

  • Wichtig im Zusammenhang mit dem "ScavengeInterval" ist auch die "negative cache period". Wurde beispielsweise nach einer VPN-Einwahl in das Unternehmensnetzwerk kein DC gefunden, wird nicht permanent vom Client versucht, einen "neuen" DC zu finden. Auch hier gibt es einen veränderbaren Intervall. Das bedeutet, daß sich der Zeitraum für eine Kennwortänderung noch weiter erhöhen kann - ist man dann nur kurz in dem Unternehmensnetzwerk angemeldet, wird das Kennwort ebenfalls unter Umständen nicht geändert.

    Der entsprechende Registry Schlüssel heißt:
    Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
    Wert: NegativeCachePeriod DWORD 45
    Empfohlener Wert: 84600 (in Sekunden)

    Siehe dazu: 819108 Settings for minimizing periodic WAN traffic https://support.microsoft.com/kb/819108/en-US

Möchte man also einen automatisierten Aufräumvorgang per Script o.ä. realisieren, sollte vorher das genaue Anmeldeverhalten der Benutzer mit Ihren Computern geprüft werden. Kommt es vor, daß Benutzer z.B. mit Ihren Laptops sich nur alle 3 Monate im Unternehmensnetzwerk  anmelden (egal ob direkt oder per VPN), sollte der Zeitraum für den Aufräumvorgang höher als 90 Tage liegen. Zusätzlich sollte der oben genannte Scavenging Intervall ggf. überprüft werden – denn wenn ein Client vielleicht nur knappe 14 Minuten im Netzwerk angemeldet ist, wird er aufgrund des versetzten Zeitraumes der Kennwortänderung nicht mehr zu dieser Aktion kommen.

Er kann sich dann weiterhin mit seinem alten Kennwort authentifizieren – aus Sicherheitsgründen ist es aber durchaus sinnvoll, das Kennwort regelmäßig zu erneuern. Also kann man entweder den „ScavengeInterval“ und die "negative cache period" notfalls anpassen oder man muß dafür sorgen, daß die Clients länger als 15 Minuten im Netzwerk mit DC Zugriff / secure channel angemeldet sind.

Ab und an kommt es bei einigen Kunden von uns dann trotzdem zu Problemen, obwohl die Computerkonten nicht manuell oder per Script zurückgesetzt / deaktiviert / gelöscht wurden und Computer können sich nicht mehr an der Domäne authentifizieren. Die häufigsten Ursachen hierfür sind unserer Erfahrung nach die folgenden:

  • Es wurde zwischenzeitlich ein Computerkonto mit gleichem Namen wie der alte Client im AD aufgenommen. Hier „übernimmt“ der neue Client das Konto – somit ist eine Anmeldung des alten Clients nicht mehr möglich.
  • Es wurde eine autorative Rücksicherung eines Backups durchgeführt, welches das Computerkonto auf einen alten Status zurückgesetzt hat. Somit ist auch das Computerkennwort unter Umständen ein älteres, als jenes welches der Client gespeichert hat. Damit scheitert die Authentifizierung ebenso.
  • Gleiches gilt natürlich bei der Rücksicherung eines Images - hat der Client in der Zwischenzeit nachdem das Image gezogen wurde sein Computerkennwort geändert, ist keine Anmeldung mehr möglich. Ggf. hier also gleich SYSPREP mit einplanen.
  • Funktioniert die Replikation zwischen den DCs der Domäne / des Forests nicht korrekt, kann auch eine Kennwortänderung des Clients nicht repliziert werden. Somit haben unterschiedliche DCs einen anderen Status bzw. einen anderen Versionsstand des Kennworts. Etwaige Replikationsprobleme müssen behoben werden, damit sich die Clients wieder erfolgreich authentifizieren können. (In diesem Zusammenhang gibt es zwar auch eine "n-1" Historie der Computerkennwörter auf dem Client, aber das wird an dieser Stelle bewußt einmal vernachlässigt, um das ganze nicht zu verkomplizieren).

Also – möchte man „ungenutzte“ Computeraccounts deaktivieren oder löschen, sollte man hier Umsicht walten lassen. Fallen dauernd Computerkonten aus dem Raster, weil der Säuberungsintervall von eigenen Scripten zu aggressiv ist, macht man sich schnell mehr Arbeit, als man ohne diesen Aufräumvorgang hätte.

Auf keinen Fall soll die Angabe der Registry Werte in diesem Blog Eintrag ein Aufruf sein, diese zu ändern. ;-) Vielmehr soll es zum Verständnis dienen, welche Prozesse und Grenzwerte hier eine Rolle spielen, um ggf. das eigene Konzept entsprechend anzupassen.

Viele Grüße
Fabian