Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Probleme mit Clienten, Diensten und Programmen auftreten

Zusammenfassung

Sicherheitseinstellungen und die Zuweisung von Benutzerrechten können in lokalen Richtlinien und Gruppenrichtlinien geändert werden, um die Sicherheit auf Domänencontrollern und Mitgliedscomputern zu erhöhen. Der Nachteil einer erhöhten Sicherheit ist jedoch die Einführung von Inkompatibilitäten mit Clients, Diensten und Programmen.

In diesem Artikel werden Inkompatibilitäten beschrieben, die auf Clientcomputern unter Windows XP oder einer früheren Version von Windows auftreten können, wenn Sie bestimmte Sicherheitseinstellungen und Benutzerrechtezuweisungen in einer Windows Server 2003-Domäne oder einer früheren Windows Server-Domäne ändern.

Informationen zu Gruppenrichtlinien für Windows 7, Windows Server 2008 R2 und Windows Server 2008 finden Sie in den folgenden Artikeln:

• Informationen zu Windows 7 finden Sie unter Gruppenrichtlinienverwaltung für IT-Spezialisten
• Informationen zu Windows 7 und Windows Server 2008 R2 finden Sie unter Neuerungen in der Gruppenrichtlinie

Hinweis: Der restliche Inhalt dieses Artikels bezieht sich speziell auf Windows XP, Windows Server 2003 und frühere Versionen von Windows.

Windows XP

Wenn Sie falsch konfigurierte Sicherheitseinstellungen besser erkennen möchten, ändern Sie die Sicherheitseinstellungen mit dem Tool "Gruppenrichtlinie-Objekt-Editor". Wenn Sie den Gruppenrichtlinie-Objekt-Editor verwenden, werden die Benutzerrechtezuweisungen unter 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 Benutzerrechtezuweisung in eine Einstellung ändern, die weniger kompatibel und restriktiver ist. Wenn Sie dieselbe Sicherheitseinstellung oder die Zuweisung von Benutzerrechten direkt über die Registrierung oder mithilfe von Sicherheitsvorlagen ändern, ist die Auswirkung identisch mit der Änderung der Einstellung im Gruppenrichtlinienobjekt-Editor. Das Dialogfeld mit dem Link zu diesem Artikel wird jedoch nicht angezeigt.

Dieser Artikel enthält Beispiele für Clients, Programme und Vorgänge, die von bestimmten Sicherheitseinstellungen oder Benutzerrechtezuweisungen 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 sicherheitsrelevanten Konfigurationsänderungen in einer Testgesamtstruktur zu überprüfen, bevor Sie sie in einer Produktionsumgebung einführen. Die Testgesamtstruktur muss die Produktionsgesamtstruktur wie folgt Spiegel:

• Client- und Serverbetriebssystemversionen, Client- und Serverprogramme, Service Pack-Versionen, Hotfixes, Schemaänderungen, Sicherheitsgruppen, Gruppenmitgliedschaften, Berechtigungen für Objekte im Dateisystem, freigegebene Ordner, die Registrierung, den Active Directory-Verzeichnisdienst, lokale und Gruppenrichtlinien-Einstellungen sowie Typ und Speicherort der Objektanzahl

• Ausgeführte Verwaltungsaufgaben, verwendete Verwaltungstools und Betriebssysteme, die zum Ausführen von Verwaltungsaufgaben verwendet werden

• Ausgeführte Vorgänge wie die folgenden:

  • Authentifizierung bei Computer- und Benutzeranmeldung
  • Kennwortzurücksetzungen durch Benutzer, Computer und Administratoren
  • Browsing
  • 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 aus allen Clientbetriebssystemen aus allen Clientbetriebssystemen aus allen Konto- oder Ressourcendomänen
  • Drucken aus administrativen und nicht administrativen Konten

Windows Server 2003 SP1

Warnungen in Gpedit.msc

Um Kunden darauf aufmerksam zu machen, dass sie ein Benutzerrecht oder eine Sicherheitsoption bearbeiten, die sich negativ auf ihr Netzwerk auswirken könnte, wurden gpedit.msc zwei Warnmechanismen hinzugefügt. Wenn Administratoren eine Benutzerberechtigung bearbeiten, die sich nachteilig auf das gesamte Unternehmen auswirken kann, wird ihnen ein neues Symbol angezeigt, das einem Vorfahrtsschild ähnelt. Außerdem erhalten sie eine Warnmeldung mit einem Link zum Microsoft Knowledge Base-Artikel 823659. Diese Meldung lautet wie folgt:

Das Ändern dieser Einstellung kann die Kompatibilität mit Clients, Diensten und Anwendungen beeinträchtigen. Weitere Informationen finden Sie unter <Änderung> von Benutzerrechten oder Sicherheitsoptionen (Q823659) Wenn Sie über einen Link in Gpedit.msc auf diesen Knowledge Base-Artikel weitergeleitet wurden, stellen Sie sicher, dass Sie die Erläuterung und die möglichen Auswirkungen einer Änderung dieser Einstellung gelesen und verstanden haben. Im Folgenden werden Benutzerrechte aufgeführt, die den Warntext enthalten:

• Auf diesen Computer über das Netzwerk zugreifen
• Lokal anmelden
• Umgehen der Traversierungsüberprüfung
• Vertrauenswürdige Delegierung für Computer und Benutzer ermöglichen

Im Folgenden werden die Sicherheitsoptionen aufgeführt, bei denen die Warnung und eine Popupmeldung angezeigt werden:

• Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer)
• Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher)
• Domänencontroller: Signaturanforderungen für LDAP-Server
• Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)
• Netzwerkzugriff: Ermöglicht anonyme SID-/Namensübersetzung
• Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben
• Netzwerksicherheit: LAN Manager-Authentifizierungsebene
• Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können
• Netzwerkzugriff: Signaturanforderungen für LDAP-Clients

Weitere Informationen

In den folgenden Abschnitten werden Inkompatibilitäten beschrieben, die auftreten können, wenn Sie bestimmte Einstellungen in Windows NT 4.0-, Windows 2000- und Windows Server 2003-Domänen ändern.

Benutzerrechte

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

1. Auf diesen Computer über das Netzwerk zugreifen

   1. Hintergrund

      Für die Möglichkeit, mit Windows-Remotecomputern zu interagieren, ist das Benutzerrecht "Auf diesen Computer vom Netzwerk aus zugreifen" erforderlich. Beispiele für solche Netzwerkoperationen sind die folgenden:

      • 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 auf Remotecomputern im Netzwerk

      Benutzer, Computer und Dienstkonten erhalten oder verlieren das Benutzerrecht "Zugriff auf diesen Computer über das Netzwerk", indem sie explizit oder implizit zu einer Sicherheitsgruppe hinzugefügt oder entfernt werden, der dieses Benutzerrecht gewährt wurde. Beispielsweise kann ein Benutzerkonto oder ein Computerkonto explizit von einem Administrator zu einer benutzerdefinierten Sicherheitsgruppe oder einer integrierten Sicherheitsgruppe hinzugefügt werden oder implizit vom Betriebssystem zu einer berechneten Sicherheitsgruppe wie Domänenbenutzern, authentifizierten Benutzern oder Unternehmensdomänencontrollern hinzugefügt werden.

      Standardmäßig wird Benutzerkonten und Computerkonten das Recht "Auf diesen Computer über das Netzwerk zugreifen" gewährt, wenn Computergruppen wie "Jeder" oder vorzugsweise "Authentifizierte Benutzer" und im Falle von Domänencontrollern die Gruppe "Unternehmensdomänencontroller" in den Standarddomänencontrollern Gruppenrichtlinie Object (GPO) definiert sind.

   2. Riskante Konfigurationen

      Die folgenden sind schädliche Konfigurationseinstellungen:

      • Entfernen der Sicherheitsgruppe "Domänencontroller der Organisation" aus diesem Benutzerrecht
      • Entfernen der Gruppe "Authentifizierte Benutzer" oder einer expliziten Gruppe, die Benutzern, Computern und Dienstkonten das Benutzerrecht zum Herstellen einer Verbindung mit Computern über das Netzwerk gewährt
      • Entfernen aller Benutzer und Computer aus diesem Benutzerrecht

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

      • Das Gewähren des Zugriffsrechts "Zugriff auf diesen Computer vom Netzwerk aus" auf die Gruppe "Organisationsdomänencontroller" erfüllt die Authentifizierungsanforderungen, die die Active Directory-Replikation erfüllen muss, damit die Replikation zwischen Domänencontrollern in derselben Gesamtstruktur erfolgen kann.
      • Mit dieser Benutzerberechtigung können Benutzer und Computer auf freigegebene Dateien, Drucker und Systemdienste zugreifen, einschließlich Active Directory.
      • Diese Benutzerberechtigung ist erforderlich, damit Benutzer mit frühen Versionen von Microsoft Outlook Web Access (OWA) auf E-Mails zugreifen können.

   4. Gründe für den Entzug dieses Benutzerrechts

      • Benutzer, die ihre Computer mit dem Netzwerk verbinden können, können auf Ressourcen auf Remotecomputern zugreifen, für die sie Berechtigungen besitzen. Diese Benutzerberechtigung ist beispielsweise erforderlich, damit ein Benutzer eine Verbindung mit freigegebenen Druckern und Ordnern herstellen kann. Wenn diese Benutzerberechtigung der Gruppe "Jeder" gewährt wird und für einige freigegebene Ordner sowohl Freigabe- als auch NTFS-Dateisystemberechtigungen so konfiguriert sind, dass dieselbe Gruppe über Lesezugriff verfügt, kann jeder die Dateien in diesen freigegebenen Ordnern anzeigen. Dies ist jedoch eine unwahrscheinliche Situation für Neuinstallationen von Windows Server 2003, da die Standardfreigabe und die NTFS-Berechtigungen in Windows Server 2003 die Gruppe "Jeder" nicht enthalten. Für Systeme, die von Microsoft Windows NT 4.0 oder Windows 2000 aktualisiert werden, kann diese Sicherheitsanfälligkeit ein höheres Risiko bergen, da die Standardfreigabe- und Dateisystemberechtigungen für diese Betriebssysteme nicht so restriktiv sind wie die Standardberechtigungen in Windows Server 2003.
      • Es gibt keinen triftigen Grund, die Gruppe "Domänencontroller der Organisation" aus diesem Benutzerrecht zu entfernen.
      • Die Gruppe "Jeder" wird in der Regel 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 der Gruppe "Jeder", der Gruppe "Authentifizierte Benutzer" oder der Gruppe "Organisationsdomänencontroller" nicht explizit das Recht "Auf diesen Computer vom Netzwerk aus zugreifen". Wenn Sie 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 vermeidet diese Fehlkonfiguration, indem der Gruppe "Domänencontroller in Organisation" dieses Benutzerrecht gewährt wird, wenn Sie ein Upgrade von primären Windows NT 4.0-Domänencontrollern (PDCs) durchführen. Erteilen Sie der Gruppe "Domänencontroller der Organisation" dieses Benutzerrecht, wenn es 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 von Überwachungstools wie REPLMON und REPADMIN oder Replikationsereignissen im Ereignisprotokoll gemeldet.

        • Active Directory-Schemapartition
        • Konfigurationspartition
        • Domänenpartition
        • Globale Katalogpartition
        • Anwendungspartition

      • Alle Microsoft-Netzwerkbetriebssysteme: Die Authentifizierung des Benutzerkontos von Remotenetzwerk-Clientcomputern schlägt fehl, es sei denn, dem Benutzer oder einer Sicherheitsgruppe, der der Benutzer angehört, wurde dieses Benutzerrecht erteilt.

      • 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 erteilt. Dieses Szenario gilt für Benutzerkonten, Computerkonten und Dienstkonten.

      • Alle Microsoft-Netzwerkbetriebssysteme: Wenn Sie alle Konten aus diesem Benutzerrecht entfernen, wird verhindert, dass sich ein Konto bei der Domäne anmeldet oder auf Netzwerkressourcen zugreift. Wenn berechnete Gruppen wie Organisationsdomänencontroller, Jeder oder Authentifizierte Benutzer entfernt werden, müssen Sie dieses Benutzerrecht Konten oder Sicherheitsgruppen, denen das Konto angehört, explizit gewähren, um über das Netzwerk auf Remotecomputer zuzugreifen. Dieses Szenario gilt für alle Benutzerkonten, für alle Computerkonten und für 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 können Sie mit der Fehlermeldung "Zugriff verweigert" rechnen.

2. Lokale Anmeldung zulassen

   1. Hintergrund

      Benutzer, die versuchen, sich an der Konsole eines Windows-basierten Computers anzumelden (mit der Tastenkombination STRG+ALT+ENTF), 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 oder Domänencontrollern im gesamten Unternehmen anmelden, sowie Domänenbenutzer, die sich bei Mitgliedscomputern anmelden, um mit nicht privilegierten Konten auf ihre Desktops zuzugreifen. Benutzer, die eine Remotedesktopverbindung oder Terminaldienste verwenden, müssen auf Zielcomputern mit Windows 2000 oder Windows XP über das Benutzerrecht "Lokale Anmeldung zulassen" verfügen, da diese Anmeldemodi für den Hostcomputer als lokal 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 sind schädliche Konfigurationseinstellungen:

      • Entfernen von administrativen Sicherheitsgruppen, einschließlich Konto-Operatoren, Sicherungs-Operatoren, Drucker-Operatoren oder Server-Operatoren und der integrierten Administratorengruppe aus der Richtlinie des Standarddomänencontrollers.
      • Entfernen von Dienstkonten, die von Komponenten und Programmen auf Mitgliedscomputern und Domänencontrollern in der Domäne verwendet werden, aus der Richtlinie des Standarddomänencontrollers.
      • Entfernen von Benutzern oder Sicherheitsgruppen, die sich an der Konsole von Mitgliedscomputern 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" zum Recht "Lokale Anmeldung verweigern". Diese Konfiguration verhindert, dass sich Benutzer bei Mitgliedscomputern oder Domänencontrollern in der Domäne anmelden.

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

      • Benutzer müssen über das Benutzerrecht "Lokale Anmeldung zulassen" verfügen, um auf die Konsole oder den Desktop eines Arbeitsgruppencomputers, eines Mitgliedscomputers oder eines Domänencontrollers zuzugreifen.
      • Benutzer müssen über dieses Benutzerrecht verfügen, um sich über eine Terminaldienstesitzung anzumelden, die auf einem Windows 2000-basierten Mitgliedscomputer oder Domänencontroller ausgeführt wird.

   4. Gründe für den Entzug dieses Benutzerrechts

      • Wenn der Konsolenzugriff nicht auf legitime Benutzerkonten beschrä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 des Benutzerrechts "Lokale Anmeldung zulassen" verhindert unbefugte Anmeldungen auf den Konsolen von Computern, z. B. Domänencontrollern oder Anwendungsservern.
      • Durch das Entfernen dieses Anmelderechts wird 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: Das Benutzerrecht "Lokale Anmeldung zulassen" 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 müssen diese Berechtigung gewährt werden, um sich an der Konsole von Computern anzumelden, auf denen Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003 ausgeführt wird.
      • Windows NT 4.0 und höher: Wenn Sie auf Computern unter Windows NT 4.0 und höher das Benutzerrecht "Lokale Anmeldung zulassen" hinzufügen, aber implizit oder explizit auch das Recht "Lokale Anmeldung verweigern" erteilen, können sich die Konten nicht bei der Konsole der Domänencontroller anmelden.

3. Umgehen der Traversierungsüberprüfung

   1. Hintergrund

      Das Benutzerrecht "Traverse-Überprüfung umgehen" ermöglicht es dem Benutzer, Ordner im NTFS-Dateisystem oder in der Registrierung zu durchsuchen, ohne nach der speziellen Zugriffsberechtigung "Traverse-Ordner" zu suchen. Das Benutzerrecht "Traverse Checking umgehen" erlaubt es dem Benutzer nicht, den Inhalt eines Ordners aufzulisten. Es erlaubt dem Benutzer, nur die zugehörigen Ordner zu durchsuchen.

   2. Riskante Konfigurationen

      Die folgenden sind schädliche Konfigurationseinstellungen:

      • Entfernen von Nicht-Administratorkonten, die sich an Windows 2000-basierten Terminaldienstecomputern oder Windows Server 2003-basierten Terminaldienstecomputern anmelden, die nicht über die Berechtigung für den Zugriff auf Dateien und Ordner im Dateisystem verfügen.
      • Entfernen der Gruppe "Jeder" aus der Liste der Sicherheitsprinzipale, die standardmäßig über diese Benutzerberechtigung verfügen. Windows-Betriebssysteme und auch viele Programme werden mit der Erwartung entwickelt, dass jeder, der rechtmäßig auf den Computer zugreifen kann, über das Benutzerrecht "Traverse Checking umgehen" verfügt. Daher kann das Entfernen der Gruppe "Jeder" aus der Liste der Sicherheitsprinzipale, die standardmäßig über diese Benutzerberechtigung verfügen, zu Instabilität des Betriebssystems oder zu Programmfehlern führen. Es ist besser, diese Einstellung auf die Standardeinstellung festzulegen.

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

      Die Standardeinstellung für das Benutzerrecht "Traverse-Überprüfung umgehen" besteht darin, jedem das Umgehen der Traversierungsüberprüfung zu ermöglichen. Für erfahrene Windows-Systemadministratoren ist dies das erwartete Verhalten, und sie konfigurieren die Dateisystem-Zugriffssteuerungslisten (SACLs) entsprechend. Das einzige Szenario, in dem die Standardkonfiguration zu einem Missgeschick 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 den Inhalt von untergeordneten Ordnern zugreifen können.

   4. Gründe für den Entzug dieses Benutzerrechts

      Um den Zugriff auf die Dateien oder Ordner im Dateisystem zu verhindern, könnten Organisationen, die sehr auf die Sicherheit bedacht sind, versucht sein, die Gruppe "Jeder" oder sogar die Gruppe "Benutzer" aus der Liste der Gruppen zu entfernen, die über das Benutzerrecht "Traverse Checking umgehen" verfügen.

   5. Beispiele für Kompatibilitätsprobleme

      • Windows 2000, Windows Server 2003: Wenn auf Computern unter Windows 2000 oder Windows Server 2003 das Benutzerrecht "Traverse Checking umgehen" entfernt oder falsch konfiguriert ist, werden die Einstellungen der Gruppenrichtlinie im Ordner SYVOL nicht zwischen Domänencontrollern in der Domäne repliziert.

      • Windows 2000, Windows XP Professional und Windows Server 2003: Computer unter Windows 2000, Windows XP Professional oder Windows Server 2003 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 das Benutzerrecht "Traverse-Überprüfung umgehen" entfernt oder falsch konfiguriert wurde.

         

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

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

        Hinweis

        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 "Zugriff verweigert"-Fehlermeldungen, wenn ihnen das Benutzerrecht "Traverse Checking umgehen" nicht gewährt wird.

         

      • Windows NT 4.0: Auf Windows NT 4.0-basierten Computern führt das Entfernen des Benutzerrechts "Traverse Checking umgehen" dazu, dass beim Kopieren eine Dateikopie Dateistreams verworfen werden. Wenn Sie dieses Benutzerrecht entfernen, geht beim Kopieren einer Datei von einem Windows-Client oder einem Macintosh-Client auf einen Windows NT 4.0-Domänencontroller, auf dem Dienste für Macintosh ausgeführt werden, der Zieldatenstrom verloren, und die Datei wird als Nur-Text-Datei angezeigt.

      • Microsoft Windows 95, Microsoft Windows 98: Auf einem Clientcomputer unter Windows 95 oder Windows 98 schlägt der Befehl net use * /home mit der Fehlermeldung "Zugriff verweigert" fehl, wenn der Gruppe "Authentifizierte Benutzer" das Benutzerrecht "Traverse Checking umgehen" nicht 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 Benutzerrecht "Traverse Checking umgehen" 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 angegeben, die beim Konfigurieren der Sicherheitseinstellung auftreten können.

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

   1. Hintergrund

      • Über die Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können, wird bestimmt, ob das System heruntergefahren wird, wenn Sicherheitsereignisse nicht protokolliert werden können. Diese Einstellung ist für die C2-Auswertung des TCSEC-Programms (Trusted Computer Security Evaluation Criteria) und für die Common Criteria for Information Technology Security Evaluation erforderlich, um überwachbare Ereignisse zu verhindern, wenn das Überwachungssystem diese Ereignisse nicht protokollieren kann. Wenn das Überwachungssystem fehlschlägt, wird das System heruntergefahren und eine Stoppfehlermeldung angezeigt.
      • Wenn der Computer Ereignisse nicht im Sicherheitsprotokoll aufzeichnen kann, stehen wichtige Beweise oder wichtige Informationen zur Problembehandlung nach einem Sicherheitsvorfall möglicherweise nicht zur Überprüfung zur Verfügung.

   2. Riskante Konfiguration

      Das Folgende ist eine schädliche Konfigurationseinstellung: Die Einstellung "Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können" ist aktiviert, und die Größe des Sicherheitsereignisprotokolls wird durch die Option Ereignisse nicht überschreiben (Protokoll manuell löschen), die Option Ereignisse nach Bedarf überschreiben oder die Option Ereignisse überschreiben, die älter als die Anzahl Tage sind" in der Ereignisanzeige eingeschränkt. Im Abschnitt "Beispiele für Kompatibilitätsprobleme" finden Sie weitere Informationen zu spezifischen Risiken für Computer, auf denen die ursprüngliche veröffentlichte Version von Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 oder Windows 2000 SP3 ausgeführt wird.

   3. Gründe für das Aktivieren dieser Einstellung

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

   4. Gründe für das Deaktivieren dieser Einstellung

      • Durch Aktivieren der Einstellung "Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können" wird das System beendet, wenn eine Sicherheitsüberwachung aus irgendeinem Grund nicht protokolliert werden kann. In der Regel kann ein Ereignis nicht protokolliert werden, wenn das Sicherheitsüberwachungsprotokoll voll ist und wenn die angegebene Aufbewahrungsmethode entweder die Option Ereignisse nicht überschreiben (Protokoll manuell löschen) oder die Option Ereignisse überschreiben, die älter als die Anzahl der Tage sind.
      • Der Verwaltungsaufwand für die Aktivierung der Einstellung "Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können" 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 eine individuelle Verantwortlichkeit für Bedieneraktionen. Beispielsweise könnte ein Administrator Berechtigungen für alle Benutzer, Computer und Gruppen in einer Organisationseinheit zurücksetzen, in der die Überwachung mithilfe des integrierten Administratorkontos oder eines anderen freigegebenen Kontos aktiviert wurde, und dann das Zurücksetzen dieser Berechtigungen verweigern. Die Aktivierung der Einstellung verringert jedoch die Stabilität des Systems, da ein Server möglicherweise heruntergefahren wird, indem er mit Anmeldeereignissen und anderen Sicherheitsereignissen, die in das Sicherheitsprotokoll geschrieben werden, überlastet wird. Da es sich nicht um ein ordnungsgemäßes Herunterfahren handelt, können außerdem irreparable Schäden am Betriebssystem, an Programmen oder an Daten die Folge sein. NTFS garantiert zwar, dass die Integrität des Dateisystems bei einem unzulässigen Herunterfahren des Systems erhalten bleibt, kann jedoch nicht garantieren, dass jede Datendatei für jedes Programm beim Neustart des Systems noch in einer brauchbaren 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 kann es vorkommen, dass Computer, auf denen die ursprüngliche 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 ist. Dieser Fehler wurde in Windows 2000 Service Pack 4 (SP4) behoben. Vergewissern Sie sich, dass auf den Windows 2000-Domänencontrollern Windows 2000 Service Pack 4 installiert ist, bevor Sie diese Einstellung aktivieren.

         

      • Windows 2000, Windows Server 2003: Computer unter Windows 2000 oder Windows Server 2003 reagieren möglicherweise nicht mehr und werden dann spontan neu gestartet, wenn die Einstellung "Überwachung: System sofort herunterfahren" aktiviert ist, das Sicherheitsprotokoll voll ist und ein vorhandener Ereignisprotokolleintrag nicht überschrieben werden kann. Beim Neustart des Computers wird die folgende Abbruchfehlermeldung angezeigt:

        Hinweis

        STOP: C0000244 {Audit Failed}
        Fehler beim Generieren einer Sicherheitsüberwachung.

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

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

        Hinweis

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

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

        Hinweis

        Unbekannter Benutzer oder ungültiges Kennwort

      • Windows 2000: Auf Windows 2000-Domänencontrollern wird der standortübergreifende Messagingdienst (Intersite Messaging Service, 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 die Meldung "Zugriff verweigert" wird angezeigt, wenn das Sicherheitsereignisprotokoll voll ist.

      • 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: Nichtadministratoren können nicht über Microsoft Outlook oder Microsoft Outlook Web Access auf ihre E-Mails zugreifen und erhalten einen 503-Fehler.

2. Domänencontroller: Signaturanforderungen für LDAP-Server

   1. Hintergrund

      Die Sicherheitseinstellung Domänencontroller: Signaturanforderungen für LDAP-Server bestimmt, ob der LDAP-Server (Lightweight Directory Access-Protokoll) LDAP-Clients zum Aushandeln der Datensignatur erfordert. Die möglichen Werte für diese Richtlinieneinstellung lauten:

      • Keine: Die Datensignierung ist für die Bindung an den Server nicht erforderlich. Wenn der Client eine Datensignatur anfordert, unterstützt der Server diese.
      • Signierung erforderlich: Die LDAP-Datensignaturoption muss ausgehandelt werden, es sei denn, TLS/SSL (Transport Layer Security/Secure Socket Layer) wird verwendet.
      • nicht definiert: Diese Einstellung ist nicht aktiviert oder deaktiviert.

   2. Riskante Konfigurationen

      Die folgenden sind schädliche Konfigurationseinstellungen:

      • Aktivieren von "Anmeldung anfordern" in Umgebungen, in denen Clients LDAP-Signaturen nicht unterstützen oder in denen die clientseitige LDAP-Signatur auf dem Client nicht aktiviert ist
      • Anwendung der Sicherheitsvorlage "Hisecdc.inf" für Windows 2000 oder Windows Server 2003 in Umgebungen, in denen die Clients LDAP-Signaturen nicht unterstützen oder die clientseitige LDAP-Signatur nicht aktiviert ist
      • Anwendung der Sicherheitsvorlage Hisecws.inf für Windows 2000 oder Windows Server 2003 in Umgebungen, in denen die Clients LDAP-Signaturen nicht unterstützen oder die clientseitige LDAP-Signatur nicht aktiviert ist

   3. Gründe für das Aktivieren dieser Einstellung

      Nicht signierter Netzwerkverkehr ist anfällig für "Man-in-the-Middle"-Angriffe, bei denen ein Angreifer Pakete zwischen Client und Server abfängt, die Pakete ändert und sie anschließend an den Server weiterleitet. Wenn dieses Verhalten auf einem LDAP-Server auftritt, kann ein Angreifer den Server zu Entscheidungen veranlassen, 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 den IP-Datenverkehr durch.

   4. Gründe für das Deaktivieren dieser Einstellung

      • Clients, die LDAP-Signaturen nicht unterstützen, können LDAP-Abfragen für Domänencontroller und globale Kataloge nicht ausfü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-Konversationen.
      • 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:

        Hinweis

        Ldap_simple_bind_s() fehlgeschlagen: Starke Authentifizierung erforderlich.

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

         

      • Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Auf Clients unter Windows 2000 SP4, Windows XP oder Windows Server 2003 funktionieren einige Active Directory-Verwaltungsprogramme, die auf Domänencontroller ausgerichtet sind, auf denen ältere Versionen von Windows 2000 als 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 unter Windows 2000 SP4, Windows XP oder Windows Server 2003 funktionieren einige Active Directory-Verwaltungsprogramme, die auf Domänencontroller ausgerichtet sind, auf denen ältere Versionen von Windows 2000 als SP3 ausgeführt werden, nicht ordnungsgemäß.

         

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

   1. Hintergrund

      • Die Einstellung Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) bestimmt, ob ein sicherer Kanal mit einem Domänencontroller eingerichtet werden kann, der den Datenverkehr des sicheren Kanals nicht mit einem starken 128-Bit-Sitzungsschlüssel verschlüsseln kann. Durch Aktivieren dieser Einstellung wird die Einrichtung eines sicheren Kanals mit einem Domänencontroller verhindert, der die Daten des sicheren Kanals nicht mit einem starken Schlüssel verschlüsseln kann. Wenn Sie diese Einstellung deaktivieren, sind 64-Bit-Sitzungsschlüssel zulässig.
      • 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, in der Lage sein, Daten des sicheren Kanals mit einem starken 128-Bit-Schlüssel zu verschlüsseln. Das bedeutet, dass auf allen diesen Domänencontrollern Windows 2000 oder höher ausgeführt werden muss.

   2. Riskante Konfiguration

      Die Aktivierung der Einstellung Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) ist eine schädliche Konfigurationseinstellung.

   3. Gründe für das Aktivieren 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 der Microsoft-Betriebssysteme.
      • Wenn möglich, empfiehlt es sich, diese stärkeren Sitzungsschlüssel zu nutzen, um die sichere Kanalkommunikation vor Lauschangriffen und vor Netzwerkangriffen durch Sitzungsentführungen zu schützen. Lauschangriffe sind eine Form von böswilligen Angriffen, bei denen Netzwerkdaten während der Übertragung gelesen oder geändert werden. Die Daten können geändert werden, um den Absender auszublenden, zu ändern oder umzuleiten.

      Wichtig Ein Computer unter 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 Windows NT 4.0-basierten Domänen und Windows Server 2008 R2-basierten Domänen. Außerdem wird durch diese Einschränkung die Windows NT 4.0-basierte Domänenmitgliedschaft von Computern blockiert, auf denen Windows 7 oder Windows Server 2008 R2 ausgeführt wird, und umgekehrt.

   4. Gründe für das Deaktivieren 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 von Vertrauensstellungen zwischen Windows NT 4.0- und Windows 2000-Domänen mit NLTEST fehl. Es wird die Fehlermeldung "Zugriff verweigert" angezeigt:
      Fehler bei der Vertrauensstellung zwischen der primären Domäne und der vertrauenswürdigen Domäne.

      Windows 7 und Windows Server 2008 R2: Für Windows 7 und höhere Versionen sowie 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: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer)

   1. Hintergrund

      • Aktivierung von Domänenmitglied: Das digitale Verschlüsseln oder Signieren von Daten des sicheren Kanals verhindert (immer) das Einrichten eines sicheren Kanals mit einem Domänencontroller, der nicht alle Daten des sicheren Kanals signieren oder verschlüsseln kann. Zum Schutz des Authentifizierungsverkehrs vor Man-in-the-Middle-Angriffen, Replay-Angriffen und anderen Arten von Netzwerkangriffen erstellen Windows-basierte Computer über den Netzwerkanmeldungsdienst einen Kommunikationskanal, der als sicherer Kanal bezeichnet wird, 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 Multidomänenauthentifizierung oder Passthrough-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.
      • So aktivieren Sie die Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) Auf einem Mitgliedscomputer müssen alle Domänencontroller in der Domäne, zu der das Mitglied gehört, alle Daten des sicheren Kanals signieren oder verschlüsseln können. Das bedeutet, dass auf allen diesen Domänencontrollern Windows NT 4.0 mit Service Pack 6a (SP6a) oder höher ausgeführt werden muss.
      • Durch Aktivieren der Einstellung "Domänenmitglied: Sichere Kanaldaten digital verschlüsseln oder signieren (immer)" wird automatisch die Einstellung "Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (wenn möglich)" aktiviert.

   2. Riskante Konfiguration

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

   3. Gründe für das Aktivieren dieser Einstellung

      Unsignierter Netzwerkverkehr ist anfällig für "Man-in-the-Middle"-Angriffe, bei denen ein Angreifer Pakete zwischen dem Server und dem Client abfängt und dann ändert, bevor er sie an den Client weiterleitet. Wenn dieses Verhalten auf einem LDAP-Server (Lightweight Directory Access Protocol) auftritt, kann der Eindringling einen Client zu Entscheidungen veranlassen, die auf falschen Einträgen 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 den IP-Datenverkehr durch.

   4. Gründe für das Deaktivieren dieser Einstellung

      • Computer in lokalen oder externen Domänen unterstützen verschlüsselte sichere Kanäle.
      • Nicht alle Domänencontroller in der Domäne verfügen über die entsprechenden Service Pack-Revisionsstufen, 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-Mitgliedscomputer können keinen Windows NT 4.0-Domänen beitreten und erhalten die folgende Fehlermeldung:

        Hinweis

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

        Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
        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 keine untergeordnete Vertrauensstellung mit einer Windows 2000-Domäne einrichten und erhalten die folgende Fehlermeldung:

        Hinweis

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

        Vorhandene niedrigere Vertrauensstellungen 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 es wird möglicherweise eine Fehlermeldung angezeigt, die besagt, dass der Client die Domäne nicht finden kann.

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

        Hinweis

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

      • Microsoft-Netzwerk: Microsoft-Netzwerkclients erhalten eine der folgenden Fehlermeldungen:

        Hinweis

        Anmelden gescheitert: Unbekannter Benutzername oder ungültiges Kennwort.

        Hinweis

        Es gibt keinen Benutzersitzungsschlüssel für die angegebene Anmeldesitzung.

5. Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)

   1. Hintergrund

      Server Message Block (SMB) ist das Protokoll für die gemeinsame Nutzung von Ressourcen, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Grundlage des NetBIOS (Network Basic Input/Output System) und vieler anderer Protokolle. Die SMB-Signatur authentifiziert sowohl den Benutzer als auch den Server, der die Daten hostet. Wenn eine Seite den Authentifizierungsprozess nicht besteht, findet keine Datenübertragung statt.

      Die Aktivierung der SMB-Signatur beginnt während der SMB-Protokollaushandlung. Die SMB-Signaturrichtlinien bestimmen, ob der Computer die Clientkommunikation immer digital signiert.

      Das SMB-Authentifizierungsprotokoll von Windows 2000 unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung schließt einen "Man-in-the-Middle"-Angriff. Das SMB-Authentifizierungsprotokoll von Windows 2000 unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft, Angriffe auf aktive Nachrichten zu verhindern. Um Ihnen diese Authentifizierung zu ermöglichen, platziert die SMB-Signatur eine digitale Signatur in jedem SMB. Der Client und der Server überprüfen jeweils die digitale Signatur.

      Um die SMB-Signatur verwenden zu können, müssen Sie die SMB-Signatur sowohl auf dem SMB-Client als auch auf dem SMB-Server aktivieren oder verlangen. Wenn die SMB-Signatur auf einem Server aktiviert ist, verwenden Clients, die ebenfalls für die SMB-Signatur aktiviert sind, das Paketsignaturprotokoll während aller nachfolgenden Sitzungen. Wenn eine SMB-Signatur auf einem Server erforderlich ist, kann ein Client keine Sitzung einrichten, es sei denn, der Client ist aktiviert oder für die SMB-Signatur erforderlich.

      Das Aktivieren der digitalen Signatur in Hochsicherheitsnetzwerken trägt dazu bei, die Identität von Clients und Servern zu verhindern. Diese Art des Identitätswechsels wird als Session-Hijacking bezeichnet. Ein Angreifer, der Zugriff auf dasselbe 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 ihn dann weiterleiten, sodass der Server unerwünschte Aktionen ausführen könnte. Oder der Angreifer könnte sich nach einer legitimen Authentifizierung als Server oder als Client ausgeben und dann unbefugten Zugriff auf Daten erhalten.

      Das SMB-Protokoll, das für die Dateifreigabe und die Druckerfreigabe 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 beendet Session-Hijacking-Angriffe und unterstützt die Nachrichtenauthentifizierung. Daher werden Man-in-the-Middle-Angriffe verhindert. Die SMB-Signatur stellt diese Authentifizierung bereit, indem sie in jedem SMB eine digitale Signatur platziert. 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 Netzwerkverkehr zu schützen. Es gibt hardwarebasierte Schnellinfos für die IPSec-Verschlüsselung und -Signatur, mit denen Sie die Leistungsbeeinträchtigung der Server-CPU minimieren können. Es gibt keine solchen Schnellinfos, die für SMB-Signaturen verfügbar sind.

        Weitere Informationen finden Sie im Kapitel "Serverkommunikation digital signieren " auf der MSDN-Website von Microsoft.

        Konfigurieren Sie die SMB-Signierung über den Gruppenrichtlinien-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 Verzeichnisdiensteclient die SMB-Signatur, wenn er sich bei Windows Server 2003-Servern mithilfe der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signatur, wenn sie sich bei diesen Servern mithilfe der NTLMv2-Authentifizierung authentifizieren. Außerdem reagieren Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients. Weitere Informationen finden Sie unter Punkt 10: "Netzwerksicherheit: Lan Manager-Authentifizierungsebene".

   2. Riskante Konfiguration

      Die folgende Einstellung ist schädlich für die Konfiguration: Wenn sowohl der Microsoft-Netzwerkclient: Kommunikation digital signieren (immer) als auch die Microsoft-Netzwerkclient: Kommunikation digital signieren (wenn Server zustimmt) auf "Nicht definiert" festgelegt oder deaktiviert, sind sie deaktiviert. Mit diesen Einstellungen kann der Redirector Nur-Text-Kennwörter an Nicht-Microsoft SMB-Server senden, die keine Kennwortverschlüsselung während der Authentifizierung unterstützen.

   3. Gründe für das Aktivieren dieser Einstellung

      Aktivieren von Microsoft-Netzwerkclient: Zum digitalen Signieren von Kommunikationen (immer) müssen Clients SMB-Datenverkehr signieren, wenn sie Server kontaktieren, die keine SMB-Signatur erfordern. Dadurch werden Clients weniger anfällig für Session-Hijacking-Angriffe.

   4. Gründe für das Deaktivieren dieser Einstellung

      • Aktivieren des Microsoft-Netzwerkclients: Das digitale Signieren der Kommunikation verhindert (immer), dass Clients mit Zielservern kommunizieren, die keine SMB-Signatur unterstützen.
      • Wenn Sie Computer so konfigurieren, dass die gesamte nicht signierte SMB-Kommunikation ignoriert wird, können frühere Programme und Betriebssysteme keine 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-Server und auf Windows Server 2003-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:

        Hinweis

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

   8. Neustartanforderungen

      Starten Sie den Computer neu, oder starten Sie den Arbeitsstationsdienst neu. Geben Sie dazu bei einer Eingabeaufforderung die Befehle hier unten ein. Drücken Sie nach jedem eingegebenen Befehl die Eingabetaste.
      net stop workstation
      net start workstation

6. Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)

   1. Hintergrund

      • Server Messenger Block (SMB) ist das Protokoll zur gemeinsamen Nutzung von Ressourcen, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Grundlage des NetBIOS (Network Basic Input/Output System) und vieler anderer Protokolle. Die SMB-Signatur authentifiziert sowohl den Benutzer als auch den Server, der die Daten hostet. Wenn eine Seite den Authentifizierungsprozess nicht besteht, findet keine Datenübertragung statt.

        Die Aktivierung der SMB-Signatur beginnt während der SMB-Protokollaushandlung. Die SMB-Signaturrichtlinien bestimmen, ob der Computer die Clientkommunikation immer digital signiert.

        Das SMB-Authentifizierungsprotokoll von Windows 2000 unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung schließt einen "Man-in-the-Middle"-Angriff. Das SMB-Authentifizierungsprotokoll von Windows 2000 unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft, Angriffe auf aktive Nachrichten zu verhindern. Um Ihnen diese Authentifizierung zu ermöglichen, platziert die SMB-Signatur eine digitale Signatur in jedem SMB. Der Client und der Server überprüfen jeweils die digitale Signatur.

        Um die SMB-Signatur verwenden zu können, müssen Sie die SMB-Signatur sowohl auf dem SMB-Client als auch auf dem SMB-Server aktivieren oder verlangen. Wenn die SMB-Signatur auf einem Server aktiviert ist, verwenden Clients, die ebenfalls für die SMB-Signatur aktiviert sind, das Paketsignaturprotokoll während aller nachfolgenden Sitzungen. Wenn eine SMB-Signatur auf einem Server erforderlich ist, kann ein Client keine Sitzung einrichten, es sei denn, der Client ist aktiviert oder für die SMB-Signatur erforderlich.

        Das Aktivieren der digitalen Signatur in Hochsicherheitsnetzwerken trägt dazu bei, die Identität von Clients und Servern zu verhindern. Diese Art des Identitätswechsels wird als Session-Hijacking bezeichnet. Ein Angreifer, der Zugriff auf dasselbe 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 SBM-Pakete (Subnet Bandwidth Manager) abfangen und ändern, den Datenverkehr ändern und ihn dann weiterleiten, sodass der Server unerwünschte Aktionen ausführen könnte. Oder der Angreifer könnte sich nach einer legitimen Authentifizierung als Server oder als Client ausgeben und dann unbefugten Zugriff auf Daten erhalten.

        Das SMB-Protokoll, das für die Dateifreigabe und die Druckerfreigabe 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 beendet Session-Hijacking-Angriffe und unterstützt die Nachrichtenauthentifizierung. Daher werden Man-in-the-Middle-Angriffe verhindert. Die SMB-Signatur stellt diese Authentifizierung bereit, indem sie in jedem SMB eine digitale Signatur platziert. 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 Netzwerkverkehr zu schützen. Es gibt hardwarebasierte Schnellinfos für die IPSec-Verschlüsselung und -Signatur, mit denen Sie die Leistungsbeeinträchtigung der Server-CPU minimieren können. Es gibt keine solchen Schnellinfos, die für SMB-Signaturen verfügbar sind.

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

   2. Riskante Konfiguration

      Die folgende Einstellung ist schädlich: Aktivieren des Microsoft-Netzwerkservers: Kommunikation (immer) digital signieren auf Servern und Domänencontrollern, auf die von inkompatiblen Windows-basierten Computern und auf Clientcomputern von Drittanbietern in lokalen oder externen Domänen zugegriffen wird.

   3. Gründe für das Aktivieren dieser Einstellung

      • Alle Clientcomputer, die diese Einstellung direkt über die Registrierung oder die Gruppenrichtlinie aktivieren, unterstützen die SMB-Signierung. Mit anderen Worten: Alle Clientcomputer, für die 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 Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) deaktiviert ist, ist die SMB-Signatur vollständig deaktiviert. Wenn Sie alle SMB-Signaturen vollständig deaktivieren, werden Computer anfälliger für Session-Hijacking-Angriffe.

   4. Gründe für das Deaktivieren dieser Einstellung

      • Die Aktivierung dieser Einstellung kann zu langsamerem Kopieren von Dateien und zu einer langsameren Netzwerkleistung auf Clientcomputern führen.
      • Durch Aktivieren dieser Einstellung wird verhindert, dass Clients, die SMB-Signaturen nicht 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: Bei Windows 95-Clients, auf denen der Client für Verzeichnisdienste (DS) nicht installiert ist, schlagen die Anmeldeauthentifizierung fehl und sie erhalten die folgende Fehlermeldung:

        Hinweis

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

      • Windows NT 4.0: Auf Clientcomputern mit Windows NT 4.0-Versionen, die älter als Service Pack 3 (SP3) sind, tritt bei der Anmeldeauthentifizierung ein Fehler auf, und die folgende Fehlermeldung wird angezeigt:

        Hinweis

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

        Einige SMB-Server, die nicht von Microsoft stammen, unterstützen nur den unverschlüsselten Kennwortaustausch während der Authentifizierung. (Dieser Austausch wird auch als "Nur-Text"-Austausch bezeichnet.) Bei Windows NT 4.0 SP3 und späteren Versionen sendet der SMB-Redirector während der Authentifizierung kein unverschlüsseltes Kennwort an einen SMB-Server, es sei denn, Sie fügen einen spezifischen Registrierungseintrag hinzu.
        Um unverschlüsselte Kennwörter für den SMB-Client auf 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 die Sicherheitseinstellungen auf Domänencontrollern, auf denen Windows Server 2003 ausgeführt wird, so konfiguriert, dass sie verhindern, dass die Kommunikation der Domänencontroller 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 SMB-Signatur und -Verschlüsselung als auch die Signatur für den Datenverkehr des sicheren Kanals verwenden. Standardmäßig ist auf Clients unter Windows NT 4.0, auf denen Service Pack 2 (SP2) oder früher installiert ist, und auf Clients unter Windows 95 die SMB-Paketsignierung nicht aktiviert. Daher sind diese Clients möglicherweise nicht in der Lage, sich bei einem Domänencontroller mit Windows Server 2003 zu authentifizieren.

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

        • Computerkonfiguration\Einstellungen für Windows-Sicherheit\Sicherheitsoptionen
        • Unverschlüsseltes Kennwort senden, um eine Verbindung mit SMB-Servern von Drittanbietern herzustellen (diese Einstellung gilt für Windows 2000)
        • Microsoft-Netzwerk (Client): Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden (diese Einstellung gilt für Windows Server 2003)

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

      • Die folgenden Clients sind mit dem Microsoft-Netzwerkserver nicht kompatibel: Kommunikation digital signieren (immer):

        • Apple Computer, Inc., Mac OS X-Clients
        • Microsoft MS-DOS-Netzwerkclients (z. B. Microsoft LAN Manager)
        • Microsoft Windows for Workgroups-Clients
        • Microsoft Windows 95-Clients ohne installierten DS Client
        • Microsoft Windows NT 4.0-basierte Computer ohne SP3 oder höher
        • Novell Netware 6 CIFS-Clients
        • SAMBA SMB-Clients, die keine Unterstützung für SMB-Signaturen haben

   8. Neustartanforderungen

      Starten Sie den Computer neu, oder starten Sie den Serverdienst neu. Geben Sie dazu bei einer Eingabeaufforderung die Befehle hier unten ein. Drücken Sie nach jedem eingegebenen Befehl die Eingabetaste.
      net stop server
      net start server

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

   1. Hintergrund

      Die Sicherheitseinstellung Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen bestimmt, ob ein anonymer Benutzer SID-Attribute (Security ID Number, Sicherheitsidentifikationsnummer) für einen anderen Benutzer anfordern kann.

   2. Riskante Konfiguration

      Aktivieren des Netzwerkzugriffs: Anonyme SID-/Namensübersetzungseinstellung zulassen ist eine schädliche Konfigurationseinstellung.

   3. Gründe für das Aktivieren dieser Einstellung

      Wenn die Einstellung Netzwerkzugriff: Anonyme SID/Namensübersetzung 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 RAS-Dienstserver
      • Microsoft SQL Server, die auf Windows NT 3.x-Computern oder Windows NT 4.0-Computern ausgeführt werden
      • RAS-Dienst, der auf Windows 2000-basierten Computern ausgeführt wird, die sich in Windows NT 3.x- oder Windows NT 4.0-Domänen befinden
      • SQL Server, 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
      • Benutzer in einer Windows NT 4.0-Ressourcendomäne, die Benutzerkonten aus Kontodomänen, die Windows Server 2003-Domänencontroller enthalten, Berechtigungen für den Zugriff auf Dateien, freigegebene Ordner und Registrierungsobjekte erteilen möchten

   4. Gründe für das Deaktivieren dieser Einstellung

      Wenn diese Einstellung aktiviert ist, könnte ein böswilliger Benutzer die bekannte Administrator-SID verwenden, um den echten Namen des integrierten Administratorkontos zu erhalten, selbst wenn das Konto umbenannt wurde. Diese Person könnte dann den Kontonamen verwenden, um einen Angriff zum Erraten von Kennwörtern zu starten.

   5. Symbolischer Name: N/A

   6. Registrierungspfad: keiner. Der Pfad wird im Benutzeroberflächencode angegeben.

   7. Beispiele für Kompatibilitätsprobleme

      Windows NT 4.0: Computer in Windows NT 4.0-Ressourcendomänen zeigen im ACL-Editor die Fehlermeldung "Unbekanntes Konto" an, 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 erlauben

   1. Hintergrund

      • Die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht zulassen bestimmt, welche zusätzlichen Berechtigungen für anonyme Verbindungen mit dem Computer gewährt werden. Windows ermöglicht anonymen Benutzern das Ausführen bestimmter Aktivitäten, z. B. das Aufzählen der Namen von SAM-Konten (Security Accounts Manager, Sicherheitskonten) auf Arbeitsstationen und Servern sowie von Netzwerkfreigaben. Beispielsweise kann ein Administrator dies verwenden, um Benutzern in einer vertrauenswürdigen Domäne Zugriff zu gewähren, die keine gegenseitige Vertrauensstellung verwaltet. Sobald eine Sitzung durchgeführt wurde, kann ein anonymer Benutzer denselben Zugriff haben, der der Gruppe "Jeder" gewährt wird, basierend auf der Einstellung in der Einstellung Netzwerkzugriff: Alle Berechtigungen können auf anonyme Benutzer angewendet werden oder die freigegebene Zugriffssteuerungsliste (Discretionary Access Control List, DACL) des Objekts.

        In der Regel werden anonyme Verbindungen von früheren Versionen von Clients (untergeordnete Clients) während des Setups einer SMB-Sitzung angefordert. In diesen Fällen zeigt eine Netzwerkablaufverfolgung, dass die SMB-Prozess-ID (PID) der Clientredirector ist, z. B. 0xFEFF in Windows 2000 oder 0xCAFE in Windows NT. RPC versucht möglicherweise auch, 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 "Prä-Windows 2000-kompatibler Zugriff" gesteuert.

      • In Windows 2000 verwaltet eine ähnliche Einstellung namens "Zusätzliche Einschränkungen für anonyme Verbindungen" den Registrierungswert "RestrictAnonymous ". Dieser Wert befindet sich wie folgt
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Riskante Konfigurationen

      Die Einstellung "Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht zulassen" ist aus Kompatibilitätssicht eine schädliche Konfigurationseinstellung. Ihre Deaktivierung ist aus Sicherheitssicht eine schädliche Konfigurationseinstellung.

   3. Gründe für das Aktivieren dieser Einstellung

      Ein nicht autorisierter Benutzer könnte anonym Kontonamen auflisten und die Informationen dann verwenden, um Passwörter zu erraten oder Social-Engineering-Angriffe durchzuführen. Social Engineering ist Jargon, der bedeutet, Menschen dazu zu bringen, ihre Passwörter oder andere Sicherheitsinformationen preiszugeben.

   4. Gründe für das Deaktivieren dieser Einstellung

      Wenn diese Einstellung aktiviert ist, ist es nicht möglich, Vertrauensstellungen mit Windows NT 4.0-Domänen einzurichten. Diese Einstellung verursacht auch Probleme mit älteren Clients (wie 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

   • Die SMS-Netzwerkermittlung kann keine Betriebssysteminformationen abrufen und schreibt "Unbekannt" 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: Mitgliedscomputer mit Windows NT 4.0 können nicht authentifiziert werden.
   • Windows 95, Windows 98: Computer mit Windows 95 und Windows 98 können nicht von Microsoft-Domänencontrollern authentifiziert werden.
   • Windows 95, Windows 98: Benutzer von Windows 95- und Windows 98-Computern können die Kennwörter für ihre Benutzerkonten nicht ändern.

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

   1. Hintergrund

      • Die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht zulassen (auch als "RestrictAnonymous" bezeichnet) bestimmt, ob die anonyme Aufzählung von SAM-Konten (Security Accounts Manager) zulässig ist. Windows ermöglicht anonymen Benutzern das Ausführen bestimmter Aktivitäten, z. B. das Aufzählen der Namen von Domänenkonten (Benutzer, Computer und Gruppen) und von Netzwerkfreigaben. Dies ist beispielsweise dann praktisch, wenn ein Administrator Benutzern in einer vertrauenswürdigen Domäne Zugriff gewähren möchte, die keine gegenseitige Vertrauensstellung verwaltet. Wenn Sie die anonyme Aufzählung von SAM-Konten und Freigaben nicht zulassen möchten, aktivieren Sie diese Einstellung.
      • In Windows 2000 verwaltet eine ähnliche Einstellung namens "Zusätzliche Einschränkungen für anonyme Verbindungen" den Registrierungswert "RestrictAnonymous ". Dieser Wert befindet sich wie folgt:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

   2. Riskante Konfiguration

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

   3. Gründe für das Aktivieren dieser Einstellung

      • Aktivieren des Netzwerkzugriffs: Anonyme Aufzählung von SAM-Konten und Freigaben nicht zulassen Die Einstellung für die Aufhebung der Aufzählung von SAM-Konten und -Freigaben durch Benutzer und Computer, die anonyme Konten verwenden, wird verhindert.

   4. Gründe für das Deaktivieren dieser Einstellung

      • Wenn diese Einstellung aktiviert ist, könnte ein nicht autorisierter Benutzer anonym Kontonamen auflisten und die Informationen dann verwenden, um Kennwörter zu erraten oder Social Engineering-Angriffe durchzuführen. Social Engineering ist ein Jargon, bei dem Menschen dazu gebracht werden, ihr Passwort oder andere Sicherheitsinformationen preiszugeben.
      • Wenn diese Einstellung aktiviert ist, können keine Vertrauensstellungen mit Windows NT 4.0-Domänen eingerichtet werden. Diese Einstellung verursacht auch Probleme mit älteren Clients wie Windows NT 3.51 und Windows 95, die versuchen, Ressourcen auf dem Server zu verwenden.
      • Es ist nicht mö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:

        Hinweis

        Es sind derzeit keine Anmeldeserver verfügbar, um die Anmeldeanforderung zu bearbeiten.

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

      • Windows NT 4.0: Das Einrichten einer niedrigeren Vertrauensstellung mit Windows NT 4.0-Ressourcendomänen schlägt fehl. Die folgende Fehlermeldung wird angezeigt, wenn "RestrictAnonymous" in der vertrauenswürdigen Domäne aktiviert ist:

        Hinweis

        Der Domänencontroller für diese Domäne wurde nicht gefunden.

      • Windows NT 4.0: Benutzer, die sich an Windows NT 4.0-basierten Terminalservercomputern anmelden, werden dem Standard-Basisverzeichnis zugeordnet, anstatt dem Basisverzeichnis, das im Benutzer-Manager für Domänen definiert ist.

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

      • Windows 2000: Windows 2000-Mitgliedscomputer in Windows NT 4.0-Domänen können keine Drucker in externen Domänen 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 diese aus der Strukturansicht ausgewählt haben.

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

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

        Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
        322981 Problembehandlung bei der Kennwortmigration zwischen Gesamtstrukturen mit ADMTv2

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

      • SMS: Die Microsoft Systems Management Server (SMS)-Netzwerkermittlung kann die Betriebssysteminformationen nicht abrufen. Daher wird "Unknown" in die OperatingSystemNameandVersion-Eigenschaft der SMS-DDR-Eigenschaft des Discovery-Datensatzes (DDR) 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. Auf den Verwaltungspunkt ist anonymer Zugriff erforderlich.

      • SMS: Wenn Sie die Netzwerkerkennungsfunktion in SMS 2.0 und bei der Remoteclientinstallation mit aktivierter Netzwerkerkennungsoption für Topologie, Client und Clientbetriebssysteme verwenden, werden Computer möglicherweise erkannt, 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änenbeitritte, Zugriff auf Netzwerkressourcen und Benutzer- oder Computerauthentifizierung. Die LM-Authentifizierungsebene bestimmt, welches Abfrage-/Antwort-Authentifizierungsprotokoll zwischen dem Client- und dem Servercomputer ausgehandelt wird. Insbesondere bestimmt die LM-Authentifizierungsebene, welche Authentifizierungsprotokolle der Client auszuhandeln versucht oder der Server akzeptiert. Der für LmCompatibilityLevel festgelegte Wert bestimmt, welches Abfrage-/Antwort-Authentifizierungsprotokoll für Netzwerkanmeldungen verwendet wird. Dieser Wert wirkt sich auf die Ebene des Authentifizierungsprotokolls aus, das Clients verwenden, auf die ausgehandelte Ebene der Sitzungssicherheit und auf die von Servern akzeptierte Authentifizierungsebene.

       Mögliche Einstellungen sind unter anderem:

       Value	Einstellung	Beschreibung
       0	LM- & NTLM-Antworten senden	Clients verwenden LM- und NTLM-Authentifizierung und nie NTLMv2-Sitzungssicherheit. Domänencontroller akzeptieren die LM-, NTLM- und NTLMv2-Authentifizierung.
       1	LM & NTLM senden – NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt	Clients verwenden LM- und NTLM-Authentifizierung sowie NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller akzeptieren die LM-, NTLM- und NTLMv2-Authentifizierung.
       2	Nur NTLM-Antwort senden	Clients verwenden nur die NTLM-Authentifizierung und die NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller akzeptieren die LM-, NTLM- und NTLMv2-Authentifizierung.
       3	Nur NTLMv2-Antwort senden	Clients verwenden nur die NTLMv2-Authentifizierung und die NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller akzeptieren die LM-, NTLM- und NTLMv2-Authentifizierung.
       4	Nur NTLMv2-Antwort senden/LM ablehnen	Clients verwenden nur die NTLMv2-Authentifizierung und die NTLMv2-Sitzungssicherheit, wenn der Server dies unterstützt. Domänencontroller lehnen LM ab und akzeptieren nur die NTLM- und NTLMv2-Authentifizierung.
       5	Nur NTLMv2-Antwort senden/LM ablehnen & NTLM	Clients verwenden nur die NTLMv2-Authentifizierung und die 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 Verzeichnisdiensteclient die SMB-Signatur, wenn er sich bei Windows Server 2003-Servern mithilfe der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden jedoch keine SMB-Signatur, wenn sie sich bei diesen Servern mithilfe der NTLMv2-Authentifizierung authentifizieren. Außerdem reagieren Windows 2000-Server nicht auf SMB-Signierungsanforderungen 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 für die Unterstützung von NTLMv2 konfigurieren.

       Wenn die Richtlinie auf dem Zielcomputer, mit dem Sie eine Verbindung herstellen möchten, auf (5) Nur NTLMv2-Antwort senden\LM & NTLM ablehnen festgelegt ist, müssen Sie entweder die Einstellung auf diesem Computer verringern oder die Sicherheit auf die gleiche Einstellung festlegen, die auf dem Quellcomputer gilt, von dem aus Sie eine Verbindung herstellen.

       Suchen Sie den richtigen Speicherort, um die LAN Manager-Authentifizierungsebene zu ändern, um Client und Server auf dieselbe Ebene zu bringen. Wenn Sie nach der Richtlinie, mit der die LAN Manager-Authentifizierungsebene festgelegt wird, eine Verbindung zu und von Computern herstellen möchten, auf denen frühere Versionen von Windows ausgeführt werden, verringern Sie den Wert auf mindestens (1) LM senden & NTLM – verwenden Sie die NTLM Version 2 Sitzungssicherheit, falls dies ausgehandelt wurde. Eine Auswirkung inkompatibler Einstellungen besteht darin, dass, wenn der Server NTLMv2 (Wert 5) erfordert, der Client jedoch so konfiguriert ist, dass nur LM und NTLMv1 (Wert 0) verwendet werden, der Benutzer, der die Authentifizierung versucht, einen Anmeldefehler mit einem falschen Kennwort erfährt, wodurch die Anzahl der ungültigen Kennwörter erhöht wird. Wenn eine Kontosperrung konfiguriert ist, wird der Benutzer möglicherweise irgendwann gesperrt.

       Möglicherweise müssen Sie sich den Domänencontroller ansehen, oder Sie müssen die Richtlinien des Domänencontrollers überprüfen.

       Sehen Sie auf dem Domänencontroller nach.

       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 Verwaltung.
       2. Erweitern Sie unter Lokale Sicherheitseinstellungen die Option Lokale Richtlinien.
       3. Klicken Sie auf "Sicherheitsoptionen".
       4. Doppelklicken Sie auf Netzwerksicherheit: LAN Manager-Authentifizierungsebene, und klicken Sie dann auf einen Wert in der Liste.

       Wenn die effektive Einstellung und die lokale Einstellung identisch sind, wurde die Richtlinie auf dieser Ebene geändert. Wenn die Einstellungen unterschiedlich sind, müssen Sie die Richtlinie des Domänencontrollers überprüfen, um festzustellen, ob die Einstellung Netzwerksicherheit: LAN Manager-Authentifizierungsebene dort definiert ist. Wenn die ID 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 Verwaltung.
       2. Erweitern Sie in der Sicherheitsrichtlinie des Domänencontrollersdie Option Sicherheitseinstellungen, und erweitern Sie dann die Option Lokale Richtlinien.
       3. Klicken Sie auf "Sicherheitsoptionen".
       4. Doppelklicken Sie auf Netzwerksicherheit: LAN Manager-Authentifizierungsebene, und klicken Sie dann auf einen Wert in der Liste.

       Hinweis

       • Möglicherweise müssen Sie auch Richtlinien überprüfen, die auf Standortebene, Domänenebene oder Organisationseinheitsebene (OU) verknüpft sind, um zu bestimmen, wo Sie die LAN Manager-Authentifizierungsebene konfigurieren müssen.
       • Wenn Sie eine Gruppenrichtlinie als Standarddomänenrichtlinie implementieren, wird diese Richtlinie auf alle Computer der Domäne angewendet.
       • Wenn Sie eine Gruppenrichtlinie als Standardrichtlinie eines Domänencontrollers implementieren, gilt die Richtlinie nur für die Server in der Organisationseinheit 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 weist eine neue Standardeinstellung auf, sodass nur NTLMv2 verwendet wird. Standardmäßig ist auf Domänencontrollern mit Windows Server 2003 und Windows 2000 Server SP3 die Richtlinie "Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)" aktiviert. Diese Einstellung erfordert, dass der SMB-Server eine SMB-Paketsignierung durchführt. Die Änderungen an Windows Server 2003 wurden vorgenommen, da Domänencontroller, Dateiserver, Netzwerkinfrastrukturserver und Webserver in einer 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 für die Verwendung dieser 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, nicht von Windows 2000-Gruppenrichtlinien-Objekten 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 Option Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderungsrichtlinie speichern oder den Registrierungsschlüssel NoLMHash festlegen, können sich Windows 95- und Windows 98-basierte Clients, die den Verzeichnisdiensteclient nicht installiert haben, nach einer Kennwortänderung nicht bei der Domäne anmelden.

       Viele CIFS-Server von Drittanbietern, wie z. B. Novell Netware 6, kennen NTLMv2 nicht und verwenden nur NTLM. Daher ist bei Stufen über 2 keine Konnektivität zulässig. Es gibt auch SMB-Clients von Drittanbietern, die keine erweiterte Sitzungssicherheit verwenden. In diesen Fällen wird der LmCompatiblityLevel des Ressourcenservers nicht berücksichtigt. Der Server verpackt dann diese Legacyanforderung und sendet sie an den Domänencontroller des Benutzers. Die Einstellungen auf dem Domänencontroller entscheiden dann, welche Hashes zum Überprüfen der Anforderung verwendet werden und ob diese die Sicherheitsanforderungen des Domänencontrollers erfüllen.

        
       299656 So verhindern Sie, dass Windows einen LAN Manager-Hash Ihres Kennworts in Active Directory und lokalen SAM-Datenbanken speichert
        
       2701704 Überwachungsereignis zeigt an, dass das Authentifizierungspaket als NTLMv1 anstatt als NTLMv2 angezeigt wird. Weitere Informationen zu LM-Authentifizierungsebenen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
       239869 Aktivieren der NTLM 2-Authentifizierung
        

    2. Riskante Konfigurationen

       Die folgenden sind schädliche Konfigurationseinstellungen:

       • Nicht restriktive Einstellungen, die Kennwörter im Klartext senden und die NTLMv2-Verhandlung verweigern

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

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

       • Erfordern der NTLMv2-Authentifizierung auf Windows 95-Clients oder Windows 98-Clients, auf denen der Windows-Verzeichnisdiensteclient nicht installiert ist.

       • Wenn Sie auf einem Computer mit Windows Server 2003 oder Windows 2000 Service Pack 3 im Snap-In des Microsoft Management Console-Gruppenrichtlinien-Editors das Kontrollkästchen "NTLMv2-Sitzungssicherheit erforderlich" aktivieren und die LAN Manager-Authentifizierungsebene auf 0 senken, stehen die beiden Einstellungen in Konflikt, und Sie erhalten möglicherweise die folgende Fehlermeldung in der Datei "Secpol.msc" oder "GPEdit.msc":

         Hinweis

         Die lokale Richtliniendatenbank kann nicht geöffnet werden. Beim Versuch, die Datenbank zu öffnen, ist ein unbekannter Fehler aufgetreten.

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

    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 Organization unterstützt wird.
       • Wenn die sichere Authentifizierung eine geschäftliche Anforderung ist, möchten Sie die Aushandlung der LM- und NTLM-Protokolle verbieten.

    4. Gründe für das Deaktivieren dieser Einstellung

       Die Anforderungen an die Client- und/oder Serverauthentifizierung wurden so weit erhöht, dass die Authentifizierung über ein allgemeines Protokoll nicht mehr möglich ist.

    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 Einstellung für Windows Server 2003 NTLMv2 NTLM-Antworten senden" aktiviert. Daher erhält Windows Server 2003 nach der Erstinstallation die Fehlermeldung "Zugriff verweigert", wenn Sie versuchen, eine Verbindung zu einem Windows NT 4.0-basierten Cluster oder zu LanManager V2.1-basierten Servern herzustellen, z. B. OS/2 Lanserver. Dieses Problem tritt auch auf, wenn Sie versuchen, von einem Client einer früheren Version eine Verbindung mit einem Server unter Windows Server 2003 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, z. B. Novell Netware 6 oder Linux-basierte Samba-Server, kennen NTLMv2 nicht und verwenden nur NTLM. Daher ist bei Stufen über "2" keine Konnektivität zulässig. In dieser Version des Betriebssystems wurde der Standardwert für LmCompatibilityLevel in "3" geändert. Wenn Sie also Windows aktualisieren, funktionieren diese Drittanbieterdateien 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 eingeben, wird die folgende Fehlermeldung angezeigt: Windows 7 und Windows Server 2008 R2

         Hinweis

         Die angegebenen Anmeldeinformationen waren falsch. Vergewissern Sie sich, dass Ihr Benutzername und Ihre Domäne korrekt sind, und geben Sie dann Ihr Kennwort erneut ein.

         Wenn Sie Outlook starten, werden Sie möglicherweise zur Eingabe Ihrer Anmeldeinformationen aufgefordert, selbst wenn Ihre Netzwerksicherheitseinstellung beim Anmelden auf Passthrough oder Kennwortauthentifizierung festgelegt ist. Nachdem Sie die richtigen Anmeldeinformationen eingegeben haben, wird möglicherweise die folgende Fehlermeldung angezeigt:

         Hinweis

         Die angegebenen Anmeldeinformationen waren falsch.

         Eine Netzwerkmonitor-Ablaufverfolgung kann zeigen, dass der globale Katalog einen Remoteprozeduraufruf (RPC)-Fehler mit einer status von 0x5 ausgegeben hat. Ein status von 0x5 bedeutet "Zugriff verweigert".

       • Windows 2000: Eine Netzwerkmonitor-Erfassung zeigt möglicherweise die folgenden Fehler in der NetBIOS over TCP/IP (NetBT) Server Message Block (SMB)-Sitzung an:

         Hinweis

         SMB R Verzeichnis durchsuchen DOS-Fehler, (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-Mitgliedscomputern in der Ressourcendomäne möglicherweise Authentifizierungsfehler auf.

       • Windows 2000 und Windows XP: Standardmäßig setzen Windows 2000 und Windows XP die Option der LAN Manager-Authentifizierungsstufe für lokale Sicherheitsrichtlinie auf 0. Die Einstellung 0 bedeutet "LM- und NTLM-Antworten senden".

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

       • Windows 2000: Beim Windows 2000-Clustering wird ein beitretender Knoten nicht authentifiziert, wenn beide Knoten Teil einer Domäne mit Windows NT 4.0 Service Pack 6a (SP6a) sind.

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

       • Dienste für Macintosh

         Benutzerauthentifizierungsmodul (UAM): Das Microsoft UAM (User Authentication Module) bietet eine Methode zum Verschlüsseln von Kennwörtern, mit denen Sie sich bei Windows AFP-Servern (AppleTalk Filing Protocol) anmelden. Das Apple User Authentication Module (UAM) bietet nur minimale oder keine Verschlüsselung. Daher könnte Ihr Passwort leicht im LAN oder im Internet abgefangen werden. Obwohl das UAM nicht erforderlich ist, bietet es eine verschlüsselte Authentifizierung für Windows 2000-Server, auf denen Dienste für Macintosh ausgeführt werden. Diese Version bietet Unterstützung für NTLMv2 128-Bit-verschlüsselte Authentifizierung und eine mit MacOS X 10.1 kompatible Version.

         Standardmäßig lassen die Windows Server 2003-Dienste 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 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 von 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: Signaturanforderungen für LDAP-Clients

    1. Hintergrund

       Die Einstellung Netzwerksicherheit: Signaturanforderungen für LDAP-Clients bestimmt die Ebene der Datensignierung, die im Namen von Clients angefordert wird, die LDAP-BIND-Anforderungen wie folgt ausgeben:

       • None: Die LDAP BIND-Anforderung wird mit den vom Aufrufer angegebenen Optionen ausgegeben.
       • Signatur aushandeln: Wenn Secure Sockets Layer/Transport Layer Security (SSL/TLS) nicht gestartet wurde, wird die LDAP BIND-Anforderung mit der LDAP-Datensignaturoption initiiert, die zusätzlich zu den vom Anrufer angegebenen Optionen festgelegt ist. Wenn SSL/TLS gestartet wurde, wird die LDAP BIND-Anforderung mit den vom Anrufer angegebenen Optionen initiiert.
       • Signierung erforderlich: Dies entspricht der Verhandlungssignatur. Wenn die saslBindInProgress-Zwischenantwort des LDAP-Servers jedoch nicht angibt, dass eine LDAP-Datenverkehrssignierung erforderlich ist, wird dem Aufrufer mitgeteilt, dass die LDAP BIND-Befehlsanforderung fehlgeschlagen ist.

    2. Riskante Konfiguration

       Die Aktivierung der Einstellung Netzwerksicherheit: Signaturanforderungen für LDAP-Clients ist eine schädliche Konfigurationseinstellung. Wenn auf dem Server LDAP-Signaturen erforderlich sind, müssen Sie auch die LDAP-Signatur auf dem Client konfigurieren. Wenn der Client nicht für die Verwendung von LDAP-Signaturen konfiguriert ist, wird die Kommunikation mit dem Server verhindert. Dies führt dazu, dass die Benutzerauthentifizierung, die Einstellungen für Gruppenrichtlinien, Anmeldeskripts und andere Features fehlschlagen.

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

       Nicht signierter Netzwerkverkehr ist anfällig für "Man-in-the-Middle"-Angriffe, bei denen ein Angreifer Pakete zwischen dem Client und den Servern abfängt, modifiziert und dann an den Server weiterleitet. In diesem Fall kann ein Angreifer auf einem LDAP-Server 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 alle Arten von Man-in-the-Middle-Angriffen verhindern, indem Sie digitale Signaturen für alle Netzwerkpakete mittels IPSec-Authentifizierungsheadern anfordern.

    4. Symbolischer Name:

       LDAPClientIntegrity

    5. Registrierungspfad:
       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

12. Ereignisprotokoll: Maximale Größe des Sicherheitsprotokolls

    1. Hintergrund

       Die Sicherheitseinstellung Ereignisprotokoll: Maximale Größe des Sicherheitsprotokolls 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
       Windows-Einstellungen, und erweitern Sie dann Sicherheitseinstellungen.

    2. Riskante Konfigurationen

       Die folgenden sind schädliche Konfigurationseinstellungen:

       • Einschränken der Größe des Sicherheitsprotokolls und der Aufbewahrungsmethode für Sicherheitsprotokolle, wenn die Einstellung "Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können" aktiviert ist. Weitere Informationen finden Sie im Abschnitt "Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können".
       • Einschränken der Größe des Sicherheitsprotokolls, sodass relevante Sicherheitsereignisse überschrieben werden.

    3. Gründe für die Erhöhung dieser Einstellung

       Geschäfts- und Sicherheitsanforderungen können es erfordern, die Größe des Sicherheitsprotokolls zu erhöhen, um zusätzliche Sicherheitsprotokolldetails zu verarbeiten oder Sicherheitsprotokolle über einen längeren Zeitraum aufzubewahren.

    4. Gründe für das Verringern dieser Einstellung

       Protokolle der Ereignisanzeige sind Dateien mit Speicherzuordnung. Die maximale Größe eines Ereignisprotokolls wird durch die Größe des physischen Arbeitsspeichers auf dem lokalen Computer und durch den virtuellen Arbeitsspeicher beschränkt, der für den Ereignisprotokollprozess verfügbar ist. Wenn Sie die Protokollgröße über den für die Ereignisanzeige verfügbaren virtuellen Arbeitsspeicher hinaus erhöhen, erhöht sich nicht die Anzahl der beibehaltenen Protokolleinträge.

    5. Beispiele für Kompatibilitätsprobleme

       Windows 2000: Computer mit Windows 2000-Versionen vor Service Pack 4 (SP4) beenden möglicherweise die Protokollierung von Ereignissen im Ereignisprotokoll, bevor sie die in der Einstellung "Maximale Protokollgröße" in der Ereignisanzeige festgelegte Größe erreicht haben, wenn die Option "Ereignisse nicht überschreiben (Protokoll manuell löschen)" aktiviert ist.

        

13. Ereignisprotokoll: Sicherheitsprotokoll aufbewahren

    1. Hintergrund

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

    2. Riskante Konfigurationen

       Die folgenden sind schädliche Konfigurationseinstellungen:

       • Es können nicht alle protokollierten Sicherheitsereignisse beibehalten werden, bevor sie überschrieben werden
       • Die Einstellung für die maximale Größe des Sicherheitsprotokolls ist zu klein, sodass Sicherheitsereignisse überschrieben werden
       • Einschränken der Größe und der Aufbewahrungsmethode für Sicherheitsprotokolle während des Überwachungsprozesses "System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können" aktiviert ist

    3. Gründe für das Aktivieren dieser Einstellung

       Aktivieren Sie diese Einstellung nur, wenn Sie die Aufbewahrungsmethode Ereignisse nach Tagen überschreiben auswählen. Wenn Sie ein Ereigniskorrelationssystem verwenden, das Ereignisse abfragt, stellen Sie sicher, dass die Anzahl der Tage mindestens dreimal so hoch ist wie die Abfragehäufigkeit. Tun Sie dies, um fehlgeschlagene Abfragezyklen zuzulassen.

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

    1. Hintergrund

       Standardmäßig ist die Einstellung Netzwerkzugriff: Alle Berechtigungen für anonyme Benutzer gelten lassen unter Windows Server 2003 auf "Nicht definiert" festgelegt. Standardmäßig enthält Windows Server 2003 das anonyme Zugriffstoken nicht in der Gruppe "Jeder".

    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 als vertrauenswürdig eingestuft wird und die Ressourcendomäne auf der Windows Server 2003-Seite als vertrauenswürdig festgelegt ist. Dieses Verhalten tritt auf, weil der Prozess zum Starten der Vertrauensstellung nach der ersten anonymen Verbindung mit dem Jeder-Token, das die anonyme SID in Windows NT 4.0 enthält, ACLs ist.

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

       Der Wert muss auf 0x1 festgelegt oder mithilfe eines Gruppenrichtlinienobjekts in der Organisationseinheit des Domänencontrollers festgelegt werden, um Folgendes zu sein: Netzwerkzugriff: Jeder-Berechtigungen können auf anonyme Benutzer angewendet werden – Aktiviert, um die Erstellung von Vertrauensstellungen zu ermöglichen.

       Hinweis: Der Wert der meisten anderen Sicherheitseinstellungen steigt anstatt auf 0x0 im sichersten Zustand zu fallen. Eine sicherere Vorgehensweise besteht darin, die Registrierung auf dem primären Domänencontroller-Emulator statt auf allen Domänencontrollern zu ändern. Wenn die Rolle des primären Domänencontroller-Emulators aus irgendeinem Grund verschoben wird, muss die Registrierung auf dem neuen Server aktualisiert werden.

       Nach dem Festlegen dieses Werts ist ein Neustart erforderlich.

    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 im Snap-In des Microsoft Management Console-Gruppenrichtlinien-Editors zu überprüfen:

       • Computereinstellungen\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen
       • Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Server (einschließlich sicherer RPC-Server)
       • Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Clients (einschließlich sicherer RPC-Clients)

       Die Optionen für diese Einstellungen lauten wie folgt:

       • Nachrichtenintegrität erforderlich
       • Vertraulichkeit von Nachrichten erforderlich
       • NTLM Version 2-Sitzungssicherheit erforderlich
       • 128-Bit-Verschlüsselung erforderlich

       Die Standardeinstellung vor Windows 7 ist "Keine Voraussetzungen". Ab Windows 7 wurde die Standardeinstellung in "128-Bit-Verschlüsselung erforderlich" geändert, um die Sicherheit zu erhöhen. Mit dieser Standardeinstellung können Legacygeräte, die 128-Bit-Verschlüsselung nicht unterstützen, keine Verbindung herstellen.

       Diese Richtlinien bestimmen die Mindestsicherheitsstandards für eine Kommunikationssitzung zwischen Anwendungen auf einem Server für einen Client.

       Beachten Sie, dass, obwohl sie als gültige Einstellungen beschrieben werden, die Flags für die Anforderung der Nachrichtenintegrität und Vertraulichkeit nicht verwendet werden, wenn die NTLM-Sitzungssicherheit bestimmt wird.

       In der Vergangenheit hat Windows NT die folgenden zwei Varianten der Abfrage/Antwort-Authentifizierung für Netzwerkanmeldungen unterstützt:

       • LM Challenge/Antwort
       • NTLM Version 1 Aufforderung/Antwort

       LM ermöglicht die Interoperabilität mit der installierten Basis von Clients und Servern. NTLM bietet eine 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 beispielsweise RPC-basierte Sitzungen, die mit NTLM authentifiziert wurden. Es bestehen die folgenden Risiken:

       • Die Verwendung älterer Authentifizierungsmethoden als NTLMv2 erleichtert den Angriff auf die Kommunikation aufgrund der einfacheren verwendeten Hashingmethoden.
       • Die Verwendung von Verschlüsselungsschlüsseln, die niedriger als 128-Bit sind, ermöglicht es Angreifern, die Kommunikation mit Brute-Force-Angriffen zu unterbrechen.

Zeitsynchronisation

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

Problemumgehung für SMB-Signatur

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

Der Verzeichnisdiensteclient für Windows 98 Second Edition, Windows 98 und Windows 95 führt die SMB-Signatur mit Windows 2003-Servern unter NTLM-Authentifizierung, aber nicht mit NTLMv2-Authentifizierung durch. Außerdem reagieren Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients.

Obwohl wir dies nicht empfehlen, können Sie verhindern, dass die SMB-Signatur auf allen Domänencontrollern erforderlich ist, auf denen Windows Server 2003 in einer Domäne ausgeführt wird. Gehen Sie folgendermaßen vor, 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. Klicken Sie auf die Richtlinieneinstellung "Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)", und klicken Sie dann auf "Deaktiviert".

Wichtig: Dieser Abschnitt bzw. die Methoden- oder Aufgabenbeschreibung enthält Hinweise zum Ändern der Registrierung. Es können jedoch schwerwiegende Probleme auftreten, wenn Sie die Registrierung falsch ändern. Stellen Sie deshalb sicher, dass Sie diese Schritte sorgfältig ausführen. Als zusätzlichen Schutz erstellen Sie eine Sicherung der Registrierung, bevor Sie sie ändern. So ist gewährleistet, dass Sie die Registrierung wiederherstellen können, falls ein Problem auftritt. Weitere Informationen zum Erstellen und Wiederherstellen einer Sicherungskopie der Registrierung finden Sie im folgenden Artikel der Microsoft Knowledge Base:

322756 Sichern und Wiederherstellen der Registrierung in Windows Alternativ können Sie die SMB-Signatur auf dem Server deaktivieren, indem Sie die Registrierung ändern. Führen Sie hierzu die folgenden Schritte aus:

1. Klicken Sie auf Start und dann auf Ausführen, geben Sie „regedit“ ein und klicken Sie auf OK.
2. Klicken Sie auf den folgenden Unterschlüssel:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters
3. Klicken Sie auf den Eintrag enablesecuritysignature .
4. Klicken Sie im Menü Bearbeiten auf Ändern.
5. Geben Sie im Feld "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 an einer Eingabeaufforderung die folgenden Befehle ein, und drücken Sie nach jedem eingegebenen Befehl die Eingabetaste:
   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 sind die übersetzten Fehlercodenummern in status Codes und in die wörtlichen Fehlermeldungen aufgeführt, die zuvor erwähnt wurden:

Weitere Informationen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:

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

816585 Anwenden vordefinierter Sicherheitsvorlagen in Windows Server 2003