• administration
  • migration
  • powershell
  • kontakt
  • EN
info@firstattribute.com
by FirstAttribute
Active Directory FAQ Active Directory FAQ
  • administration
  • migration
  • powershell
  • kontakt
  • EN

Active Directory – Account Lockout Policy

Feb 17, 2015 (Letztes Update) | Posted by Jens Künzler | Administration, KnowHow, Tools |

 

Active Directory – Account Lockout Policy

Die Einstellungen in der Account Lockout Policy der Active Directory Default Domain Policy können zu unerwarteten Kontosperrungen führen.

Dieser Beitrag erläutert warum…

 

 

Inhaltsverzeichnis

  • 1 Einstellmöglichkeiten der Account Lockout Policies
    • 1.1 Account Lockout Duration
    • 1.2 Account Lockout Threshold
    • 1.3 Reset Account Lockout counter after
  • 2 Wie funktioniert die Account Lockout Policy?
  • 3 Probleme mit gesperrten Konten
  • 4 Zu langes „OberservationWindow“
 

Einstellmöglichkeiten der Account Lockout Policies

Die Account Lockout Policies sind Bestandteil der Default Domain Policy der Domain und werden hier konfiguriert:

\ Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Account Policies \ Account Lockout Policy

AccountLockouPolicy

 

Die Account Lockout Policy beinhaltet 3 Settings:

Account Lockout Duration

Zeitdauer in Minuten, bis ein gesperrtes Konto automatisch wieder entsperrt wird. Eine Einstellung von 0 Minuten bewirkt, dass der Account nicht automatisch wieder entsperrt wird und ein Administrator tätig werden muss.

Account Lockout Threshold

Anzahl der Fehlversuche, bis ein Konto gesperrt wird. Eine Einstellung von 0 Fehlversuchen (Default) bewirkt, dass nie eine Kontosperrung ausgelöst wird.

Reset Account Lockout counter after

Zeitdauer, bis die Anzahl der Fehlversuche automatisch zurückgesetzt werden.

 

Wie funktioniert die Account Lockout Policy?

Bei einer Eingabe eines falschen Kennworts an einem lokalen Domain Controller (DC) sendet der lokale DC das Kennwort zur endgültigen Prüfung an den PDC Emulator. Kennwortänderungen werden unmittelbar zum PDC Emulator repliziert, sodass der PDC hier die beste Instanz zur Prüfung ist. Stellt der PDC ebenfalls ein falsches Kennwort fest, so werden auf dem DC und dem PDC zwei Werte erfasst:

BadPwdCount +1

BadPasswordTime – aktuelle Uhrzeit

Wird mit der Erhöhung des BadPwdCount die maximal zulässige Anzahl von Fehlversuchen des Settings Account Lockout Threshold überschritten, so wird das Konto gesperrt.

Nachdem die Account Lockout Duration verstrichen ist, wird das Konto wieder aktiviert und der BadPwdCount auf 0 zurückgestzt. Der BadPwdCount wird ebenfalls zurückgesetzt, wenn nach einigen Fehlversuchen ein richtiges Kennwort eingegeben wird oder wenn die Zeitdauer des Reset Account Lockout counter after (ObservationWindow) ohne zwischenzeitlichen erneuten Fehlversuch verstrichen ist.

Probleme mit gesperrten Konten

Zu Problemen mit gesperrten Konten kann es kommen, wenn Programme nach einer falschen Passworteingabe trotzdem mehrere Anmeldeversuche unternehmen oder noch mit alten Credentials laufen, z.B. Scheduled Tasks, getrennte RDP Sitzungen oder manuell verbundene Netzwerklaufwerke.

Um die Ursache zu finden kann es hilfreich sein, den Security Eventlog des DC zu durchsuchen. Hier wird unter anderem auch der Computername registriert, von welchem die Sperrung ausgelöst wurde. In verteilten Umgebungen mit vielen DCs kann dies ein schwieriges Unterfangen werden, da man nicht weiß, auf welchem DC die Sperrung ausgelöst wurde. Hier kann ein kleines Tool von Microsoft helfen: LockOutStatus.exe. LockOutStatus überprüft – wie der Name vermuten lässt – den Lock Out Status eines Accounts auf allen DCs. Somit lässt sich feststellen, auf welchem DC der Account gesperrt wurde und welches Security Eventlog man genauer untersuchen sollte.

Microsoft Download Link: LockOutStatus.exe

Zu langes „OberservationWindow“

Mit allzu strengen Einstellungen können hier seltsame Effekte auftreten. Stellt man zum Beispiel den Account Lockout Threshold auf einen sehr kleinen Wert – wie z.B. „3“ – und den Wert für Reset Account Lockout counter after (ObservationWindow) auf einen sehr hohen Wert, z.B. mehrere Stunden, so kann es zu folgendem Effekt kommen:

Das Attribut BadPwdCount wird nicht repliziert und auf jedem DC separat gezählt. Nehmen wir an, wir hätten 3 DCs und einen PDC Emulator. Ein Fehlversuch auf DC1 wird and den PDC weitergeben. Auch der PDC entscheidet auf „falsches Kennwort“. Danach erfolgt eine erfolgreiche Anmeldung an DC1

DC1 BadPwdCount=0
PDC BadPwdCount=1

Innerhalb des OberservationWindow erfolgt ein weiterer Fehlversuch an DC2 mit Weiterleitung an den PDC. Danach erfolgt eine erfolgreiche Anmeldung an DC2

DC1 BadPwdCount=0
DC2 BadPwdCount=0
PDC BadPwdCount=2

Innerhalb des OberservationWindow erfolgt ein weiterer Fehlversuch an DC3 mit Weiterleitung an den PDC. Danach erfolgt eine erfolgreiche Anmeldung an DC3

DC1 BadPwdCount=0
DC2 BadPwdCount=0
DC3 BadPwdCount=0

Der PDC hat nun einen BadPwdCount=3 und sperrt das Konto

Dies geschieht auch, wenn nach jedem Fehlversuch ein korrektes Passwort eingegeben wurde. Die korrekten Passworteingaben bekommt der PDC schlicht nicht mit. Dies ist ein extremes Beispiel, vielleicht auch etwas an den Haaren herbeigezogen. Ich wollte hiermit die Aufmerksamkeit darauf lenken, dass man sich mit unüberlegten oder zu stregen Richtlinien seltsame Effekte einhandeln kann.

Artikel weiterempfehlen:
  • xingen
  • sharen
  • tweeten
  • teilen
  • Google+
  • mailen
Artikel erstellt am: 05.02.2015
Tags: Account Lockout Policy
0

Leave a Reply

Danke für Ihre Anregungen, Fragen und Hinweise.
Infos zum Datenschutz

Cancel Reply

Neueste Artikel

  • Seltene AD Attribute mit PowerShell setzen
  • OUs einfach exportieren und importieren
  • Tasks per PowerShell anlegen
  • PowerShell Skripte zeitgesteuert ausführen mit Task Scheduler
  • Primäre E-Mail-Adresse ändern mit PowerShell
  • Einfaches Datenmapping mit Calculated Properties (PS)
  • Pester: Test-Framework für PowerShell
  • PowerShell – Gruppen-Manager Berechtigung setzen
  • Outlook 2016 sendet winmail.dat als Anlage
  • O365 Hybrid – Outlook Autodiscover

Links

  • FirstAttribute – AD Consulting
  • FirstAttribute – Migrationen
  • Jobs bei FirstAttribute

Kategorien

  • Administration
  • Citrix
  • Cloud
  • Exchange
  • KnowHow
  • Konfiguration
  • Migration
  • PowerShell
  • Programmierung
  • Quest Migration Manager
  • SharePoint
  • Tools

AD Gruppen dynamisch machen

Schlagwörter

ACL Active Directory AD Objekt azure Azure AD Berechtigung Berechtigungen Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange 2016 Exchange Migration Federation FirstWare Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP lokale Gruppen Microsoft Azure Migration New-ADUser Novell NTFS Office 365 PowerShell QMM QMM Exchange Quest Migration Manager Schema Set-ADUser SharePoint SID SID History SQL Windows 10 Windows Server 2012 R2 ZCM Zenworks

Kontakt aufnehmen

Sie haben eine Frage oder Anmerkung? Schicken Sie uns schnell eine Nachricht.

Nachricht senden
Ohne nachdenken. Active Directory ganz anders. FirstWare IDM-Portal

Folgen Sie uns

Kontakt

  • FirstAttribute AG
  • Hagenheimer Strasse 4, 86928 Hofstetten, Germany
  • +49 89 215 442 400
  • www.firstattribute.com

Schlagwörter

ACL Active Directory AD Objekt azure Azure AD Berechtigung Berechtigungen Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange 2016 Exchange Migration Federation FirstWare Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP lokale Gruppen Microsoft Azure Migration New-ADUser Novell NTFS Office 365 PowerShell QMM QMM Exchange Quest Migration Manager Schema Set-ADUser SharePoint SID SID History SQL Windows 10 Windows Server 2012 R2 ZCM Zenworks

Neue Kommentare

  • Anna Schmitz bei Windows 7 – Geändertes Verhalten beim Verschieben
  • Be Do bei Windows 10 Azure AD Join
  • Steve König bei Powershell – Home Directory anlegen und Berechtigungen vergeben
Login

© 2019 · Active-Directory-FAQ by firstattribute.com

Prev Next