Kontosperrungsereignis wird auch in Sicherheitsprotokoll auf Domänencontroller gespeichert

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 182918 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D182918
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
182918 Account Lockout Event Also Stored in Security Event Log on Domain Controller


Warnung: Dieser Artikel enthält Informationen zum Bearbeiten der Registrierung. Erstellen Sie eine Sicherungskopie der Dateien System.dat und User.dat (unter Windows Millennium ebenfalls der Datei Classes.dat), bevor Sie die Registrierung bearbeiten. Vergewissern Sie sich, dass Sie die Registrierung wiederherstellen können, falls ein Problem auftritt. Informationen hierzu finden Sie in der integrierten Hilfe der Registrierungseditoren "Regedit.exe" oder "Regedt32.exe". Suchen Sie hier im Index nach "Wiederherstellen der Registrierung" oder nach "Wiederherstellen eines Registrierungsschlüssels". Wenn Sie mit Windows NT oder Windows 2000 arbeiten, sollten Sie zudem Ihre Notfalldiskette (Emergency Recovery Disk - ERD) aktualisieren.
Alles erweitern | Alles schließen

Auf dieser Seite

Problembeschreibung

Wenn Benutzer bei dem Versuch, sich über Domänenkonten bei Windows NT anzumelden, mehrere Male hintereinander ein falsches Kennwort eingeben, sodass der Grenzwert für ungültige Kennworteingaben für das Konto erreicht wird, wird das Konto auf dem Domänencontroller gesperrt.

Windows NT erzeugt ein Kontosperrungsereignis (Ereigniskennung: 539) auf der Arbeitsstation, auf der die fehlgeschlagenen Anmeldeversuche stattgefunden haben, wenn die Überwachungsrichtlinie auf dieser Arbeitsstation das Überwachen fehlgeschlagener Anmelde-/Abmeldeversuche zulässt. Auf dem Domänencontroller wird jedoch kein Ereignis protokolliert. Administratoren müssen die Ereignisprotokolle aller Clientsysteme durchsuchen, um den Computer zu finden, auf dem die fehlerhaften Kennworteingaben erfolgt sind.

Lösung

Vor der Anwendung des Updates

Da dieses Update eine Modifizierung bei der Speicherung der LSA-Dateninformationen auf der Festplatte vornimmt, rät Microsoft von einer späteren Deinstallation des Updates ab. Führen Sie die folgenden Schritte durch, um die Wiederherstellung der Konfiguration vor Anwendung des LSA2-Updates zu erleichtern, falls Probleme mit dem Update auftreten:

  1. Führen Sie eine vollständige Systemsicherung durch.
  2. Führen Sie Rdisk /s aus. Durch Verwenden der Befehlszeilenoption /s mit Rdisk.exe werden die Sam._- und Security._-Datenbanken in den Ordner %Systemroot%\Repair kopiert.
  3. Erstellen Sie unter dem %Systemroot%-Ordner einen temporären Ordner mit dem Namen Lsabackout.
  4. Kopieren Sie die folgenden Dateien vom Ordner %Systemroot\System32 in den Ordner %Systemroot%\Lsabackout, da sie durch das LSA2-Update aktualisiert werden:
    Eventlog.dll
    Lsasrv.dll
    Msaudite.dll
    Msv1_0.dll
    Netcfg.dll
    Samlib.dll
    Samsrv.dll
    Services.exe
    Srvmgr.exe
    Xactsrv.dll
  5. Erstellen Sie eine aktualisierte Notfalldiskette (Emergency Repair Disk, ERD), die die SAM- und Registrierungsinformationen auf der Festplatte im Ordner %Systemroot%\System32\Config aktualisiert.
Installieren Sie das neueste Service Pack für Windows NT 4.0 oder Windows NT Server 4.0, Terminal Server Edition, um dieses Problem zu beheben. Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
152734 How to Obtain the Latest Windows NT 4.0 Service Pack

Hinweis: Dieses Update ersetzt das in den folgenden Artikeln der Microsoft Knowledge Base beschriebene Update:

Artikel-ID: 154087
TITEL : Access Violation in LSASS.EXE Due to Incorrect Buffer Size

Artikel-ID: 174205
TITEL : LSASS May Use a Large Amount of Memory on a Domain Controller

Artikel-ID: 129457
TITEL : Anonymous Connections May Be Able to Obtain the Password Policy


Dieses Update wird steht Ihnen in den Dateien Lsa2fixi.exe (x86) und Lsa2fixa.exe (Alpha) zur Verfügung. Die englischsprachige Version des Nach-SP3-Updates steht auf folgender Internetseite zur Verfügung. Microsoft empfiehlt jedoch, Windows NT 4.0 Service Pack 4 zu installieren und auf diese Weise das Problem zu lösen.

Hinweis: Eine aktualisierte Version dieses Updates, die eine zusätzliche Sicherheitsstufe für Systeme mit Windows NT 4.0 Service Pack 3 bereitstellt, wurde am 20. Juli 1998 ausgegeben.

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/lsa2-fix/

Wenn Sie auf Systemen, bei denen dieses Update angewendet wurde, Systems Management Server ausführen, erzeugt der SNMP-Ereignisprotokollerweiterungs-Agent (Snmpelea) den folgenden Fehler mit der Ereigniskennung 3007:

   Fehler beim Öffnen der Ereignisprotokolldatei SECURITY.
   Das Protokoll wird nicht verarbeitet.
   Der Rückgabecode von OpenEventLog ist 1314.


Der SNMP-Ereignisprotokollerweiterungs-Agent muss aktualisiert werden, um das Sicherheitsprotokoll verwalten zu können. Informationen zum Beheben des Problems mit dem SNMP-Ereignisprotokollerweiterungs-Agenten finden Sie in folgendem Artikel der Microsoft Knowledge Base:

ARTIKEL-ID: 183770
TITEL : SMS: Snmpelea Unable to Open Security Event Log

Weitere Informationen

Microsoft stellt ein Update zur Verfügung, um dieses Verhalten zu ändern. Nachdem das Update auf allen Domänencontrollern angewendet wurde, erzeugen ungültige Kennworteingaben, die zur Sperrung eines Benutzerkontos führen, ein Überwachungsereignis im Sicherheitsprotokoll auf dem primären Domänencontroller und auf dem Domänencontroller, der die Anmeldeanforderung bearbeitet. Es wird ein neues Sicherheitsereignis (Ereigniskennung: 644 - Gesperrtes Benutzerkonto) auf dem primären Domänencontroller erzeugt, um anzuzeigen, dass das Benutzerkonto aufgrund von ungültigen Kennworteingaben automatisch gesperrt wurde. Das Sicherheitsereignis wird erzeugt, wenn die Überwachungsrichtlinie für die Domäne Erfolgsüberwachung für die Kategorie Benutzer- und Gruppenverwaltung zulässt.

Wenn die Clientarbeitsstation mit Windows NT oder Windows 95 arbeitet, enthält das Kontosperrungsereignis den Namen der Clientarbeitsstation, um den Computer zu identifizieren, auf dem die ungültigen Kennwörter eingegeben wurden.

Führen Sie die folgenden Schritte durch, um die Systemkonfiguration vor dem Anwenden des Updates wiederherstellen zu können, wenn Probleme mit dem Update auftreten:

  1. Führen Sie eine vollständige Systemsicherung durch, die Registrierung eingeschlossen. Dieser Sicherungssatz wird nur benötigt, wenn die folgenden Schritte fehlschlagen.
  2. Benennen Sie die folgenden Dateien im Ordner %Systemroot%\System32 um, die durch das Update ersetzt wurden:
    Eventlog.dll
    Lsasrv.dll
    Msaudite.dll
    Msv1_0.dll
    Netcfg.dll
    Samlib.dll
    Samsrv.dll
    Services.exe
    Srvmgr.exe
    Xactsrv.dll
  3. Kopieren Sie die ursprünglichen Versionen dieser Systemdateien vom Ordner %Systemroot%\Lsabackout in den Ordner %Systemroot%\System32.
  4. Starten Sie den Computer mit den Installationsdisketten neu und wählen Sie die Option zum Reparieren des Systems aus.
  5. Deaktivieren Sie alle Optionen außer "Untersuchen der Registrierungsdateien" und fahren Sie fort.
  6. Drücken Sie die [Esc]-Taste, um anzuzeigen, dass Sie die Reparaturinformationen auf der Festplatte verwenden wollen.
  7. Drücken Sie die Eingabetaste, um die Reparatur durchzuführen.
  8. Klicken Sie nur auf SECURITY (Sicherheitsrichtlinie) und SAM (Benutzerkontendatenbank).

    Achtung: Die unkorrekte Verwendung des Registrierungseditors kann schwerwiegende, das gesamte System betreffende Probleme verursachen, die eine Neuinstallierung Ihres Betriebssystems erforderlich machen. Microsoft kann nicht dafür garantieren, dass Probleme, die von einer falschen Verwendung des Registrierungseditors herrühren, behoben werden können. Benutzen Sie den Registrierungseditor auf eigene Verantwortung. Microsoft kann keine Gewährleistungen oder Support für Probleme übernehmen, welche durch eine Manipulation der Windows- oder Windows NT-Registrierung verursacht wurden. Es ist Ihr eigenes Risiko, den Windows- oder Windows NT-Registrierungseditor Regedit.exe oder ähnliche Werkzeuge zur Manipulation der Windows- oder Windows NT-Registrierung zu verwenden.
  9. Starten Sie den Registrierungseditor (Regedt32.exe) und löschen Sie den Schlüssel 184017 aus dem folgenden Registrierungsschlüssel:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix

Status

Microsoft hat bestätigt, dass es sich dabei um ein Problem bei den Microsoft-Produkten handelt, die zu Beginn dieses Artikels aufgeführt sind. Dieses Problem wurde erstmals in Windows NT 4.0, Service Pack 4.0 und Windows NT Server 4.0, Terminal Server Edition, Service Pack 4 behoben.

Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.

Eigenschaften

Artikel-ID: 182918 - Geändert am: Donnerstag, 24. April 2003 - Version: 2.0
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Server 4.0 Enterprise Edition
  • Microsoft BackOffice Small Business Server 4.0
  • Microsoft Windows NT Server 4.0 Terminal Server
Keywords: 
kbbug kbfix kbfea kbwinnt400sp4fea kbwinnt400sp4fix KB182918
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com