Probleme mit Clients, Diensten und Programmen können auftreten, wenn Sie Sicherheitseinstellungen und Benutzerrechte ändern

Zusammenfassung

Sicherheit und Benutzerrechte können in lokalen Richtlinien und Gruppenrichtlinien können Sie die Sicherheit auf Domänencontrollern und Mitgliedscomputern geändert werden. Der Nachteil dieser erhöhten Sicherheit ist jedoch die Einführung Inkompatibilitäten mit Clients, Diensten und Programmen.

Dieser Artikel beschreibt Inkompatibilitäten erfolgen auf Clientcomputer, auf denen Windows XP oder eine frühere Version von Windows ausgeführt werden, wenn Sie spezifischen Benutzerrechte in Windows Server 2003-Domäne oder eine frühere Windows ändern Server-Domäne.

Informationen über Group Policy für Windows 7, Windows Server 2008 R2 und Windows Server 2008 finden Sie in folgenden Artikeln:

  • Windows 7 finden Sie unter

  • Windows 7 und Windows Server 2008 R2 finden Sie unter

  • Windows Server 2008 finden Sie unter

Hinweis: Der verbleibende Inhalt dieses Artikels gilt für Windows XP, Windows Server 2003 und früheren Versionen von Windows.

Windows XP

Um falsch konfigurierte Einstellungen zu sensibilisieren, verwenden Sie das Gruppenrichtlinien-Tool Sicherheit ändern. Bei Verwendung des Gruppenrichtlinienobjekt-Editors werden Benutzerrechte auf folgenden Betriebssystemen verbessert:

  • Windows XP Professional Servicepack 2 (SP2)

  • Windows Server 2003 Servicepack 1 (SP1)

Die verbesserte Funktion ist ein Dialogfeld mit einem Link zu diesem Artikel. Das Dialogfeld wird angezeigt, wenn Sie eine Sicherheitsstufe ändern oder einer Zuweisung von Benutzerrechten, die weniger Kompatibilität und restriktivere Einstellung. Direkt die gleiche Sicherheit Einstellung oder Benutzer Benutzerrechten mithilfe der Registrierung oder mithilfe von Sicherheitsvorlagen ändern, ist der Effekt ändern die Einstellung im Gruppenrichtlinienobjekt-Editor. Das Dialogfeld mit der Verknüpfung zu diesem Artikel wird jedoch nicht angezeigt.

Dieser Artikel enthält Beispiele für Clients, Programme und Vorgänge, die von bestimmten Sicherheitsrichtlinien oder Benutzerrechte betroffen sind. Die Beispiele sind jedoch nicht für alle Microsoft-Betriebssysteme, alle Fremdanbieter Betriebssysteme bzw. alle betroffenen Programmversionen autorisierend. Nicht alle Einstellungen und Benutzerrechte sind in diesem Artikel enthalten.

Wir empfehlen die Kompatibilität des gesamten Sicherheits-Konfiguration in einer Testgesamtstruktur vor Einführung in der Produktion zu überprüfen. Der Testgesamtstruktur muss die Produktionsgesamtstruktur folgt spiegeln:

  • Client und Server Betriebssystemversionen Client und Serverprogramme Service Pack-Versionen Hotfixes Schemaversion Sicherheitsgruppen Gruppenmitgliedschaften, Berechtigungen für Objekte im Dateisystem, freigegebene Ordner, Registrierungsschlüssel, Active Directory-Verzeichnisdienst Service, lokale Gruppenrichtlinien und Objekts zählen Typ und Speicherort

  • Administrative Aufgaben, die ausgeführt werden, Verwaltungstools, mit denen und Verwaltungsaufgaben verwendete Betriebssysteme

  • Vorgänge, die ausgeführt werden, wie die folgenden:

    • Computer und Benutzeranmeldeauthentifizierung

    • Das Zurücksetzen von Kennwörtern durch Benutzer, Computer und Administratoren

    • Durchsuchen

    • Festlegen von Berechtigungen für das Dateisystem, gemeinsame für Ordner, für die Registrierung und für Active Directory-Ressourcen mit ACL-Editor in allen Client-Betriebssystemen in allen oder die Ressourcengruppe Domänen von Client-Betriebssystemen aus allen Konto oder Ressource Domänen

    • Verwaltung und nicht administrative drucken

Windows Server 2003 SP1

Warnung in Gpedit.msc

Damit werden Kunden darauf hingewiesen, dass sie ein Benutzerrecht bearbeiten oder Sicherheitsoption, die sich negativ auf das Netzwerk auswirken, wurden zwei Warnung Mechanismen gpedit.msc hinzugefügt. Wenn Administratoren ein Benutzerrecht bearbeiten, die das gesamte Unternehmen beeinträchtigen können, sehen sie ein neues Symbol, das Text ein ähnelt. Sie erhalten zudem eine Warnung, die eine Verknüpfung zu Microsoft Knowledge Base-Artikel 823659. Der Text dieser Meldung lautet wie folgt:

Diese Einstellung kann die Kompatibilität mit Clients, Dienste und Programme auswirken. Weitere Informationen finden Sie unter < Benutzerrechte oder Sicherheitsoptionen Benutzeroption geändert > (Q823659) Wenn Sie über einen Link in Gpedit.msc zu diesem Knowledge Base-Artikel weitergeleitet wurden, unbedingt lesen und verstehen die Erklärung und die mögliche Auswirkung dieser Einstellung ändern. Im folgenden werden Benutzerrechte, die den Warnungstext enthalten:

  • Auf diesen Computer vom Netzwerk

  • Lokal anmelden

  • Auslassen der durchsuchenden Überprüfung

  • Computer und Benutzer für vertrauenswürdige Delegierung aktivieren

Im folgenden werden die Sicherheitsoptionen, die die Warnung und ein Popup-Meldung:

  • Domänenmitglied: Digital verschlüsseln Sie oder signieren Sie (immer) Daten des sicheren Kanals

  • Domänenmitglied: Erfordern starken (Windows 2000 oder höher) Sitzungsschlüssel

  • Domänencontroller: LDAP-Server Anforderungen signieren

  • Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)

  • Netzwerkzugriff: Anonyme Sid können Name Übersetzung

  • Netzwerkzugriff: Lassen Sie keine anonyme Aufzählung von SAM-Konten und Freigaben zu

  • Sicherheit: LAN Manager-Authentifizierungsebene

  • Audit: Fahren Sie System zu Sicherheits-Audits protokolliert

  • Netzwerkzugriff: LDAP-Client Anforderungen signieren

Weitere Informationen

Die folgenden Abschnitte beschreiben Inkompatibilitäten, die auftreten können, wenn Sie Einstellungen in Windows NT 4.0, Windows 2000-Domänen und Windows Server 2003-Domänen ändern.

Benutzerrechte

Folgende beschreibt ein Benutzerrecht, bezeichnet die Einstellungen, die Probleme verursachen beschreibt, warum das Benutzerrecht gelten und warum das Benutzerrecht entfernen möchten, und enthält Beispiele für Kompatibilitätsprobleme, die auftreten können, wenn der Benutzer rechts wird konfiguriert.

  1. Auf diesen Computer vom Netzwerk

    1. Hintergrund

      Interaktion mit entfernten Windows-Computern ist das Benutzerrecht auf diesen Computer vom Netzwerk erforderlich. Die Beispiele für solche Netzwerkbetrieb:

      • Active Directory-Replikation zwischen Domänencontrollern in einer gemeinsamen Domäne oder Gesamtstruktur

      • Authentifizierungsanfragen auf Domänencontroller von Benutzern und Computern

      • Zugriff auf freigegebene Ordner, Drucker und andere Systemdienste auf remote-Computern im Netzwerk



      Benutzern, Computern und Dienstkonten gewinnen oder verlieren das Benutzerrecht auf diesen Computer vom Netzwerk explizit oder implizit hinzugefügt oder aus einer Sicherheitsgruppe, die dieses Benutzerrecht gewährt wurde entfernt. Beispielsweise ein Benutzerkonto oder ein Computerkonto kann explizit hinzugefügt werden eine benutzerdefinierte Sicherheitsgruppe oder integrierten Sicherheitsgruppe Administrator oder implizit durch das Betriebssystem zu einer vordefinierten Sicherheitsgruppe, wie Domänen-Benutzer, hinzugefügt werden authentifiziert Benutzer oder Domänencontroller der Organisation.

      Standardmäßig werden Benutzer- und Computerkonten gewährt den Zugriff auf diesen Computer vom Netzwerk richtig berechnet wie jeder oder authentifizierte Benutzer und für Domänencontroller die Gruppe Domänencontroller Benutzergruppen , in das Gruppenrichtlinienobjekt (GPO) für Standarddomänencontroller definiert sind.

    2. Risikoreiche Konfigurationen

      Folgende sind schädliche Konfigurationen:

      • Dieses Benutzerrecht entfernen Domänencontroller Sicherheitsgruppe

      • Entfernen die Gruppe Authentifizierte Benutzer oder eine explizite Gruppe, Benutzern, Computern und Dienstkonten die Berechtigung über das Netzwerk eine Verbindung zu Computern

      • Entfernen alle Benutzer und Computer aus diesem Benutzerrecht

    3. Gründe zum gewähren dieses Benutzerrechts

      • Das Benutzerrecht auf diesen Computer vom Netzwerk aus Gruppe Domänencontroller erteilen entspricht Authentifizierung Vorschriften, die Active Directory-Replikation für die Replikation zwischen Domänencontrollern in derselben Gesamtstruktur.

      • Dieses Benutzerrecht ermöglicht Benutzern und Computern Dateien, Drucker und Systemdienste, einschließlich Active Directory zugreifen.

      • Dieses Benutzerrecht ist für Benutzer Zugriff auf Ihre e-Mail mit frühen Versionen von Microsoft Outlook Web Access (OWA) erforderlich.

    4. Gründe für das Entfernen dieses Benutzerrechts

      • Benutzer ihre Computer mit dem Netzwerk verbinden können können Ressourcen auf Remotecomputern zugreifen, denen sie für Berechtigungen. Dieses Benutzerrecht ist beispielsweise für Benutzer mit freigegebenen Druckern oder Ordnern herstellen. Wenn dieses Benutzerrecht, jeder gewährt wird Gruppe und haben einige freigegebene Ordner sowohl Freigabe-als auch NTFS-Berechtigungen so konfiguriert, dass die gleiche Gruppe Lesezugriff verfügt jeder kann Dateien in den freigegebenen Ordnern. Dies ist jedoch eine unwahrscheinliche Situation bei einer Neuinstallation von Windows Server 2003, da die standardmäßigen Freigabe- und NTFS-Berechtigungen in Windows Server 2003 nicht die Gruppe "Jeder" enthalten. Für Systeme, die von Microsoft Windows NT 4.0 oder Windows 2000 aktualisiert diese Sicherheitslücke ein höheres Risiko möglicherweise weil die standardmäßigen Freigabe- und Dateisystemberechtigungen für diese Betriebssysteme nicht so restriktiv wie die Standardberechtigungen in WindowsServer 2003.

      • Es gibt keinen gültigen Grund Domänencontroller Gruppe aus diesem Benutzerrecht entfernt.

      • Die Gruppe wird in der Regel für die Gruppe Authentifizierte Benutzer entfernt. Wenn die Gruppe Jeder entfernt wird, muss die Gruppe Authentifizierte Benutzer dieses Benutzerrecht gewährt.

      • Windows NT 4.0-Domänen auf Windows 2000 aktualisiert explizit Benutzer Zugriff auf diesen Computer vom Netzwerk Recht der Gruppe Jeder die Gruppe Authentifizierte Benutzer oder Domänencontroller Gruppe gewährt keine. Daher beim Entfernen die Gruppe Jeder aus Windows NT 4.0-Domänenrichtlinie, Active Directory-Replikation fehl mit Fehlermeldung "Zugriff verweigert" nach der Aktualisierung auf Windows 2000. Winnt32.exe in Windows Server 2003 vermeidet diese Fehlkonfiguration, Domänencontroller der Organisation Gruppe dieses Benutzerrecht während der Aktualisierung von Windows NT 4.0 primäre Domänencontroller (PDCs) gewährt. Erteilen Sie der Gruppe Domänencontroller dieses Benutzerrecht, wenn es nicht im Gruppenrichtlinien-Editor vorhanden ist.

    5. Beispiele für Kompatibilitätsprobleme

      • Windows 2000 und WindowsServer 2003: Replikation der folgenden Partitionen fehl mit Fehler "Zugriff verweigert" von Überwachungstools wie REPLMON und REPADMIN oder Replikation im Ereignisprotokoll gemeldet.

        • Active Directory-Schema-partition

        • Konfigurationspartition

        • Domänenpartition

        • Globaler Katalog partition

        • Anwendungspartition

      • Alle Microsoft-Netzwerkbetriebssysteme: Authentifizierung von Clientcomputern Remotenetzwerk schlägt fehl, wenn der Benutzer oder eine Sicherheitsgruppe, denen der Benutzer Mitglied dieses Benutzerrecht gewährt wurde.

      • Alle Microsoft-Netzwerkbetriebssysteme: Kontoauthentifizierung von remote-Netzwerkclients schlägt fehl, wenn das Konto oder die Sicherheitsgruppe, der das Konto gehört dieses Benutzerrecht gewährt wurde. Dieses Szenario betrifft Benutzerkonten, Computerkonten und Dienstkonten.

      • Alle Microsoft-Netzwerkbetriebssysteme: Entfernen aller Konten aus diesem Benutzerrecht verhindern jedes Konto die Domäne anmelden oder auf Netzwerkressourcen zugreifen. Berechnet wie Domänencontroller müssen jeder und authentifizierte Benutzer entfernt werden, Sie explizit gewähren dieses Benutzerrecht Konten oder Sicherheitsgruppen, die das Konto Mitglied der remote-Computer über das Netzwerk zugreifen. Dieses Szenario betrifft alle Benutzerkonten, Computerkonten und Dienstkonten.

      • Alle Microsoft-Netzwerkbetriebssysteme: Der lokale Administrator verwendet ein "leeres" Kennwort. Netzwerkkonnektivität mit leeren Kennwörtern darf nicht für Administratorkonten in einer domänenumgebung. Mit dieser Konfiguration können Sie erwarten eine Fehlermeldung "Zugriff verweigert".

  2. Lokal anmelden zulassen

    1. Hintergrund

      Benutzer, die sich an der Konsole eines Windows-Computers anmelden möchten (mithilfe der Tastenkombination STRG + ALT + ENTF) und Konten, die einen Dienst starten müssen lokale Anmeldeberechtigungen auf dem Host-Computer. Lokale Anmeldung gehören Administratoren auf den Konsolen von Mitgliedscomputern oder Domänencontrollern in der Organisation Benutzer anmelden, die Mitgliedscomputer auf ihren Desktops mit anmelden nicht-privilegierte Konten. Benutzer, die eine Remotedesktopverbindung oder die Terminaldienste verwenden müssen Lokal anmelden zulassen auf Zielcomputern, die Windows 2000 oder Windows XP ausgeführt werden, da diese Anmeldemodi als lokal auf dem Host-Computer betrachtet werden. Benutzer, die auf einem Server anmelden, dass Terminaldiensten und nicht über dieses Benutzerrecht verfügen kann weiterhin eine interaktive Remotesitzung in Windows Server 2003-Domänen haben das Benutzerrecht Anmelden über Terminaldienste zulassen .

    2. Risikoreiche Konfigurationen

      Folgende sind schädliche Konfigurationen:

      • Administrativen Sicherheitsgruppen, einschließlich Kontenoperatoren, Sicherungsoperatoren, Druckoperatoren oder Server-Operatoren und der integrierten Administratorgruppe entfernt die Standarddomänencontroller Richtlinie.

      • Entfernen von Dienstkonten, die von Komponenten und Programmen auf Mitgliedscomputern und Domänencontrollern in der Domäne der Standarddomänencontroller Richtlinie verwendet werden.

      • Entfernen von Benutzern oder Sicherheitsgruppen, die in der Konsole von Mitgliedscomputern in der Domäne anmelden.

      • Entfernen von Dienstkonten, die in der lokalen Datenbank der Sicherheitskontenverwaltung (Security Accounts Manager, SAM) von Mitgliedscomputern oder Arbeitsgruppencomputern definiert sind.

      • Entfernen nicht erstellt-Administratorkonten, die über Terminaldienste authentifizieren, die auf einem Domänencontroller ausgeführt wird.

      • Hinzufügen aller Benutzerkonten in der Domäne explizit oder implizit über jeder Gruppe die lokale Anmeldung verweigern anmelden rechts. Diese Konfiguration verhindert Benutzer bei beliebigen Mitgliedscomputern oder Domänencontrollern in der Domäne anmelden.

    3. Gründe zum gewähren dieses Benutzerrechts

      • Benutzer müssen das Benutzerrecht Lokal anmelden zulassen auf der Konsole oder den Desktop Arbeitsgruppencomputer, ein Computer oder ein Domänencontroller.

      • Benutzer müssen dieses Benutzerrecht Anmeldung über eine Terminaldienste-Sitzung, die auf einem Windows 2000-Mitgliedscomputer oder Domänencontroller ausgeführt wird.

    4. Gründe für das Entfernen dieses Benutzerrechts

      • Fehler beim Konsolenzugriff auf berechtigte Benutzerkonten beschränkt führen unbefugte herunterladen und Ausführen von bösartigem Code die Benutzerrechte zu ändern.

      • Entfernen des Benutzerrecht Lokal anmelden zulassen wird die unberechtigte Anmeldung auf Konsolen von Computern, wie beispielsweise Domänencontrollern oder Anwendungsservern verhindert.

      • Entfernen dieses Anmelderechts wird verhindert, dass nicht-Domänenkonten auf der Konsole von Mitgliedscomputern in der Domäne anmelden.

    5. Beispiele für Kompatibilitätsprobleme

      • Windows 2000 terminal Servern: Das Benutzerrecht Lokal anmelden zulassen ist erforderlich für Benutzer, die Windows 2000-Terminalserver anmelden.

      • Windows NT 4.0, Windows 2000, Windows XP oder WindowsServer 2003: Benutzerkonten müssen bewilligt dieses Benutzerrecht Anmeldung an der Konsole von Computern, die Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden.

      • Windows NT 4.0 und höher: Auf Computern, die Windows NT 4.0 ausgeführt, wenn der Lokal anmelden zulassen , jedoch implizit oder explizit hinzugefügt werden auch die Berechtigung lokale Anmeldung verweigern Anmeldung Konten dürfen sich an der Konsole der Domäne Domänencontroller.

  3. Auslassen der durchsuchenden Überprüfung

    1. Hintergrund

      Das Benutzerrecht Auslassen der durchsuchenden Überprüfung kann der Benutzer Ordner in das NTFS-Dateisystem oder die Registrierung durchsuchen ohne für die spezielle Berechtigung Ordner durchsuchen . Das Benutzerrecht Auslassen der durchsuchenden Überprüfung lässt nicht den Benutzer die Inhalte eines Ordners auflistet. Es ermöglicht dem Benutzer nur die Ordner durchlaufen.

    2. Risikoreiche Konfigurationen

      Folgende sind schädliche Konfigurationen:

      • Entfernen von nicht-Administratorkonten, die auf Windows 2000 Terminaldienste-Computer Windows Server 2003-basierten Terminal Services, die Zugriffsberechtigungen für Dateien und Ordner im Dateisystem nicht anmelden

      • Entfernt die Gruppe Jeder aus der Liste der Sicherheitsprinzipale, die dieser Benutzer standardmäßig rechts. Windows-Betriebssysteme und auch viele Programme mit der Erwartung dienen, wer hat den Computer zugreifen können das Benutzerrecht Auslassen der durchsuchenden Überprüfung muss. Daher kann jeder entfernen Gruppe aus der Liste der Sicherheitsprinzipale, die standardmäßig dieses Benutzerrecht können zu einer Instabilität des Betriebssystems oder einem Programmfehler führen. Es empfiehlt sich, diese Einstellung den Standardwert belassen.

    3. Gründe zum gewähren dieses Benutzerrechts

      Die Standardeinstellung für das Benutzerrecht Auslassen der durchsuchenden Überprüfung werden alle Auslassen der durchsuchenden Überprüfung zugelassen. Für erfahrene Windows-Systemadministratoren ist dies das erwartete Verhalten und sie Systemzugriffssteuerungslisten (SACLs) entsprechend konfigurieren. Das einzige Szenario, in dem die Standardkonfiguration zu Missverständnissen führen, ist Administrator Berechtigungen konfiguriert Verhalten nicht bekannt und erwartet, dass Benutzer einen übergeordneten Ordner Zugriff auf den Inhalt eines Kindes nicht Ordner.

    4. Gründe für das Entfernen dieses Benutzerrechts

      Um Zugriff auf die Dateien oder Ordner im Dateisystem zu verhindern, können Organisationen Sicherheit sehr ernst verführen Entfernen der Gruppe oder der Gruppe aus der Liste der Gruppen, Auslassen der durchsuchenden Überprüfung Benutzerrecht.

    5. Beispiele für Kompatibilitätsprobleme

      • Windows 2000 und WindowsServer 2003: Wenn Benutzerrecht Auslassen der durchsuchenden Überprüfung auf Computern mit Windows 2000 oder Windows Server 2003 falsch konfiguriert oder entfernt wird, werden Gruppenrichtlinien im Ordner "SYVOL" nicht zwischen Domänencontrollern in der Domäne repliziert.

      • Windows 2000, Windows XP Professional, WindowsServer 2003: Computer mit Windows 2000, Windows XP Professional oder Windows Server 2003 protokolliert Ereignisse 1000 und 1202 und werden nicht Computerrichtlinie und Benutzerrichtlinie anwenden, wenn die erforderliche Dateisystemberechtigungen aus der SYSVOL-Struktur entfernt werden die umgehen durchsuchenden Überprüfung Benutzerrecht entfernt oder falsch konfiguriert.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        Ereignis-IDs 1000 und 1001 wird alle fünf Minuten im Anwendungsprotokoll protokolliert.
         

      • Windows 2000 und WindowsServer 2003: Auf Computern mit Windows 2000 oder Windows Server 2003, verschwindet die Registerkarte Kontingent in Windows Explorer, wenn Eigenschaften für ein Volume anzeigen.

      • Windows 2000: Nicht-Administratoren, die Windows 2000-Terminalserver anmelden möglicherweise die folgende Fehlermeldung angezeigt:

        Fehler der Anwendung Userinit.exe. Die Anwendung konnte nicht richtig initialisiert 0xc0000142 klicken Sie auf OK um die Anwendung zu beenden.

      • Windows NT 4.0, Windows 2000, Windows XP, WindowsServer 2003: Benutzer, auf deren Computern Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden möglicherweise nicht auf freigegebene Ordner oder Dateien in freigegebenen Ordnern zugreifen und sie erhalten Fehlermeldungen "Zugriff verweigert", wenn sie nicht die erteilt umgehen durchsuchen Überprüfen Recht.


        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        Fehlermeldung "Zugriff verweigert", wenn Benutzer versuchen, auf freigegebene Ordner zugreifen
         

      • Windows NT 4.0: Auf Windows NT 4.0-Computern verursacht entfernen das Benutzerrecht Auslassen der durchsuchenden Überprüfung kopieren Dateistreams löschen. Wenn Sie dieses Benutzerrecht entfernen, eine Datei von einem Windows-Client oder einem Macintosh-Client auf einen Windows NT 4.0-Domänencontroller kopiert wird, die Dienste für Macintosh ausgeführt wird, ist des Ziel-Dateistreams verloren und die Datei wird als nur-Text-Datei.

      • Microsoft Windows 95, Microsoft Windows 98: Auf einem Clientcomputer mit Windows 95 oder Windows 98 die mit net * / home Befehl fehl mit Fehlermeldung "Zugriff verweigert", wenn die Gruppe Authentifizierte Benutzer das Benutzerrecht Auslassen der durchsuchenden Überprüfung nicht gewährt wird.

      • Outlook Web Access: Nicht-Administratoren nicht Microsoft Outlook Web Access anmelden, und sie erhalten eine Fehlermeldung "Zugriff verweigert", wenn sie das Benutzerrecht Auslassen der durchsuchenden Überprüfung nicht gewährt werden.

Sicherheit

Die folgende Liste enthält eine Sicherheitsrichtlinie und verschachtelte Liste enthält eine Beschreibung der Sicherheitsstufe bezeichnet die Einstellungen, die beschreibt, warum Sie sollten die Sicherheitsstufe anwenden und beschreibt dann die Gründe Warum Probleme verursachen Sie können die Sicherheitsstufe entfernen möchten. Die verschachtelte Liste enthält dann einen symbolischen Namen für die Sicherheitsstufe und den Registrierungspfad Sicherheitsstufe. Schließlich dienen Beispiele für Kompatibilitätsprobleme, die auftreten können, wenn die Sicherheitsrichtlinie konfiguriert ist.

  1. Audit: Fahren Sie System zu Sicherheits-Audits protokolliert

    1. Hintergrund

      • Die Überwachung: fahren Sie System zu Sicherheits-Audits protokolliert legt fest, ob das System heruntergefahren wird, wenn Sicherheitsereignisse protokollieren kann. Diese Einstellung ist erforderlich für das Trusted Computer Security Evaluation Kriterien (TCSEC) Programm C2-Überprüfung und Common Criteria for Information Technology Security Evaluation, überwachbare Ereignisse zu verhindern, wenn das System Diese Ereignisse protokollieren kann. Überwachungssystem auftritt, das System heruntergefahren und eine Stop-Fehlermeldung angezeigt.

      • Wenn der Computer Ereignisse im Sicherheitsprotokoll aufzeichnen kann, Nachweise oder Informationen zur Problembehandlung zur Überprüfung nach einem Sicherheitsvorfall möglicherweise nicht.

    2. Risikoreiche Konfiguration

      Folgende gefährliche konfiguriert ist: die Audit: System sofort zu heruntergefahren Einstellung ist aktiviert, und die Größe des Sicherheitsprotokolls wird durch die (Protokoll manuell löschen) Ereignisse nicht überschreiben Option oder die Option Ereignisse überschreiben bei Bedarf die Option Ereignisse überschreiben Anzahl Tage älter in der Ereignisanzeige. Siehe Abschnitt "Beispiele für Kompatibilitätsprobleme" Informationen zu bestimmten Risiken für Computer, die die ursprüngliche Version von Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 oder Windows 2000 SP3 ausgeführt werden.

    3. Gründe zum Aktivieren dieser Einstellung

      Wenn der Computer Ereignisse im Sicherheitsprotokoll aufzeichnen kann, Nachweise oder Informationen zur Problembehandlung zur Überprüfung nach einem Sicherheitsvorfall möglicherweise nicht.

    4. Gründe zum Deaktivieren dieser Einstellung

      • Aktivieren der überwachen: fahren Sie System zu Sicherheits-Audits protokolliert Einstellung reagiert das System, wenn aus irgendeinem Grund eine Sicherheitswarnmeldung protokolliert werden. Ein Ereignis kann nicht in der Regel protokolliert werden, wird das Sicherheitsprotokoll voll ist und als Speichermethode der Option (Protokoll manuell löschen) Ereignisse nicht überschreiben oder Ereignisse überschreiben Anzahl Tage älter ist.

      • Der Verwaltungsaufwand aktivieren die Audit: fahren Sie System zu Sicherheits-Audits protokolliert Einstellung kann sehr hoch sein, insbesondere wenn Sie auch die Option nicht überschreiben (Protokoll manuell löschen) Ereignisse für das Sicherheitsprotokoll aktivieren. Diese Einstellung bietet für individuelle Verantwortlichkeit Operator Aktionen. Beispielsweise konnte ein Administrator Berechtigungen für alle Benutzer, Computer und Gruppen in einer Organisationseinheit (OU), in dem die Überwachung aktiviert wurde das integrierte Administratorkonto oder anderes freigegebenes Konto, zurücksetzen und, dieser Berechtigungen zurücksetzen verweigern. Jedoch verringert ermöglicht das Festlegen die Stabilität des Systems, da ein Server durch Überfluten mit Anmeldeereignissen und anderen Sicherheitsereignissen, die in das Sicherheitsprotokoll geschrieben Herunterfahren gezwungen werden kann. Da das Herunterfahren nicht ordnungsgemäß erfolgt, kann darüber hinaus Schäden an das Betriebssystem, Programme oder Daten führen. NTFS garantiert, dass die Integrität einer unvermittelten Herunterfahren verwaltet wird, können sie garantieren, dass jede Datendatei für jedes Programm noch Format beim Neustart des Systems werden.

    5. Symbolische Namen:

      "CrashOnAuditFail"

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

    7. Beispiele für Kompatibilitätsprobleme

      • Windows 2000: Aufgrund eines Fehlers können Computern mit der Originalversion von Windows 2000, Windows 2000 SP1, Windows 2000 SP2 oder Windows Server SP3 Protokollierung vor der Größe mehr, die in der Option Maximalgröße für die Sicherheit das Ereignisprotokoll ist erreicht. Dieser Fehler wird in Windows 2000 Service Pack 4 (SP4). Stellen Sie sicher, dass die Windows 2000-Domänencontrollern Windows 2000 Service Pack 4 installiert, bevor Sie sollten Sie diese Einstellung aktivieren.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        das Ereignisprotokoll beendet, Ereignisse vor dem Erreichen der Maximalgröße
         

      • Windows 2000 und WindowsServer 2003: Computer mit Windows 2000 oder Windows Server 2003 reagiert, und dann können spontan neu starten, wenn die Audit: System sofort zu Herunterfahren Einstellung aktiviert ist, das Sicherheitsprotokoll ist voll, und vorhandene Eintrag im Ereignisprotokoll kann nicht überschrieben werden. Beim Neustart des Computers wird die folgende Stop-Fehlermeldung angezeigt:

        STOP: C0000244 {Überwachung fehlgeschlagen}
        Fehler beim Generieren eine Sicherheitswarnmeldung.

        Zum Wiederherstellen muss Administrator anmelden, das Sicherheitsprotokoll archivieren (optional) das Sicherheitsprotokoll löschen und dann diese Option zurücksetzen (optional und Bedarf).

      • Microsoft Network Client für MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, WindowsServer 2003: Nicht-Administratoren, die an einer Domäne anmelden werden die folgende Fehlermeldung angezeigt:

        Ihr Konto konfiguriert Sie mit diesem Computer verhindern. Versuchen Sie einen anderen Computer.

      • Windows 2000: Windows 2000-Computern nicht-Administratoren nicht RAS-Servern anmelden und erhalten sie eine Fehlermeldung ähnlich der folgenden:

        Unbekannte Benutzer oder falsches Kennwort

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        -Fehlermeldung: Ihr Konto konfiguriert Sie mit diesem Computer verhindern
         

      • Windows 2000: Auf Windows 2000-Domänencontrollern Intersite Messaging-Dienst (Ismserv.exe) beendet und kann nicht neu gestartet werden. DCDIAG meldet den Fehler "Failed Test Services ISMserv", und Ereignis-ID 1083 wird im Ereignisprotokoll registriert.

      • Windows 2000: Windows 2000-Domänencontroller Active Directory-Replikation fehl, und eine Meldung "Zugriff verweigert" wird angezeigt, wenn das Sicherheitsprotokoll voll ist.

      • Microsoft Exchange 2000: Servern mit Exchange 2000 werden nicht die Informationsspeicher-Datenbank bereitstellen und Ereignis 2102 wird im Ereignisprotokoll registriert.

      • Outlook, Outlook Web Access: Nicht-Administratoren nicht auf ihre e-Mail-Nachrichten über Microsoft Outlook oder Microsoft Outlook Web Access zugreifen, und sie erhalten einen Fehler 503.

  2. Domänencontroller: LDAP-Server Anforderungen signieren

    1. Hintergrund

      Die Domänencontroller: LDAP-Server Signieren Vorschriften festgelegt, ob Lightweight Directory Access Protocol (LDAP) Server LDAP-Clients zu Datensignatur erfordert. Die möglichen Werte für diese Einstellung sind:

      • Keine: Datensignatur muss nicht mit dem Server verbinden. Wenn der Client Datensignaturen anfordert, wird dies vom Server unterstützt.

      • Signatur erforderlich: Die LDAP-Datensignatur Option muss ausgehandelt werden, außer Transport Layer Security/Secure Socket Layer (SSL/TLS).

      • nicht definiert: Diese Einstellung ist nicht aktiviert oder deaktiviert.

    2. Risikoreiche Konfigurationen

      Folgende sind schädliche Konfigurationen:

      • In einer Umgebung aktivieren Signatur erforderlich , wo Clients keine LDAP-Signierung unterstützen oder, clientseitige LDAP-Signierung auf dem Client nicht aktiviert ist

      • Windows 2000 oder Windows Server 2003 Hisecdc.inf Sicherheitsvorlage in einer Umgebung anwenden, wobei die Clients keine LDAP-Signierung unterstützen oder, clientseitige LDAP-Signierung nicht aktiviert ist

      • Windows 2000 oder Windows Server 2003 Hisecws.inf Sicherheitsvorlage in einer Umgebung anwenden, wobei die Clients keine LDAP-Signierung unterstützen oder, clientseitige LDAP-Signierung nicht aktiviert ist

    3. Gründe zum Aktivieren dieser Einstellung

      Nicht signierter Netzwerkverkehr ist anfällig für Man-in-the-Middle-Angriffe, ein Eindringling Pakete zwischen Client und Server abfängt, die Pakete modifiziert und anschließend an den Server weiterleitet. Wenn dieses auf einem LDAP-Server Verhalten könnte ein Angreifer bewirken, einen Server zu, die auf falschen Abfragen vom LDAP-Client basieren. Sie können dieses Risiko in einem Unternehmensnetzwerk senken, indem Sie strenge physische Sicherheitsmaßnahmen zum Schutz die Netzwerkinfrastruktur implementieren. Internet Protocol Security (IPSec) Header-Authentifizierungsmodus kann Man-in-the-Middle-Angriffe verhindern. Header-Authentifizierungsmodus führt die gegenseitige Authentifizierung und Integrität des Pakets für IP-Datenverkehr.

    4. Gründe zum Deaktivieren dieser Einstellung

      • Clients, die keine LDAP-Signierung dürfen LDAP-Abfragen auf Domänencontrollern und in globalen Katalogen ausführen, wenn NTLM-Authentifizierung ausgehandelt wird und die richtigen Servicepacks für Windows 2000-Domänencontroller nicht installiert sind.

      • Netzwerk-Spuren von LDAP-Datenverkehr zwischen Clients und Servern verschlüsselt werden. Dies erschwert die LDAP-Kommunikation zu.

      • Windows 2000-basierten Servern benötigen Windows 2000 Service Pack 3 (SP3) oder sie bei Programmen unterstützen LDAP-Signaturen von Clientcomputer unter Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt. Für Weitere Informationen klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

        Windows 2000-Domänencontroller müssen Servicepack 3 oder höher bei Einsatz der Windows Server 2003-Verwaltungsprogramme
         

    5. Symbolische Namen:

      LDAPServerIntegrity

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

    7. Beispiele für Kompatibilitätsprobleme

      • Einfache Bindung schlägt fehl und Sie erhalten die folgende Fehlermeldung angezeigt:

        Fehler Ldap_simple_bind_s(): starke Authentifizierung erforderlich.

      • Windows 2000 Service Pack 4, Windows XP, WindowsServer 2003: Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 einige Active Directory-Verwaltungstools funktioniert nicht richtig für Domänencontroller, die Versionen von Windows 2000 vor Service Pack 3 Wenn NTLM Authentifizierung wird ausgehandelt.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        Windows 2000-Domänencontroller müssen Servicepack 3 oder höher bei Einsatz der Windows Server 2003-Verwaltungsprogramme
         

      • Windows 2000 Service Pack 4, Windows XP, WindowsServer 2003: Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 einige Active Directory-Verwaltungstools, Ziel sind Domänencontroller, auf denen Versionen von Windows 2000 vor SP3 nicht korrekt sind mit IP-Adressen (z. B. "dsa.msc/Server =xxxx",
        xxxx ist eine IP-Adresse).


        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        Windows 2000-Domänencontroller müssen Servicepack 3 oder höher bei Einsatz der Windows Server 2003-Verwaltungsprogramme
         

      • Windows 2000 Service Pack 4, Windows XP, WindowsServer 2003: Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 einige Active Directory-Verwaltungstools, Ziel sind Domänencontroller, auf denen Versionen von Windows 2000 vor SP3 nicht korrekt funktioniert.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        Windows 2000-Domänencontroller müssen Servicepack 3 oder höher bei Einsatz der Windows Server 2003-Verwaltungsprogramme
         

  3. Domänenmitglied: Starker Sitzungsschlüssel (Windows 2000 oder höher) erforderlich

    1. Hintergrund

      • Die Domänenmitglied: Starker Sitzungsschlüssel (Windows 2000 oder höher) erforderlich legt fest, ob ein sicherer Kanal mit einem Domänencontroller hergestellt werden kann, der keinen starken 128-Bit-Sitzungsschlüssel für sicheren Kanalverkehr verwendet. Durch Aktivieren dieser Einstellung verhindert die Einrichtung eines sicheren Kanals zu einem Domänencontroller, die Daten des sicheren Kanals mit einem starken Schlüssel verschlüsseln kann. Durch Deaktivieren dieser Einstellung kann 64-Bit-Sitzungsschlüssel.

      • Vor dem Aktivieren dieser Einstellung auf einer Mitgliedsarbeitsstation oder einem Server müssen alle Domänencontroller in der Domäne, zu der der Member gehört Daten des sicheren Kanals mit einem starken, 128-Bit-Schlüssel verschlüsseln können. Dies bedeutet, dass diese Domänencontroller Windows 2000 oder höher ausgeführt werden müssen.

    2. Risikoreiche Konfiguration

      Aktivieren der Domänenmitglied: Starker Sitzungsschlüssel (Windows 2000 oder höher) erforderlich schädliche konfiguriert ist.

    3. Gründe zum Aktivieren dieser Einstellung

      • Zu sicheren Kommunikationskanal zwischen den Mitgliedscomputern und Domänencontrollern verwendeten Sitzungsschlüssel sind in Windows 2000 viel stärker als in früheren Versionen von Microsoft-Betriebssystemen sind.

      • Es möglich ist, wird eine gute Idee zu dieser Sitzungsschlüssel stärker zu sicheren Kommunikationskanal Abhören und Session hijacking-Netzwerkangriffen schützen. Lauschangriffe sind böswillige Angriffe, in denen Daten gelesen oder bei der Übertragung geändert. Die Daten können ausblenden oder den Absender ändern oder es umleiten geändert werden.

      Wichtig Ein Computer mit Windows Server 2008 R2 oder Windows 7 unterstützt starke Schlüssel, wenn sichere Kanäle verwendet werden. Diese Einschränkung verhindert, dass eine Vertrauensstellung zwischen jeder Windows NT 4.0-Domäne und jeder Windows Server 2008 R2-basierten Domäne. Diese Einschränkung verhindert außerdem die Windows NT 4.0-basierten Domänenmitgliedschaft der Computer mit Windows 7 oder Windows Server 2008 R2 und umgekehrt.

    4. Gründe zum Deaktivieren dieser Einstellung

      Die Domäne enthält Mitgliedscomputer, die Betriebssysteme Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden.

    5. Symbolische Namen:

      StrongKey

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

    7. Beispiele für Kompatibilitätsprobleme

      Windows NT 4.0: Windows NT 4.0-Computern tritt beim Zurücksetzen der sicheren Kanäle von Vertrauensstellungen zwischen Windows NT 4.0 und Windows 2000-Domänen mit NLTEST. Fehlermeldung "Zugriff verweigert" angezeigt wird:

      Die Vertrauensstellung zwischen der primären Domäne und der vertrauenswürdigen Domäne ist fehlgeschlagen.

      Windows 7 und Server 2008 R2: Für Windows 7 und höher und Windows Server 2008 R2 und höher wird diese Einstellung nicht mehr berücksichtigt und starke Schlüssel immer verwendet. Daher funktionieren mit Windows NT 4.0-Domänen nicht mehr.

  4. Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals

    1. Hintergrund

      • Aktivieren von Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals verhindert die Einrichtung eines sicheren Kanals zu einem Domänencontroller, die nicht signiert oder verschlüsselt alle Daten des sicheren Kanals. Authentifizierungsverkehr vor Man-in-the-Middle-Angriffen, Replay-Angriffen und anderen Arten von Netzwerkangriffen zu schützen erstellen Windows-Computer einen Kommunikationskanal, der als sicherer Kanal durch den Anmeldedienst bezeichnet Computerkonten zu authentifizieren. Sichere Kanäle werden außerdem verwendet, wenn ein Benutzer in einer Domäne zu einer Netzwerkressource in einer remote-Domäne herstellt. Diese Domänen Authentifizierung oder Durchsatzauthentifizierungermöglicht einen Windows-basierten Computer, der einer Domäne auf die Benutzerkontodatenbank in seiner Domäne und in vertrauenswürdigen Domänen zugreifen.

      • So aktivieren Sie die Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals auf einem Computer einrichten, alle Domänencontroller in der Domäne gehört, dürfen signieren oder Verschlüsseln von Daten des sicheren Kanals. Dies bedeutet, dass diese Domänencontroller Windows NT 4.0 mit Service Pack 6a ausgeführt werden müssen (SP6a) oder höher.

      • Aktivieren der Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals automatisch ermöglicht die Domänenmitglied: digital verschlüsseln oder signieren (wenn möglich) Daten des sicheren Kanals festlegen.

    2. Risikoreiche Konfiguration

      Aktivieren der Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals Einstellung in Domänen, in denen nicht alle Domänencontroller signieren oder Verschlüsseln von Daten des sicheren Kanals können, schädliche konfiguriert ist.

    3. Gründe zum Aktivieren dieser Einstellung

      Nicht signierter Netzwerkverkehr ist anfällig für Man-in-the-Middle-Angriffe, in denen ein Eindringling Pakete zwischen dem Server und dem Client abfängt und modifiziert, bevor sie an den Client weitergeleitet. Tritt dieses Verhalten auf einem Server Lightweight Directory Access Protocol (LDAP), könnte der Angreifer einen Client zu, die auf falschen Datensätzen aus dem LDAP-Verzeichnis. Sie können das Risiko eines solchen Angriffs auf ein Unternehmensnetzwerk senken, indem Sie strenge physische Sicherheitsmaßnahmen zum Schutz die Netzwerkinfrastruktur implementieren. Zusätzlich kann Implementierung von Internet Protocol Security (IPSec) Authentifizierung zum Man-in-the-Middle-Angriffe zu verhindern. Dieser Modus führt die gegenseitige Authentifizierung und Integrität des Pakets für IP-Datenverkehr.

    4. Gründe zum Deaktivieren dieser Einstellung

      • Computer in lokalen oder externen Domänen unterstützen verschlüsselte sichere Kanäle.

      • Nicht alle Domänencontroller in der Domäne müssen die entsprechenden Service Packs installiert, die verschlüsselte sichere Kanäle unterstützen.

    5. Symbolische Namen:

      StrongKey

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

    7. Beispiele für Kompatibilitätsprobleme

      • Windows NT 4.0: Windows 2000-Computern nicht Windows NT 4.0-Domänen beitreten und erhalten die folgende Fehlermeldung angezeigt:

        Das Konto darf nicht von dieser Station aus anmelden.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        -Fehlermeldung: das Konto ist nicht berechtigt, von dieser Arbeitsstation aus anzumelden
         

      • Windows NT 4.0: Windows NT 4.0-Domänen werden keine untergeordnete Vertrauensstellung mit einer Windows 2000-Domäne einrichten und erhalten die folgende Fehlermeldung angezeigt:

        Das Konto darf nicht von dieser Station aus anmelden.

        Vorhandene untergeordnete Vertrauensstellungen authentifiziert Benutzer aus der vertrauenswürdigen Domäne können auch nicht. Einige Benutzer möglicherweise Probleme beim Anmelden an der Domäne, und sie erhalten eine Fehlermeldung, die besagt, dass der Client die Domäne finden kann.

      • Windows XP: Windows XP-Clients, die Windows NT 4.0-Domänen angehören, werden keine Anmeldeversuche authentifizieren und möglicherweise die folgende Fehlermeldung angezeigt, oder möglicherweise die folgenden Ereignisse im Ereignisprotokoll registriert:

        Windows kann nicht der Domäne herstellen, da der Domänencontroller nicht verfügbar ist oder nicht verfügbar oder das Computerkonto nicht gefunden wurde

      • Microsoft Network: Microsoft Network-Clients erhalten eine der folgenden Fehlermeldungen angezeigt:

        Anmeldung fehlgeschlagen: Unbekannte Benutzername oder ungültiges Kennwort.

        Es ist kein Sitzungsschlüssel für die angegebene Sitzung.

  5. Microsoft Network Client: Kommunikation digital signieren (immer)

    1. Hintergrund

      Server Message Block (SMB) ist die gemeinsame Nutzung von Ressourcen Protokoll, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Grundlage von Network basic Input/Output System (NetBIOS) und viele andere Protokolle. SMB-Signatur authentifiziert den Benutzer und der Server, auf dem die Daten gehostet. Seitlich der Authentifizierungsprozess fehlschlägt, wird keine Datenübertragung statt.

      Aktivieren von SMB-Signaturen beginnt während der SMB-Protokollaushandlung. Die SMB-Signatur-Richtlinien bestimmen, ob der Computer Client-Kommunikation immer digital signiert.

      Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Gegenseitige Authentifizierung schließt ein "Man-in-the-Middle"-Angriffe. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft, Angriffe zu verhindern. Geben Sie diese Authentifizierung, stellt SMB-Signaturen eine digitale Signatur in jeden SMB. Client und Server Überprüfen der digitalen Signatur.

      Verwendung von SMB-Signaturen müssen SMB-Signaturen aktivieren oder SMB-Signaturen auf dem SMB-Client und SMB-Server erforderlich. Wenn SMB-Signaturen auf einem Server Clients aktiviert ist, auch für die SMB-Signierung verwenden Paketsignatur Protokoll in allen nachfolgenden Sitzungen aktiviert sind. Wenn SMB-Signaturen auf einem Server erforderlich ist, kann kein Client einer Sitzung, wenn der Client aktiviert oder als verbindlich festgelegt.


      Aktivieren von digitalen Signaturen in Hochsicherheitsnetzwerken verhindert Identitätswechsel von Clients und Servern gespeichert hat. Diese Art von Identitätswechseln ist als Session hijackingbezeichnet. Ein Angreifer mit Zugriff auf demselben Netzwerk wie der Client oder der Server verwendet Session hijacking-Tools zu unterbrechen, zu beenden oder eine laufende Sitzung zu stehlen. Ein Angreifer konnte abfangen ändern unsignierte SMB-Pakete, den Verkehr modifizieren und anschließend weiterleiten, sodass der Server eventuell unerwünschte Aktionen ausführt. Oder der Angreifer kann nach einer rechtmäßigen Authentifizierung als Server oder Client ausgeben und nicht autorisierten Zugriff auf Daten verschaffen.

      Das SMB-Protokoll für die Dateifreigabe und Druckerfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 unterstützt die gegenseitige Authentifizierung. Gegenseitige Authentifizierung schließt Session hijacking-Angriffe und Authentifizierung von Nachrichten unterstützt. Daher verhindert Man-in-the-Middle-Angriffe. SMB-Signierung ermöglicht diese Authentifizierung durch eine digitale Signatur in jedes SMB-Paket platziert. Der Client und der Server überprüfen die Signatur.

      Hinweise

      • Eine alternative Gegenmaßnahme können Sie digitale Signaturen mit IPSec zum Schutz aller Netzwerkverkehr aktivieren. Hardware-basierte Beschleuniger für IPSec-Verschlüsselung und Signierung, mit denen Sie zu Leistungseinbußen von der Server-CPU, gibt. Es gibt keine solche Beschleunigerkarten für SMB-Signaturen zur Verfügung stehen.

        Weitere Informationen finden Sie auf der Microsoft MSDN-Website im Kapitel .

        Konfigurieren Sie die SMB-Signierung durch Gruppenrichtlinien-Editor, da eine Änderung auf einen lokalen Wert keine Auswirkung, hat ist eine überschreibende Domänenrichtlinie.

      • In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client SMB-Signatur, wenn sie mit Windows Server 2003-Server mit NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signatur, wenn sie mit Servern authentifizieren, die NTLMv2-Authentifizierung verwenden. Windows 2000 Server reagieren außerdem nicht auf SMB-Signierung Anfragen von Clients. Weitere Informationen finden Sie in Artikel 10: "Sicherheit: Lan Manager-Authentifizierungsebene."

    2. Risikoreiche Konfiguration

      Folgende gefährliche konfiguriert ist: beide verlassen der Microsoft Network Client: Kommunikation digital signieren (immer) Einstellung und Microsoft Network Client: Kommunikation digital signieren (Wenn Server zustimmt) auf festgelegt " Nicht definiert"oder deaktiviert. Den Redirector Klartextkennwörter an Microsoft SMB-Server senden, die Verschlüsselung von Kennwörtern bei der Authentifizierung nicht unterstützen können.

    3. Gründe zum Aktivieren dieser Einstellung

      Aktivieren von Microsoft Network Client: Kommunikation digital signieren (immer) Clients müssen SMB-Verkehr signieren, wenn Sie Server kontaktieren, die keine SMB-Signaturen. Dadurch wird Kunden weniger anfällig für Session hijacking-Angriffe.

    4. Gründe zum Deaktivieren dieser Einstellung

      • Aktivieren von Microsoft Network Client: Kommunikation digital signieren (immer) verhindert, dass Clients mit Zielservern, die keine SMB-Signaturen unterstützen.

      • Konfigurieren von Computern alle nicht signierte SMB-Kommunikation ignoriert verhindert, dass frühere Betriebssysteme und Programme verbinden.

    5. Symbolische Namen:

      RequireSMBSignRdr

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

    7. Beispiele für Kompatibilitätsprobleme

      • Windows NT 4.0: Nicht sicheren Kanal einer Vertrauensstellung zwischen einer Windows Server 2003-Domäne und einer Windows NT 4.0-Domäne mit NLTEST oder NETDOM zurücksetzen werden, und Sie erhalten eine Fehlermeldung "Zugriff verweigert".

      • Windows XP: Dateien von Windows XP können Clients auf Windows 2000 Server und Windows Server 2003-basierten Servern länger dauern.

      • Keinem Netzlaufwerk von einem Client durch Aktivieren dieser Einstellung werden, und Sie erhalten die folgende Fehlermeldung angezeigt:

        Das Konto darf nicht von dieser Station aus anmelden.

    8. Neustart

      Starten Sie den Computer oder den Arbeitsstationsdienst neu. Geben Sie hierzu die folgenden Befehle in einer Eingabeaufforderung ein. Nach der Eingabe jedes Befehls die EINGABETASTE.

      Net Stop workstation
      Net Start workstation

  6. Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)

    1. Hintergrund

      • Server Messenger Block (SMB) ist die gemeinsame Nutzung von Ressourcen Protokoll, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Grundlage von Network basic Input/Output System (NetBIOS) und viele andere Protokolle. SMB-Signatur authentifiziert den Benutzer und der Server, auf dem die Daten gehostet. Seitlich der Authentifizierungsprozess fehlschlägt, wird keine Datenübertragung statt.

        Aktivieren von SMB-Signaturen beginnt während der SMB-Protokollaushandlung. Die SMB-Signatur-Richtlinien bestimmen, ob der Computer Client-Kommunikation immer digital signiert.

        Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Gegenseitige Authentifizierung schließt ein "Man-in-the-Middle"-Angriffe. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft, Angriffe zu verhindern. Geben Sie diese Authentifizierung, stellt SMB-Signaturen eine digitale Signatur in jeden SMB. Client und Server Überprüfen der digitalen Signatur.

        Verwendung von SMB-Signaturen müssen SMB-Signaturen aktivieren oder SMB-Signaturen auf dem SMB-Client und SMB-Server erforderlich. Wenn SMB-Signaturen auf einem Server Clients aktiviert ist, auch für die SMB-Signierung verwenden Paketsignatur Protokoll in allen nachfolgenden Sitzungen aktiviert sind. Wenn SMB-Signaturen auf einem Server erforderlich ist, kann kein Client einer Sitzung, wenn der Client aktiviert oder als verbindlich festgelegt.


        Aktivieren von digitalen Signaturen in Hochsicherheitsnetzwerken verhindert Identitätswechsel von Clients und Servern gespeichert hat. Diese Art von Identitätswechseln ist als Session hijackingbezeichnet. Ein Angreifer mit Zugriff auf demselben Netzwerk wie der Client oder der Server verwendet Session hijacking-Tools zu unterbrechen, zu beenden oder eine laufende Sitzung zu stehlen. Ein Angreifer kann abfangen und unsignierte Pakete Subnetz Bandbreite Manager (SBM) ändern, den Verkehr modifizieren und weiterleiten, sodass der Server eventuell unerwünschte Aktionen ausführt. Oder der Angreifer kann nach einer rechtmäßigen Authentifizierung als Server oder Client ausgeben und nicht autorisierten Zugriff auf Daten verschaffen.

        Das SMB-Protokoll für die Dateifreigabe und Druckerfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 unterstützt die gegenseitige Authentifizierung. Gegenseitige Authentifizierung schließt Session hijacking-Angriffe und Authentifizierung von Nachrichten unterstützt. Daher verhindert Man-in-the-Middle-Angriffe. SMB-Signierung ermöglicht diese Authentifizierung durch eine digitale Signatur in jedes SMB-Paket platziert. Der Client und der Server überprüfen die Signatur.

      • Eine alternative Gegenmaßnahme können Sie digitale Signaturen mit IPSec zum Schutz aller Netzwerkverkehr aktivieren. Hardware-basierte Beschleuniger für IPSec-Verschlüsselung und Signierung, mit denen Sie zu Leistungseinbußen von der Server-CPU, gibt. Es gibt keine solche Beschleunigerkarten für SMB-Signaturen zur Verfügung stehen.

      • In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client SMB-Signatur, wenn sie mit Windows Server 2003-Server mit NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signatur, wenn sie mit Servern authentifizieren, die NTLMv2-Authentifizierung verwenden. Windows 2000 Server reagieren außerdem nicht auf SMB-Signierung Anfragen von Clients. Weitere Informationen finden Sie in Artikel 10: "Sicherheit: Lan Manager-Authentifizierungsebene."

    2. Risikoreiche Konfiguration

      Folgt einer schädlichen Einstellung: Aktivieren der Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) auf Servern und auf Domänencontrollern, die nicht kompatibel mit Windows-basierten Computern und von Drittanbietern zugreifen Betriebssystem-Clientcomputern in lokalen oder externen Domänen.

    3. Gründe zum Aktivieren dieser Einstellung

      • Alle Client-Computer, mit denen diese Einstellung direkt über die Registrierung oder über eine Gruppenrichtlinie unterstützen SMB-Signaturen. Alle Clientcomputer, die Einstellung führen also entweder Windows 95 mit dem Verzeichnisdienste-Client, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional oder Windows Server 2003.

      • Wenn Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) wird deaktiviert, SMB-Signaturen zur Verfügung. Deaktivierung aller SMB-verlässt Signieren Computer anfälliger für Session hijacking-Angriffe.

    4. Gründe zum Deaktivieren dieser Einstellung

      • Durch Aktivieren dieser Einstellung verursachen Datei kopieren und Netzwerk langsamer auf Client Computer.

      • Durch Aktivieren dieser Einstellung werden Clients verhindern, die SMB-Signaturen mit Servern und Domänencontrollern aushandeln können. Hierdurch können Vorgänge wie Domänenbeitritte, Benutzer- und Computerauthentifizierung oder Netzwerkzugriff durch Programme fehlschlagen.

    5. Symbolische Namen:

      RequireSMBSignServer

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

    7. Beispiele für Kompatibilitätsprobleme

      • Windows 95: Windows 95-Clients, die nicht den Directory Services (DS)-Client installiert Anmeldeauthentifizierung fehl und die folgende Fehlermeldung erhalten:

        Das eingegebene Kennwort ist nicht korrekt, oder der Zugriff auf den Anmeldeserver wurde verweigert.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        -Fehlermeldung beim Client für Windows 95 oder Windows NT 4.0 auf Windows Server 2003-Domäne anmelden
         

      • Windows NT 4.0: Clientcomputer, auf denen Versionen von Windows NT 4.0 werden vor Service Pack 3 (SP3) Anmeldeauthentifizierung fehl, wird die folgende Fehlermeldung angezeigt:

        Das System konnte Sie nicht anmelden. Stellen Sie sicher, dass Benutzername und Domäne korrekt sind, und geben Ihr Kennwort erneut.

        Einige Microsoft SMB-Server unterstützen nur einen nicht verschlüsselten Kennwortaustausch während der Authentifizierung. (Ein solcher Austausch auch bekannt als "nur Text"-Austausch.) Für Windows NT 4.0 SP3 und höher sendet SMB-Redirector nicht Unverschlüsseltes Kennwort während der Authentifizierung mit einem SMB-Server, wenn Sie einen bestimmten Registrierungseintrag hinzufügen.
        Um unverschlüsselte Kennwörter für den SMB-Client auf Windows NT 4.0 SP3 und neueren Systemen zu aktivieren, ändern Sie die Registrierung wie folgt: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters

        Wertname: EnablePlainTextPassword

        Datentyp: REG_DWORD

        Daten: 1


        Weitere Informationen zu verwandten Themen klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

        -Fehlermeldung: Systemfehler 1240 ist aufgetreten. Das Konto darf nicht von dieser Arbeitsstation aus anzumelden.

      • WindowsServer 2003: Standardmäßig sind Sicherheitsrichtlinien auf Domänencontrollern, die Windows Server 2003 ausführen konfiguriert um Domain Controller Kommunikation abgefangen oder manipuliert durch böswillige Benutzer zu verhindern. Damit Benutzer erfolgreich mit einem Domänencontroller kommunizieren, die Windows Server 2003 ausgeführt wird, müssen Clientcomputer sowohl SMB-Signaturen und Verschlüsselung oder Signaturen für sichere Kanäle Datenverkehr verwenden. Standardmäßig müssen führen Windows NT 4.0 mit Service Pack 2 (SP2) oder früher installiert Clients und Clients unter Windows 95 nicht SMB-Paketsignatur aktiviert. Deshalb diese Clients auf Windows Server 2003-Domänencontroller authentifiziert möglicherweise nicht.

      • Richtlinien für Windows 2000 und Windows Server 2003: Je nach Konfiguration und spezifische Installation benötigt wird empfohlen, die folgenden Richtlinien an die niedrigste Entität erforderlichen Umfang in der Microsoft Management Console Gruppenrichtlinien-Editor-Snap-in Hierarchie:

        • Computer Computerkonfiguration\Windows-Einstellungen\sicherheitseinstellungen\sicherheitsoptionen

        • Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden (diese Einstellung ist für Windows 2000)

        • Microsoft Network Client: Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden (diese Einstellung ist für Windows Server 2003)


        Hinweis Einige Drittanbieter-CIFS-Server wie älteren Samba-Versionen können nicht verschlüsselte Kennwörter verwenden.

      • Die folgenden Clients sind inkompatibel mit der Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) festlegen:

        • Apple Computer, Inc., Mac OS X-clients

        • Microsoft MS-DOS-Netzwerk-Clients (z. B. Microsoft LAN Manager)

        • Microsoft Windows für Workgroups-clients

        • Microsoft Windows 95-Clients ohne den Verzeichnisdienste-Client installiert

        • Microsoft Windows NT 4.0-Computer ohne SP3 oder höher installiert

        • Novell Netware 6 CIFS-clients

        • SAMBA SMB-Clients, die keine Unterstützung für SMB-Signaturen

    8. Neustart

      Starten Sie den Computer oder den Serverdienst neu. Geben Sie hierzu die folgenden Befehle in einer Eingabeaufforderung ein. Nach der Eingabe jedes Befehls die EINGABETASTE.

      Net Stop server
      Net Start server

  7. Netzwerkzugriff: anonyme SID-Name Verschiebung zulassen

    1. Hintergrund

      Die Netzwerkzugriff: anonyme SID-Name Übersetzung ermöglichen festgelegt, ob ein anonymer Benutzer ID Nummer SID (Security) Attribute für einen anderen Benutzer anfordern kann.

    2. Risikoreiche Konfiguration

      Aktivieren der Netzwerkzugriff: anonyme SID-Name Übersetzung ermöglichen schädliche konfiguriert ist.

    3. Gründe zum Aktivieren dieser Einstellung

      Wenn die Netzwerkzugriff: anonyme SID-Name Übersetzung ermöglichen ist deaktiviert, früheren Betriebssystemen oder Programme möglicherweise nicht mit Windows Server 2003-Domänen kommunizieren. Beispielsweise funktionieren folgende Betriebssysteme, Dienste oder Programme nicht:

      • Windows NT 4.0-basierten RAS-Servern

      • Microsoft SQL Server, die auf Windows NT 3.x-Computern oder Windows NT 4.0-Computern ausgeführt werden

      • RAS-Dienst, der auf Windows 2000-Computer ausgeführt wird, die in Windows NT 3.x-Domänen oder Windows NT 4.0-Domänen befinden

      • SQL Server, die auf Windows 2000-Computer ausgeführt wird, die in Windows NT 3.x oder Windows NT 4.0-Domänen befinden

      • Erteilen von Zugriffsberechtigungen für Dateien, freigegebene Ordner und Registrierungsobjekte Benutzerkonten aus Kontendomänen, die Windows Server 2003-Domänencontroller enthalten möchten Benutzer in Windows NT 4.0-Ressourcendomäne

    4. Gründe zum Deaktivieren dieser Einstellung

      Wenn diese Einstellung aktiviert ist, können ein böswilliger Benutzer die bekannte Administrator-SID den tatsächlichen Namen des integrierten Administratorkontos abzurufen, selbst wenn dieses Konto umbenannt wurde. Diese Person dann können den Kontonamen erraten Angriff initiieren.

    5. Symbolischen Namen: N/A

    6. Pfad: Keine. Der Pfad wird im Code der Benutzeroberfläche angegeben.

    7. Beispiele für Kompatibilitätsprobleme

      Windows NT 4.0: Computer unter Windows NT 4.0-Ressourcendomänen Fehlermeldung "Unbekanntes Konto" im ACL-Editor anzeigt, wenn Ressourcen, einschließlich freigegebener Ordner, Dateien und Registrierungsobjekte, mit Sicherheitsprinzipalen geschützt sind, die sich in Kontendomänen, die enthalten Sie Windows Server 2003-Domänencontroller.

  8. Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben

    1. Hintergrund

      • Die Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben Einstellung bestimmt, welche zusätzlichen Berechtigungen für anonyme Verbindung mit dem Computer erteilt werden. Windows gestattet anonymen Benutzern bestimmte Aktivitäten, wie die Namen der Workstation und Server Sicherheitskontenverwaltung (Security Accounts Manager, SAM) und Netzwerkfreigaben auflisten. Beispielsweise können ein Administrator diese Benutzern in einer vertrauenswürdigen Domäne Zugriff gewähren, die keine gegenseitige Vertrauensstellung unterhält. Sobald eine Sitzung erstellt wird, müssen ein anonymer Benutzer dieselbe Zugriffsrechte, die jeder erteilt, Gruppe basierend auf der Einstellung in der Netzwerkzugriff: lassen Sie "Jeder"-Berechtigungen für anonyme Benutzer festlegen oder die freigegebene Zugriffssteuerungsliste (DACL) des das Objekt.

        Normalerweise werden anonyme Verbindung von früheren Versionen von Clients (kompatible Clients) während der Einrichtung einer SMB-Sitzung angefordert. In diesen Fällen wird eine Netzwerk-Trace, dass der Client-Redirector 0xFEFF in Windows 2000 oder 0xCAFE in Windows NT RPC auch versucht, eine anonyme Verbindung zu SMB-Prozess-ID (PID) ist.

      • Wichtig Diese Einstellung hat keine Auswirkung auf den Domänencontrollern. Auf Domänencontrollern wird dieses Verhalten durch das Vorhandensein von "NT-AUTORITÄT\ANONYMOUS-Anmeldung" im "Prä-Windows 2000 kompatibler Zugriff" gesteuert.

      • In Windows 2000 existiert eine ähnliche Einstellung Einschränkungen für anonymen Namen des Registrierungswertes RestrictAnonymous . Dieser Wert ist wie folgt

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA Weitere Informationen zum Registrierungswert "RestrictAnonymous" finden Sie in den folgenden zu Artikeln der Microsoft Knowledge Base:

        zum Verwenden des Registrierungswertes RestrictAnonymous in Windows 2000
         

        Beschränken der Informationen für anonym angemeldete Benutzer
         

    2. Risikoreiche Konfigurationen

      Aktivieren der Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben ist eine gefährliche Einstellung hinsichtlich Kompatibilität. Das Deaktivieren ist gefährlich in Bezug auf die Sicherheit.

    3. Gründe zum Aktivieren dieser Einstellung

      Ein nicht autorisierter Benutzer kann anonym auflisten und anhand dieser Informationen Kennwörter erraten oder Social Engineering -Angriffe auszuführen. Social Engineering ist Jargon, das bedeutet Täuschung Personen Offenlegung ihrer Kennwörter oder andere Sicherheitsinformationen.

    4. Gründe zum Deaktivieren dieser Einstellung

      Wenn diese Einstellung aktiviert ist, ist es unmöglich, Vertrauensstellungen mit Windows NT 4.0-Domänen einzurichten. Durch diese Einstellung wird auch Probleme mit älteren Clients (z. B. Windows NT 3.51-Clients und Windows 95-Clients), die versuchen, Ressourcen auf dem Server.

    5. Symbolische Namen:


      RestrictAnonymousSAM

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

    7. Beispiele für Kompatibilitätsprobleme

    • SMS werden keine Betriebssystem-Informationen und schreibt "Unbekannt" in der Erkennungsdatensatzes-Eigenschaft.

    • Windows 95, Windows 98: Windows 95- und Windows 98-Clients werden nicht ihre Kennwörter ändern können.

    • Windows NT 4.0: Windows NT 4.0-Computern nicht authentifiziert werden können.

    • Windows 95, Windows 98: Windows 95- und Windows 98-basierten Computern werden nicht von Microsoft-Domänencontrollern authentifiziert werden.

    • Windows 95, Windows 98: Benutzer von Windows 95- und Windows 98-Computern werden keine Kennwörter für Benutzerkonten ändern.

  9. Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben

    1. Hintergrund

      • Die Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben Einstellung (auch als RestrictAnonymousbezeichnet) bestimmt, ob anonyme Aufzählung Sicherheitskontenverwaltung (Security Accounts Manager, SAM) und Freigaben erlaubt wird. Windows gestattet anonymen Benutzern bestimmte Aktivitäten, wie das Aufzählen der Namen von Domänenkonten (Benutzer, Computer und Gruppen) und Netzwerkfreigaben. Dies empfiehlt sich beispielsweise, wenn ein Administrator Benutzern in einer vertrauenswürdigen Domäne, die keine gegenseitige Vertrauensstellung unterhält, Zugriff gewähren möchte. Wenn Sie keine anonyme Aufzählung von SAM-Konten und Freigaben zulassen möchten, aktivieren Sie diese Einstellung.

      • In Windows 2000 existiert eine ähnliche Einstellung Einschränkungen für anonymen Namen des Registrierungswertes RestrictAnonymous . Die Position dieses Werts lautet wie folgt:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

    2. Risikoreiche Konfiguration

      Aktivieren der Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben schädliche konfiguriert ist.

    3. Gründe zum Aktivieren dieser Einstellung

      • Aktivieren der Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben Einstellung verhindert die Aufzählung von SAM-Konten und Freigaben durch Benutzer und Computer, die anonyme Konten verwenden.

    4. Gründe zum Deaktivieren dieser Einstellung

      • Wenn diese Einstellung aktiviert ist, kann ein nicht autorisierter Benutzer anonym auflisten und anhand dieser Informationen Kennwörter erraten oder Social Engineering -Angriffe auszuführen. Social Engineering ist Jargon, das bedeutet Täuschung Personen ihr Kennwort oder andere Informationen preiszugeben.

      • Wenn diese Einstellung aktiviert ist, werden nicht mit Windows NT 4.0-Domänen hergestellt. Diese Einstellung verursacht außerdem Probleme mit untergeordneten Clients wie Windows NT 3.51 und Windows 95-Clients, die versuchen, Ressourcen auf dem Server.

      • Es werden Benutzern von Ressourcendomänen Zugriff gewähren, weil Administratoren in der vertrauenden Domäne nicht Listen der Konten in der Domäne aufgelistet werden können. Benutzer, die anonym auf Datei- und Druckserver zugreifen werden nicht können die freigegebenen Netzwerkressourcen auf diesen Servern. Die Benutzer müssen authentifizieren, bevor sie die Listen von freigegebenen Ordnern und Druckern anzeigen können.

    5. Symbolische Namen:

      "RestrictAnonymous"

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

    7. Beispiele für Kompatibilitätsprobleme

      • Windows NT 4.0: Benutzer dürfen ihre Kennwörter auf Windows NT 4.0-Arbeitsstationen ändern, wenn RestrictAnonymous auf Domänencontrollern in der Domäne des Benutzers aktiviert ist.

      • Windows NT 4.0: Hinzufügen von Benutzern oder globalen Gruppen aus vertrauenswürdigen Windows 2000-Domänen zu lokalen Gruppen von Windows NT 4.0 im Benutzer-Manager schlägt fehl und die folgende Fehlermeldung angezeigt:

        Zurzeit die Anmeldung Anforderung zur Verfügung.

      • Windows NT 4.0: Windows NT 4.0-Computern können nicht während der Installation oder der Domäne beitreten-Benutzeroberfläche Domänen beitreten.

      • Windows NT 4.0: Einrichten einer untergeordneten Vertrauensstellung mit Windows NT 4.0-Ressourcendomänen schlägt fehl. Folgende Fehlermeldung wird angezeigt, wenn RestrictAnonymous auf die vertrauenswürdige Domäne aktiviert ist:

        Domänencontroller konnte für diese Domäne nicht gefunden werden.

      • Windows NT 4.0: Benutzer, die Windows NT 4.0 Terminal Server-Computern anmelden werden das Standardbasisverzeichnis anstelle des Basisverzeichnisses zugeordnet, die im Benutzer-Manager für Domänen definiert ist.

      • Windows NT 4.0: Windows NT 4.0-Reservedomänencontroller (BDCs) dürfen den Anmeldedienst starten, eine Liste der Sicherungssuchdienste oder die SAM-Datenbank von Windows 2000 oder Windows Server 2003-Domänencontroller in derselben Domäne zu synchronisieren.

      • Windows 2000: Windows 2000-Mitgliedscomputer in Windows NT 4.0-Domänen nicht Drucker in externen Domänen anzeigen, wenn die Einstellung kein Zugriff ohne explizite anonyme Berechtigung in der lokalen Sicherheitsrichtlinie des Client-Computers aktiviert ist.

      • Windows 2000: Benutzer von Windows 2000-Domäne können keine Netzwerkdrucker aus Active Directory hinzufügen; Allerdings werden sie Drucker hinzufügen, nachdem sie in der Strukturansicht ausgewählt.

      • Windows 2000: Auf Windows 2000-basierten Computern werden ACL-Editor keine Benutzer oder globale Gruppen aus vertrauenswürdigen Windows NT 4.0-Domänen hinzufügen.

      • ADMT, Version 2: Kennwortmigration für Benutzerkonten, die Migration zwischen Gesamtstrukturen mit dem Active Directory Migration Tool (ADMT) Version 2 schlägt fehl.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        Behandlung von gesamtstrukturübergreifende Kennwortmigration mit ADMTv2

      • Outlook-Clients: Die globale Adressliste erscheint für Microsoft Exchange Outlook-Clients leer.

        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        langsame SMB-Leistung beim Kopieren von Dateien von Windows XP auf einen Windows 2000-Domänencontroller

      • SMS: Microsoft Systems Management Server (SMS)-Netzwerkermittlung können nicht Betriebssysteminformationen abrufen. Daher wird "Unbekannt" in der Erkennungsdatensatzes-Eigenschaft der SMS DDR-Eigenschaft des Discovery Data Record (DDR) schreiben.

      • SMS: Wenn Sie Benutzer und Gruppen suchen SMS Administrator-Benutzer-Assistenten verwenden, werden keine Benutzer oder Gruppen aufgelistet. Darüber hinaus können keine erweiterte Clients mit dem Verwaltungspunkt kommunizieren. Anonymer Zugriff muss auf dem Verwaltungspunkt.

      • SMS: Wenn Sie Netzwerk-Suchfunktion in SMS 2.0 und Remoteinstallation mit der Topologie, Client und Clientbetriebssysteme Netzwerk Discovery Option verwenden, Computer ermittelt werden können aber nicht installiert.

  10. Sicherheit: Lan Manager-Authentifizierungsebene

    1. Hintergrund

      LAN Manager (LM)-Authentifizierung ist das Protokoll, mit dem Windows-Clients bei Netzwerkvorgängen, wie Domänenbeitritte, Zugriff auf Netzwerkressourcen sowie Benutzer- oder Computerauthentifizierung authentifizieren. Die LM-Authentifizierungsebene bestimmt, welches Challenge/Response-Authentifizierungsprotokoll zwischen Client und Server-Computern ausgehandelt wird. Die LM-Authentifizierungsebene wird außerdem bestimmt, welche Authentifizierungsprotokolle, die der Client versucht auszuhandeln oder der Server akzeptiert. Der Wert für "LMCompatibilityLevel" bestimmt, welches Challenge/Response-Authentifizierungsprotokoll für Netzwerk-Anmeldung verwendet wird. Dieser Wert wirkt sich auf die Clients verwenden Authentifizierungsprotokoll, die Sicherheitsstufe Sitzung ausgehandelt und auf die Authentifizierungsebene, die von Servern akzeptiert wird.

      Folgende: Einstellungen

      Wert

      Einstellung

      Beschreibung

      0

      LM & NTLM-Antworten senden

      Clients verwenden LM- und NTLM-Authentifizierung und NTLMv2 sitzungssicherheit verwenden. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

      1

      Senden, LM & NTLM - ausgehandelt NTLMv2 sitzungssicherheit verwenden

      Clients verwenden LM- und NTLM-Authentifizierung und der Server unterstützt NTLMv2 sitzungssicherheit verwenden. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

      2

      Nur NTLM-Antworten senden

      Clients verwenden nur die NTLM-Authentifizierung und NTLMv2 Sitzung Security Server unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

      3

      Nur NTLMv2-Antworten senden

      Clients verwenden nur die NTLMv2-Authentifizierung und NTLMv2 Sitzung Security Server unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

      4

      Nur NTLMv2-Antworten senden / LM verweigern

      Clients verwenden nur die NTLMv2-Authentifizierung und NTLMv2 Sitzung Security Server unterstützt. Domänencontroller verweigern LM und akzeptieren nur NTLM- und NTLMv2-Authentifizierung.

      5

      Nur NTLMv2-Antworten senden / LM NTLM verweigern

      Clients verwenden nur die NTLMv2-Authentifizierung und NTLMv2 Sitzung Security Server unterstützt. Domänencontroller verweigern LM und NTLM und akzeptieren nur NTLMv2-Authentifizierung.

      Hinweis In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client SMB-Signatur, wenn sie mit Windows Server 2003-Server mit NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signatur, wenn sie mit Servern authentifizieren, die NTLMv2-Authentifizierung verwenden. Windows 2000 Server reagieren außerdem nicht auf SMB-Signierung Anfragen von Clients.

      Überprüfen Sie die LM-Authentifizierungsebene: Ändern Sie die Richtlinie auf dem Server, um NTLM zuzulassen oder konfigurieren Sie die Clientcomputer, dass sie NTLMv2 unterstützen.

      Wenn die Richtlinie festgelegt ist (5) versenden NTLMv2 senden\LM und NTLM auf dem Zielcomputer, die Sie herstellen möchten, müssen entweder verringern die Einstellung auf dem Computer oder die Sicherheit auf die Einstellung, die auf dem Quellcomputer verbunden sind Stellen aus.

      Suchen Sie den richtigen Ort, wo Sie die LAN-Manager Authentifizierungsebene so ändern können, dass auf dem Client und dem Server die gleiche Ebene festgelegt ist. Nach Wunsch zu und von Computern mit früheren Versionen von Windows Sie die Richtlinie, die LAN-Manager-Authentifizierungsebene, festlegen finden, verringern Sie den Wert mindestens (1) senden LM- und NTLM - NTLM Version 2 verwenden sitzungssicherheit Wenn ausgehandelte. Eine inkompatible Einstellungen wird das verlangt der Server NTLMv2 (Wert 5), aber Client konfiguriert LM und NTLMv1 nur (Wert 0), das Authentifizierung versucht Benutzererlebnis Anmeldefehler, hat ein falsches Kennwort und schlechten erhöhen, die Anzahl der Kennwörter. Wenn Konto Sperre konfiguriert ist, kann der Benutzer schließlich gesperrt.

      Beispielsweise müssen sich auf dem Domänencontroller oder möglicherweise zu Richtlinien des Domänencontrollers.

      Suchen Sie auf dem Domänencontroller

      Hinweis Sie müssen das folgende Verfahren auf allen Domänencontrollern anwenden.

      1. Klicken Sie auf Start, zeigen Sie auf Programmeund klicken Sie dann auf Verwaltung.

      2. Erweitern Sie Lokale Richtlinienunter Lokale Sicherheitsrichtlinie.

      3. Klicken Sie auf Sicherheitsoptionen.

      4. Doppelklicken Sie auf Network Security: LAN Manager-Authentifizierungsebene auf, und klicken Sie dann auf einen Wert in der Liste.


      Wenn die effektive Einstellung und die lokale Einstellung identisch sind, wurde die Richtlinie auf dieser Ebene geändert. Wenn unterschiedliche Einstellungen müssen Sie überprüfen, dass der Domänencontroller-Richtlinie bestimmt, ob die Network Security: LAN Manager-Authentifizierungsebene Einstellung es definiert. Wenn es nicht definiert ist, untersuchen Sie Richtlinien des Domänencontrollers.

      Überprüfen Richtlinien des Domänencontrollers

      1. Klicken Sie auf Start, zeigen Sie auf Programmeund klicken Sie dann auf Verwaltung.

      2. In der Sicherheitsrichtlinie für Domänencontroller erweitern Sie Sicherheit, und dann Lokale Richtlinien.

      3. Klicken Sie auf Sicherheitsoptionen.

      4. Doppelklicken Sie auf Network Security: LAN Manager-Authentifizierungsebene auf, und klicken Sie dann auf einen Wert in der Liste.


      Note

      • Sie müssen außerdem Richtlinien überprüfen, die auf Standortebene, der Domänenebene oder der Organisationseinheit Ebene verknüpft sind um zu ermitteln, müssen Sie die LAN Manager-Authentifizierungsebene konfigurieren.

      • Wenn Sie eine Gruppenrichtlinie als Standarddomänenrichtlinie implementieren, gilt die Richtlinie für alle Computer in der Domäne.

      • Wenn Sie eine Gruppenrichtlinie die Standarddomänencontroller Richtlinie implementieren, gilt die Richtlinie nur auf den Servern in der Domänencontroller-Organisationseinheit.

      • In diesem Zusammenhang empfiehlt es sich, die LAN Manager-Authentifizierungsebene in der niedrigsten Entität erforderlichen Umfang in die Hierarchie der Anwendung festgelegt.

      Windows Server 2003 wurde eine neue Standardeinstellung nur NTLMv2 verwendet. Standardmäßig Windows Server 2003 und Windows 2000 Server SP3 auf Domänencontrollern konnten die "Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)" Richtlinie. Diese Einstellung erfordert den SMB-Server für SMB-Paketsignatur. Da Domänencontroller, Dateiserver, Netzwerk-Infrastrukturserver und Webservern in jeder Organisation unterschiedliche Einstellungen erfordern zu ihrer Sicherheit wurde verändert, Windows Server 2003.

      Wenn Sie NTLMv2-Authentifizierung in Ihrem Netzwerk implementieren möchten, müssen Sie sicherstellen, dass alle Computer in der Domäne festgelegt sind, dass diese Authentifizierungsebene verwendet. Wenn Sie Active Directory Client Extensions für Windows 95 oder Windows 98 und Windows NT 4.0 anwenden, verwenden diese Clienterweiterungen die verbesserten Funktionen, die in NTLMv2 verfügbar sind. Da Clientcomputer, auf denen die folgenden Betriebssystemen ausgeführt werden von Windows 2000-Gruppenrichtlinienobjekten nicht betroffen sind, müssen Sie diese Clients manuell konfigurieren:

      • Microsoft Windows NT 4.0

      • Microsoft Windows Millennium Edition

      • Microsoft Windows 98

      • Microsoft Windows 95

      Hinweis Aktivieren Sie die Sicherheit: LAN Manager-Hashwert nicht auf Nächste Änderung speichern Richtlinie oder Set NoLMHash Registrierungsschlüssel nicht Windows 95- und Windows 98-Clients, die nicht der Verzeichnisdienstclient installiert Melden Sie sich nach einer Änderung der Domäne an.

      Viele Drittanbieter-CIFS-Server wie Novell Netware 6, sind nicht NTLMv2-fähig und verwenden ausschließlich NTLM. Daher erlauben Ebenen höher als 2 Verbindung. Gibt SMB-Clients von Drittanbietern, die erweiterte sitzungssicherheit nicht verwenden. In diesen Fällen ist der LmCompatiblityLevel der Ressourcenserver nicht berücksichtigt. Der Server packt diese älteren Anforderung und sendet diese an die Benutzer-Domänencontroller. Auf dem Domänencontroller dann entscheiden, was Hashes verwendet werden, um die Anforderung zu überprüfen und ob diese des Domänencontrollers Sicherheit erfüllen.

      Weitere Informationen zum manuellen Konfigurieren der Authentifizierungsebene des LAN-Managers klicken Sie auf die folgenden Artikelnummern klicken, um die Artikel der Microsoft Knowledge Base:

      zum Deaktivieren des LM-Authentifizierung in Windows NT
       

      wie Sie verhindern, dass Windows LAN Manager-Hashwerte Ihres Kennworts in Active Directory und der lokalen SAM-Datenbank speichern
       

      Outlook weiterhin aufgefordert, Anmeldeinformationen einzugeben
       

      Überwachungsereignis zeigt Authentifizierungspaket NTLMv1 statt NTLMv2 Weitere Informationen zu LM-Authentifizierungsebenen klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:


       

    2. Risikoreiche Konfigurationen

      Folgende sind schädliche Konfigurationen:

      • Einschränkende Einstellung Kennwörter in Klartext senden und die NTLMv2-Aushandlung verweigern

      • Restriktive Einstellung, die verhindert, dass nicht kompatible Clients oder Domänencontroller kein gemeinsames Authentifizierungsprotokoll ausgehandelt

      • Die NTLMv2-Authentifizierung auf Mitgliedscomputern und Domänencontrollern, die Versionen von Windows NT 4.0 ausführen, die älter als Service Pack 4 (SP4)

      • Die NTLMv2-Authentifizierung auf Windows 95- oder Windows 98-Clients, die keine Windows Directory Services Client installiert haben.

      • Wenn das Kontrollkästchen NTLMv2 erforderlich sitzungssicherheit im Gruppenrichtlinieneditor für Microsoft Management Console-Snap-in auf einem Windows Server 2003 oder Windows 2000 Service Pack 3-Computers aktivieren und die LAN Manager-Authentifizierungsebene senken 0 erhalten zwei Konflikt und die folgende Fehlermeldung in der Datei "Gpedit.msc" Secpol.msc oder:

        Die lokalen Richtlinien-Datenbank kann nicht geöffnet werden. Unbekannte Fehler beim Öffnen der Datenbank.

        Weitere Informationen zur Sicherheitskonfiguration und Analyse-Tool finden Sie unter Windows 2000 oder Windows Server 2003 Help Files.

    3. Gründe zum Ändern dieser Einstellung

      • Möchten Sie das niedrigste gemeinsame Authentifizierungsprotokoll erhöhen, das von Clients und Domänencontroller in Ihrer Organisation unterstützt wird.

      • Sicherer Authentifizierung eine geschäftliche Anforderung ist, sollte die Aushandlung des LM- und NTLM-Protokolls verweigert werden.

    4. Gründe zum Deaktivieren dieser Einstellung

      Client-authentifizierungsanforderungen oder beides wurden so erhöht, Authentifizierung über ein gemeinsames Protokoll erfolgen kann.

    5. Symbolische Namen:

      LmCompatibilityLevel

    6. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. Beispiele für Kompatibilitätsprobleme

      • WindowsServer 2003: Standardmäßig ist die Windows Server 2003 NTLMv2 NTLM-Anworten senden festlegen aktiviert. Daher erhält der Windows Server 2003 Wenn Sie versuchen, die Verbindung zu einem Windows NT 4.0-basierten Cluster oder zu LanManager v2. 1-basierten Servern wie OS/2 Lanserver die Fehlermeldung "Zugriff verweigert" nach der Erstinstallation. Dieses Problem tritt auch auf, wenn Sie versuchen, eine frühere Version Client auf einem Windows Server 2003-basierten Server herstellen.

      • Sie installieren Windows 2000 Security Rollup Package 1 (SRP1). SRP1 erzwingt die NTLM Version 2 (NTLMv2). Dieses Rollup Package wurde nach der Veröffentlichung von Windows 2000 Service Pack 2 (SP2) freigegeben. Weitere Informationen zum SRP1 klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

        Windows 2000 Security Rollup Package 1, Januar 2002
         

      • Windows 7 und Windows Server 2008 R2: viele Drittanbieter-CIFS-Server wie Novell Netware 6 oder Linux-basierten Samba-Server sind nicht NTLMv2-fähig und verwenden ausschließlich NTLM. Daher erlauben größer als "2" Ebenen Verbindung. In dieser Version des Betriebssystems wurde nun der Standard für LmCompatibilityLevel auf "3" geändert. Daher während der Aktualisierung von Windows eventuell diese Drittanbieter Filer funktioniert nicht.

      • Microsoft Outlook-Clients können Anmeldeinformationen aufgefordert werden, obwohl sie an der Domäne angemeldet sind. Wenn Benutzer ihre Anmeldeinformationen eingeben, erhalten sie folgende Fehlermeldung: Windows 7 und Windows Server 2008 R2

        Die Anmeldeinformationen sind ungültig. Stellen Sie sicher, dass Benutzername und Domäne korrekt sind, und geben Ihr Kennwort erneut.

        Beim Starten von Outlook können Sie Ihre Anmeldeinformationen aufgefordert, wenn die Anmeldung Network Security Passthrough oder Kennwortauthentifizierung festgelegt ist. Nachdem Sie Ihre Anmeldeinformationen eingeben, erhalten Sie folgende Fehlermeldung:

        Die Anmeldeinformationen sind falsch.

        Ein zeigt an, dass der globale Katalog einen Remoteprozeduraufruf Remoteprozeduraufruf-Fehler mit dem Status 0 x 5 ausgestellt. Status 0 x 5 bedeutet "Zugriff verweigert".

      • Windows 2000: Eine Netzwerkmonitor-Aufzeichnung kann die folgenden Fehler in der NetBIOS über TCP/IP (NetBT) Server Message Block (SMB) Sitzung anzeigen:

        SMB-R Suche Verzeichnis Dos-Fehler (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) ungültige Benutzer-ID

      • Windows 2000: Wenn eine Windows 2000-Domäne mit NTLMv2 der Stufe 2 oder höher von einer Windows NT 4.0-Domäne vertrauenswürdig ist, können Windows 2000-Mitgliedscomputern in der Ressourcendomäne Authentifizierungsfehler auftreten.

      • Windows 2000 und Windows XP: Windows 2000 und Windows XP setzen die Option LAN Manager-Authentifizierung der lokalen Sicherheitsrichtlinie standardmäßig auf 0. Die Einstellung 0 bedeutet "LM- und NTLM Anworten senden."

        Hinweis Windows NT 4.0-Cluster müssen für die Verwaltung LM verwenden.

      • Windows 2000: Windows 2000-Cluster keine Authentifizierung ein beitretenden Knotens Wenn beide Knoten Teil einer Windows NT 4.0 Service Pack 6a sind (SP6a) Domäne.

      • Das IIS Lockdown Tool (HiSecWeb) setzt den Wert LMCompatibilityLevel auf 5 und den Wert "RestrictAnonymous" auf 2.

      • Dienste für Macintosh

        -Benutzerauthentifizierungsmodul (UAM): Microsoft UAM (User Authentication Module) bietet eine Methode zum Verschlüsseln der Kennwörter für die Anmeldung bei Windows AFP (AppleTalk Filing Protocol)-Server verwenden. Das Apple-Benutzerauthentifizierungsmodul (UAM) ermöglicht nur eine minimale oder gar keine Verschlüsselung. Daher kann Ihr Kennwort im LAN oder im Internet leicht abgefangen werden. Obwohl das UAM nicht erforderlich ist, bietet es verschlüsselten Authentifizierung auf Windows 2000 Server, die Dienste für Macintosh ausgeführt. Diese Version unterstützt NTLMv2 128-Bit-verschlüsselte Authentifizierung und ein MacOS X 10.1-kompatibles Release.

        Standardmäßig ermöglicht Windows Server 2003 Services for Macintosh nur Microsoft Authentication.


        Klicken Sie für weitere Informationen auf die folgenden Artikelnummern, um die betreffenden Artikel in der Microsoft Knowledge Base anzuzeigen:

        Macintosh-Client kann keine Verbindung zu den Services for Macintosh unter Windows Server 2003 herstellen

      • WindowsServer 2008, WindowsServer 2003, Windows XP und Windows 2000: LMCompatibilityLevel-Wert 0 oder 1 und konfigurieren Sie den NoLMHash Wert 1 konfigurieren, können eine Anwendungsprogramme und Komponenten über NTLM Zugriff verweigert. Dieses Problem tritt auf, weil der Computer LM aktivieren, aber nicht LM-gespeicherten Kennwörter konfiguriert ist.

        Konfigurieren den NoLMHash Wert 1 müssen Sie LMCompatibilityLevel-Wert 2 oder höher zu konfigurieren.

  11. Sicherheit: LDAP-Client Anforderungen signieren

    1. Hintergrund

      Die Sicherheit: LDAP-Client Signieren Vorschriften Einstellung bestimmt die Ebene der Datensignatur für Clients angefordert wird, die Lightweight Directory Access Protocol (LDAP) BINDUNG ausstellen Anfragen wie folgt:

      • None: der LDAP-BIND-Anforderung mit den vom Aufrufer festgelegten Optionen ausgegeben.

      • Signatur aushandeln: Wenn die Secure Sockets Layer/Transport Layer Security (SSL/TLS) nicht gestartet wurde, wird die LDAP BIND-Anforderung mit der LDAP-Datensignaturoption außerdem den vom Aufrufer festgelegten Optionen initiiert. Wenn SSL/TLS bereits gestartet wurde, wird die LDAP BIND-Anforderung mit den vom Aufrufer festgelegten Optionen initiiert.

      • Signatur erforderlich: Dies entspricht der Signatur aushandeln. Aber wenn-Zwischenantwort des LDAP-Servers nicht darauf hinweist, dass LDAP erforderlich sind, wird dem Aufrufer mitgeteilt, dass LDAP BIND-Befehl Anforderungsfehler.

    2. Risikoreiche Konfiguration

      Aktivieren der Sicherheit: LDAP-Client Signieren Vorschriften schädliche konfiguriert ist. Wenn Sie festlegen, um LDAP-Signaturen verlangt, müssen Sie auch LDAP-Signierung auf dem Client konfigurieren. Nicht konfigurieren den Client LDAP-Signaturen verhindert die Kommunikation mit dem Server. Dadurch Benutzerauthentifizierung, Group Policy Settings Anmeldeskripts und andere Features nicht.

    3. Gründe zum Ändern dieser Einstellung

      Nicht signierter Netzwerkverkehr ist anfällig für Man-in-the-Middle-Angriffe, in denen ein Eindringling Pakete zwischen Client und Server abfängt modifiziert und anschließend an den Server weiterleitet. In diesem Fall auf einem LDAP-Server könnte ein Angreifer Server reagieren auf falschen Abfragen vom LDAP-Client. Sie können dieses Risiko in einem Unternehmensnetzwerk senken, indem Sie strenge physische Sicherheitsmaßnahmen zum Schutz die Netzwerkinfrastruktur implementieren. Darüber hinaus helfen Ihnen, alle Arten von Man-in-the-Middle-Angriffe verhindern, indem Sie digitale Signaturen für alle Netzwerkpakete über IPSec-Authentifizierungsheader erfordern.

    4. Symbolische Namen:

      LDAPClientIntegrity

    5. Pfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

  12. Ereignisprotokoll: Maximalgröße des Sicherheitsprotokolls

    1. Hintergrund

      Die Ereignisprotokoll: Maximalgröße des Sicherheitsprotokolls Einstellung gibt die maximale Größe des Sicherheitsprotokolls. Dieses Protokoll besitzt eine maximale Größe von 4 GB. Um diese Einstellung zu finden, erweitern
      Windows-Einstellungen, und erweitern Sie dann Sicherheit.

    2. Risikoreiche Konfigurationen

      Folgende sind schädliche Konfigurationen:

      • Beschränken die Größe des Sicherheitsprotokolls und der Speichermethode Sicherheit bei den Audit: System sofort zu Herunterfahren aktiviert ist. Finden Sie den "Audit: System sofort zu Herunterfahren" Abschnitt dieses Artikels Weitere Informationen.

      • Beschränken die Größe des Sicherheitsprotokolls, sodass relevante Sicherheitsereignisse überschrieben werden.

    3. Gründe für diese Einstellung erhöhen

      Geschäfts- und möglicherweise herstellt, erhöhen die Größe des Sicherheitsprotokolls zusätzliche Protokolldetail behandeln oder Sicherheitsprotokolle für längere Zeit beibehalten.

    4. Gründe zum Verringern dieser Einstellung

      Protokolle der Ereignisanzeige sind Speicherabbilddateien. Die maximale Größe des Ereignisprotokolls ist eingeschränkt, die Größe des physischen Speichers auf dem lokalen Computer und den virtuellen Speicher, der dem Ereignisprotokoll Prozess verfügbar ist. Darüber hinaus, die Ereignisanzeige verfügbaren virtuellen Speicher erhöhen Protokoll erhöhen verwaltet werden die Anzahl der Protokolleinträge nicht.

    5. Beispiele für Kompatibilitätsprobleme

      Windows 2000: Computer mit Windows 2000-Versionen, die sind älter als Service Pack 4 (SP4) möglicherweise keine Protokollierung im Ereignisprotokoll mehr vor die Größe angegeben wird, die maximale Protokollgröße festlegen in der Ereignisanzeige der Ereignisse nicht überschreiben (Protokoll manuell löschen) aktiviert ist.


      Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

      das Ereignisprotokoll beendet, Ereignisse vor dem Erreichen der Maximalgröße
       

  13. Ereignisprotokoll: Sicherheitsprotokoll-Aufbewahrung

    1. Hintergrund

      Die Ereignisprotokoll: Sicherheitsprotokoll-Aufbewahrung festgelegt, die "Umbruchmethode" für das Sicherheitsprotokoll. Um diese Einstellung zu finden, erweitern Sie Windows-Einstellungen, und anschließend Sicherheit.

    2. Risikoreiche Konfigurationen

      Folgende sind schädliche Konfigurationen:

      • Nicht erfolgte Speicherung Sicherheitsereignisse aller, bevor diese überschrieben werden

      • Maximalgröße des Sicherheitsprotokolls klein festlegen, sodass die Sicherheitsereignisse überschrieben werden

      • Die Protokoll Größe und Aufbewahrung Methode beim Einschränken der Audit: System sofort zu Herunterfahren Sicherheit aktiviert ist

    3. Gründe zum Aktivieren dieser Einstellung

      Aktivieren Sie diese Einstellung nur, wenn die Aufbewahrungsmethode Überschreiben Ereignisse auf Tagen auswählen. Verwenden Sie eine Korrelation Ereignissystem, die Umfragen Ereignisse Achten Sie die Anzahl der Tage mindestens dreimal die Abruffrequenz. Dies ermöglicht Abfragefehlers Zyklen.

  14. Netzwerkzugriff: "Jeder" für anonyme Benutzer-Berechtigungen ermöglichen

    1. Hintergrund

      Standardmäßig die Netzwerkzugriff: lassen Sie "Jeder"-Berechtigungen für anonyme Benutzer Einstellung in Windows Server 2003 Nicht definiert . Standardmäßig Windows Server 2003 enthält keinen anonymen Zugriff Token in jeder Gruppe.

    2. Beispiel für Kompatibilitätsprobleme

      Der folgende Wert

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous[REG_DWORD] = 0 x 0 Seitenumbrüche Vertrauensstellung erstellt zwischen Windows Server 2003 und Windows NT 4.0 bei die Windows Server 2003-Domäne die Kontendomäne und der Windows NT 4.0-Domäne die Ressourcendomäne. Dies bedeutet, dass das Konto unter Windows NT 4.0 vertraut wird und der Ressourcendomäne vertrauen auf Windows Server 2003. Dieses Verhalten tritt auf, weil der Prozess zum Starten der Vertrauensstellung nach die erste anonyme Verbindung ACL ist alle token würden, die anonyme SID unter Windows NT 4.0 enthält.

    3. Gründe zum Ändern dieser Einstellung

      Der Wert muss auf 0 x 1 festgelegt oder mithilfe eines Gruppenrichtlinienobjekts auf der Domänencontroller-Organisationseinheit zu: Netzwerkzugriff: Let Everyone-Berechtigungen für anonyme Benutzer - ermöglichen die Bildung von Vertrauensstellungen.

      Hinweis Die meisten anderen Einstellungen gehen in Wert auf 0 x 0 in die gesicherten Zustand. Sicherer wäre die Registrierung auf der PDC-Emulation statt auf allen Domänencontrollern ändern. Primäre Funktion des Domänencontrollers Emulator aus irgendeinem Grund verschoben, muss die Registrierung auf dem neuen Server aktualisiert werden.

      Nach dem Festlegen dieses Werts ist ein Neustart erforderlich.

    4. Pfad

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

  15. NTLMv2-Authentifizierung

    1. Sitzungssicherheit

      Sitzungssicherheit bestimmt die Mindestsicherheitsstandards für Client und Server. In diesem Zusammenhang empfiehlt es sich, die folgenden Security Policy Einstellungen im Gruppenrichtlinieneditor für Microsoft Management Console-Snap-in:

      • Computereinstellungen\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\sicherheitsoptionen

      • Network Security: Minimum sitzungssicherheit NTLM SSP basiert (einschließlich sicheren RPC) Server

      • Network Security: Minimum sitzungssicherheit NTLM SSP basiert (einschließlich sicheren RPC) Clients

      Die Optionen für diese Einstellung sind wie folgt:

      • Nachrichtenintegrität erfordern

      • Vertraulichkeit erforderlich

      • NTLM Version 2 erfordern sitzungssicherheit

      • 128-Bit-Verschlüsselung

      Die Standardeinstellung vor Windows 7 ist keine. Beginnend mit Windows 7 standardmäßig erfordert 128-Bit- Verschlüsselung zur Erhöhung der Sicherheit geändert. Diese Standardeinstellung werden Legacygeräte, die 128-Bit-Verschlüsselung nicht unterstützen konnte nicht hergestellt.

      Diese Richtlinien bestimmen die Mindestsicherheitsstandards für eine Anwendung-kommunikationssitzung auf einem Server für einen Client.

      Beachten Sie, dass beschrieben als gültigen Einstellungen Flags Nachrichtenintegrität und Vertraulichkeit nicht verwendet werden, wenn die NTLM-sitzungssicherheit bestimmt wird.

      In der Vergangenheit unterstützt Windows NT zwei Varianten der Sicherheitspaket für Netzwerk-Anmeldung:

      • LM NTLM

      • NTLM Version 1 Challenge/response

      LM ermöglicht die Interoperabilität mit der installierten Basis von Clients und Servern. NTLM bietet verbesserte Sicherheit für Verbindungen zwischen Clients und Servern.

      Die entsprechenden Registrierungsschlüssel lauten folgendermaßen:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

    2. Risikoreiche Konfigurationen

      Diese Einstellung steuert die Behandlung NTLM gesicherte Netzwerk-Sessions. Dies betrifft beispielsweise mit NTLM authentifizierte RPC-basierte Sessions. Es gibt folgenden Risiken:

      • Verwenden ältere Authentifizierungsmethoden als NTLMv2 Kommunikation für Angriffe aufgrund der einfacheren hashing verwendet erleichtert.

      • Kleiner als 128-Bit-Schlüssel können Angreifer mit Brute-Force-Angriffen-Kommunikation unterbrochen.

Synchronisierung

Synchronisierung fehlgeschlagen. Die Zeit ist mehr als 30 Minuten auf einem betroffenen Computer aus. Stellen Sie sicher, dass die Uhr des Clientcomputers mit der Uhr des Domänencontrollers synchronisiert wird.

Abhilfe für SMB-Signaturen

Wir empfehlen die Installation von Service Pack 6a (SP6a) auf Windows NT 4.0-Clients in einer Windows Server 2003-Domäne zusammen. Windows 98 Second Edition-basierten Clients, die Windows 98-basierten Clients und Windows 95-basierten Clients müssen der Verzeichnisdienstclient, um NTLMv2 ausführen ausgeführt. Wenn Windows NT 4.0-basierten Clients nicht Windows NT 4.0 SP6 installiert haben oder Windows 95-basierten Clients Windows 98-basierten Clients und Windows 98 SE-Clients nicht der Verzeichnisdienstclient installiert, über SMB deaktivieren Standarddomäne anmelden Richtlinie für die Domänencontroller die Organisationseinheit und diese Richtlinie dann mit allen Organisationseinheiten, die anderen Domänencontroller verknüpfen.

Directory Services Client für Windows 98 Second Edition, Windows 98 und Windows 95 führt die SMB-Signierung mit Windows Server 2003 unter NTLM-Authentifizierung, jedoch nicht unter die NTLMv2-Authentifizierung. Außerdem reagiert Windows 2000-Servern auf SMB-Signierung von Clients nicht.

Obwohl es nicht empfehlen, verhindert Sie SMB-Signaturen auf allen Domänencontrollern, die Windows Server 2003 in einer Domäne ausführen erforderlich. Gehen Sie folgendermaßen vor, um diese Einstellung zu konfigurieren:

  1. Öffnen Sie die Standarddomänencontroller Richtlinie.

  2. Öffnen Sie den Ordner Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\sicherheitsoptionen .

  3. Klicken Sie auf die Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) Einstellung, und klicken Sie auf deaktiviert.

Wichtig Dieser Abschnitt bzw. die Methode oder Aufgabe enthält Schritte, die erklären, wie Sie die Registrierung ändern. Allerdings können schwerwiegende Probleme auftreten, wenn Sie die Registrierung falsch ändern. Stellen Sie daher sicher, dass Sie die folgenden Schritte sorgfältig ausführen. Sichern Sie die Registry für zusätzlichen Schutz, bevor Sie sie ändern. Anschließend können Sie die Registrierung wiederherstellen, falls ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie im folgenden Artikel der Microsoft Knowledge Base:

zum Sichern und Wiederherstellen der Registrierung in WindowsAlternativ deaktivieren Sie SMB-Signaturen auf dem Server durch Ändern der Registrierung. Gehen Sie hierzu folgendermaßen vor:

  1. Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie regedit ein, und klicken Sie dann auf OK.

  2. Suchen Sie und klicken Sie auf den folgenden Unterschlüssel:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

  3. Klicken Sie auf den Eintrag Enablesecuritysignature .

  4. Klicken Sie im Menü Bearbeiten auf Ändern.

  5. Geben Sie im Feld Wert 0ein, und klicken Sie auf OK.

  6. Registrierungseditor beenden.

  7. Starten Sie den Computer neu und beenden den Serverdienst neu. Dazu geben Sie folgende Befehle ein und drücken Sie nach jedem Befehl:
    Net Stop server
    Net Start server

Hinweis Der entsprechende Schlüssel auf dem Client-Computer ist im folgenden Registrierungsunterschlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\ParametersDie folgenden Listet die übersetzten Code Fehlernummern Statuscodes und zuvor genannten wörtlichen Fehlermeldungen:

Fehler 5
ERROR_ACCESS_DENIED

Zugriff wurde verweigert.

Fehler 1326

ERROR_LOGON_FAILURE

Anmeldefehler: unbekannten Benutzernamen oder das Kennwort falsch.

Fehler 1788

ERROR_TRUSTED_DOMAIN_FAILURE

Die Vertrauensstellung zwischen der primären Domäne und der vertrauenswürdigen Domäne ist fehlgeschlagen.

Fehler 1789

ERROR_TRUSTED_RELATIONSHIP_FAILURE

Das Vertrauensverhältnis zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.

Klicken Sie für weitere Informationen auf die folgenden Artikelnummern, um die betreffenden Artikel in der Microsoft Knowledge Base anzuzeigen:

zum Konfigurieren von Gruppenrichtlinien zum Festlegen der Sicherheit für Systemdienste in Windows Server 2003
 

Aktivieren von SMB-Signaturen in Windows NT
 

wie Anwenden vordefinierter Sicherheitsvorlagen in Windows Server 2003
 

Fenster Kontoanmeldeinformationen Geben Sie, wenn Sie die Verbindung zum Exchange Server 2003 mit Outlook 2003 RPC über HTTP-feature

Benötigen Sie weitere Hilfe?

Ihre Office-Fähigkeiten erweitern
Schulungen erkunden
Neue Funktionen als Erster erhalten
Microsoft Insider beitreten

War diese Information hilfreich?

Vielen Dank für Ihr Feedback!

Vielen Dank für Ihr Feedback. Es klingt, als ob es hilfreich sein könnte, Sie mit einem unserer Office-Supportmitarbeiter zu verbinden.

×