Client-, Dienst- und Programmprobleme können auftreten, wenn Sie Sicherheitseinstellungen und Benutzerrechtezuweisungen ändern.

Windows XP

Um das Bewusstsein für falsch konfigurierte Sicherheitseinstellungen zu erhöhen, verwenden Sie das Tool Gruppenrichtlinie-Objekt-Editor, um Sicherheitseinstellungen zu ändern. Wenn Sie Gruppenrichtlinie-Objekt-Editor verwenden, werden die Zuweisungen von Benutzerrechten auf den folgenden Betriebssystemen verbessert:

• Windows XP Professional Service Pack 2 (SP2)

• Windows Server 2003 Service Pack 1 (SP1)

Das erweiterte Feature ist ein Dialogfeld, das einen Link zu diesem Artikel enthält. Das Dialogfeld wird angezeigt, wenn Sie eine Sicherheitseinstellung oder eine Zuweisung von Benutzerrechten in eine Einstellung ändern, die weniger Kompatibilität bietet und restriktiver ist. Wenn Sie die gleiche Sicherheitseinstellung oder Benutzerberechtigungszuweisung direkt mithilfe der Registrierung oder mithilfe von Sicherheitsvorlagen ändern, ist der Effekt identisch mit dem Ändern der Einstellung im Gruppenrichtlinie Objekt-Editor. Das Dialogfeld, das den Link zu diesem Artikel enthält, wird jedoch nicht angezeigt.

Dieser Artikel enthält Beispiele für Clients, Programme und Vorgänge, die von bestimmten Sicherheitseinstellungen oder Benutzerrechten betroffen sind. Die Beispiele sind jedoch nicht für alle Microsoft-Betriebssysteme, für alle Betriebssysteme von Drittanbietern oder für alle betroffenen Programmversionen autoritativ. Nicht alle Sicherheitseinstellungen und Benutzerrechtezuweisungen sind in diesem Artikel enthalten.

Es wird empfohlen, die Kompatibilität aller sicherheitsbezogenen Konfigurationsänderungen in einer Testgesamtstruktur zu überprüfen, bevor Sie sie in einer Produktionsumgebung einführen. Die Testgesamtstruktur muss die Produktionsgesamtstruktur auf folgende Weise spiegeln:

• Client- und Serverbetriebssystemversionen, Client- und Serverprogramme, Service Pack-Versionen, Hotfixes, Schemaänderungen, Sicherheitsgruppen, Gruppenmitgliedschaften, Berechtigungen für Objekte im Dateisystem, freigegebene Ordner, die Registrierung, Active Directory-Verzeichnisdienst, lokale und Gruppenrichtlinie Einstellungen sowie Objektanzahltyp und -speicherort

• Ausgeführte Administrative Aufgaben, verwendete Verwaltungstools und Betriebssysteme, die zum Ausführen administrativer Aufgaben verwendet werden

• Ausgeführte Vorgänge, z. B. die folgenden:

  • Computer- und Benutzeranmeldungsauthentifizierung

  • Kennwortzurücksetzung durch Benutzer, Computer und Administratoren

  • Surfen

  • Festlegen von Berechtigungen für das Dateisystem, für freigegebene Ordner, für die Registrierung und für Active Directory-Ressourcen mithilfe des ACL-Editors in allen Clientbetriebssystemen in allen Konto- oder Ressourcendomänen aller Clientbetriebssysteme aus allen Konto- oder Ressourcendomänen

  • Drucken aus administrativen und nichtadministrativen Konten

Windows Server 2003 SP1

Benutzerrechte

Die folgende Liste beschreibt ein Benutzerrecht, identifiziert Konfigurationseinstellungen, die Probleme verursachen können, beschreibt, warum Sie das Benutzerrecht anwenden sollten und warum Sie möglicherweise das Benutzerrecht entfernen möchten, und enthält Beispiele für Kompatibilitätsprobleme, die auftreten können, wenn das Benutzerrecht konfiguriert ist.

1. Zugreifen auf diesen Computer über das Netzwerk

   1. Hintergrund
      
      Die Möglichkeit zur Interaktion mit Windows-Remotecomputern erfordert, dass der Zugriff auf diesen Computer vom Netzwerkbenutzer aus erfolgt. Beispiele für solche Netzwerkvorgänge sind:

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

      • Authentifizierungsanforderungen an Domänencontroller von Benutzern und computern

      • Zugriff auf freigegebene Ordner, Drucker und andere Systemdienste, die sich auf Remotecomputern im Netzwerk befinden

      
      
      Benutzer, Computer und Dienstkonten erhalten oder verlieren den Zugriff auf diesen Computer vom Netzwerkbenutzerrecht, indem sie explizit oder implizit einer Sicherheitsgruppe hinzugefügt oder daraus entfernt werden, der dieses Benutzerrecht gewährt wurde. Beispielsweise kann ein Benutzerkonto oder ein Computerkonto explizit einer benutzerdefinierten Sicherheitsgruppe oder einer integrierten Sicherheitsgruppe von einem Administrator hinzugefügt oder implizit vom Betriebssystem einer berechneten Sicherheitsgruppe wie Domänenbenutzern, authentifizierten Benutzern oder Unternehmensdomänencontrollern hinzugefügt werden.
      
      Benutzerkonten und Computerkonten erhalten standardmäßig den Zugriff auf diesen Computer vom Netzwerkbenutzer aus, wenn berechnete Gruppen wie "Jeder" oder vorzugsweise "Authentifizierte Benutzer" und bei Domänencontrollern die Gruppe "Unternehmensdomänencontroller" in den Standarddomänencontrollern Gruppenrichtlinie-Objekt (GPO) definiert sind.

   2. Riskante Konfigurationen
      
      Die folgenden Konfigurationseinstellungen sind schädlich:

      • Entfernen der Sicherheitsgruppe "Unternehmensdomänencontroller" von diesem Benutzerrecht

      • Entfernen der Gruppe "Authentifizierte Benutzer" oder einer expliziten Gruppe, die Benutzern, Computern und Dienstkonten das Recht des Benutzers ermöglicht, eine Verbindung mit Computern über das Netzwerk herzustellen

      • Entfernen aller Benutzer und Computer von diesem Benutzerrecht

   3. Gründe für die Gewährung dieses Benutzerrechts

      • Die Gewährung des Zugriffs dieses Computers vom Netzwerkbenutzer auf die Gruppe der Unternehmensdomänencontroller erfüllt die Authentifizierungsanforderungen, die die Active Directory-Replikation erfüllen muss, damit die Replikation zwischen Domänencontrollern in derselben Gesamtstruktur erfolgen kann.

      • Dieses Benutzerrecht ermöglicht Benutzern und Computern den Zugriff auf freigegebene Dateien, Drucker und Systemdienste, einschließlich Active Directory.

      • Dieses Benutzerrecht ist erforderlich, damit Benutzer über frühe Versionen von Microsoft Outlook Web Access (OWA) auf E-Mails zugreifen können.

   4. Gründe, dieses Benutzerrecht zu entfernen

      • Benutzer, die ihre Computer mit dem Netzwerk verbinden können, können auf Ressourcen auf Remotecomputern zugreifen, für die sie über Berechtigungen verfügen. Beispielsweise ist dieses Benutzerrecht erforderlich, damit ein Benutzer eine Verbindung mit freigegebenen Druckern und Ordnern herstellen kann. Wenn dieses Benutzerrecht der Gruppe "Jeder" gewährt wird und für einige freigegebene Ordner die Berechtigungen für das Freigabe- und ntfs-Dateisystem konfiguriert sind, sodass die gleiche Gruppe Lesezugriff hat, kann jeder Dateien in diesen freigegebenen Ordnern anzeigen. Dies ist jedoch für Neuinstallationen von Windows Server 2003 unwahrscheinlich, da die Standardfreigabe und die NTFS-Berechtigungen in Windows Server 2003 nicht die Gruppe "Jeder" enthalten. Bei Systemen, die von Microsoft Windows NT 4.0 oder Windows 2000 aktualisiert werden, kann diese Sicherheitsanfälligkeit ein höheres Risiko aufweisen, da die Standardfreigabe und die Dateisystemberechtigungen für diese Betriebssysteme nicht so restriktiv sind wie die Standardberechtigungen in Windows Server 2003.

      • Es gibt keinen gültigen Grund für das Entfernen der Gruppe "Unternehmensdomänencontroller" von diesem Benutzerrecht.

      • Die Gruppe "Jeder" wird im Allgemeinen zugunsten der Gruppe "Authentifizierte Benutzer" entfernt. Wenn die Gruppe "Jeder" entfernt wird, muss der Gruppe "Authentifizierte Benutzer" dieses Benutzerrecht gewährt werden.

      • Windows NT 4.0-Domänen, die auf Windows 2000 aktualisiert werden, gewähren dem Zugriff auf diesen Computer nicht explizit das Recht des Netzwerkbenutzers auf die Gruppe "Jeder", die Gruppe "Authentifizierte Benutzer" oder die Gruppe "Unternehmensdomänencontroller". Wenn Sie daher die Gruppe "Jeder" aus der Windows NT 4.0-Domänenrichtlinie entfernen, schlägt die Active Directory-Replikation nach dem Upgrade auf Windows 2000 mit der Fehlermeldung "Zugriff verweigert" fehl. Winnt32.exe in Windows Server 2003 verhindert diese Fehlkonfiguration, indem der Gruppe "Unternehmensdomänencontroller" dieses Benutzerrecht gewährt wird, wenn Sie windows NT 4.0 primäre Domänencontroller (PRIMARY Domain Controller, PDCs) aktualisieren. Erteilen Sie der Gruppe "Unternehmensdomänencontroller" diesem Benutzer das Recht, wenn er nicht im Gruppenrichtlinie-Objekt-Editor vorhanden ist.

   5. Beispiele für Kompatibilitätsprobleme

      • Windows 2000 und Windows Server 2003: Die Replikation der folgenden Partitionen schlägt mit "Zugriff verweigert"-Fehlern fehl, wie sie von Überwachungstools wie REPLMON und REPADMIN oder Replikationsereignissen im Ereignisprotokoll gemeldet werden.

        • Active Directory-Schemapartition

        • Konfigurationspartition

        • Domänenpartition

        • Globale Katalogpartition

        • Anwendungspartition

      • Alle Microsoft-Netzwerkbetriebssysteme: Die Benutzerkontenauthentifizierung von Remotenetzwerkclientcomputern schlägt fehl, es sei denn, dem Benutzer oder einer Sicherheitsgruppe, in der der Benutzer Mitglied ist, wurde dieses Benutzerrecht gewährt.

      • Alle Microsoft-Netzwerkbetriebssysteme: Die Kontoauthentifizierung von Remotenetzwerkclients schlägt fehl, es sei denn, dem Konto oder einer Sicherheitsgruppe, in der das Konto Mitglied ist, wurde dieses Benutzerrecht gewährt. Dieses Szenario gilt für Benutzerkonten, Computerkonten und Dienstkonten.

      • Alle Microsoft-Netzwerkbetriebssysteme: Durch das Entfernen aller Konten von diesem Benutzerrecht wird verhindert, dass sich ein Konto bei der Domäne anmeldet oder auf Netzwerkressourcen zugreift. Wenn berechnete Gruppen wie Unternehmensdomänencontroller, Jeder oder authentifizierte Benutzer entfernt werden, müssen Sie diesem Benutzer explizit das Recht gewähren, Konten oder Sicherheitsgruppen, bei denen das Konto Mitglied ist, auf Remotecomputer über das Netzwerk zuzugreifen. Dieses Szenario gilt für alle Benutzerkonten, alle Computerkonten und alle Dienstkonten.

      • Alle Microsoft-Netzwerkbetriebssysteme: Das lokale Administratorkonto verwendet ein "leeres" Kennwort. Netzwerkkonnektivität mit leeren Kennwörtern ist für Administratorkonten in einer Domänenumgebung nicht zulässig. Bei dieser Konfiguration wird die Fehlermeldung "Zugriff verweigert" angezeigt.

2. Lokale Anmeldung zulassen

   1. Hintergrund
      
      Benutzer, die versuchen, sich an der Konsole eines Windows-basierten Computers (mithilfe der Tastenkombination STRG+ALT+ENTF) anzumelden, und Konten, die versuchen, einen Dienst zu starten, müssen über lokale Anmeldeberechtigungen auf dem Hostcomputer verfügen. Beispiele für lokale Anmeldevorgänge sind Administratoren, die sich an den Konsolen von Mitgliedscomputern anmelden, oder Domänencontroller im gesamten Unternehmen und Domänenbenutzer, die sich bei Mitgliedscomputern anmelden, um mithilfe nicht privilegierter Konten auf ihre Desktops zuzugreifen. Benutzer, die eine Remotedesktopverbindung oder Terminaldienste verwenden, müssen sich lokal bei Zielcomputern mit Windows 2000 oder Windows XP anmelden lassen, da diese Anmeldemodi als lokal auf dem Hostcomputer gelten. Benutzer, die sich bei einem Server anmelden, auf dem Terminal Server aktiviert ist und die nicht über dieses Benutzerrecht verfügen, können weiterhin eine interaktive Remotesitzung in Windows Server 2003-Domänen starten, wenn sie über das Benutzerrecht "Anmeldung über Terminaldienste zulassen" verfügen.

   2. Riskante Konfigurationen
      
      Die folgenden Konfigurationseinstellungen sind schädlich:

      • Entfernen administrativer Sicherheitsgruppen, einschließlich Kontooperatoren, Sicherungsoperatoren, Druckoperatoren oder Serveroperatoren, und der integrierten Administratorengruppe aus der Richtlinie des Standarddomänencontrollers.

      • Dienstkonten, die von Komponenten und Programmen auf Mitgliedscomputern und domänencontrollern in der Domäne verwendet werden, werden aus der Richtlinie des Standarddomänencontrollers entfernt.

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

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

      • Entfernen nicht integrierter Administratorkonten, die sich über Terminaldienste authentifizieren, die auf einem Domänencontroller ausgeführt werden.

      • Hinzufügen aller Benutzerkonten in der Domäne explizit oder implizit über die Gruppe "Jeder" zur lokalen Anmeldeberechtigung "Anmeldung verweigern". Diese Konfiguration verhindert, dass sich Benutzer bei einem Mitgliedscomputer oder einem Domänencontroller in der Domäne anmelden.

   3. Gründe für die Gewährung dieses Benutzerrechts

      • Benutzer müssen über das Recht zum lokalen Anmelden des Benutzers verfügen, um auf die Konsole oder den Desktop eines Arbeitsgruppencomputers, eines Mitgliedscomputers oder eines Domänencontrollers zugreifen zu können.

      • Benutzer müssen über das Recht verfügen, sich über eine Terminaldienstesitzung anzumelden, die auf einem Windows 2000-basierten Mitgliedscomputer oder Domänencontroller ausgeführt wird.

   4. Gründe, dieses Benutzerrecht zu entfernen

      • Wenn der Konsolenzugriff auf legitime Benutzerkonten nicht eingeschränkt wird, kann dies dazu führen, dass nicht autorisierte Benutzer bösartigen Code herunterladen und ausführen, um ihre Benutzerrechte zu ändern.

      • Das Entfernen der Berechtigung "Lokale Anmeldung zulassen" verhindert nicht autorisierte Anmeldungen auf den Konsolen von Computern, z. B. Domänencontrollern oder Anwendungsservern.

      • Das Entfernen dieses Anmelderechts verhindert, dass sich Nicht-Domänenkonten an der Konsole von Mitgliedscomputern in der Domäne anmelden.

   5. Beispiele für Kompatibilitätsprobleme

      • Windows 2000-Terminalserver: Die Berechtigung zum lokalen Anmelden von Benutzern ist erforderlich, damit sich Benutzer bei Windows 2000-Terminalservern anmelden können.

      • Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003: Benutzerkonten muss dieses Benutzerrecht für die Anmeldung an der Konsole von Computern gewährt werden, auf denen Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003 ausgeführt wird.

      • Windows NT 4.0 und höher: Auf Computern, auf denen Windows NT 4.0 und höher ausgeführt wird, können sich die Konten nicht bei der Konsole der Domänencontroller anmelden, wenn Sie das Lokale Benutzerrecht "Anmeldung zulassen" hinzufügen, aber implizit oder explizit auch die lokale Anmeldung verweigern.

3. Umgehen der Traversenüberprüfung

   1. Hintergrund
      
      Die Umgehungsdurchquerungsüberprüfung ermöglicht dem Benutzer das Durchsuchen von Ordnern im NTFS-Dateisystem oder in der Registrierung, ohne nach der speziellen Zugriffsberechtigung für den Ordner "Traverse" zu suchen. Die Umgehungsdurchquerungsüberprüfung mit der Benutzerberechtigung ermöglicht es dem Benutzer nicht, den Inhalt eines Ordners auflisten. Es ermöglicht dem Benutzer, nur seine Ordner zu durchlaufen.

   2. Riskante Konfigurationen
      
      Die folgenden Konfigurationseinstellungen sind schädlich:

      • Entfernen nicht administrativer Konten, die sich bei Windows 2000-basierten Terminaldienstecomputern oder Windows Server 2003-basierten Terminaldienstecomputern anmelden, die nicht über berechtigungen für den Zugriff auf Dateien und Ordner im Dateisystem verfügen.

      • Entfernen der Gruppe "Jeder" aus der Liste der Sicherheitsprinzipale, für die dieser Benutzer standardmäßig das Recht hat. Windows-Betriebssysteme und viele Programme sind mit der Erwartung konzipiert, dass jeder, der rechtmäßig auf den Computer zugreifen kann, das Recht auf Umgehungsdurchquerungsüberprüfung hat. Daher kann das Entfernen der Gruppe "Jeder" aus der Liste der Sicherheitsprinzipale, die standardmäßig über dieses Benutzerrecht verfügen, zu Instabilität des Betriebssystems oder zu Programmfehlern führen. Es ist besser, diese Einstellung auf dem Standardwert zu belassen.

   3. Gründe für die Gewährung dieses Benutzerrechts
      
      Die Standardeinstellung für die Benutzerberechtigung für die Umgehungsdurchquerungsprüfung besteht darin, jedem die Umgehung der Durchquerungsprüfung zu ermöglichen. Für erfahrene Windows-Systemadministratoren ist dies das erwartete Verhalten, und sie konfigurieren Dateisystem-Zugriffssteuerungslisten (SACLs) entsprechend. Das einzige Szenario, in dem die Standardkonfiguration zu einem Mishap führen kann, ist, wenn der Administrator, der Berechtigungen konfiguriert, das Verhalten nicht versteht und erwartet, dass Benutzer, die nicht auf einen übergeordneten Ordner zugreifen können, nicht auf die Inhalte von untergeordneten Ordnern zugreifen können.

   4. Gründe, dieses Benutzerrecht
      
      zu entfernen Um zu versuchen, den Zugriff auf die Dateien oder Ordner im Dateisystem zu verhindern, sind Organisationen, die sehr besorgt über die Sicherheit sind, möglicherweise versucht, die Gruppe "Jeder" oder sogar die Gruppe "Benutzer" aus der Liste der Gruppen zu entfernen, für die das Recht der Benutzerüberprüfung "Umgehen" gilt.

   5. Beispiele für Kompatibilitätsprobleme

      • Windows 2000, Windows Server 2003: Wenn die Überprüfung der Benutzerberechtigung für die Umgehungsdurchsicht entfernt oder auf Computern mit Windows 2000 oder Windows Server 2003 falsch konfiguriert ist, werden Gruppenrichtlinie Einstellungen im Ordner "SYVOL" nicht zwischen Domänencontrollern in der Domäne repliziert.

      • Windows 2000, Windows XP Professional, Windows Server 2003: Computer, auf denen Windows 2000, Windows XP Professional oder Windows Server 2003 ausgeführt wird, protokollieren die Ereignisse 1000 und 1202 und können keine Computerrichtlinie und Benutzerrichtlinie anwenden, wenn die erforderlichen Dateisystemberechtigungen aus der SYSVOL-Struktur entfernt werden, wenn die Umgehungsdurchsicht zur Überprüfung der Benutzerrechte entfernt oder falsch konfiguriert wird.
        
         

      • Windows 2000, Windows Server 2003: Auf Computern mit Windows 2000 oder Windows Server 2003 wird die Registerkarte " Kontingent " im Windows-Explorer ausgeblendet, wenn Sie Eigenschaften auf einem Volume anzeigen.

      • Windows 2000: Nicht-Administratoren, die sich bei einem Windows 2000-Terminalserver anmelden, erhalten möglicherweise die folgende Fehlermeldung:

        Userinit.exe Anwendungsfehler. Die Anwendung konnte nicht ordnungsgemäß initialisiert werden, 0xc0000142 klicken Sie auf "OK", um die App zu beenden.

      • Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Benutzer, auf deren Computern Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003 ausgeführt wird, können möglicherweise nicht auf freigegebene Ordner oder Dateien in freigegebenen Ordnern zugreifen, und sie erhalten möglicherweise Fehlermeldungen vom Typ "Zugriff verweigert", wenn ihnen nicht die Umgehungsüberprüfung des Benutzerrechts gewährt wird.
        
        
         

      • Windows NT 4.0: Auf Windows NT 4.0-basierten Computern führt das Entfernen der Umgehungsdurchquerungsprüfung dazu, dass eine Dateikopie Dateidatenströme ablaget. Wenn Sie dieses Benutzerrecht entfernen und eine Datei von einem Windows-Client oder einem Macintosh-Client auf einen Windows NT 4.0-Domänencontroller kopiert wird, auf dem Services für Macintosh ausgeführt wird, geht der Zieldateidatenstrom verloren, und die Datei wird als nur Textdatei angezeigt.

      • Microsoft Windows 95, Microsoft Windows 98: Auf einem Clientcomputer, auf dem Windows 95 oder Windows 98 ausgeführt wird, schlägt der Befehl "Net Use * /home" mit der Fehlermeldung "Zugriff verweigert" fehl, wenn der Gruppe "Authentifizierte Benutzer" nicht das Umgehungsdurchlaufüberprüfungs-Benutzerrecht gewährt wird.

      • Outlook Web Access: Nicht-Administratoren können sich nicht bei Microsoft Outlook Web Access anmelden, und sie erhalten die Fehlermeldung "Zugriff verweigert", wenn ihnen das Umgehungsdurchquerungsüberprüfungs-Benutzerrecht nicht gewährt wird.

Sicherheitseinstellungen

Die folgende Liste identifiziert eine Sicherheitseinstellung, und die geschachtelte Liste enthält eine Beschreibung der Sicherheitseinstellung, identifiziert Konfigurationseinstellungen, die Probleme verursachen können, beschreibt, warum Sie die Sicherheitseinstellung anwenden sollten, und beschreibt dann Gründe, warum Sie die Sicherheitseinstellung möglicherweise entfernen möchten. Die geschachtelte Liste stellt dann einen symbolischen Namen für die Sicherheitseinstellung und den Registrierungspfad der Sicherheitseinstellung bereit. Schließlich werden Beispiele für Kompatibilitätsprobleme bereitgestellt, die auftreten können, wenn die Sicherheitseinstellung konfiguriert ist.

1. Überwachung: System sofort herunterfahren, wenn Sicherheitsüberwachungen nicht protokolliert werden können

   1. Hintergrund

      • Die Einstellung "Überwachung: System sofort herunterfahren", wenn die Einstellung für Sicherheitsüberwachungen nicht protokolliert werden kann, bestimmt, ob das System heruntergefahren wird, wenn Sie Keine Sicherheitsereignisse protokollieren können. Diese Einstellung ist für die C2-Bewertung des Trusted Computer Security Evaluation Criteria (TCSEC)-Programms und für die Allgemeinen Kriterien für die Sicherheitsbewertung der Informationstechnologie erforderlich, um überwachbare Ereignisse zu verhindern, wenn das Überwachungssystem diese Ereignisse nicht protokollieren kann. Wenn das Überwachungssystem fehlschlägt, wird das System heruntergefahren, und es wird eine Stopp-Fehlermeldung angezeigt.

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

   2. Riskante Konfiguration
      
      Die folgende Konfigurationseinstellung ist schädlich: Die Überwachungseinstellung: Das System wird sofort heruntergefahren, wenn die Einstellung für Sicherheitsüberwachungen nicht protokolliert werden kann, und die Größe des Sicherheitsereignisprotokolls wird durch die Option "Ereignisse nicht überschreiben" (Protokoll manuell löschen), die Option "Ereignisse bei Bedarf überschreiben" oder die Option "Ereignisse älter als Anzahl Tage überschreiben" in Ereignisanzeige eingeschränkt. Informationen zu bestimmten Risiken für Computer, auf denen die ursprünglich veröffentlichte Version von Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 oder Windows 2000 SP3 ausgeführt wird, finden Sie im Abschnitt "Beispiele für Kompatibilitätsprobleme".

   3. Gründe für die Aktivierung dieser Einstellung
      
      Wenn der Computer keine Ereignisse im Sicherheitsprotokoll aufzeichnen kann, sind wichtige Nachweise oder wichtige Informationen zur Problembehandlung nach einem Sicherheitsvorfall möglicherweise nicht zur Überprüfung verfügbar.

   4. Gründe für die Deaktivierung dieser Einstellung

      • Aktivieren der Überwachung: Das System wird sofort heruntergefahren, wenn die Einstellung für Sicherheitsüberwachungen nicht protokolliert werden kann, wenn aus irgendeinem Grund keine Sicherheitsüberwachung protokolliert werden kann. In der Regel kann ein Ereignis nicht protokolliert werden, wenn das Sicherheitsüberwachungsprotokoll voll ist und die angegebene Aufbewahrungsmethode entweder die Option "Ereignisse nicht überschreiben" (Protokoll manuell löschen) oder die Option "Ereignisse überschreiben, die älter als Anzahl Tage sind" ist.

      • Der Verwaltungsaufwand für die Aktivierung der Überwachung: Das System sofort herunterfahren, wenn die Einstellung für Sicherheitsüberwachungen nicht protokolliert werden kann, kann sehr hoch sein, insbesondere, wenn Sie auch die Option "Ereignisse nicht überschreiben" (Protokoll manuell löschen) für das Sicherheitsprotokoll aktivieren. Diese Einstellung ermöglicht die individuelle Verantwortlichkeit von Operatoraktionen. Beispielsweise könnte ein Administrator Berechtigungen für alle Benutzer, Computer und Gruppen in einer Organisationseinheit (OU) zurücksetzen, in der die Überwachung mithilfe des integrierten Administratorkontos oder eines anderen freigegebenen Kontos aktiviert wurde, und dann verweigern, dass diese Berechtigungen zurückgesetzt wurden. Das Aktivieren der Einstellung verringert jedoch die Robustheit des Systems, da ein Server möglicherweise gezwungen ist, herunterzufahren, indem er ihn mit Anmeldeereignissen und anderen Sicherheitsereignissen überlastet, die in das Sicherheitsprotokoll geschrieben wurden. Da das Herunterfahren nicht ordnungsgemäß erfolgt, kann es zu irreparablen Schäden am Betriebssystem, an Programmen oder Daten kommen. Während NTFS garantiert, dass die Integrität des Dateisystems während eines nicht ordnungsgemäßem Herunterfahrens des Systems beibehalten wird, kann nicht garantiert werden, dass jede Datendatei für jedes Programm beim Neustart des Systems weiterhin in einer verwendbaren Form ist.

   5. Symbolischer Name:
      
      Crashonauditfail

   6. Registrierungspfad:

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

   7. Beispiele für Kompatibilitätsprobleme

      • Windows 2000: Aufgrund eines Fehlers können Computer, auf denen die ursprünglich veröffentlichte Version von Windows 2000, Windows 2000 SP1, Windows 2000 SP2 oder Windows Server SP3 ausgeführt wird, die Protokollierung von Ereignissen beenden, bevor die in der Option "Maximale Protokollgröße" für das Sicherheitsereignisprotokoll angegebene Größe erreicht wird. Dieser Fehler wurde in Windows 2000 Service Pack 4 (SP4) behoben. Stellen Sie sicher, dass auf Ihren Windows 2000-Domänencontrollern Windows 2000 Service Pack 4 installiert ist, bevor Sie diese Einstellung aktivieren.
        
         

      • Windows 2000, Windows Server 2003: Computer, auf denen Windows 2000 oder Windows Server 2003 ausgeführt wird, reagieren möglicherweise nicht mehr und können dann spontan neu gestartet werden, wenn die Einstellung "Überwachung: System sofort herunterfahren", wenn die Einstellung für Sicherheitsüberwachungen nicht aktiviert ist, das Sicherheitsprotokoll voll ist und ein vorhandener Ereignisprotokolleintrag nicht überschrieben werden kann. Wenn der Computer neu gestartet wird, wird die folgende Stopp-Fehlermeldung angezeigt:

        STOP: C0000244 {Audit Failed}
        Fehler beim Versuch, eine Sicherheitsüberwachung zu generieren.

        Zur Wiederherstellung muss sich ein Administrator anmelden, das Sicherheitsprotokoll archivieren (optional), das Sicherheitsprotokoll löschen und diese Option zurücksetzen (optional und nach Bedarf).

      • Microsoft-Netzwerkclient für MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Nicht-Administratoren, die versuchen, sich bei einer Domäne anzumelden, erhalten die folgende Fehlermeldung:

        Ihr Konto ist so konfiguriert, dass Sie diesen Computer nicht verwenden können. Versuchen Sie es bitte mit einem anderen Computer.

      • Windows 2000: Auf Windows 2000-basierten Computern können sich Nichtadministratoren nicht bei Remotezugriffsservern anmelden, und sie erhalten eine Fehlermeldung, die der folgenden ähnelt:

        Unbekannter Benutzer oder ungültiges Kennwort

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

      • Windows 2000: Auf Windows 2000-Domänencontrollern schlägt die Active Directory-Replikation fehl, und wenn das Sicherheitsereignisprotokoll voll ist, wird die Meldung "Zugriff verweigert" angezeigt.

      • Microsoft Exchange 2000: Server, auf denen Exchange 2000 ausgeführt wird, können die Informationsspeicherdatenbank nicht bereitstellen, und Ereignis 2102 wird im Ereignisprotokoll registriert.

      • Outlook, Outlook Web Access: Nicht-Administratoren können nicht über Microsoft Outlook oder Microsoft Outlook Web Access auf ihre E-Mails zugreifen, und sie erhalten einen 503-Fehler.

2. Domänencontroller: Ldap-Serversignaturanforderungen

   1. Hintergrund
      
      Die Sicherheitseinstellung "Domänencontroller: LDAP-Serversignaturanforderungen" bestimmt, ob der LDAP-Server (Lightweight Directory Access Protocol) LDAP-Clients zum Aushandeln der Datensignierung benötigt. Die folgenden Werte sind für diese Richtlinieneinstellung möglich:

      • Keine: Zum Binden an den Server ist keine Datensignatur erforderlich. Wenn der Client die Datensignierung anfordert, unterstützt der Server dies.

      • Signieren erforderlich: Die LDAP-Datensignierungsoption muss ausgehandelt werden, es sei denn, Transport Layer Security/Secure Socket Layer (TLS/SSL) wird verwendet.

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

   2. Riskante Konfigurationen
      
      Die folgenden Konfigurationseinstellungen sind schädlich:

      • Aktivieren von Require signing in environments where clients do not support LDAP signing or where client-side LDAP signing is not enabled on the client

      • Anwenden der Sicherheitsvorlage "Windows 2000" oder "Windows Server 2003 Hisecdc.inf" in Umgebungen, in denen die Clients die LDAP-Signatur nicht unterstützen oder die clientseitige LDAP-Signatur nicht aktiviert ist

      • Anwenden der Sicherheitsvorlage Windows 2000 oder Windows Server 2003 Hisecws.inf in Umgebungen, in denen die Clients die LDAP-Signatur nicht unterstützen oder die clientseitige LDAP-Signatur nicht aktiviert ist

   3. Gründe für die Aktivierung dieser Einstellung
      
      Nicht signierter Netzwerkdatenverkehr ist anfällig für Man-in-the-Middle-Angriffe, bei denen ein Eindringling Pakete zwischen dem Client und dem Server erfasst, die Pakete ändert und diese dann an den Server weiterleitet. Wenn dieses Verhalten auf einem LDAP-Server auftritt, kann ein Angreifer einen Server dazu veranlassen, Entscheidungen zu treffen, die auf falschen Abfragen vom LDAP-Client basieren. Sie können dieses Risiko in einem Unternehmensnetzwerk verringern, indem Sie starke physische Sicherheitsmaßnahmen zum Schutz der Netzwerkinfrastruktur implementieren. Der IPSec-Authentifizierungsheadermodus (Internet Protocol Security) kann dazu beitragen, Man-in-the-Middle-Angriffe zu verhindern. Der Authentifizierungsheadermodus führt die gegenseitige Authentifizierung und Paketintegrität für IP-Datenverkehr durch.

   4. Gründe für die Deaktivierung dieser Einstellung

      • Clients, die die LDAP-Signatur nicht unterstützen, können keine LDAP-Abfragen für Domänencontroller und globale Kataloge durchführen, wenn die NTLM-Authentifizierung ausgehandelt wird und die richtigen Service Packs nicht auf Windows 2000-Domänencontrollern installiert sind.

      • Netzwerkablaufverfolgungen des LDAP-Datenverkehrs zwischen Clients und Servern werden verschlüsselt. Dies erschwert die Untersuchung von LDAP-Unterhaltungen.

      • Auf Windows 2000-basierten Servern muss Windows 2000 Service Pack 3 (SP3) installiert sein, wenn sie mit Programmen verwaltet werden, die LDAP-Signaturen unterstützen, die von Clientcomputern ausgeführt werden, auf denen Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt wird.  

   5. Symbolischer Name:
      
      LDAPServerIntegrity

   6. Registrierungspfad:

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

   7. Beispiele für Kompatibilitätsprobleme

      • Einfache Bindungen schlagen fehl, und Sie erhalten die folgende Fehlermeldung:

        Ldap_simple_bind_s() fehlgeschlagen: Starke Authentifizierung erforderlich.

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Auf Clients, auf denen Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt wird, funktionieren einige Active Directory-Verwaltungstools nicht ordnungsgemäß für Domänencontroller, auf denen Versionen von Windows 2000 ausgeführt werden, die vor SP3 liegen, wenn die NTLM-Authentifizierung ausgehandelt wird.
        
         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Auf Clients, auf denen Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt wird, funktionieren einige Active Directory-Verwaltungstools für Domänencontroller, auf denen Versionen von Windows 2000 vor SP3 ausgeführt werden, nicht ordnungsgemäß, wenn sie IP-Adressen verwenden (z. B. "dsa.msc /server=x.x.x.x", wobei
        "x.x.x.x " eine IP-Adresse ist).
        
        
         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Auf Clients, auf denen Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt wird, funktionieren einige Active Directory-Verwaltungstools für Domänencontroller, auf denen Frühere Versionen von Windows 2000 als SP3 ausgeführt werden, nicht ordnungsgemäß.
        
         

3. Domänenmitglied: Erfordern eines starken Sitzungsschlüssels (Windows 2000 oder höher)

   1. Hintergrund

      • Das Domänenmitglied: Die Einstellung für einen starken Sitzungsschlüssel (Windows 2000 oder höher) bestimmt, ob ein sicherer Kanal mit einem Domänencontroller eingerichtet werden kann, der sicheren Kanaldatenverkehr nicht mit einem starken 128-Bit-Sitzungsschlüssel verschlüsseln kann. Durch Aktivieren dieser Einstellung wird die Einrichtung eines sicheren Kanals mit jedem Domänencontroller verhindert, der sichere Kanaldaten mit einem starken Schlüssel nicht verschlüsseln kann. Das Deaktivieren dieser Einstellung ermöglicht 64-Bit-Sitzungsschlüssel.

      • Bevor Sie diese Einstellung auf einer Mitgliedsarbeitsstation oder auf einem Server aktivieren können, müssen alle Domänencontroller in der Domäne, zu der das Mitglied gehört, sichere Kanaldaten mit einem starken 128-Bit-Schlüssel verschlüsseln können. Dies bedeutet, dass auf allen solchen Domänencontrollern Windows 2000 oder höher ausgeführt werden muss.

   2. Riskante Konfiguration
      
      Aktivieren des Domänenmitglieds: Die Einstellung für den starken Sitzungsschlüssel (Windows 2000 oder höher) ist eine schädliche Konfigurationseinstellung.

   3. Gründe für die Aktivierung dieser Einstellung

      • Sitzungsschlüssel, die zum Herstellen einer sicheren Kanalkommunikation zwischen Mitgliedscomputern und Domänencontrollern verwendet werden, sind in Windows 2000 wesentlich stärker als in früheren Versionen von Microsoft-Betriebssystemen.

      • Wenn dies möglich ist, empfiehlt es sich, diese stärkeren Sitzungsschlüssel zu nutzen, um die sichere Kanalkommunikation vor Lauschangriffen und Angriffen durch Sitzungsentführer zu schützen. Lauschangriffe sind eine Form böswilliger Angriffe, bei denen Netzwerkdaten während der Übertragung gelesen oder geändert werden. Die Daten können geändert werden, um den Absender auszublenden oder zu ändern oder umzuleiten.

      Wichtig Ein Computer mit Windows Server 2008 R2 oder Windows 7 unterstützt nur sichere Schlüssel, wenn sichere Kanäle verwendet werden. Diese Einschränkung verhindert eine Vertrauensstellung zwischen einer windows NT 4.0-basierten Domäne und einer Windows Server 2008 R2-basierten Domäne. Darüber hinaus blockiert diese Einschränkung die Windows NT 4.0-basierte Domänenmitgliedschaft von Computern, auf denen Windows 7 oder Windows Server 2008 R2 ausgeführt wird, und umgekehrt.

   4. Gründe für die Deaktivierung dieser Einstellung
      
      Die Domäne enthält Mitgliedscomputer, auf denen andere Betriebssysteme als Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden.

   5. Symbolischer Name:
      
      StrongKey

   6. Registrierungspfad:

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

   7. Beispiele für Kompatibilitätsprobleme
      
      Windows NT 4.0: Auf Windows NT 4.0-basierten Computern schlägt das Zurücksetzen sicherer Kanäle mit Vertrauensstellungen zwischen Windows NT 4.0- und Windows 2000-Domänen mit NLTEST fehl. Die Fehlermeldung "Zugriff verweigert" wird angezeigt:

      Fehler bei der Vertrauensstellung zwischen der primären Domäne und der vertrauenswürdigen Domäne.
      
      Windows 7 und Server 2008 R2: Für Windows 7 und höhere Versionen und Windows Server 2008 R2 und höhere Versionen wird diese Einstellung nicht mehr berücksichtigt, und der starke Schlüssel wird immer verwendet. Aus diesem Grund funktionieren Vertrauensstellungen mit Windows NT 4.0-Domänen nicht mehr.

4. Domänenmitglied: Digitale Verschlüsselung oder Signation sicherer Kanaldaten (immer)

   1. Hintergrund

      • Aktivieren eines Domänenmitglieds: Das digitale Verschlüsseln oder Signen von Daten für sicheren Kanal (immer) verhindert die Einrichtung eines sicheren Kanals mit jedem Domänencontroller, der nicht alle Daten des sicheren Kanals sign oder verschlüsseln kann. Um den Authentifizierungsdatenverkehr vor Man-in-the-Middle-Angriffen, Wiederholungsangriffen und anderen Arten von Netzwerkangriffen zu schützen, erstellen Windows-basierte Computer einen Kommunikationskanal, der als sicherer Kanal über den Net Logon-Dienst bekannt ist, um Computerkonten zu authentifizieren. Sichere Kanäle werden auch verwendet, wenn ein Benutzer in einer Domäne eine Verbindung mit einer Netzwerkressource in einer Remotedomäne herstellt. Diese Mehrdomänenauthentifizierung oder Pass-Through-Authentifizierung ermöglicht einem Windows-basierten Computer, der einer Domäne beigetreten ist, Zugriff auf die Benutzerkontodatenbank in seiner Domäne und in allen vertrauenswürdigen Domänen zu haben.

      • Um das Domänenmitglied zu aktivieren: Die Einstellung für sichere Kanaldaten (immer) auf einem Mitgliedscomputer digital verschlüsseln oder signieren, müssen alle Domänencontroller in der Domäne, zu der das Mitglied gehört, alle Sicheren Kanaldaten signieren oder verschlüsseln können. Dies bedeutet, dass auf allen solchen Domänencontrollern Windows NT 4.0 mit Service Pack 6a (SP6a) oder höher ausgeführt werden muss.

      • Aktivieren des Domänenmitglieds: Die Einstellung zum digitalen Verschlüsseln oder Signen von Sicheren Kanaldaten (immer) aktiviert automatisch das Domänenmitglied: Einstellung für das digitale Verschlüsseln oder Signen von Sicheren Kanaldaten (wenn möglich).

   2. Riskante Konfiguration
      
      Aktivieren des Domänenmitglieds: Die Einstellung zum digitalen Verschlüsseln oder Signen von Sicheren Kanaldaten (immer) in Domänen, in denen nicht alle Domänencontroller sichere Kanaldaten signiert oder verschlüsseln können, ist eine schädliche Konfigurationseinstellung.

   3. Gründe für die Aktivierung dieser Einstellung
      
      Nicht signierter Netzwerkdatenverkehr ist anfällig für Man-in-the-Middle-Angriffe, bei denen ein Eindringling Pakete zwischen dem Server und dem Client erfasst und diese dann ändert, bevor er sie an den Client weiterleitet. Wenn dieses Verhalten auf einem LDAP-Server (Lightweight Directory Access Protocol) auftritt, kann der Eindringling dazu führen, dass ein Client Entscheidungen treffen kann, die auf falschen Datensätzen aus dem LDAP-Verzeichnis basieren. Sie können das Risiko eines solchen Angriffs auf ein Unternehmensnetzwerk verringern, indem Sie starke physische Sicherheitsmaßnahmen zum Schutz der Netzwerkinfrastruktur implementieren. Darüber hinaus kann die Implementierung des IPSec-Authentifizierungsheadermodus (Internet Protocol Security) dazu beitragen, Man-in-the-Middle-Angriffe zu verhindern. Dieser Modus führt die gegenseitige Authentifizierung und Paketintegrität für IP-Datenverkehr aus.

   4. Gründe für die Deaktivierung dieser Einstellung

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

      • Nicht alle Domänencontroller in der Domäne verfügen über die entsprechenden Service Pack-Revisionsebenen, um verschlüsselte sichere Kanäle zu unterstützen.

   5. Symbolischer Name:
      
      StrongKey

   6. Registrierungspfad:

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

   7. Beispiele für Kompatibilitätsprobleme

      • Windows NT 4.0: Windows 2000-basierte Mitgliedscomputer können windows NT 4.0-Domänen nicht beitreten und erhalten die folgende Fehlermeldung:

        Das Konto ist nicht berechtigt, sich von dieser Station aus anzumelden.

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

        281648 Fehlermeldung: Das Konto ist nicht berechtigt, sich von dieser Station aus anzumelden.
         

      • Windows NT 4.0: Windows NT 4.0-Domänen können bei einer Windows 2000-Domäne keine Vertrauensstellung auf untergeordneter Ebene einrichten und erhalten die folgende Fehlermeldung:

        Das Konto ist nicht berechtigt, sich von dieser Station aus anzumelden.

        Vorhandene Vertrauensstellungen auf untergeordneter Ebene authentifizieren möglicherweise auch keine Benutzer aus der vertrauenswürdigen Domäne. Einige Benutzer haben möglicherweise Probleme beim Anmelden bei der Domäne, und sie erhalten möglicherweise eine Fehlermeldung, die besagt, dass der Client die Domäne nicht finden kann.

      • Windows XP: Windows XP-Clients, die mit Windows NT 4.0-Domänen verbunden sind, können anmeldeversuche nicht authentifizieren und erhalten möglicherweise die folgende Fehlermeldung, oder die folgenden Ereignisse werden im Ereignisprotokoll registriert:

        Windows kann keine Verbindung mit der Domäne herstellen, weil der Domänencontroller ausgefallen oder anderweitig nicht verfügbar ist oder weil Ihr Computerkonto nicht gefunden wurde.

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

        Anmeldefehler: unbekannter Benutzername oder ungültiges Kennwort.

        Für die angegebene Anmeldesitzung ist kein Benutzersitzungsschlüssel vorhanden.

5. Microsoft-Netzwerkclient: Kommunikation digital signieren (immer)

   1. Hintergrund
      
      Server Message Block (SMB) ist das Ressourcenfreigabeprotokoll, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Basis des Netzwerk-Basis-Eingabe-/Ausgabesystems (NetBIOS) und vieler anderer Protokolle. Die SMB-Signatur authentifiziert sowohl den Benutzer als auch den Server, auf dem die Daten gehostet werden. Wenn bei beiden Seiten der Authentifizierungsprozess fehlschlägt, erfolgt keine Datenübertragung.
      
      Das Aktivieren der SMB-Signatur beginnt während der SMB-Protokollverhandlung. Die SMB-Signaturrichtlinien bestimmen, ob der Computer die Clientkommunikation immer digital signiert.
      
      Das Windows 2000 SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung schließt einen "Man-in-the-Middle"-Angriff. Das Windows 2000 SMB-Authentifizierungsprotokoll unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung trägt dazu bei, aktive Nachrichtenangriffe zu verhindern. Um Ihnen diese Authentifizierung zu ermöglichen, fügt die SMB-Signatur in jedem SMB eine digitale Signatur ein. Der Client und der Server überprüfen jeweils die digitale Signatur.
      
      Um die SMB-Signatur zu verwenden, müssen Sie die SMB-Signatur aktivieren oder SMB-Signierung sowohl auf dem SMB-Client als auch auf dem SMB-Server anfordern. Wenn die SMB-Signatur auf einem Server aktiviert ist, verwenden Clients, die auch für die SMB-Signatur aktiviert sind, das Paketsignierungsprotokoll während aller nachfolgenden Sitzungen. Wenn SMB-Signierung auf einem Server erforderlich ist, kann ein Client keine Sitzung einrichten, es sei denn, der Client ist für die SMB-Signatur aktiviert oder erforderlich.
      
      
      Die Aktivierung der digitalen Signierung in Hochsicherheitsnetzwerken trägt dazu bei, den Identitätswechsel von Clients und Servern zu verhindern. Diese Art des Identitätswechsels wird als Session Hijacking bezeichnet. Ein Angreifer, der Zugriff auf das gleiche Netzwerk wie der Client oder der Server hat, verwendet Session Hijacking-Tools, um eine laufende Sitzung zu unterbrechen, zu beenden oder zu stehlen. Ein Angreifer könnte nicht signierte SMB-Pakete abfangen und ändern, den Datenverkehr ändern und dann weiterleiten, damit der Server unerwünschte Aktionen ausführen kann. Oder der Angreifer kann sich nach einer legitimen Authentifizierung als Server oder als Client darstellen und dann nicht autorisierten Zugriff auf Daten erhalten.
      
      Das SMB-Protokoll, das für die Dateifreigabe und die Druckfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 verwendet wird, unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung schließt Session Hijacking-Angriffe und unterstützt die Nachrichtenauthentifizierung. Daher verhindert es Man-in-the-Middle-Angriffe. Die SMB-Signatur stellt diese Authentifizierung bereit, indem in jedem SMB eine digitale Signatur platziert wird. Der Client und der Server überprüfen dann die Signatur.
      
      Notizen

      • Als alternative Gegenmaßnahme können Sie digitale Signaturen mit IPSec aktivieren, um den gesamten Netzwerkdatenverkehr zu schützen. Es gibt hardwarebasierte Zugriffstasten für IPSec-Verschlüsselung und -Signierung, die Sie verwenden können, um die Leistungseinbußen durch die CPU des Servers zu minimieren. Es gibt keine solchen Zugriffstasten, die für die SMB-Signatur verfügbar sind.
        
        Weitere Informationen finden Sie im Kapitel " Digitales Signieren der Serverkommunikation " auf der Microsoft MSDN-Website.
        
        Konfigurieren Sie die SMB-Signierung über Gruppenrichtlinie Objekt-Editor, da eine Änderung an einem lokalen Registrierungswert keine Auswirkung hat, wenn eine übergeordnete Domänenrichtlinie vorhanden ist.

      • In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienstclient die SMB-Signatur, wenn er sich mit Windows Server 2003-Servern mithilfe der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signierung, wenn sie sich mithilfe der NTLMv2-Authentifizierung bei diesen Servern authentifizieren. Darüber hinaus reagieren Windows 2000-Server nicht auf SMB-Signaturanforderungen von diesen Clients. Weitere Informationen finden Sie unter Punkt 10: "Netzwerksicherheit: Lan Manager-Authentifizierungsebene".

   2. Riskante Konfiguration
      
      Es folgt eine schädliche Konfigurationseinstellung: Verlassen des Microsoft-Netzwerkclients: Einstellung "Kommunikation digital signieren (immer)" und Microsoft-Netzwerkclient: Einstellung "Kommunikation digital signieren(wenn Server zustimmt)" auf "Nicht definiert" oder deaktiviert. Diese Einstellungen ermöglichen es dem Umleitungsmodul, Nur-Text-Kennwörter an Nicht-Microsoft-SMB-Server zu senden, die die Kennwortverschlüsselung während der Authentifizierung nicht unterstützen.

   3. Gründe für die Aktivierung dieser Einstellung
      
      Aktivieren des Microsoft-Netzwerkclients: Die kommunikation digital signieren (immer) erfordert, dass Clients SMB-Datenverkehr signieren, wenn sie Server kontaktieren, für die keine SMB-Signatur erforderlich ist. Dies macht Clients weniger anfällig für Session Hijacking-Angriffe.

   4. Gründe für die Deaktivierung dieser Einstellung

      • Aktivieren des Microsoft-Netzwerkclients: Kommunikation (immer) digital signieren verhindert, dass Clients mit Zielservern kommunizieren, die keine SMB-Signierung unterstützen.

      • Wenn Computer so konfiguriert werden, dass alle nicht signierten SMB-Kommunikationen ignoriert werden, wird verhindert, dass frühere Programme und Betriebssysteme eine Verbindung herstellen.

   5. Symbolischer Name:
      
      RequireSMBSignRdr

   6. Registrierungspfad:

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

   7. Beispiele für Kompatibilitätsprobleme

      • Windows NT 4.0: Sie können den sicheren Kanal einer Vertrauensstellung zwischen einer Windows Server 2003-Domäne und einer Windows NT 4.0-Domäne nicht mithilfe von NLTEST oder NETDOM zurücksetzen, und Sie erhalten die Fehlermeldung "Zugriff verweigert".

      • Windows XP: Das Kopieren von Dateien von Windows XP-Clients auf Windows 2000-basierte Server und auf Windows Server 2003-basierte Server kann mehr Zeit in Anspruch nehmen.

      • Sie können kein Netzlaufwerk von einem Client zuordnen, auf dem diese Einstellung aktiviert ist, und Sie erhalten die folgende Fehlermeldung:

        Das Konto ist nicht berechtigt, sich von dieser Station aus anzumelden.

   8. Neustartanforderungen
      
      Starten Sie den Computer neu, oder starten Sie den Workstation-Dienst neu. Geben Sie dazu die folgenden Befehle an einer Eingabeaufforderung ein. Drücken Sie die EINGABETASTE, nachdem Sie jeden Befehl eingegeben haben.

      Net Stop Workstation
      Net Start Workstation

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

   1. Hintergrund

      • Server Messenger Block (SMB) ist das Ressourcenfreigabeprotokoll, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Basis des Netzwerk-Basis-Eingabe-/Ausgabesystems (NetBIOS) und vieler anderer Protokolle. Die SMB-Signatur authentifiziert sowohl den Benutzer als auch den Server, auf dem die Daten gehostet werden. Wenn bei beiden Seiten der Authentifizierungsprozess fehlschlägt, erfolgt keine Datenübertragung.
        
        Das Aktivieren der SMB-Signatur beginnt während der SMB-Protokollverhandlung. Die SMB-Signaturrichtlinien bestimmen, ob der Computer die Clientkommunikation immer digital signiert.
        
        Das Windows 2000 SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung schließt einen "Man-in-the-Middle"-Angriff. Das Windows 2000 SMB-Authentifizierungsprotokoll unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung trägt dazu bei, aktive Nachrichtenangriffe zu verhindern. Um Ihnen diese Authentifizierung zu ermöglichen, fügt die SMB-Signatur in jedem SMB eine digitale Signatur ein. Der Client und der Server überprüfen jeweils die digitale Signatur.
        
        Um die SMB-Signatur zu verwenden, müssen Sie die SMB-Signatur aktivieren oder SMB-Signierung sowohl auf dem SMB-Client als auch auf dem SMB-Server anfordern. Wenn die SMB-Signatur auf einem Server aktiviert ist, verwenden Clients, die auch für die SMB-Signatur aktiviert sind, das Paketsignierungsprotokoll während aller nachfolgenden Sitzungen. Wenn SMB-Signierung auf einem Server erforderlich ist, kann ein Client keine Sitzung einrichten, es sei denn, der Client ist für die SMB-Signatur aktiviert oder erforderlich.
        
        
        Die Aktivierung der digitalen Signierung in Hochsicherheitsnetzwerken trägt dazu bei, den Identitätswechsel von Clients und Servern zu verhindern. Diese Art des Identitätswechsels wird als Session Hijacking bezeichnet. Ein Angreifer, der Zugriff auf das gleiche Netzwerk wie der Client oder der Server hat, verwendet Session Hijacking-Tools, um eine laufende Sitzung zu unterbrechen, zu beenden oder zu stehlen. Ein Angreifer könnte SBM-Pakete (Unsigned Subnet Bandwidth Manager) abfangen und ändern, den Datenverkehr ändern und dann weiterleiten, damit der Server unerwünschte Aktionen ausführen kann. Oder der Angreifer kann sich nach einer legitimen Authentifizierung als Server oder als Client darstellen und dann nicht autorisierten Zugriff auf Daten erhalten.
        
        Das SMB-Protokoll, das für die Dateifreigabe und die Druckfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 verwendet wird, unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung schließt Session Hijacking-Angriffe und unterstützt die Nachrichtenauthentifizierung. Daher verhindert es Man-in-the-Middle-Angriffe. Die SMB-Signatur stellt diese Authentifizierung bereit, indem in jedem SMB eine digitale Signatur platziert wird. Der Client und der Server überprüfen dann die Signatur.

      • Als alternative Gegenmaßnahme können Sie digitale Signaturen mit IPSec aktivieren, um den gesamten Netzwerkdatenverkehr zu schützen. Es gibt hardwarebasierte Zugriffstasten für IPSec-Verschlüsselung und -Signierung, die Sie verwenden können, um die Leistungseinbußen durch die CPU des Servers zu minimieren. Es gibt keine solchen Zugriffstasten, die für die SMB-Signatur verfügbar sind.

      • In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienstclient die SMB-Signatur, wenn er sich mit Windows Server 2003-Servern mithilfe der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signierung, wenn sie sich mithilfe der NTLMv2-Authentifizierung bei diesen Servern authentifizieren. Darüber hinaus reagieren Windows 2000-Server nicht auf SMB-Signaturanforderungen von diesen Clients. Weitere Informationen finden Sie unter Punkt 10: "Netzwerksicherheit: Lan Manager-Authentifizierungsebene".

   2. Riskante Konfiguration
      
      Es folgt eine schädliche Konfigurationseinstellung: Aktivieren des Microsoft-Netzwerkservers: Einstellung für die digitale Signieren der Kommunikation (immer) auf Servern und auf Domänencontrollern, auf die von inkompatiblen Windows-basierten Computern und betriebssystembasierten Clientcomputern von Drittanbietern in lokalen oder externen Domänen zugegriffen wird.

   3. Gründe für die Aktivierung dieser Einstellung

      • Alle Clientcomputer, die diese Einstellung direkt über die Registrierung oder über die Gruppenrichtlinie-Einstellung aktivieren, unterstützen die SMB-Signierung. Mit anderen Worten: Alle Clientcomputer, auf denen diese Einstellung aktiviert ist, führen entweder Windows 95 mit installiertem DS-Client, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional oder Windows Server 2003 aus.

      • Wenn Der Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) deaktiviert ist, ist die SMB-Signatur vollständig deaktiviert. Durch das vollständige Deaktivieren aller SMB-Signaturen sind Computer anfälliger für Session Hijacking-Angriffe.

   4. Gründe für die Deaktivierung dieser Einstellung

      • Das Aktivieren dieser Einstellung kann zu einer langsameren Dateikopie und Netzwerkleistung auf Clientcomputern führen.

      • Durch Aktivieren dieser Einstellung wird verhindert, dass Clients, die keine SMB-Signierung aushandeln können, mit Servern und Domänencontrollern kommunizieren. Dies führt dazu, dass Vorgänge wie Domänenbeitritte, Benutzer- und Computerauthentifizierung oder Netzwerkzugriff durch Programme fehlschlagen.

   5. Symbolischer Name:
      
      RequireSMBSignServer

   6. Registrierungspfad:

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

   7. Beispiele für Kompatibilitätsprobleme

      • Windows 95: Windows 95-Clients, auf denen der Verzeichnisdienste-Client (DS) nicht installiert ist, schlagen bei der Anmeldeauthentifizierung fehl und erhalten die folgende Fehlermeldung:

        Das angegebene Domänenkennwort ist nicht korrekt, oder der Zugriff auf Ihren Anmeldeserver wurde verweigert.

      • Windows NT 4.0: Clientcomputer, auf denen Versionen von Windows NT 4.0 ausgeführt werden, die älter als Service Pack 3 (SP3) sind, schlagen bei der Anmeldeauthentifizierung fehl und erhalten die folgende Fehlermeldung:

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

        Einige nicht von Microsoft stammende SMB-Server unterstützen während der Authentifizierung nur den austausch von unverschlüsselten Kennwörtern. (Diese Börsen werden auch als "Nur-Text-Austausch" bezeichnet.) Für Windows NT 4.0 SP3 und höhere Versionen sendet der SMB-Redirector während der Authentifizierung kein unverschlüsseltes Kennwort an einen SMB-Server, es sei denn, Sie fügen einen bestimmten Registrierungseintrag hinzu.
        Um unverschlüsselte Kennwörter für den SMB-Client unter Windows NT 4.0 SP 3 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
        
         

      • Windows Server 2003: Standardmäßig sind Sicherheitseinstellungen auf Domänencontrollern, auf denen Windows Server 2003 ausgeführt wird, so konfiguriert, dass die Kommunikation mit Domänencontrollern nicht von böswilligen Benutzern abgefangen oder manipuliert wird. Damit Benutzer erfolgreich mit einem Domänencontroller kommunizieren können, auf dem Windows Server 2003 ausgeführt wird, müssen Clientcomputer sowohl die SMB-Signatur als auch die Verschlüsselung oder die Signierung des sicheren Kanaldatenverkehrs verwenden. Standardmäßig ist für Clients, auf denen Windows NT 4.0 mit Service Pack 2 (SP2) oder früher installiert ist, und Clients mit Windows 95 keine SMB-Paketsignierung aktiviert. Daher können sich diese Clients möglicherweise nicht bei einem Windows Server 2003-basierten Domänencontroller authentifizieren.

      • Richtlinieneinstellungen für Windows 2000 und Windows Server 2003: Je nach Ihren spezifischen Installationsanforderungen und Konfiguration empfehlen wir, die folgenden Richtlinieneinstellungen auf die niedrigste Entität des erforderlichen Bereichs in der Microsoft Management Console Gruppenrichtlinie Editor-Snap-In-Hierarchie festzulegen:

        • Computerkonfiguration\Windows-Sicherheit Einstellungen\Sicherheitsoptionen

        • Senden eines unverschlüsselten Kennworts zum Herstellen einer Verbindung mit SMB-Servern von Drittanbietern (diese Einstellung gilt für Windows 2000)

        • Microsoft-Netzwerkclient: Senden eines unverschlüsselten Kennworts an SMB-Server von Drittanbietern (diese Einstellung gilt für Windows Server 2003)

        
        Hinweis: Bei einigen CIFS-Servern von Drittanbietern, z. B. älteren Samba-Versionen, können Sie keine verschlüsselten Kennwörter verwenden.

      • Die folgenden Clients sind nicht mit dem Microsoft-Netzwerkserver kompatibel: Einstellung für die digital signierte Kommunikation (immer):

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

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

        • Microsoft Windows für Arbeitsgruppen-Clients

        • Microsoft Windows 95-Clients ohne installierten DS-Client

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

        • Novell Netware 6 CIFS-Clients

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

   8. Neustartanforderungen
      
      Starten Sie den Computer neu, oder starten Sie den Serverdienst neu. Geben Sie dazu die folgenden Befehle an einer Eingabeaufforderung ein. Drücken Sie die EINGABETASTE, nachdem Sie jeden Befehl eingegeben haben.

      Net Stop-Server
      Net Start Server

7. Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen

   1. Hintergrund
      
      Der Netzwerkzugriff: Die Sicherheitseinstellung "Anonyme SID/Name-Übersetzung zulassen" bestimmt, ob ein anonymer Benutzer SID-Attribute (Security Identification Number) für einen anderen Benutzer anfordern kann.

   2. Riskante Konfiguration
      
      Aktivieren des Netzwerkzugriffs: Anonyme SID/Name-Übersetzungseinstellung zulassen ist eine schädliche Konfigurationseinstellung.

   3. Gründe für die Aktivierung dieser Einstellung
      
      Wenn der Netzwerkzugriff: Anonyme SID/Name-Übersetzungseinstellung zulassen deaktiviert ist, können frühere Betriebssysteme oder Anwendungen möglicherweise nicht mit Windows Server 2003-Domänen kommunizieren. Beispielsweise funktionieren die folgenden Betriebssysteme, Dienste oder Anwendungen möglicherweise nicht:

      • Windows NT 4.0-basierte Remotezugriffsdienstserver

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

      • Remotezugriffsdienst, der auf Windows 2000-basierten Computern ausgeführt wird, die sich in Windows NT 3.x-Domänen oder Windows NT 4.0-Domänen befinden

      • SQL Server, die auf Windows 2000-basierten Computern ausgeführt werden, die sich in Windows NT 3.x-Domänen oder in Windows NT 4.0-Domänen befinden

      • Benutzer in der Windows NT 4.0-Ressourcendomäne, die Berechtigungen für den Zugriff auf Dateien, freigegebene Ordner und Registrierungsobjekte für Benutzerkonten von Kontodomänen erteilen möchten, die Windows Server 2003-Domänencontroller enthalten

   4. Gründe für die Deaktivierung dieser Einstellung
      
      Wenn diese Einstellung aktiviert ist, kann ein böswilliger Benutzer die bekannte Administrator-SID verwenden, um den tatsächlichen Namen des integrierten Administratorkontos abzurufen, auch wenn das Konto umbenannt wurde. Diese Person könnte dann den Kontonamen verwenden, um einen Kennwort-Schätzangriff zu initiieren.

   5. Symbolischer Name: NV

   6. Registrierungspfad: Keine. Der Pfad wird im UI-Code angegeben.

   7. Beispiele für Kompatibilitätsprobleme
      
      Windows NT 4.0: Bei Computern in Windows NT 4.0-Ressourcendomänen wird die Fehlermeldung "Konto unbekannt" im ACL-Editor angezeigt, wenn Ressourcen, einschließlich freigegebener Ordner, freigegebener Dateien und Registrierungsobjekte, mit Sicherheitsprinzipalen gesichert sind, die sich in Kontodomänen befinden, die Windows Server 2003-Domänencontroller enthalten.

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

   1. Hintergrund

      • Netzwerkzugriff: Die Einstellung "Anonyme Aufzählung von SAM-Konten nicht zulassen" bestimmt, welche zusätzlichen Berechtigungen für anonyme Verbindungen mit dem Computer erteilt werden. Windows ermöglicht anonymen Benutzern, bestimmte Aktivitäten auszuführen, z. B. das Aufzählen der Namen von Sam-Konten (Security Accounts Manager) für Arbeitsstationen und Servern sowie von Netzwerkfreigaben. Ein Administrator kann dies beispielsweise verwenden, um Benutzern in einer vertrauenswürdigen Domäne, die keine gegenseitige Vertrauensstellung aufrechterhält, Zugriff zu gewähren. Sobald eine Sitzung durchgeführt wurde, hat ein anonymer Benutzer möglicherweise den gleichen Zugriff, der der Gruppe "Jeder" basierend auf der Einstellung im Netzwerkzugriff gewährt wird: "Jeder-Berechtigungen für anonyme Benutzer übernehmen" oder die optionale Zugriffssteuerungsliste (DACL) des Objekts.
        
        In der Regel werden anonyme Verbindungen von früheren Versionen von Clients (Clients auf niedrigerer Ebene) während der SMB-Sitzungseinrichtung angefordert. In diesen Fällen zeigt eine Netzwerkablaufverfolgung, dass die SMB-Prozess-ID (PID) die Clientumleitung ist, z. B. 0xFEFF in Windows 2000 oder 0xCAFE in Windows NT. RPC kann auch versuchen, anonyme Verbindungen herzustellen.

      • Wichtig Diese Einstellung hat keine Auswirkungen auf Domänencontroller. Auf Domänencontrollern wird dieses Verhalten durch das Vorhandensein von "NT AUTHORITY\ANONYMOUS LOGON" in "Pre-Windows 2000 compatible Access" gesteuert.

      • In Windows 2000 wird mit einer ähnlichen Einstellung namens "Zusätzliche Einschränkungen für anonyme Verbindungen" der Registrierungswert "RestrictAnonymous " verwaltet. Der Speicherort dieses Werts lautet wie folgt:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

   2. Riskante Konfigurationen
      
      Aktivieren des Netzwerkzugriffs: Anonyme Enumeration von SAM-Konten zulassen ist aus Kompatibilitätssicht eine schädliche Konfigurationseinstellung. Das Deaktivieren ist aus Sicherheitssicht eine schädliche Konfigurationseinstellung.

   3. Gründe für die Aktivierung dieser Einstellung
      
      Ein nicht autorisierter Benutzer könnte Kontonamen anonym auflisten und dann die Informationen verwenden, um Kennwörter zu erraten oder Social Engineering-Angriffe auszuführen. Social Engineering ist Jargon, der bedeutet, Menschen dazu zu bringen, ihre Kennwörter oder irgendeine Form von Sicherheitsinformationen preiszugeben.

   4. Gründe für die Deaktivierung dieser Einstellung
      
      Wenn diese Einstellung aktiviert ist, ist es unmöglich, Vertrauensstellungen mit Windows NT 4.0-Domänen einzurichten. Diese Einstellung verursacht auch Probleme mit Abwärtsclients (z. B. Windows NT 3.51-Clients und Windows 95-Clients), die versuchen, Ressourcen auf dem Server zu verwenden.

   5. Symbolischer Name:
      
      
      RestrictAnonymousSAM

   6. Registrierungspfad:

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

   7. Beispiele für Kompatibilitätsprobleme

   • SMS Network Discovery kann keine Betriebssysteminformationen abrufen und schreibt "Unknown" in die OperatingSystemNameandVersion-Eigenschaft.

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

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

   • Windows 95, Windows 98: Windows 95-basierte und Windows 98-basierte Computer können nicht von Microsoft-Domänencontrollern authentifiziert werden.

   • Windows 95, Windows 98: Benutzer auf Windows 95- und Windows 98-basierten Computern können die Kennwörter für ihre Benutzerkonten nicht ändern.

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

   1. Hintergrund

      • Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht zulassen (auch als RestrictAnonymous bezeichnet) bestimmt, ob die anonyme Enumeration von SAM-Konten und -Freigaben (Security Accounts Manager) zulässig ist. Windows ermöglicht anonymen Benutzern, bestimmte Aktivitäten auszuführen, z. B. das Aufzählen der Namen von Domänenkonten (Benutzer, Computer und Gruppen) und von Netzwerkfreigaben. Dies ist beispielsweise praktisch, wenn ein Administrator Benutzern in einer vertrauenswürdigen Domäne, die keine gegenseitige Vertrauensstellung unterhält, Zugriff gewähren möchte. Wenn Sie die anonyme Aufzählung von SAM-Konten und Freigaben nicht zulassen möchten, aktivieren Sie diese Einstellung.

      • In Windows 2000 wird mit einer ähnlichen Einstellung namens "Zusätzliche Einschränkungen für anonyme Verbindungen" der Registrierungswert "RestrictAnonymous " verwaltet. Der Speicherort dieses Werts lautet wie folgt:

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Riskante Konfiguration
      
      Aktivieren des Netzwerkzugriffs: Anonyme Aufzählung von SAM-Konten und Freigaben nicht zulassen, ist eine schädliche Konfigurationseinstellung.

   3. Gründe für die Aktivierung dieser Einstellung

      • Aktivieren des Netzwerkzugriffs: Anonyme Enumeration von SAM-Konten und Freigaben nicht zulassen, verhindert die Enumeration von SAM-Konten und -Freigaben durch Benutzer und Computer, die anonyme Konten verwenden.

   4. Gründe für die Deaktivierung dieser Einstellung

      • Wenn diese Einstellung aktiviert ist, könnte ein nicht autorisierter Benutzer Kontonamen anonym auflisten und dann die Informationen verwenden, um Kennwörter zu erraten oder Social Engineering-Angriffe auszuführen. Social Engineering ist Jargon, der bedeutet, Dass Menschen dazu verleiten, ihr Kennwort oder eine Form von Sicherheitsinformationen preiszugeben.

      • Wenn diese Einstellung aktiviert ist, können keine Vertrauensstellungen mit Windows NT 4.0-Domänen hergestellt werden. Diese Einstellung führt auch zu Problemen mit Clients auf unterer Ebene, z. B. Windows NT 3.51- und Windows 95-Clients, die versuchen, Ressourcen auf dem Server zu verwenden.

      • Es ist unmöglich, Benutzern von Ressourcendomänen Zugriff zu gewähren, da Administratoren in der vertrauenden Domäne keine Listen von Konten in der anderen Domäne aufzählen können. Benutzer, die anonym auf Datei- und Druckserver zugreifen, können die freigegebenen Netzwerkressourcen auf diesen Servern nicht auflisten. Die Benutzer müssen sich authentifizieren, bevor sie die Listen der freigegebenen Ordner und Drucker anzeigen können.

   5. Symbolischer Name:
      
      Restrictanonymous

   6. Registrierungspfad:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

   7. Beispiele für Kompatibilitätsprobleme

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

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

        Zurzeit sind keine Anmeldeserver verfügbar, um die Anmeldeanforderung zu warten.

      • Windows NT 4.0: Windows NT 4.0-basierte Computer können während des Setups oder über die Benutzeroberfläche für den Domänenbeitritt keine Domänen beitreten.

      • Windows NT 4.0: Das Einrichten einer Vertrauensstellung auf untergeordneter Ebene mit Windows NT 4.0-Ressourcendomänen schlägt fehl. Die folgende Fehlermeldung wird angezeigt, wenn RestrictAnonymous für die vertrauenswürdige Domäne aktiviert ist:

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

      • Windows NT 4.0: Benutzer, die sich bei Windows NT 4.0-basierten Terminalservercomputern anmelden, werden dem Standardmäßigen Startverzeichnis und nicht dem Startverzeichnis zugeordnet, das im Benutzer-Manager für Domänen definiert ist.

      • Windows NT 4.0: Windows NT 4.0-Sicherungsdomänencontroller (BDCs) können den Net-Anmeldedienst nicht starten, eine Liste der Sicherungsbrowser abrufen oder die SAM-Datenbank von Windows 2000 oder von Windows Server 2003-Domänencontrollern in derselben Domäne synchronisieren.

      • Windows 2000: Windows 2000-basierte Mitgliedscomputer in Windows NT 4.0-Domänen können Drucker in externen Domänen nicht anzeigen, wenn die Einstellung "Kein Zugriff ohne explizit anonyme Berechtigungen" in der lokalen Sicherheitsrichtlinie des Clientcomputers aktiviert ist.

      • Windows 2000: Windows 2000-Domänenbenutzer können keine Netzwerkdrucker aus Active Directory hinzufügen. Sie können jedoch Drucker hinzufügen, nachdem sie sie in der Strukturansicht ausgewählt haben.

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

      • ADMT Version 2: Die Kennwortmigration für Benutzerkonten, die mit Active Directory Migration Tool (ADMT) Version 2 zwischen Gesamtstrukturen migriert werden, schlägt fehl.
        
        Klicken Sie für weitere Informationen auf die folgende Artikelnummer, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

        322981 Problembehandlung bei der gesamtstrukturübergreifenden Kennwortmigration mit ADMTv2

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

      • SMS: Microsoft Systems Management Server (SMS) Network Discovery kann die Betriebssysteminformationen nicht abrufen. Daher wird in der OperatingSystemNameandVersion-Eigenschaft der SMS-DDR-Eigenschaft des Discoverydatensatzes (DDR) "Unknown" geschrieben.

      • SMS: Wenn Sie den SMS-Administratorbenutzer-Assistenten verwenden, um nach Benutzern und Gruppen zu suchen, werden keine Benutzer oder Gruppen aufgelistet. Darüber hinaus können erweiterte Clients nicht mit dem Verwaltungspunkt kommunizieren. Anonymer Zugriff ist für den Verwaltungspunkt erforderlich.

      • SMS: Wenn Sie das Netzwerkermittlungsfeature in SMS 2.0 und in der Remoteclientinstallation mit aktivierter Netzwerkermittlungsoption für Topologie, Client und Clientbetriebssysteme verwenden, werden Computer möglicherweise ermittelt, aber möglicherweise nicht installiert.

10. Netzwerksicherheit: Lan Manager-Authentifizierungsebene

    1. Hintergrund
       
       Die LAN-Manager-Authentifizierung (LM) ist das Protokoll, das verwendet wird, um Windows-Clients für Netzwerkvorgänge zu authentifizieren, einschließlich Domänenbeitritten, Zugriff auf Netzwerkressourcen und Benutzer- oder Computerauthentifizierung. Die LM-Authentifizierungsebene bestimmt, welches Abfrage-/Antwortauthentifizierungsprotokoll zwischen dem Client und den Servercomputern ausgehandelt wird. Insbesondere bestimmt die LM-Authentifizierungsebene, welche Authentifizierungsprotokolle der Client auszuhandeln versucht oder die der Server akzeptiert. Der für LmCompatibilityLevel festgelegte Wert bestimmt, welches Abfrage-/Antwortauthentifizierungsprotokoll für Netzwerkanmeldungen verwendet wird. Dieser Wert wirkt sich auf die Von Clients verwendete Authentifizierungsprotokollebene, die ausgehandelte Sitzungssicherheit und die von Servern akzeptierte Authentifizierungsebene aus.
       
       Mögliche Einstellungen sind:

       Wert	Einstellung	Beschreibung
       0	Senden von LM-& NTLM-Antworten	Clients verwenden die LM- und NTLM-Authentifizierung und verwenden niemals NTLMv2-Sitzungssicherheit. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
       1	LM & NTLM senden – NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt	Clients verwenden LM- und NTLM-Authentifizierung und NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
       2	Nur NTLM-Antwort senden	Clients verwenden nur NTLM-Authentifizierung und NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
       3	Nur NTLMv2-Antwort senden	Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
       4	Nur NTLMv2-Antwort senden/LM ablehnen	Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller lehnen LM ab und akzeptieren nur NTLM- und NTLMv2-Authentifizierung.
       5	Nur NTLMv2-Antwort senden/LM & NTLM ablehnen	Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller lehnen LM und NTLM ab und akzeptieren nur die NTLMv2-Authentifizierung.

       Hinweis In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienstclient die SMB-Signatur, wenn er sich mit Windows Server 2003-Servern mithilfe der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signierung, wenn sie sich mithilfe der NTLMv2-Authentifizierung bei diesen Servern authentifizieren. Darüber hinaus reagieren Windows 2000-Server nicht auf SMB-Signaturanforderungen von diesen Clients.
       
       Überprüfen Sie die LM-Authentifizierungsebene: Sie müssen die Richtlinie auf dem Server ändern, um NTLM zuzulassen, oder Sie müssen den Clientcomputer so konfigurieren, dass NTLMv2 unterstützt wird.
       
       Wenn die Richtlinie auf (5) Nur NTLMv2-Antwort senden\LM & NTLM auf dem Zielcomputer ablehnen, mit dem Sie eine Verbindung herstellen möchten, müssen Sie entweder die Einstellung auf diesem Computer herabsetzen oder die Sicherheit auf die gleiche Einstellung festlegen, die sich auf dem Quellcomputer befindet, von dem aus Sie eine Verbindung herstellen.
       
       Suchen Sie den richtigen Speicherort, an dem Sie die Authentifizierungsebene des LAN-Managers ändern können, um den Client und den Server auf dieselbe Ebene festzulegen. Nachdem Sie die Richtlinie gefunden haben, mit der die Authentifizierungsebene des LAN-Managers festgelegt wird, sollten Sie, wenn Sie eine Verbindung mit computern herstellen möchten, auf denen frühere Versionen von Windows ausgeführt werden, den Wert auf mindestens (1) LM & NTLM senden – verwenden Sie die NTLM-Sitzungssicherheit der Version 2, wenn sie ausgehandelt wird. Ein Effekt von inkompatiblen Einstellungen besteht darin, dass, wenn der Server NTLMv2 (Wert 5) erfordert, der Client jedoch so konfiguriert ist, dass nur LM und NTLMv1 verwendet werden (Wert 0), der Benutzer, der die Authentifizierung versucht, einen Anmeldefehler mit einem ungültigen Kennwort aufweist und die Anzahl ungültiger Kennwörter erhöht. Wenn die Kontosperrung konfiguriert ist, kann der Benutzer möglicherweise gesperrt werden.
       
       Möglicherweise müssen Sie sich beispielsweise den Domänencontroller ansehen, oder Sie müssen die Richtlinien des Domänencontrollers überprüfen.
       
       Schauen Sie sich den Domänencontroller
       
       an Hinweis: Möglicherweise müssen Sie das folgende Verfahren auf allen Domänencontrollern wiederholen.

       1. Klicken Sie auf "Start", zeigen Sie auf "Programme", und klicken Sie dann auf "Verwaltungstools".

       2. Erweitern Sie unter "Lokale Sicherheitseinstellungen""Lokale Richtlinien".

       3. Klicken Sie auf "Sicherheitsoptionen".

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

       
       Wenn die effektive Einstellung und die lokale Einstellung identisch sind, wurde die Richtlinie auf dieser Ebene geändert. Wenn die Einstellungen unterschiedlich sind, müssen Sie die Richtlinie des Domänencontrollers überprüfen, um festzustellen, ob die Einstellung für die Authentifizierungsebene "Netzwerksicherheit: LAN-Manager" dort definiert ist. Wenn sie dort nicht definiert ist, überprüfen Sie die Richtlinien des Domänencontrollers.
       
       Überprüfen der Richtlinien des Domänencontrollers

       1. Klicken Sie auf "Start", zeigen Sie auf "Programme", und klicken Sie dann auf "Verwaltungstools".

       2. Erweitern Sie in der Sicherheitsrichtlinie für Domänencontroller die Sicherheitseinstellungen und dann die lokalen Richtlinien.

       3. Klicken Sie auf "Sicherheitsoptionen".

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

       
       Hinweis

       • Möglicherweise müssen Sie auch Richtlinien überprüfen, die auf Standortebene, Domänenebene oder Organisationseinheitsebene verknüpft sind, um zu bestimmen, wo Sie die Authentifizierungsebene des LAN-Managers konfigurieren müssen.

       • Wenn Sie eine Gruppenrichtlinie-Einstellung als Standarddomänenrichtlinie implementieren, wird die Richtlinie auf alle Computer in der Domäne angewendet.

       • Wenn Sie eine Gruppenrichtlinie-Einstellung als Richtlinie des Standarddomänencontrollers implementieren, gilt die Richtlinie nur für die Server in der Oe des Domänencontrollers.

       • Es empfiehlt sich, die LAN-Manager-Authentifizierungsebene in der niedrigsten Entität des erforderlichen Bereichs in der Richtlinienanwendungshierarchie festzulegen.

       Windows Server 2003 verfügt über eine neue Standardeinstellung, um nur NTLMv2 zu verwenden. Standardmäßig haben Windows Server 2003- und Windows 2000 Server SP3-basierte Domänencontroller die Richtlinie "Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)" aktiviert. Diese Einstellung erfordert, dass der SMB-Server die SMB-Paketsignierung durchführt. Änderungen an Windows Server 2003 wurden vorgenommen, da Domänencontroller, Dateiserver, Netzwerkinfrastrukturserver und Webserver in jeder Organisation unterschiedliche Einstellungen erfordern, um ihre Sicherheit zu maximieren.
       
       Wenn Sie die NTLMv2-Authentifizierung in Ihrem Netzwerk implementieren möchten, müssen Sie sicherstellen, dass alle Computer in der Domäne auf diese Authentifizierungsebene festgelegt sind. Wenn Sie Active Directory-Clienterweiterungen für Windows 95 oder Windows 98 und Windows NT 4.0 anwenden, verwenden die Clienterweiterungen die verbesserten Authentifizierungsfeatures, die in NTLMv2 verfügbar sind. Da Clientcomputer, auf denen eines der folgenden Betriebssysteme ausgeführt wird, von Windows 2000 Gruppenrichtlinie Objects nicht betroffen sind, müssen Sie diese Clients möglicherweise manuell konfigurieren:

       • Microsoft Windows NT 4.0

       • Microsoft Windows Millennium Edition

       • Microsoft Windows 98

       • Microsoft Windows 95

       Hinweis Wenn Sie die Netzwerksicherheit aktivieren: Speichern Sie den LAN-Manager-Hashwert nicht in der nächsten Kennwortänderungsrichtlinie , oder legen Sie den NoLMHash-Registrierungsschlüssel fest. Windows 95- und Windows 98-basierte Clients, auf denen der Verzeichnisdienstclient nicht installiert ist, können sich nach einer Kennwortänderung nicht bei der Domäne anmelden.
       
       Viele CIFS-Server von Drittanbietern, z. B. Novell Netware 6, kennen NTLMv2 nicht und verwenden nur NTLM. Daher lassen Ebenen größer als 2 keine Konnektivität zu. Es gibt auch SMB-Clients von Drittanbietern, die keine erweiterte Sitzungssicherheit verwenden. In diesen Fällen wird die LmCompatiblityLevel des Ressourcenservers nicht berücksichtigt. Der Server packt dann diese Legacyanforderung und sendet sie an den Benutzerdomänencontroller. Die Einstellungen auf dem Domänencontroller entscheiden dann, welche Hashes verwendet werden, um die Anforderung zu überprüfen und ob diese die Sicherheitsanforderungen des Domänencontrollers erfüllen.
       
        

       299656 So verhindern Sie, dass Windows einen LAN-Managerhash Ihres Kennworts in Active Directory und lokalen SAM-Datenbanken speichert
        

       2701704Überwachungsereignis zeigt das Authentifizierungspaket als NTLMv1 anstelle von NTLMv2 an. Weitere Informationen zu LM-Authentifizierungsebenen finden Sie in der Microsoft Knowledge Base:

       239869 Aktivieren der NTLM 2-Authentifizierung
        

    2. Riskante Konfigurationen
       
       Die folgenden Konfigurationseinstellungen sind schädlich:

       • Nicht eingeschränkte Einstellungen, die Kennwörter im Klartext senden und ntlmv2-Aushandlung verweigern

       • Restriktive Einstellungen, die verhindern, dass inkompatible Clients oder Domänencontroller ein gemeinsames Authentifizierungsprotokoll aushandeln

       • Erfordern der NTLMv2-Authentifizierung auf Mitgliedscomputern und Domänencontrollern, auf denen Versionen von Windows NT 4.0 ausgeführt werden, die früher als Service Pack 4 (SP4) sind

       • NtlMv2-Authentifizierung auf Windows 95-Clients oder auf Windows 98-Clients erforderlich, auf denen der Windows Directory Services-Client nicht installiert ist.

       • Wenn Sie in der Microsoft Management Console Gruppenrichtlinie Editor-Snap-In auf einem Windows Server 2003- oder Windows 2000 Service Pack 3-basierten Computer das Kontrollkästchen "NTLMv2-Sitzungssicherheit anfordern" aktivieren und die Authentifizierungsstufe des LAN-Managers auf 0 senken, gibt es einen Konflikt zwischen den beiden Einstellungen, und möglicherweise wird die folgende Fehlermeldung in der Datei "Secpol.msc" oder in der Datei "GPEdit.msc" angezeigt:

         Windows kann die lokale Richtliniendatenbank nicht öffnen. Unbekannter Fehler beim Öffnen der Datenbank.

         Weitere Informationen zum Sicherheitskonfigurations- und Analysetool finden Sie in den Windows 2000- oder Windows Server 2003-Hilfedateien.

    3. Gründe für das Ändern dieser Einstellung

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

       • Wenn die sichere Authentifizierung eine geschäftliche Anforderung ist, sollten Sie die Aushandlung des LM und der NTLM-Protokolle verbieten.

    4. Gründe für die Deaktivierung dieser Einstellung
       
       Die Anforderungen an die Client- oder Serverauthentifizierung oder beides wurden so weit erhöht, dass die Authentifizierung über ein gemeinsames Protokoll nicht erfolgen kann.

    5. Symbolischer Name:
       
       LmCompatibilityLevel

    6. Registrierungspfad:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. Beispiele für Kompatibilitätsprobleme

       • Windows Server 2003: Standardmäßig ist die Windows Server 2003 NTLMv2 Send NTLM Responses-Einstellung aktiviert. Daher empfängt Windows Server 2003 nach der Erstinstallation die Fehlermeldung "Zugriff verweigert", wenn Sie versuchen, eine Verbindung mit einem Windows NT 4.0-basierten Cluster oder mit LanManager V2.1-basierten Servern wie OS/2 Lanserver herzustellen. Dieses Problem tritt auch auf, wenn Sie versuchen, eine Verbindung von einem Client früherer Version mit einem Windows Server 2003-basierten Server herzustellen.

       • Sie installieren Windows 2000 Security Rollup Package 1 (SRP1). SRP1 erzwingt NTLM Version 2 (NTLMv2). Dieses Rolluppaket wurde nach der Veröffentlichung von Windows 2000 Service Pack 2 (SP2) veröffentlicht.
          

       • Windows 7 und Windows Server 2008 R2: Viele CIFS-Server von Drittanbietern, wie Novell Netware 6 oder Linux-basierte Sambaserver, kennen NTLMv2 nicht und verwenden nur NTLM. Daher lassen Ebenen größer als "2" keine Konnektivität zu. In dieser Version des Betriebssystems wurde nun der Standardwert für LmCompatibilityLevel in "3" geändert. Wenn Sie Windows aktualisieren, funktionieren diese Drittanbieter-Filer möglicherweise nicht mehr.

       • Microsoft Outlook-Clients werden möglicherweise zur Eingabe von Anmeldeinformationen aufgefordert, obwohl sie bereits bei der Domäne angemeldet sind. Wenn Benutzer ihre Anmeldeinformationen angeben, erhalten sie die folgende Fehlermeldung: Windows 7 und Windows Server 2008 R2

         Die angegebenen Anmeldeinformationen waren falsch. Stellen Sie sicher, dass Ihr Benutzername und Ihre Domäne richtig sind, und geben Sie dann ihr Kennwort erneut ein.

         Wenn Sie Outlook starten, werden Sie möglicherweise auch dann zur Eingabe Ihrer Anmeldeinformationen aufgefordert, wenn Ihre Einstellung für Anmeldenetzwerksicherheit auf Passthrough oder Kennwortauthentifizierung festgelegt ist. Nachdem Sie Die richtigen Anmeldeinformationen eingegeben haben, wird möglicherweise die folgende Fehlermeldung angezeigt:

         Die angegebenen Anmeldeinformationen waren falsch.

         Eine Netzwerküberwachungsablaufverfolgung kann zeigen, dass der globale Katalog einen Remoteprozeduraufruffehler (Remote Procedure Call, RPC) mit dem Status 0x5 ausgegeben hat. Ein Status von 0x5 bedeutet "Zugriff verweigert".

       • Windows 2000: Bei einer Netzwerkmonitorerfassung werden möglicherweise die folgenden Fehler in der NetBIOS over TCP/IP (NetBT)-Servernachrichtenblocksitzung (SMB) angezeigt:

         SMB R Search Directory Dos error, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Ungültiger Benutzerbezeichner

       • Windows 2000: Wenn eine Windows 2000-Domäne mit NTLMv2 Level 2 oder höher von einer Windows NT 4.0-Domäne als vertrauenswürdig eingestuft wird, treten bei Windows 2000-basierten Mitgliedscomputern in der Ressourcendomäne möglicherweise Authentifizierungsfehler auf.

       • Windows 2000 und Windows XP: Standardmäßig legen Windows 2000 und Windows XP die Lokale Sicherheitsrichtlinie für die LAN-Manager-Authentifizierungsebene auf 0 fest. Eine Einstellung von 0 bedeutet "LM- und NTLM-Antworten senden"
         
         . Beachten Sie, dass Windows NT 4.0-basierte Cluster LM für die Verwaltung verwenden müssen.

       • Windows 2000: Windows 2000-Clustering authentifiziert keinen verbindenden Knoten, wenn beide Knoten Teil einer Windows NT 4.0 Service Pack 6a (SP6a)-Domäne sind.

       • Das IIS-Sperrmodustool (HiSecWeb) legt den LMCompatibilityLevel-Wert auf 5 und den RestrictAnonymous-Wert auf 2 fest.

       • Dienste für Macintosh
         
         Benutzerauthentifizierungsmodul (User Authentication Module, UAM): Das Microsoft UAM (User Authentication Module) stellt eine Methode zum Verschlüsseln der Kennwörter bereit, die Sie für die Anmeldung bei Windows AFP-Servern (AppleTalk Filing Protocol) verwenden. Das Apple User Authentication Module (UAM) bietet nur eine minimale oder keine Verschlüsselung. Daher kann Ihr Kennwort problemlos im LAN oder im Internet abgefangen werden. Obwohl das UAM nicht erforderlich ist, stellt es eine verschlüsselte Authentifizierung für Windows 2000-Server bereit, auf denen Dienste für Macintosh ausgeführt werden. Diese Version enthält Unterstützung für die verschlüsselte NTLMv2-128-Bit-Authentifizierung und eine MacOS X 10.1-kompatible Version.
         
         Standardmäßig lässt der Windows Server 2003 Services für Macintosh-Server nur die Microsoft-Authentifizierung zu.
          

       • Windows Server 2008, Windows Server 2003, Windows XP und Windows 2000: Wenn Sie den LMCompatibilityLevel-Wert auf 0 oder 1 konfigurieren und dann den NoLMHash-Wert auf 1 konfigurieren, wird Anwendungen und Komponenten möglicherweise der Zugriff über NTLM verweigert. Dieses Problem tritt auf, weil der Computer so konfiguriert ist, dass LM aktiviert, aber keine LM-gespeicherten Kennwörter verwendet werden.
         
         Wenn Sie den NoLMHash-Wert auf 1 konfigurieren, müssen Sie den LMCompatibilityLevel-Wert auf 2 oder höher konfigurieren.

11. Netzwerksicherheit: Anforderungen an die LDAP-Clientsignierung

    1. Hintergrund
       
       Die Einstellung "Netzwerksicherheit: LDAP-Clientsignaturanforderungen" bestimmt die Ebene der Datensignierung, die im Auftrag von Clients angefordert wird, die BIND-Anforderungen (Lightweight Directory Access Protocol, LDAP) wie folgt ausstellen:

       • Keine: Die LDAP BIND-Anforderung wird mit den vom Aufrufer angegebenen Optionen ausgegeben.

       • Signierung aushandeln: Wenn ssl/TLS (Secure Sockets Layer/Transport Layer Security) nicht gestartet wurde, wird die LDAP BIND-Anforderung mit der LDAP-Datensignierungsoption initiiert, die zusätzlich zu den vom Aufrufer angegebenen Optionen festgelegt ist. Wenn SSL/TLS gestartet wurde, wird die LDAP BIND-Anforderung mit den vom Aufrufer angegebenen Optionen initiiert.

       • Signieren erforderlich: Dies entspricht dem Signieren von Aushandlungen. Wenn die zwischengeschaltete SaslBindInProgress-Antwort des LDAP-Servers jedoch nicht darauf hinweist, dass eine LDAP-Datenverkehrssignierung erforderlich ist, wird dem Aufrufer mitgeteilt, dass die LDAP BIND-Befehlsanforderung fehlgeschlagen ist.

    2. Riskante Konfiguration
       
       Aktivieren der Netzwerksicherheit: Die Einstellung für die Ldap-Clientsignierungsanforderungen ist eine schädliche Konfigurationseinstellung. Wenn Sie festlegen, dass der Server LDAP-Signaturen erfordert, müssen Sie auch die LDAP-Signatur auf dem Client konfigurieren. Wenn der Client nicht für die Verwendung von LDAP-Signaturen konfiguriert wird, wird die Kommunikation mit dem Server verhindert. Dies führt dazu, dass die Benutzerauthentifizierung, Gruppenrichtlinie-Einstellungen, Anmeldeskripts und andere Features fehlschlagen.

    3. Gründe für das Ändern dieser Einstellung
       
       Nicht signierter Netzwerkdatenverkehr ist anfällig für Man-in-the-Middle-Angriffe, bei denen ein Eindringling Pakete zwischen dem Client und den Servern erfasst, ändert und dann an den Server weiterleitet. Wenn dies auf einem LDAP-Server geschieht, kann ein Angreifer dazu führen, dass ein Server basierend auf falschen Abfragen vom LDAP-Client antwortet. Sie können dieses Risiko in einem Unternehmensnetzwerk verringern, indem Sie starke physische Sicherheitsmaßnahmen zum Schutz der Netzwerkinfrastruktur implementieren. Darüber hinaus können Sie dazu beitragen, alle Arten von Man-in-the-Middle-Angriffen zu verhindern, indem Sie digitale Signaturen für alle Netzwerkpakete mithilfe von IPSec-Authentifizierungsheadern benötigen.

    4. Symbolischer Name:
       
       LDAPClientIntegrity

    5. Registrierungspfad:

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

12. Ereignisprotokoll: Maximale Sicherheitsprotokollgröße

    1. Hintergrund
       
       Die Sicherheitseinstellung "Ereignisprotokoll: Maximale Sicherheitsprotokollgröße" gibt die maximale Größe des Sicherheitsereignisprotokolls an. Dieses Protokoll hat eine maximale Größe von 4 GB. Um diese Einstellung zu finden, erweitern Sie
       die Windows-Einstellungen und dann die Sicherheitseinstellungen.

    2. Riskante Konfigurationen
       
       Die folgenden Konfigurationseinstellungen sind schädlich:

       • Einschränken der Größe des Sicherheitsprotokolls und der Aufbewahrungsmethode für Sicherheitsprotokolle bei der Überwachung: Das System wird sofort heruntergefahren, wenn die Einstellung für Sicherheitsüberwachungen nicht protokolliert werden kann. Weitere Informationen finden Sie im Abschnitt "Audit: Shut down system immediately if unable to log security audits" in diesem Artikel.

       • Einschränken der Größe des Sicherheitsprotokolls, sodass sicherheitsrelevante Ereignisse überschrieben werden.

    3. Gründe für die Erhöhung dieser Einstellung
       
       Geschäfts- und Sicherheitsanforderungen können festlegen, dass Sie die Größe des Sicherheitsprotokolls erhöhen, um zusätzliche Sicherheitsprotokolldetails zu verarbeiten oder Sicherheitsprotokolle über einen längeren Zeitraum aufzubewahren.

    4. Gründe, diese Einstellung
       
       zu verringern Ereignisanzeige Protokolle sind speicherzuordnungen Dateien. Die maximale Größe eines Ereignisprotokolls wird durch die Menge des physischen Speichers auf dem lokalen Computer und durch den virtuellen Speicher eingeschränkt, der für den Ereignisprotokollprozess verfügbar ist. Wenn Sie die Protokollgröße über den für Ereignisanzeige verfügbaren virtuellen Speicher hinaus erhöhen, wird die Anzahl der verwalteten Protokolleinträge nicht erhöht.

    5. Beispiele für Kompatibilitätsprobleme
       
       Windows 2000: Computer, auf denen Versionen von Windows 2000 ausgeführt werden, die älter als Service Pack 4 (SP4) sind, können die Protokollierung von Ereignissen im Ereignisprotokoll beenden, bevor die in der Einstellung "Maximale Protokollgröße" in Ereignisanzeige angegebene Größe erreicht wird, wenn die Option "Ereignisse nicht überschreiben" (Protokoll manuell löschen) aktiviert ist.
       
       
        

13. Ereignisprotokoll: Sicherheitsprotokoll beibehalten

    1. Hintergrund
       
       Die Sicherheitseinstellung "Ereignisprotokoll: Sicherheitsprotokoll beibehalten" bestimmt die "wrapping"-Methode für das Sicherheitsprotokoll. Um diese Einstellung zu finden, erweitern Sie die Windows-Einstellungen und dann die Sicherheitseinstellungen.

    2. Riskante Konfigurationen
       
       Die folgenden Konfigurationseinstellungen sind schädlich:

       • Fehler beim Aufbewahren aller protokollierten Sicherheitsereignisse, bevor sie überschrieben werden

       • Konfigurieren der Einstellung "Maximale Sicherheitsprotokollgröße" zu klein, sodass Sicherheitsereignisse überschrieben werden

       • Einschränken der Größe des Sicherheitsprotokolls und der Aufbewahrungsmethode während der Überwachung: Sofortiges Herunterfahren des Systems, wenn die Sicherheitseinstellung für Sicherheitsüberprüfungen nicht protokolliert werden kann

    3. Gründe für die Aktivierung dieser Einstellung
       
       Aktivieren Sie diese Einstellung nur, wenn Sie die Aufbewahrungsmethode "Ereignisse nach Tagen überschreiben " auswählen. Wenn Sie ein Ereigniskorrelationssystem verwenden, das Ereignisse abruft, stellen Sie sicher, dass die Anzahl der Tage mindestens dreimal so hoch ist wie die Abfragehäufigkeit. Führen Sie diese Vorgehensweise aus, um fehlgeschlagene Abfragezyklen zuzulassen.

14. Netzwerkzugriff: Zulassen, dass alle Berechtigungen auf anonyme Benutzer angewendet werden

    1. Hintergrund
       
       Standardmäßig ist die Einstellung "Netzwerkzugriff: Zulassen, dass alle Berechtigungen auf anonyme Benutzer angewendet werden" auf "Unter Windows Server 2003 nicht definiert" festgelegt. Standardmäßig schließt Windows Server 2003 das Token für anonymen Zugriff nicht in die Gruppe "Jeder" ein.

    2. Beispiel für Kompatibilitätsprobleme
       
       Der folgende Wert von

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 unterbricht die Erstellung von Vertrauensstellungen zwischen Windows Server 2003 und Windows NT 4.0, wenn die Windows Server 2003-Domäne die Kontodomäne und die Windows NT 4.0-Domäne die Ressourcendomäne ist. Dies bedeutet, dass die Kontodomäne unter Windows NT 4.0 vertrauenswürdig ist und die Ressourcendomäne auf der Windows Server 2003-Seite als vertrauenswürdig eingestuft wird. Dieses Verhalten tritt auf, weil der Prozess zum Starten der Vertrauensstellung nach der anfänglichen anonymen Verbindung ACL mit dem "Jeder"-Token ist, das die anonyme SID unter Windows NT 4.0 enthält.

    3. Gründe für das Ändern dieser Einstellung
       
       Der Wert muss auf 0x1 festgelegt oder mithilfe eines Gruppenrichtlinienobjekts in der OE des Domänencontrollers festgelegt werden: Netzwerkzugriff: Zulassen, dass alle Berechtigungen für anonyme Benutzer gelten – aktiviert, um die Erstellung von Vertrauensstellungen zu ermöglichen.
       
       Beachten Sie, dass die meisten anderen Sicherheitseinstellungen im Wert und nicht in 0x0 in ihrem gesicherten Zustand steigen. Eine sicherere Vorgehensweise wäre, die Registrierung im Primären Domänencontroller-Emulator anstelle aller Domänencontroller zu ändern. Wenn die Primäre Domänencontroller-Emulatorrolle aus irgendeinem Grund verschoben wird, muss die Registrierung auf dem neuen Server aktualisiert werden.
       
       Ein Neustart ist erforderlich, nachdem dieser Wert festgelegt wurde.

    4. Registrierungspfad

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

15. NTLMv2-Authentifizierung

    1. Sitzungssicherheit
       
       Die Sitzungssicherheit bestimmt die Mindestsicherheitsstandards für Client- und Serversitzungen. Es empfiehlt sich, die folgenden Sicherheitsrichtlinieneinstellungen in der Microsoft Management Console Gruppenrichtlinie Editor-Snap-In zu überprüfen:

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

       • Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte (einschließlich sicherer RPC)-Server

       • Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte (einschließlich sicherer RPC)-Clients

       Die Optionen für diese Einstellungen lauten wie folgt:

       • Nachrichtenintegrität erforderlich

       • Vertraulichkeit von Nachrichten anfordern

       • NtLM-Sitzungssicherheit der Version 2 erforderlich

       • 128-Bit-Verschlüsselung erforderlich

       Die Standardeinstellung vor Windows 7 ist "Keine Anforderungen". Ab Windows 7 wurde die Standardeinstellung zur Verbesserung der Sicherheit in "128-Bit-Verschlüsselung erforderlich" geändert. Mit dieser Standardeinstellung können ältere Geräte, die keine 128-Bit-Verschlüsselung unterstützen, keine Verbindung herstellen.
       
       Diese Richtlinien bestimmen die Mindestsicherheitsstandards für eine Anwendungs-zu-Anwendung-Kommunikationssitzung auf einem Server für einen Client.
       
       Beachten Sie, dass die Flags, die nachrichtenintegrität und Vertraulichkeit erfordern, auch wenn sie als gültige Einstellungen beschrieben werden, nicht verwendet werden, wenn die NTLM-Sitzungssicherheit bestimmt wird.
       
       In der Vergangenheit hat Windows NT die folgenden beiden Varianten der Abfrage-/Antwortauthentifizierung für Netzwerkanmeldungen unterstützt:

       • LM-Herausforderung/-Antwort

       • NTLM Version 1 – Abfrage/Antwort

       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 wie folgt:

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

    2. Riskante Konfigurationen
       
       Diese Einstellung steuert, wie mit NTLM gesicherte Netzwerksitzungen behandelt werden. Dies betrifft z. B. RPC-basierte Sitzungen, die mit NTLM authentifiziert wurden. Es gibt die folgenden Risiken:

       • Die Verwendung älterer Authentifizierungsmethoden als NTLMv2 erleichtert die Kommunikation aufgrund der einfacheren Hashingmethoden.

       • Die Verwendung von Verschlüsselungsschlüsseln unter 128-Bit ermöglicht Es Angreifern, die Kommunikation mit Brute-Force-Angriffen zu unterbrechen.

Zeitsynchronisierung

Fehler bei der Zeitsynchronisierung. Die Zeit ist auf einem betroffenen Computer um mehr als 30 Minuten deaktiviert. Stellen Sie sicher, dass die Uhr des Clientcomputers mit der Uhr des Domänencontrollers synchronisiert ist.

Problemumgehung für SMB-Signierung

Es wird empfohlen, Service Pack 6a (SP6a) auf Windows NT 4.0-Clients zu installieren, die in einer Windows Server 2003-basierten Domäne zusammenarbeiten. Windows 98 Second Edition-basierte Clients, Windows 98-basierte Clients und Windows 95-basierte Clients müssen den Verzeichnisdienstclient ausführen, um NTLMv2 auszuführen. Wenn auf Windows NT 4.0-basierten Clients Windows NT 4.0 SP6 nicht installiert ist oder auf Windows 95-basierten Clients, Windows 98-basierten Clients und Windows 98SE-basierten Clients der Verzeichnisdienstclient nicht installiert ist, deaktivieren Sie die SMB-Anmeldung in der Richtlinieneinstellung des Standarddomänencontrollers in der Oe des Domänencontrollers, und verknüpfen Sie diese Richtlinie dann mit allen OUs, die Domänencontroller hosten.

Der Verzeichnisdienstclient für Windows 98 Second Edition, Windows 98 und Windows 95 führt SMB-Signierung mit Windows 2003-Servern unter NTLM-Authentifizierung durch, jedoch nicht unter NTLMv2-Authentifizierung. Darüber hinaus reagieren Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients.

Obwohl dies nicht empfohlen wird, können Sie verhindern, dass SMB-Signierung auf allen Domänencontrollern erforderlich ist, auf denen Windows Server 2003 in einer Domäne ausgeführt wird. Führen Sie die folgenden Schritte aus, um diese Sicherheitseinstellung zu konfigurieren:

1. Öffnen Sie die Richtlinie des Standarddomänencontrollers.

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

3. Suchen Und klicken Sie dann auf den Microsoft-Netzwerkserver: Richtlinieneinstellung "Kommunikation digital signieren (immer)", und klicken Sie dann auf "Deaktiviert".

Wichtig Dieser Abschnitt, die Methode oder die Aufgabe enthält Schritte, mit denen Sie erfahren, wie Sie die Registrierung ändern können. Es können jedoch schwerwiegende Probleme auftreten, wenn Sie die Registrierung falsch ändern. Stellen Sie daher sicher, dass Sie diese Schritte sorgfältig ausführen. Sichern Sie für zusätzlichen Schutz die Registrierung, bevor Sie sie ändern. Anschließend können Sie die Registrierung wiederherstellen, wenn ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung erhalten Sie, indem Sie auf die folgende Artikelnummer klicken, um den Artikel in der Microsoft Knowledge Base anzuzeigen:

322756 Sichern und Wiederherstellen der Registrierung in Windows Alternativ können Sie die SMB-Signierung auf dem Server deaktivieren, indem Sie die Registrierung ändern. Gehen Sie hierzu wie folgt vor:

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

2. Suchen Sie den folgenden Unterschlüssel, und klicken Sie dann 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 "Wertdaten " den Wert "0" ein, und klicken Sie dann auf "OK".

6. Beenden Sie den Registrierungs-Editor.

7. Starten Sie den Computer neu, oder beenden Sie den Serverdienst, und starten Sie ihn dann neu. Geben Sie dazu die folgenden Befehle an einer Eingabeaufforderung ein, und drücken Sie dann die EINGABETASTE, nachdem Sie jeden Befehl eingegeben haben:
   Net Stop-Server
   Net Start Server

Hinweis Der entsprechende Schlüssel auf dem Clientcomputer befindet sich im folgenden Registrierungsunterschlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters Im Folgenden werden die übersetzten Fehlercodenummern in Statuscodes und die ausführlichen Fehlermeldungen aufgeführt, die zuvor erwähnt wurden:

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

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

816585 Anwenden vordefinierter Sicherheitsvorlagen in Windows Server 2003