Welcome to TechNet Blogs Sign in | Join | Help

News

  • Haftungsausschluß: Alle Postings / Einträge werden zur Verfügung gestellt, wie sie sind, ohne jede Gewährleistung und ohne, daß daraus Rechte resultieren. Diese Web-Einträge repräsentieren nicht die Gedanken, Absichten, Pläne oder Strategien von Microsoft. Da Web-Einträge lediglich Momentaufnahmen von zum Zeitpunkt des Erscheinens aktuellen Themen sein sollen und keine permanente Referenz, sollten Sie berücksichtigen, daß ältere bzw. veraltete Einträge keine aktuellen Gedanken und Meinungen widerspiegeln.

Interessante MS Blogs

Foren

Schutz vor Account Lockouts auch für andere Konten als “Administrator”?

Hallo, Fabian hier. Neulich habe ich an einer Kundenanfrage gearbeitet, bei der ich feststellen mußte, daß die Antwort bisher nicht besonders gut dokumentiert bzw. in unseren Dokumentationen nicht sonderlich gut herausgearbeitet wurde:

Ist es möglich, neben dem ersten Administrator Konto (standardmäßig mit dem sAMAccountName “Administrator”) einer Windows Server 2003 Domäne, auch andere Benutzerkonten vor Account Lockouts zu schützen?

Um nicht einfach nur “nein” zu sagen, hier ein paar erläuternde Sätze dazu:

Standardmäßig ist das erste Benutzerkonto einer Domäne vor Account Lockouts (deutsch: “Kontosperrungen”) geschützt. D.h. ist auf einer Domäne eine Password Policy (deutsch: “Kennwortrichtlinie”) inklusive Account Lockout Policies (deutsch: “Richtlinie für Kontosperrung”) verknüpft, die beispielsweise nach 10 ungültigen Anmeldeversuchen das entsprechende Benutzerkonto sperrt, ist das “Administrator” Konto (oder mit anderem Namen, falls manuell umbenannt) davor geschützt, bei fehlschlagenden Logins gesperrt zu werden.

Man kann dieses Verhalten zwar auch ändern (siehe http://msdn.microsoft.com/en-us/library/ms679431(VS.85).aspx und http://support.microsoft.com/default.aspx?scid=kb;EN-US;885119), jedoch ist das selbsterklärend nicht immer und in jeder Umgebung uneingeschränkt empfehlenswert. ;-)

Diese “Sperr-Resistenz” ist über den Schutz der RID (also “Relative Identifier” oder in diesem Fall auch “Benutzer ID”) dieses Kontos gewährleistet. Der entsprechende Account hält die RID “500” als letzten Teil seiner SID, so z.B. “S-1-5-21-105687452-965872365-2697845569-500”. Diese RID wird über die Konstante “DOMAIN_USER_RID_ADMIN” mit dem hexadezimalen Wert “0x000001F4” (= dezimal “500”) zur Verfügung gestellt, siehe http://msdn.microsoft.com/en-us/library/cc245516.aspx. Diese Konstante ist hardcoded in der Funktion, die die Account Lockouts für das “Administrator” Benutzerkonto in einer Domäne verhindert, und kann daher nicht verändert werden. Als Konsequenz ist es unter Windows Server 2003 innerhalb einer Domäne nicht möglich, zusätzliche Konten vor dem Account Lockout / der Kontosperrung zu schützen.

Muß man ein solches Account Lockout verhindern, gibt es im Moment zwei Möglichkeiten:

  1. Jede Domäne stellt eine Sicherheitsgrenze dar. Sind also bestimmte Konten besonders schützenswert, kann man diese in einer (Ressourcen-) Domäne erzeugen, die mit einer eigenen Domain Password Policy ausgestattet wird. In dieser Password Policy kann das das Account Lockout abgeschaltet oder die entsprechenden Werte verändert werden.
  2. Unter Windows Server 2008 gibt es die sogenannten “Fine Grained Password Policies”, die eigene Password Policies (und damit auch eigene Account Lockout Einstellungen) für Benutzer oder Globale Gruppen erlauben. Hierfür muß jedoch die Domäne auf den Domänenfunktionsmodus “Windows Server 2008” angehoben werden. Das bedeutet, daß alle DCs dieser Domäne auf Windows Server 2008 laufen müssen.

Sind zusätzlich “schützenswerte” Accounts von Account Lockouts in Windows Server 2003 Umgebungen betroffen, sollten natürlich die Ursachen dafür herausgefunden werden. In manchen Fällen kann es jedoch Hintergründe für die Lockouts geben, die nicht so einfach behoben werden können (oder sollen) und die beiden oben genannten Workarounds keine Alternative darstellen. In diesem Fall wäre eine denkbare “quick & dirty” Lösung, im besten Fall auf dem PDC-Emulator der entsprechenden Domäne je nach Anforderung alle 5 bis 15 Minuten die entsprechenden Accounts per Script, welches als geplanter Task läuft, wieder zu entsperren. Jedoch muß man sich hier im Klaren darüber sein, daß dies keine empfohlene Variante ist, da man sich damit neben einigen Performance-, Replikations- und Überwachungsschwierigkeiten auch eine große Sicherheitslücke in die Umgebung reißen kann.

Viele Grüße, Fabian.

Posted: Monday, July 28, 2008 5:01 PM by dedsFabian
Filed under:

Comments

Tobias said:

Hallo,

vielen dank für den guten Beitrag! Ich habe mal zum Administrator Account eine Frage.

Was macht man denn wenn bei der Umstellung der Domain von NT4 auf Windows 2000 der Administrator Account gelöscht wurde?

Es scheint so das damals aufgrund von vermeindlicher Sicherheit der Administrator in der Domain gelöscht wurde. Es gibt zwar ein paar Domain Administrator Accounts aber keinen Account mit der SID 500 am Ende.

Ist die einzige Möglichkeit eine den Account zu "restoren" eine Migration in eine "neue" Domain oder gibt es andere Weg?

gruß

Tobias

# August 27, 2008 5:39 AM

dedsFabian said:

Hallo Tobias,

normalerweise lassen sich Objekte mit einer RID kleiner „1000“ nicht löschen. Von daher muß etwas „unschönes“ bei der Migration oder danach passiert sein, wenn der Account nicht mehr vorhanden ist.

Es gibt keine offiziell dokumentierte Möglichkeit den ersten Administrator Account neu anzulegen. Auf der sicheren Seite ist man also, wenn man eine Migration in eine neue Domäne / einen neuen Forest vornimmt.

Grundsätzlich ist das Konto jedoch nicht zwangsläufig notwendig. Wenn etwa in der Domäne keine Account Lockout Policies eingesetzt werden, können andere Accounts mit den gewünschten administrativen Rechten ausgestattet werden, so daß das Fehlen des ersten Administrator-Accounts der Domäne nicht weiter „auffällt“. Wenn jedoch Account Lockout Policies eingesetzt werden, macht dieser Account in jedem Fall Sinn, da ansonsten bei einem Angriff alle vorhandenen Accounts „stillgelegt“ werden können.

Viele Grüße, Fabian

# August 27, 2008 9:06 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker