• Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN
info@firstattribute.com
by FirstAttribute
Active Directory FAQActive Directory FAQ
  • Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • 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:
  • teilen
  • tweeten
  • sharen
  • xingen
  • mailen
Artikel erstellt am: 05.02.2015
Tags: Account Lockout Policy
0

Leave a Reply

<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>
Cancel Reply

FirstWare IDM-Portal im Test: IT-Administrator 08-2022

 

ADFAQ-FirstAttribute

Wer schreibt ?

Team der FirstAttribute AG

Consultants und Entwickler der FirstAttribute arbeiten seit mehr als 20 Jahren in IAM- und Cloud-Transition-Projekten.
Zusammen verfügen Sie über einen wertvollen Erfahrungsschatz im Bereich Active Directory und Azure AD und teilen diesen auf Active Directory FAQ.

Neueste Artikel

  • 8 Tipps für mehr Sicherheit in Active Directory und Backups von AD
  • Azure AD Custom Security Attributes ermöglichen flexible Berechtigungsstrukturen
  • Dateiberechtigungen in MS Teams und SharePoint Online verwalten – So funktioniert es
  • AD-Gruppen in Microsoft Teams verwenden – Dynamische Gruppen in der Praxis
  • Verbindung zwischen Microsoft 365 und SharePoint Online zu Azure AD

Unsere IAM-Lösungen

Ihre IAM-Lösung: FirstWare IDM-Portal

 

my-IAM für Cloud Identity Management in Microsoft Teams

Kontakt aufnehmen

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

Nachricht senden
Jetzt AD Tasks vereinfachen und delegieren: FirstWare IDM-Portal

Folgen Sie uns

Kontakt

  • FirstAttribute AG
  • Am Büchele 18, 86928 Hofstetten, Germany
  • +49 89 215 442 400
  • https://www.firstattribute.com

Schlagwörter

.Net ACL Active Directory AD LDS AD Objekt Azure AD Berechtigung Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange-Ordner Exchange-Postfach Exchange Migration Federation FirstWare Get-Mailbox Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP m365 Microsoft Azure Migration New-ADUser Novell NTFS Office 365 PowerShell QMM QMM AD QMM Exchange Quest Migration Manager Schema Set-ADUser SID SID History Update Windows 10 Windows Server 2012 R2

Neueste Kommentare

  • activedirectoryfaq.com sharepoint login - infoslist bei Windows 365 und Azure AD verstehen in Theorie und Praxis
  • Domäne Letzte Anmeldung - ObenGesichert.com bei LastLogon vs. LastLogonTimestamp
  • Teams Code Zur Anmeldung - ObenGesichert.com bei Authentifizierung für MS Teams in hybriden Netzwerken
Login
Impressum
Datenschutzerklärung

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

Prev Next