Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit Clients, Diensten und Programmen auftreten

Transkript

1 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 1 von 25 Suche in -> Deutsche Artikel Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit Clients, Diensten und Programmen auftreten Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base: (/EN-US/) Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments Geändert am : Montag, 29. Januar 2007 Artikel-ID : Version : 14.1 Wichtig: Dieser Artikel enthält Informationen zum Bearbeiten der Registrierung. Sie sollten eine Sicherungskopie der Registrierung erste bevor Sie die Registrierung bearbeiten. Sie müssen wissen, wie die Registrierung wiederhergestellt werden kann, wenn ein Problem auftri Weitere Informationen zum Erstellen einer Sicherungskopie, zum Wiederherstellen und Bearbeiten der Registrierung finden Sie im folgend Artikel der Microsoft Knowledge Base: ( Beschreibung der Microsoft Windows-Registrierung Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich de Vollständigkeit oder Richtigkeit der Übersetzung. Auf dieser Seite Zusammenfassung Windows Server 2003 SP1 Warnungen in "Gpedit.msc" Weitere Informationen Benutzerrechte Benutzerauthentifizierungsmodul (User Authentication Module/UAM) NTLMv2-Authentifizierung Sitzungssicherheit Uhrzeitsynchronisierung Umgehungsmöglichkeit für SMB-Signaturen Zusammenfassung Dieser Artikel beschreibt Inkompatibilitäten, die auf Client-Computern mit Microsoft Windows 95, Microsoft Windows 98, Microsoft Window NT 4.0, Microsoft Windows 2000, Microsoft Windows XP Professional oder Microsoft Windows Server 2003 auftreten können, wenn Sie bestimmte Sicherheitseinstellungen und Benutzerrechte in Windows NT 4.0-Domänen, Windows 2000-Domänen und Windows Server 200 Domänen ändern. Durch Konfigurieren dieser Einstellungen und Rechte im Rahmen lokaler Richtlinien und Gruppenrichtlinien können Sie die Sicherheit auf Domänencontrollern und Mitgliedscomputern erhöhen. Der Nachteil dieser erhöhten Sicherheit besteht darin, dass es zu Inkompatibilit mit Clients, Diensten und Programmen kommen kann. Verwenden Sie den Gruppenrichtlinienobjekt-Editor, um sich einen besseren Überblick über möglicherweise falsch konfigurierte Sicherheitseinstellungen zu verschaffen und diese Sicherheitseinstellungen zu ändern. Wenn Sie den Gruppenrichtlinienobjekt-Editor verwenden, wird die Zuweisung von Benutzerrechten unter den folgenden Betriebssystemen verbessert: Microsoft Windows XP Professional Service Pack 2 (SP2) Microsoft Windows Server 2003 Service Pack 1 (SP1) Zu diesen Verbesserungen zählt ein Dialogfeld mit einem Link zu diesem Artikel, das immer dann eingeblendet wird, wenn Sie Sicherheitseinstellungen oder Benutzerrechte zu einer Einstellung ändern, die eine geringere Kompatibilität bietet oder restriktiver ist. We Sie die gleichen Sicherheitseinstellungen oder Benutzerrechte direkt mithilfe der Registrierung oder von Sicherheitsvorlagen ändern, ist d Effekt der gleiche wie beim Ändern der Einstellung mit dem Gruppenrichtlinienobjekt-Editor. In diesem Fall wird jedoch das Dialogfeld mit dem Link zu diesem Artikel nicht angezeigt. Dieser Artikel enthält Beispiele für Clients, Programme und Vorgänge, die durch bestimmte Sicherheitseinstellungen oder Benutzerrechte beeinträchtigt werden können. Die Beispiele sind jedoch nicht für alle Microsoft-Betriebssysteme, alle Fremdanbieter-Betriebssysteme bzw alle betroffenen Programmversionen verbindlich. In diesem Artikel werden nicht alle Sicherheitseinstellungen und Benutzerrechte beschrieben. Microsoft empfiehlt, die Kompatibilität aller sicherheitsbezogenen Konfigurationsänderungen in einer Teststruktur zu prüfen, bevor Sie die Änderungen in einer Produktionsumgebung vornehmen. Die Teststruktur muss mit der Produktionsstruktur in folgenden Aspekten identisc sein:

2 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 2 von 25 Client- und Server-Betriebssystemversionen, Client- und Serverprogramme, Service Pack-Versionen, Hotfixes, Schemaänderungen, Sicherheitsgruppen, Gruppenmitgliedschaften, Berechtigungen für Objekte im Dateisystem, freigegebene Ordner, Registrierung, Acti Directory-Verzeichnisdienst, lokale Richtlinien und Gruppenrichtlinien sowie Objektanzahl, -typ und -speicherort Ausgeführte Verwaltungsaufgaben, verwendete Verwaltungswerkzeuge und zum Ausführen von Verwaltungsaufgaben verwendete Betriebssysteme Ausgeführte Vorgänge, u. a. Computer- und Benutzeranmeldeauthentifizierung; Kennwortrücksetzungen durch Benutzer, durch Computer und Administratoren; Suchvorgänge; Festlegen von Berechtigungen für das Dateisystem, für freigegebene Ordner, für die Registrierung und für Active Directory-Ressourcen mit dem ACL-Editor in allen Client-Betriebssystemen, in allen Konten- bzw. Ressourcendomänen; Drucken von Administrator- und Nicht-Administratorkonten Windows Server 2003 SP1 Warnungen in "Gpedit.msc" "Gpedit.msc" wurden zwei Warnmechanismen hinzugefügt, um den Kunden bewusst zu machen, dass Sie im Begriff sind, Benutzerrechte oder Sicherheitsoptionen zu ändern, die negative Auswirkungen auf ihr Netzwerk haben könnten. Wenn Administratoren ein Benutzerrech bearbeiten, das negative Auswirkungen auf das gesamte Unternehmen haben könnte, wird ihnen jetzt ein neues Symbol angezeigt, das w ein "Vorfahrt gewähren"-schild aussieht. Außerdem wird ihnen eine Warnmeldung mit einem Link zum Microsoft Knowledge Base-Artikel angezeigt. Der Text dieser Warnung lautet wie folgt: Das Ändern dieser Einstellung kann Auswirkungen auf die Kompatibilität zu Clients, Diensten und Anwendungen haben. Für weitere Informationen siehe <zu ändernde Benutzerrechte oder Sicherheitsoptionen> (Q823659). (Modifying this setting may affect compatibility with clients, services, and applications. For more information see <user right or security option being modified> (Q823659).) Wenn Sie über einen Link in GPEDIT.MSC zu diesem Knowledge Base-Artikel weitergeleitet worden sind, lesen Sie die entsprechende Erklärung sorgfältig durch, bis Sie verstanden haben, welche Auswirkungen das Ändern der Einstellung haben kann. Es folgt eine Liste de Benutzerrechte, für welche die neue Warnung angezeigt wird: Auf diesen Computer vom Netzwerk aus zugreifen Lokal anmelden Wechselprüfung umgehen Computer und Benutzer für vertrauenswürdige Weiterleitung aktivieren (Enable computers und users for trusted delegation) Es folgt eine Liste der Sicherheitsoptionen, für welche die Warnung und ein Popup-Fenster 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: Anonyme SID / Namensübersetzung erlauben 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 Window NT 4.0-Domänen, Windows 2000-Domänen oder Windows Server 2003-Domänen ändern. Benutzerrechte 1. Auf diesen Computer vom Netzwerk aus zugreifen Für die Interaktion mit entfernten Windows-Computern ist das Benutzerrecht Auf diesen Computer vom Netzwerk aus zugreifen erforderlich. Zu diesen Netzwerkvorgängen zählen unter anderem die Replikation des Active Directory zwischen Domänencontrollern in einer gemeinsamen Domäne oder Struktur, Authentifizierungsanforderungen an Domänencontroller von Benutzern und Computern sowie Zugriff auf freigegebene Ordner, auf Drucker und andere Systemdienste, die sich auf Remote Computern im Netzwerk befinden. Benutzern, Computern und Dienstkonten wird das Benutzerrecht Auf diesen Computer vom Netzwerk aus zugreifen gewährt oder verweigert, indem diese explizit oder implizit zu einer Sicherheitsgruppe, der dieses Benutzerrecht zugewiesen wurde, hinzugefügt oder aus dieser entfernt werden. Beispiel: Ein Benutzer- oder Computerkonto kann explizit von einem Administrator zu einer benutzerdefinierten oder vordefinierten Sicherheitsgruppe oder implizit durch das Betriebssystem zu einer vordefinierten Sicherheitsgruppe, wie z. B. Domänenbenutzer, Authentifizierte Benutzer oder Domänencontroller der Organisation, hinzugefügt werden. Benutzer- und Computerkonten wird das Benutzerrecht Auf diesen Computer vom Netzwerk aus zugreifen standardmäß gewährt, wenn vordefinierte Gruppen wie "Jeder" oder "Authentifizierte Benutzer", bzw. für Domänencontroller die Gruppe "Domänencontroller der Organisation", im Gruppenrichtlinienobjekt (GPO) der Standarddomänencontroller definiert wurden.

3 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 3 von 25 b. Risikoreiche Konfigurationen Die folgenden Konfigurationen sind risikoreich: 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 von Verbindungen mit Computern über das Netzwerk gewährt Entfernen aller Benutzer und Computer aus diesem Benutzerrecht c. Gründe für das Gewähren dieses Benutzerrechts Durch Gewähren des Benutzerrechts Auf diesen Computer vom Netzwerk aus zugreifen für die Gruppe "Domänencontroller der Organisation" werden die Authentifizierungsanforderungen erfüllt, die für die Active Directory- Replikation zwischen Domänencontrollern in derselben Struktur vorliegen müssen. Dieses Recht gewährt Benutzern und Computern den Zugriff auf freigegebene Dateien, Drucker und Systemdienste, darunter auch auf das Active Directory. Es wird von den Benutzern außerdem für den Zugriff auf ihre mit frühen Versionen von Microsoft Outlook Web Access (OWA) benötigt. d. Gründe für das Entfernen dieses Benutzerrechts Benutzer, die eine Netzwerkverbindung mit ihren Computern herstellen können, haben Zugriff auf Remote-Computer, fü die sie Berechtigungen besitzen. Dieses Benutzerrecht ist beispielsweise erforderlich, damit ein Benutzer eine Verbindung zu freigegebenen Druckern oder Ordnern herstellen kann. Wenn dieses Benutzerrecht der Gruppe "Jeder" gewährt wird, und wenn für einige freigegebene Ordner sowohl Freigabe- als auch NTFS-Dateisystemberechtigungen konfiguriert sind, sodass dieselbe Gruppe auch Lesezugriff erhält, kann jeder Benutzer Dateien in diesen freigegebenen Ordnern anzeigen. Dies ist jedoch eine unwahrscheinliche Situation bei einer Neuinstallation von Windows Server 2003, da die standardmäßigen Freigabe- und NTFS-Berechtigungen in Windows Server 2003 nicht die Gruppe "Jeder" beinhalten. Bei Systemen, die von Microsoft Windows NT 4.0 oder Windows 2000 aufgerüstet werden, besteht ein höheres Risiko für diese Anfälligkeit, da die standardmäßigen Freigabe- und Dateisystemberechtigungen für diese Betriebssysteme nicht so restriktiv wie die Standardberechtigungen in Windows Server 2003 sind. Es gibt jedoch keinen Grund, die Gruppe "Domänencontroller der Organisation" aus diesem Benutzerrecht zu entfernen. Statt der Gruppe "Authentifizierte Benutzer" wird im Allgemeinen die Gruppe "Jeder" 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 aufgerüstet werden, gewähren der Gruppe "Jeder", der Gruppe "Authentifizierte Benutzer" bzw. der Gruppe "Domänencontroller der Organisation" nicht explizit das Benutzerrecht Auf diesen Computer vom Netzwerk aus zugreifen. Wenn Sie die Gruppe "Jeder" aus einer Windows NT 4.0- Domänenrichtlinie entfernen, schlägt die Active Directory-Replikation mit der Meldung "Zugriff verweigert" fehl, nachdem Sie auf Windows 2000 aufgerüstet haben. Winnt32.exe in Windows Server 2003 vermeidet diese Fehlkonfiguration, indem der Gruppe "Domänencontroller der Organisation" dieses Benutzerrecht gewährt wird, wenn Sie Windows NT 4.0-PDCs (Primäre Domänen-Controller, PDC) aufrüsten. Gewähren Sie der Gruppe "Domänencontroller der Organisation" dieses Benutzerrecht, wenn es nicht im Editor für Gruppenrichtlinienobjekte vorhanden ist. e. Beispiele für Kompatibilitätsprobleme Windows 2000 und Windows Server 2003: Die Replikation des Active Directory-Schemas, der Konfiguration, der Domäne, des globalen Katalogs oder von Anwendungspartitionen schlägt mit der Meldung "Zugriff verweigert" fehl. Diese Fehlermeldungen werden in Überwachungsprogrammen wie REPLMON und REPADMIN oder in Replikationsereignissen des Ereignisprotokolls protokolliert. Alle Microsoft-Netzwerkbetriebssysteme: Die Benutzerkonto-Authentifizierung von Client-Computern aus Remote- Netzwerken schlägt fehl, wenn dem Benutzer oder der Sicherheitsgruppe, der dieser Benutzer angehört, dieses Benutzerrecht nicht gewährt wurde. Alle Microsoft-Netzwerkbetriebssysteme: Die Kontoauthentifizierung von Remote-Netzwerkclients schlägt fehl, wenn der Konto- oder Sicherheitsgruppe, der das Konto angehört, dieses Benutzerrecht nicht gewährt wurde. Dieses Szenario betrifft Benutzerkonten, Computerkonten und Dienstkonten. Alle Microsoft-Netzwerkbetriebssysteme: Durch Entfernen aller Konten aus diesem Benutzerrecht wird verhindert, dass Konten eine Anmeldung bei der Domäne durchführen oder auf Netzwerkressourcen zugreifen können. Wenn vordefinierte Gruppen wie "Domänencontroller der Organisation", "Jeder" oder "Authentifizierte Benutzer" entfernt werden, müssen Sie dieses Benutzerrecht explizit bestimmten Konten- bzw. Sicherheitsgruppen gewähren, denen das Konto angehört, um den Zugriff auf Remote-Computer über das Netzwerk zu ermöglichen. Dieses Szenario betrifft alle Benutzerkonten, Computerkonten und Dienstkonten. Alle Microsoft-Netzwerkbetriebssysteme: Der lokale Administrator verwendet ein "leeres" Kennwort. Netzwerkverbindungen mit leeren Kennwörtern sind für Administratorkonten in einer Domänenumgebung nicht zulässig. Bei dieser Konfiguration ist zu erwarten, dass die Meldung "Zugriff verweigert" angezeigt wird. 2. Lokal anmelden zulassen Benutzer, die sich auf der Konsole eines Microsoft Windows-Computers anmelden möchten (mithilfe der Anmeldetastenkombination [STRG]+[ALT]+[ENTF]), und Konten, die einen Dienst starten möchten, müssen über lokale Anmeldeberechtigungen auf dem Host-Computer verfügen. Lokale Anmeldevorgänge finden beispielsweise statt, wenn sich Administratoren auf den Konsolen von Mitgliedscomputern oder bei Domänencontrollern einer Organisation anmelden, oder wenn sich Domänenbenutzer bei Mitgliedscomputern anmelden, um über nicht privilegierte Konten auf ihre Desktops zuzugreifen. Benutzer, die eine Remotedesktopverbindung oder die Terminaldienste verwenden, müssen das Benutzerrecht Lokal anmelden zulassen auf Zielcomputern besitzen, auf denen Windows 2000 oder Windows XP ausgeführt wird, da diese Anmeldemodi als lokal betrachtet werden. Benutzer, die sich auf einem Server mit Terminaldiensten anmelden und nicht über

4 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 4 von 25 dieses Benutzerrecht verfügen, können jedoch eine interaktive Remotesitzung in Windows Server 2003-Domänen starten, wenn sie das Benutzerrecht Anmelden über Terminaldienste zulassen besitzen. b. Risikoreiche Konfigurationen Die folgenden Konfigurationen sind risikoreich: Entfernen von Administrator-Sicherheitsgruppen, darunter die Gruppen Konten-Operatoren, Sicherungs-Operatoren, Druck-Operatoren oder Server-Operatoren, sowie der integrierten Administratorgruppe aus der Richtlinie des Standarddomänencontrollers. Entfernen von Dienstkonten aus der Richtlinie des Standarddomänencontrollers, die von Komponenten und Programmen auf Mitgliedscomputern und Domänencontrollern der Domäne verwendet werden. Entfernen von Benutzern oder Sicherheitsgruppen, die sich auf der Konsole von Mitgliedscomputern in der Domäne anmelden. Entfernen von Dienstkonten, die in der lokalen Datenbank der Sicherheitskontenverwaltung von Mitgliedscomputern oder Arbeitsgruppencomputern definiert sind. Entfernen von nicht integrierten Administratorkonten, die über Terminaldienste auf einem Domänencontroller authentifiziert werden. Explizites oder implizites Hinzufügen aller Benutzerkonten in der Domäne durch Hinzufügen der Gruppe "Jeder" zum Benutzerrecht Lokal anmelden verweigern. Diese Konfiguration verhindert, dass sich Benutzer bei beliebigen Mitgliedscomputern oder Domänencontrollern in der Domäne anmelden können. c. Gründe für das Gewähren dieses Benutzerrechts Die Benutzer müssen das Benutzerrecht Lokal anmelden zulassen besitzen, um auf die Konsole oder den Desktop eines Arbeitsgruppencomputers, eines Mitgliedscomputers oder eines Domänencontrollers zugreifen zu können. Benutzer müssen dieses Benutzerrecht besitzen, um die Anmeldung über eine Terminaldienste-Sitzung vornehmen zu können, die auf einem Windows 2000-Mitgliedscomputer oder -Domänencontroller ausgeführt wird. d. Gründe für das Entfernen dieses Benutzerrechts Wenn der Konsolenzugriff nicht auf berechtigte Benutzerkonten beschränkt wird, ermöglicht dies unberechtigten Benutzern eventuell, böswilligen Code herunterzuladen und auszuführen, um die Benutzerrechte zu ändern. Durch Entfernen des Benutzerrechts Lokal anmelden zulassen wird die unberechtigte Anmeldung auf Konsolen von Computern, wie beispielsweise Domänencontrollern oder Anwendungsservern, verhindert. Durch Entfernen dieses Anmelderechts wird verhindert, dass sich Nicht-Domänenkonten auf der Konsole von Mitgliedscomputern in der Domäne anmelden können. e. Beispiele für Kompatibilitätsprobleme Windows 2000 Terminal Server: Benutzer benötigen das Benutzerrecht Lokal anmelden zulassen für die Anmeldung bei Windows 2000-Terminalservern. Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003: Den Benutzerkonten muss dieses Benutzerrecht gewährt werden, damit sie sich auf der Konsole von Computern anmelden können, 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 das Benutzerrecht Lokal anmelden zulassen auf Computern hinzufügen, auf denen Windows NT 4.0 und höher ausgeführt wird, dabei jedoch implizit oder explizit das Anmelderecht Lokale Anmeldung verweigern gewähren, können sich die Konten nicht auf der Konsole von Domänencontrollern anmelden. 3. Wechselprüfung umgehen Das Benutzerrecht Wechselprüfung umgehen erlaubt es dem Benutzer, die Ordner im NTFS-Dateisystem oder in der Registrierung zu durchsuchen, ohne dass das Vorhandensein der besonderen Zugriffsberechtigung Ordner durchsuchen geprüft wird. Das Benutzerrecht Wechselprüfung umgehen gestattet dem Benutzer jedoch nicht das Auflisten des Inhalts eines Ordners, sondern nur das Navigieren durch die Ordner. b. Risikoreiche Konfigurationen Die folgenden Konfigurationen sind risikoreich: Entfernen von Nicht-Administratorkonten, die sich auf Computern mit Windows 2000-Terminaldiensten oder Windows Server 2003-Terminaldiensten anmelden und keine Berechtigungen für den Zugriff auf Dateien und Ordner im Dateisystem besitzen. Entfernen der Gruppe "Jeder" aus der Liste der Sicherheitsprinzipale, die standardmäßig dieses Benutzerrecht besitzen. Windows-Betriebssysteme und viele andere Programme gehen davon aus, dass jede Person, die legitimen Zugang zu dem Computer hat, das Benutzerrecht Wechselprüfung umgehen besitzt. Daher könnte das Entfernen der Gruppe "Jeder" aus der Liste der Sicherheitsprinzipale, die standardmäßig dieses Benutzerrecht besitzen, zu einer Instabilität des Betriebssystems oder einem Programmfehler führen. Behalten Sie deshalb besser die Standardeinstellung bei. c. Gründe für das Gewähren dieses Benutzerrechts Die Standardeinstellung für das Benutzerrecht Wechselprüfung umgehen erlaubt es allen Benutzern, die Wechselprüfung zu umgehen. Für erfahrene Windows-Systemadministratoren ist dies das erwartete Verhalten. Sie konfigurieren die Zugriffskontrolllisten des Dateisystems daher entsprechend. Das einzige Szenario, in dem die Standardkonfiguration zu einem Problem führen könnte, ist, wenn dem für die Konfiguration von Berechtigungen zuständigen Administrator dieses Verhalten nicht bekannt ist und der Administrator erwartet, dass Benutzer, die nicht auf einen übergeordneten Ordner zugreifen können, auch nicht auf den Inhalt von untergeordneten Ordnern zugreifen können.

5 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 5 von 25 d. Gründe für das Entfernen dieses Benutzerrechts Organisationen mit hohen Sicherheitsanforderungen könnten eventuell versuchen, die Gruppe "Jeder" oder sogar die Gruppe "Benutzer" aus der Liste der Gruppen zu entfernen, die das Benutzerrecht Wechselprüfung umgehen besitzen, um den Zugriff auf die Dateien oder Ordner im Dateisystem zu verhindern. e. Beispiele für Kompatibilitätsprobleme Windows 2000, Windows Server 2003: Wenn das Benutzerrecht Wechselprüfung umgehen auf Computern, auf denen Windows 2000 oder Windows Server 2003 ausgeführt wird, entfernt oder falsch konfiguriert wird, erfolgt keine Replikation der Gruppenrichtlinieneinstellungen im Ordner SYVOL zwischen den Domänencontrollern der Domäne. Windows 2000, Windows XP Professional, Windows Server 2003: Computer, auf denen Windows 2000, Windows XP Professional oder Windows Server 2003 ausgeführt wird, protokollieren die Ereignisse 1000 und Diese Computer können keine Computer- und Benutzerrichtlinien mehr anwenden, wenn die erforderlichen Dateisystemberechtigungen durch Entfernen oder falsches Konfigurieren des Benutzerrechts Wechselprüfung umgehen aus der SYSVOL-Struktur entfernt wurden. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Ereignis-IDs 1000 und 1001 werden alle fünf Minuten im Anwendungsprotokoll aufgezeichnet Windows 2000, Windows Server 2003: Auf Computern, auf denen Windows 2000 oder Windows Server 2003 ausgeführt wird, wird die Registerkarte Kontingent in Windows Explorer nicht mehr angezeigt, wenn Sie die Eigenschaften für ein Volume anzeigen. Windows 2000: Nicht-Administratoren, die sich auf einem Windows 2000 Terminal Server anmelden, wird eventuell die folgende Fehlermeldung angezeigt: Fehler in der Anwendung Userinit.exe. Die Anwendung konnte nicht richtig initialisiert werden (0xc ). Klicken Sie auf "OK", um die Anwendung zu beenden. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Versuchen Benutzer bei Terminal-Dienst Anmelden an, werden Benutzer automatisch abgemeldet 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 eventuell nicht auf freigegebene Ordner oder auf Dateien in freigegebenen Ordnern zugreifen. Es wird möglicherweise die Fehlermeldung "Zugriff verweigert" angezeigt, wenn ihnen nicht das Benutzerrecht Wechselprüfung umgehen zugewiesen wurde. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Fehlermeldung um zu verweigert "Zugriff" als Zugriff Freigegebene Ordner von Benutzern versucht wird Windows NT 4.0: Auf Windows NT 4.0-Computern führt das Entfernen des Benutzerrechts Wechselprüfung umgehen dazu, dass Dateistreams bei Dateikopiervorgängen verloren gehen. 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 Ziel-Dateistream verloren und die Datei erscheint als Nur-Text-Datei. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Das Entfernen von "Wechselprüfung umgehen" verursacht Datei Drop Streams Kopieren nach Microsoft Windows 95, Microsoft Windows 98:Auf einem Client-Computer, auf dem Windows 95 oder Windows 98 ausgeführt wird, schlägt der Befehl net use * /home fehl und die Fehlermeldung "Zugriff verweigert" wird angezeigt, wenn der Gruppe "Authentifizierte Benutzer" nicht das Benutzerrecht Wechselprüfung umgehen gewährt wurde. Outlook Web Access: Nicht-Administratoren können sich nicht bei Microsoft Outlook Web Access anmelden. Die Fehlermeldung "Zugriff verweigert" wird angezeigt, wenn ihnen nicht das Benutzerrecht Wechselprüfung umgehen gewährt wurde. Sicherheitseinstellungen 1. Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können Die Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können bestimmt, ob das System heruntergefahren wird, wenn Sie keine Sicherheitsereignisse protokollieren können. Diese Einstellung ist für die C2-Überprüfung im Rahmen des TCSEC-Programms (Trusted Computer Security Evaluation Criteria) und für die allgemeinen Kriterien (Common Criteria) für die Information Technology Security Evaluation erforderlich, um überwachbare Ereignisse zu verhindern, wenn das System diese Ereignisse nicht protokollieren kann. Wenn ein Fehler beim Überwachungssystem auftritt, wird das System heruntergefahren und eine Stop-Fehlermeldung angezeigt. Wenn der Computer keine Ereignisse im Sicherheitsprotokoll aufzeichnen kann, sind nach einem Sicherheitsvorfall eventuell keine Nachweise bzw. keine Informationen zur Problembehandlung verfügbar. b. Risikoreiche Konfiguration Die folgende Konfiguration ist risikoreich: Die Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können wird aktiviert und die Größe des Sicherheitsprotokolls wird mithilfe der Option Ereignisse nicht überschreiben (Protokoll manuell löschen), der Option Ereignisse bei Bedarf

6 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 6 von 25 überschreiben oder der Option Ereignisse überschreiben, die älter sind als Zahl Tage in der Ereignisanzeige beschränkt. Weitere Informationen zu bestimmten Risiken für Computer, auf denen die ursprüngliche Version von Windows 2000, Windows 2000 Service Pack 1 (SP1), Windows 2000 SP2 oder Windows 2000 SP3 ausgeführt wird, finden Sie im Abschnitt "Beispiele für Kompatibilitätsprobleme". c. Gründe zum Aktivieren dieser Einstellung Wenn der Computer keine Ereignisse im Sicherheitsprotokoll aufzeichnen kann, sind nach einem Sicherheitsvorfall eventuell keine Nachweise bzw. keine Informationen zur Problembehandlung verfügbar. d. Gründe zum Deaktivieren dieser Einstellung Durch Aktivieren der Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können wird das System heruntergefahren, wenn aus irgendeinem Grund keine Sicherheitsereignisse protokolliert werden können. Ein Ereignis kann in der Regel nicht protokolliert werden, wenn das Sicherheitsprotokoll voll ist und als Speichermethode entweder die Option Ereignisse nicht überschreiben (Protokoll manuell löschen) oder die Option Ereignisse überschreiben, die älter sind als Zahl Tage festgelegt wurde. Der Verwaltungsaufwand bei Aktivierung der Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können kann sehr groß sein, insbesondere, wenn Sie außerdem die Option Ereignisse nicht überschreiben (Protokoll manuell löschen) für das Sicherheitsprotokoll aktivieren. Diese Einstellung ermöglicht die Einzelerfassung der Benutzeraktionen. Beispiel: Ein Administrator kann die Berechtigungen für alle Benutzer, Computer und Gruppen einer Organisationseinheit (OU) zurücksetzen, für die die Überwachung aktiviert wurde, indem er das integrierte Administratorkonto oder ein anderes freigegebenes Konto verwendet und das Recht zum Zurücksetzen dieser Berechtigungen verweigert. Durch Aktivieren dieser Einstellung wird jedoch die Stabilität des Systems beeinträchtigt, da ein Server eventuell durch Überfluten mit Anmeldeereignissen und anderen Sicherheitsereignissen, die im Sicherheitsprotokoll erfasst werden, zum Herunterfahren gezwungen werden kann. Da das Herunterfahren nicht ordnungsgemäß erfolgt, kann es zu irreparablen Schäden am Betriebssystem, an Programmen oder an Daten kommen. NTFS garantiert zwar, dass die Integrität des Dateisystems beim nicht ordnungsgemäßen Herunterfahren des Systems bewahrt wird, jedoch kann NTFS nicht garantieren, dass jede Datendatei für jedes Programm nach dem Neustart des Systems weiterhin in benutzbarem Format vorliegt. e. Symbolischer Name: CrashOnAuditFail f. Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD) g. Beispiele für Kompatibilitätsprobleme Windows 2000: Aufgrund eines Fehlers beenden Computer, auf denen die ursprüngliche Version von Windows 2000, Windows 2000 SP1, Windows 2000 SP2 oder Windows Server SP3 ausgeführt wird, die Protokollierung von Ereignissen, bevor die in der Option Maximale Größe des Sicherheitsprotokolls festgelegte Größe erreicht wird. Der Fehler wurde in Windows 2000 Service Pack 4 (SP4) behoben. Vergewissern Sie sich, ob auf Ihren Windows 2000-Domänencontrollern Windows 2000 Service Pack 4 installiert ist, bevor Sie diese Einstellung aktivieren. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Das Ereignisprotokoll beendet, Ereignisse dem Erreichen der maximalen Protokollgröße bevor zu protokollieren Windows 2000, Windows Server 2003: Computer, auf denen Windows 2000 oder Windows Server 2003 ausgeführt wird, reagieren möglicherweise nicht mehr und starten anschließend spontan neu, wenn die Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können aktiviert, das Sicherheitsprotokoll voll ist und ein vorhandener Ereignisprotokolleintrag nicht überschrieben werden kann. Wenn der Computer neu startet, wird die folgende Stop-Fehlermeldung angezeigt: STOP: C {Überwachung fehlgeschlagen} Ein Versuch zur Erzeugung einer Sicherheitsüberwachung ist fehlgeschlagen. Um das System wiederherzustellen, muss der Administrator sich anmelden, das Sicherheitsprotokoll archivieren (optional), das Sicherheitsprotokoll löschen und anschließend diese Option zurücksetzen (optional und bei Bedarf). Microsoft Network Client für MS-DOS, Windows 95, Windows 98, Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003: Nicht-Administratoren, die sich bei einer Domäne anmelden, wird eventuell die folgende Fehlermeldung angezeigt: Ihr Konto sieht es nicht vor, dass Sie sich an diesem Computer anmelden. Melden Sie sich an einem anderen Computer an. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Fehler: Benutzer können sich nicht bei einer Arbeitsstation anmelden Windows 2000: Nicht-Administratoren können sich auf Windows 2000-Computern nicht bei RAS-Servern anmelden. Es wird eine Fehlermeldung mit etwa folgendem Wortlaut angezeigt: Unbekannter Benutzername oder falsches Kennwort Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Fehlermeldung: Ihr Konto ist konfiguriert, um die Verwendung

7 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 7 von 25 dieses Computers zu verhindern. Windows 2000: Auf Windows 2000-Domänencontrollern wird der Intersite Messaging-Dienst (Ismserv.exe) angehalten und kann nicht neu gestartet werden. DCDIAG meldet den Fehler "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 Sicherheitsprotokoll voll ist. Microsoft Exchange 2000: Server, auf denen Exchange 2000 ausgeführt wird, können die Informationsspeicher- Datenbank nicht laden und das Ereignis 2102 wird im Ereignisprotokoll registriert. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( XADM: Exchange 2000-Fehlermeldungen aufgrund von Problemen mit der SeSecurityPrivilege-Berechtigung und mit Policytest Outlook, Outlook Web Access: Nicht-Administratoren sind nicht in der Lage, mit Microsoft Outlook oder Microsoft Outlook Web Access auf ihre zuzugreifen. Der Fehler 503 wird angezeigt. 2. Domänencontroller: Signaturanforderungen für LDAP-Server Die Sicherheitseinstellung Domänencontroller: Signaturanforderungen für LDAP-Server bestimmt, ob der LDAP-Server (Lightweight Directory Access Protocol, LDAP) Datensignaturen von den LDAP-Clients verlangt. Mögliche Werte für diese Richtlinieneinstellung sind: Keine: Es ist keine Datensignatur für die Bindung an den Server erforderlich. Wenn der Client Datensignaturen anfordert, wird dies vom Server unterstützt. Signatur erforderlich: Die Option für die LDAP-Datensignatur muss ausgehandelt werden, falls kein TLS/SSL (Transport Layer Security/Secure Socket Layer) verwendet wird. Nicht definiert: Diese Einstellung ist nicht aktiviert oder deaktiviert. b. Risikoreiche Konfigurationen Die folgenden Konfigurationen sind risikoreich: Aktivieren von Signatur erforderlich in Umgebungen, in denen Clients keine LDAP-Signatur unterstützen oder in der keine clientseitige LDAP-Signatur auf dem Client aktiviert ist Anwenden der Sicherheitsvorlage "Hisecdc.inf" von Windows 2000 oder Windows Server 2003 in Umgebungen, in denen die Clients keine LDAP-Signatur unterstützen oder in der keine clientseitige LDAP-Signatur aktiviert ist Anwenden der Sicherheitsvorlage "Hisecws.inf" von Windows 2000 oder Windows Server 2003 in Umgebungen, in denen die Clients keine LDAP-Signatur unterstützen oder in der keine clientseitige LDAP-Signatur aktiviert ist c. Gründe zum 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 modifiziert und anschließend an den Server weiterleitet. Wenn dieses Verhalten auf einem LDAP-Server auftritt, könnte ein Angreifer den Server zu Antworten veranlassen, die auf falschen Abfragen vom LDAP-Client basieren. Sie können dieses Risiko in einem Unternehmensnetzwerk senken, indem Sie strenge physische Sicherheitsmaßnahmen ergreifen, um die Netzwerkinfrastruktur zu schützen. Die Verwendung des IPSec-Header- Authentifizierungsmodus (Internet Protocol security, IPSec) kann "Man in the middle"-angriffe stark erschweren. Im Header Authentifizierungsmodus erfolgt eine gegenseitige Authentifizierung sowie die Prüfung der Paketintegrität des IP-Verkehrs. d. Gründe zum Deaktivieren dieser Einstellung Clients, die keine LDAP-Signaturen unterstützen, können keine LDAP-Abfragen auf Domänencontrollern und in globalen Katalogen ausführen, wenn die NTLM-Authentifizierung ausgehandelt wird und nicht die richtigen Service Packs auf den Windows 2000-Domänencontrollern installiert sind. Die Netzwerkablaufverfolgung des LDAP-Verkehrs zwischen den Clients und Servern wird verschlüsselt und erschwert somit das Abhören von LDAP-Verhandlungen. Auf Windows 2000-Servern muss Windows 2000 Service Pack 3 (SP3) oder höher installiert sein, wenn diese Server mit Programmen verwaltet werden, die LDAP-Signaturen von Client-Computern unterstützen, auf denen Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt wird. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Windows 2000-Domänencontroller benötigen SP3 oder höher bei Verwendung der Windows Server 2003-Verwaltungsprogramme e. Symbolischer Name: LDAPServerIntegrity f. Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD) g. Beispiele für Kompatibilitätsprobleme Einfache Bindungen schlagen fehl und die folgende Fehlermeldung wird angezeigt: Ldap_simple_bind_s() fehlgeschlagen: Strenge Authentifizierung erforderlich.

8 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 8 von 25 Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 ausführen, arbeiten einige Active Directory-Verwaltungswerkzeuge, die auf Domänencontroller mit Versionen von Windows 2000 vor Service Pack 3 abzielen, nicht korrekt, während die NTLM- Authentifizierung ausgehandelt wird. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Windows 2000-Domänencontroller benötigen SP3 oder höher bei Verwendung der Windows Server 2003-Verwaltungsprogramme Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 ausführen, arbeiten einige Active Directory-Verwaltungstools, die auf Domänencontroller mit Versionen von Windows 2000 vor SP3 abzielen, nicht korrekt, wenn sie IP-Adressen verwenden (z. B. "dsa.msc /server=x.x.x.x" wobei x.x.x.x eine IP-Adresse ist). Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Windows 2000-Domänencontroller benötigen SP3 oder höher bei Verwendung der Windows Server 2003-Verwaltungsprogramme Windows 2000 Service Pack 4, Windows XP, Windows Server 2003: Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 ausführen, arbeiten einige Active Directory-Verwaltungstools, die auf Domänencontroller mit Versionen von Windows 2000 vor SP3 abzielen, nicht korrekt. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Windows 2000-Domänencontroller benötigen SP3 oder höher bei Verwendung der Windows Server 2003-Verwaltungsprogramme 3. Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) Die Einstellung Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) bestimmt, ob ein sicherer Kanal zu einem Domänencontroller eingerichtet werden kann, der keinen starken 128-Bit- Sitzungsschlüssel für sicheren Kanalverkehr verwendet. Durch Aktivieren dieser Einstellung wird verhindert, dass sichere Kanäle zu Domänencontrollern eingerichtet werden, die Daten von sicheren Kanälen nicht mit einem starken Schlüssel verschlüsseln können. Durch Deaktivieren dieser Einstellung werden 64-Bit-Sitzungsschlüssel zugelassen. Bevor Sie diese Einstellung auf einer Mitgliedsarbeitsstation oder einem Server aktivieren können, müssen alle Domänencontroller in der Domäne, der dieses Mitglied angehört, in der Lage sein, Daten von sicheren Kanälen mit einem starken 128-Bit-Schlüssel zu verschlüsseln. Dies bedeutet, dass diese Domänencontroller Windows 2000 oder höher ausführen müssen. b. Risikoreiche Konfiguration Das Aktivieren der Einstellung Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) führt zu einer risikoreichen Konfiguration. c. Gründe zum Aktivieren dieser Einstellung Sitzungsschlüssel werden verwendet, um einen sicheren Kommunikationskanal zwischen den Mitgliedscomputern und Domänencontrollern einzurichten. In Windows 2000 sind sie viel stärker als in früheren Versionen anderer Microsoft- Betriebssysteme. Wenn möglich, sollten Sie diese stärkeren Sitzungsschlüssel nutzen, um die Kommunikation über sichere Kanäle vor Lauschangriffen und vor Netzwerkangriffen durch Session Hijacking (Sitzungsentführung) zu schützen. Lauschangriffe sind böswillige Angriffe, bei denen Netzwerkdaten während der Übertragung gelesen oder modifiziert werden. Beispielsweise können die Daten so modifiziert werden, dass der Absender verborgen oder geändert bzw. die Daten umgeleitet werden. d. Gründe zum Deaktivieren dieser Einstellung Die Domäne enthält Mitgliedscomputer, die auch andere Betriebssysteme als Windows 2000, Windows XP oder Windows Server 2003 ausführen. e. Symbolischer Name: StrongKey f. Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD) g. Beispiele für Kompatibilitätsprobleme Windows NT 4.0: Auf Windows NT 4.0-Computern schlägt das Zurücksetzen der sicheren Kanäle von Vertrauensstellungen zwischen Windows NT 4.0- und Windows 2000-Domänen mit NLTEST fehl. Die Fehlermeldung "Zugriff verweigert" wird angezeigt: Die Vertrauensstellung zwischen der primären Domäne und der vertrauenswürdigen Domäne konnte nicht hergestellt werden. 4. Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) Durch Aktivieren der Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder

9 Nach dem Ändern von Sicherheitseinstellungen und Benutzerrechten können Inkompatibilitäten mit... Seite 9 von 25 signieren (immer) wird die Einrichtung eines sicheren Kanals zu einem Domänencontroller verhindert, der nicht alle Daten des sicheren Kanals signieren oder verschlüsseln kann. Um den Authentifizierungsverkehr vor "Man in the middle" Angriffen, Replay-Angriffen und anderen Arten von Netzwerkangriffen zu schützen, richten Windows-Computer einen Kommunikationskanal über den Anmeldedienst ein, der auch als sicherer Kanal bezeichnet wird, um die Computerkonten zu authentifizieren. Sichere Kanäle werden außerdem verwendet, wenn ein Benutzer in einer Domäne eine Verbindung zu einer Netzwerkressource in einer Remote-Domäne herstellt. Diese Mehrdomänen-Authentifizierung oder Durchsatzauthentifizierung ermöglicht es einem Windows-Computer, der einer Domäne hinzugefügt wurde, auf die Benutzerkontodatenbank in seiner Domäne und in vertrauenswürdigen Domänen zuzugreifen. Um die Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) auf einem Mitgliedscomputer zu aktivieren, müssen alle Domänencontroller in der Domäne, der der Computer angehört, in der Lage sein, alle Daten des sicheren Kanals zu signieren oder zu verschlüsseln. Dies bedeutet, dass diese Domänencontroller Windows 4.0 mit Service Pack 6a (SP6a) oder höher ausführen müssen. Durch Aktivieren der Einstellung Domänenmitglied: Daten des sicheren Kanals 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. b. Risikoreiche Konfiguration Das Aktivieren 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 risikoreiche Konfiguration. c. Gründe zum 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 und modifiziert, bevor sie an den Client weitergeleitet werden. Wenn dieses Verhalten auf einem LDAP- Server auftritt, könnte ein Angreifer den Client zu Antworten veranlassen, die auf falschen Datensätzen aus dem LDAP- Verzeichnis basieren. Sie können das Risiko eines solchen Angriffs auf ein Unternehmensnetzwerk senken, indem Sie strenge physische Sicherheitsmaßnahmen ergreifen, um die Netzwerkinfrastruktur zu schützen. Die Implementierung des IPSec- Header-Authentifizierungsmodus (Internet Protocol security, IPSec) kann alle Arten von "Man in the middle"-angriffe stark erschweren. In diesem Modus wird eine gegenseitige Authentifizierung und eine Prüfung der Paketintegrität des IP-Verkehrs durchgeführt. d. Gründe zum Deaktivieren dieser Einstellung Computer in lokalen oder externen Domänen unterstützen keine verschlüsselten sicheren Kanäle. Nicht auf allen Domänencontrollern in der Domäne sind geeignete Service Packs installiert, die verschlüsselte sichere Kanäle unterstützen. e. Symbolischer Name: StrongKey f. Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD) g. Beispiele für Kompatibilitätsprobleme Windows NT 4.0: Windows 2000-Mitgliedscomputer sind nicht in der Lage, Windows NT 4.0-Domänen beizutreten. Die folgende Fehlermeldung wird angezeigt: Mit diesem Konto kann man sich nicht von diesem Computer aus anmelden. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Fehlermeldung: Sie auf Benutzername sind von dieser Station nicht berechtigt das Konto Windows NT 4.0: Windows NT 4.0-Domänen können keine untergeordnete Vertrauensstellung mit einer Windows 2000 Domäne einrichten. Die folgende Fehlermeldung wird angezeigt: Mit diesem Konto kann man sich nicht von diesem Computer aus anmelden. Benutzer aus der vertrauenswürdigen Domäne können auch nicht über vorhandene untergeordnete Vertrauensstellungen authentifiziert werden. Einige Benutzer haben eventuell Schwierigkeiten, sich bei der Domäne anzumelden. In einer Fehlermeldung wird mitgeteilt, dass der Client die Domäne nicht finden kann. Windows XP: Windows XP-Clients, die Windows NT 4.0-Domänen beitreten, können keine Anmeldeversuche authentifizieren. Die folgende Fehlermeldung oder die folgenden Ereignisse werden im Ereignisprotokoll registriert: Es kann keine Verbindung mit der Domäne hergestellt werden, da der Domänencontroller nicht verfügbar ist bzw. das Computerkonto nicht gefunden wurde. Ereignis 5723: Die Einrichtung einer Sitzung von Computer Computername ist an der Authentifizierung gescheitert. Der/die Kontoname(n) in der Sicherheitsdatenbank lauten Computername. Folgender Fehler ist aufgetreten: Der Zugriff wurde verweigert. Ereignis 3227: Das Setup der Sitzung des Windows NT- oder Windows 2000-Domänencontrollers Servername für die Domäne Domänenname ist fehlgeschlagen, da die Kennzeichnung und der Abschluss der Sitzung des Anmeldedienstes von Servername nicht unterstützt wird. Aktualisieren Sie den Domänencontroller oder setzen Sie den Wert des Registrierungseintrags "RequireSignOrSeal" auf "0".

10 Seite 10 von 25 Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Ein Windows XP-Client kann sich nicht an einer Windows NT 4.0- Domäne anmelden Microsoft-Netzwerk: Auf Microsoft-Netzwerk-Clients wird möglicherweise eine der folgenden Fehlermeldungen angezeigt: Anmeldung fehlgeschlagen: Unbekannter Benutzername oder falsches Kennwort. Es ist kein Benutzersitzungsschlüssel für die angegebene Anmeldesitzung vorhanden. 5. Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Server Message Block (SMB) ist ein Protokoll für die gemeinsame Nutzung von Ressourcen, das von vielen Microsoft- Betriebssystemen unterstützt wird. Es bildet die Grundlage für NetBIOS (Network Basic Input/Output System) und viele andere Protokolle. Durch SMB-Signaturen wird sowohl der Benutzer als auch der Server authentifiziert, auf dem sich die Daten befinden. Wenn der Authentifizierungsprozess für eine der beiden Seiten fehlschlägt, findet keine Datenübertragung statt. Die Aktivierung der SMB-Signaturen beginnt während der SMB-Protokollaushandlung. Die SMB-Signaturrichtlinien legen fest, ob der Computer Clientkommunikationen immer digital signiert. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung verhindert "Man in the middle"-angriffe. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft, Angriffe durch aktive Nachrichten zu verhindern Die SMB-Signierung ermöglicht diese Authentifizierung durch Einfügen von digitalen Signaturen in jeden SMB. Die digitale Signatur wird anschließend von Client und Server gleichermaßen überprüft. Um die SMB-Signierung verwenden zu können, müssen Sie diese aktivieren oder die Verwendung der SMB-Signierung sowohl auf dem SMB-Client als auch auf dem SMB-Server verbindlich machen. Falls die SMB-Signierung auf einem Server aktiviert ist verwenden Clients, auf denen die SMB-Signierung ebenfalls aktiviert ist, bei allen nachfolgenden Sitzungen das Paketsignierungsprotokoll. Falls die SMB-Signierung auf einem Server erforderlich ist, kann ein Client nur dann eine Sitzung einrichten, wenn die SMB-Signierung auf dem Client aktiviert oder als verbindlich festgelegt wurde. Das Aktivieren von digitalen Signaturen in Hochsicherheitsnetzwerken hilft, Identitätswechsel von Clients und Servern zu verhindern. Diese Art von Identitätswechsel wird auch als Session Hijacking (Sitzungsentführung) 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 entführen. Ein Angreifer könnte unsignierte SBM-Pakete abfangen und ändern, den Verkehr modifizieren und anschließend weiterleiten, sodass der Server eventuell unerwünschte Aktionen ausführt. Außerdem könnte der Angreifer sich nach einer rechtmäßigen Authentifizierung als Server oder Client ausgeben und anschließend unberechtigten Zugang zu den Daten verschaffen. Das für die Datei- und Druckerfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 verwendete SMB-Protokoll unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung beendet Angriffe zur Sitzungsentführung und unterstützt die Nachrichtenauthentifizierung. Aus diesem Grund werden auch "Man in the middle"-angriffe verhindert. Die SMB-Signierung ermöglicht diese Authentifizierung durch Einfügen von digitalen Signaturen. Die Signatur wird anschließend von Client und Server überprüft. Hinweise Eine alternative Gegenmaßnahme zum Schutz des gesamten Netzwerkverkehrs besteht darin, digitale Signaturen mit IPSec zu aktivieren. Es existieren Hardwarebeschleuniger für die IPSec-Verschlüsselung und -Signierung, anhand deren die Auswirkungen von Verschlüsselung und Signierung auf die Leistung der Server-CPU minimiert werden können. Für die SMB-Signierung stehen jedoch keine Hardwarebeschleuniger zur Verfügung. Weitere Informationen finden Sie im Kapitel "Digitally sign server communications" (Digitales Signieren der Serverkommunikation) auf der folgenden Microsoft MSDN-Website: ( t.asp?url=/library/en-us/gp/568.asp) Konfigurieren Sie die SMB-Signierung mit dem Gruppenrichtlinienobjekt-Editor, weil das entsprechende Ändern einer lokalen Registrierung keine Auswirkungen hat, wenn es eine Domänenrichtlinie mit vorrangiger Geltung gibt. In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client die SMB-Signierung, wenn er Windows Server 2003-Server unter Verwendung der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden die SMB-Signierung jedoch nicht, wenn sie sich bei diesen Servern unter Verwendung der NTLMv2- Authentifizierung authentifizieren. Außerdem antworten Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients. Siehe Punkt 10: Netzwerksicherheit: LAN Manager-Authentifizierungsebene b. Risikoreiche Konfiguration Die folgende Konfiguration ist risikoreich: Deaktivieren der Einstellungen Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) und Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) oder Festlegen von "Nicht definiert" für diese Einstellungen. Diese Einstellungen erlauben es dem Redirector, Nur Text-Kennwörter an Nicht-Microsoft-SMB-Server zu senden, die keine Kennwortverschlüsselung während der Authentifizierung unterstützen.

11 Seite 11 von 25 c. Gründe zum Aktivieren dieser Einstellung Durch Aktivieren der Einstellung Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) werden die Clients zum Signieren von SMB-Verkehr aufgefordert, wenn sie Server kontaktieren, die keine SMB-Signatur erfordern. Hierdurch werden die Clients weniger anfällig für Session Hijacking-Angriffe. d. Gründe zum Deaktivieren dieser Einstellung Durch Aktivieren von Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) wird verhindert, dass Clients mit Zielservern kommunizieren, die keine SMB-Signaturen unterstützen. Wenn die Computer so konfiguriert werden, dass die gesamte nicht signierte SMB-Kommunikation ignoriert wird, können Programme und Betriebssysteme einer früheren Version eventuell keine Verbindung herstellen. e. Symbolischer Name: RequireSMBSignRdr f. Registry Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature g. Beispiele für Kompatibilitätsprobleme Windows NT 4.0: Sie können den sicheren Kanal einer Vertrauensstellung zwischen einer Windows Server Domäne und einer Windows NT 4.0-Domäne nicht mit NLTEST oder NETDOM zurücksetzen. Die Fehlermeldung "Zugriff verweigert" wird angezeigt. Windows XP: Das Kopieren von Dateien von Windows XP-Clients auf Windows 2000-Server und Windows Server 2003 Server dauert eventuell länger. Sie können kein Netzlaufwerk auf einem Client zuordnen, auf dem diese Einstellung aktiviert ist. Außerdem wird die folgende Fehlermeldung angezeigt: Mit diesem Konto kann man sich nicht von diesem Computer aus anmelden. h. Neustart Starten Sie den Computer oder den Arbeitsstationsdienst neu. Geben Sie hierzu in der Eingabeaufforderung die folgenden Befehle ein: Drücken Sie nach jedem Befehl die [EINGABETASTE]. net stop workstation net start workstation 6. Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Server Message Block (SMB) ist ein Protokoll für die gemeinsame Nutzung von Ressourcen, das von vielen Microsoft- Betriebssystemen unterstützt wird. Es bildet die Grundlage für NetBIOS (Network Basic Input/Output System) und viele andere Protokolle. Durch SMB-Signaturen wird sowohl der Benutzer als auch der Server authentifiziert, auf dem sich die Daten befinden. Wenn der Authentifizierungsprozess für eine der beiden Seiten fehlschlägt, findet keine Datenübertragung statt. Die Aktivierung der SMB-Signaturen beginnt während der SMB-Protokollaushandlung. Die SMB-Signaturrichtlinien legen fest, ob der Computer Clientkommunikationen immer digital signiert. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung verhindert "Man in the middle"-angriffe. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstü auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft, Angriffe durch aktive Nachrichten zu verhindern Die SMB-Signierung ermöglicht diese Authentifizierung durch Einfügen von digitalen Signaturen in jeden SMB. Die digitale Signatur wird anschließend von Client und Server gleichermaßen überprüft. Um die SMB-Signierung verwenden zu können, müssen Sie diese aktivieren oder die Verwendung der SMB-Signierung sowohl auf dem SMB-Client als auch auf dem SMB-Server verbindlich machen. Falls die SMB-Signierung auf einem Server aktiviert ist, verwenden Clients, auf denen die SMB-Signierung ebenfalls aktiviert ist, bei allen nachfolgenden Sitzungen das Paketsignierungsprotokoll. Falls die SMB-Signierung auf einem Server erforderlich ist, kann ein Client nur dann eine Sitzung einrichten, wenn die SMB-Signierung auf dem Client aktiviert oder als verbindlich festgelegt wurde. Das Aktivieren von digitalen Signaturen in Hochsicherheitsnetzwerken hilft, Identitätswechsel von Clients und Servern zu verhindern. Diese Art von Identitätswechsel wird auch als Session Hijacking (Sitzungsentführung) 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 entführen. Ein Angreifer könnte unsignierte SBM-Pakete (Subnet Bandwidth Manager, SBM) abfangen und ändern, den Verkehr modifizieren und anschließend weiterleiten, sodass der Server eventuell unerwünschte Aktionen ausführt. Außerdem könnte der Angreifer sich nach einer rechtmäßigen Authentifizierung als Server oder Client ausgeben und anschließend unberechtigten Zugang zu den Daten verschaffen. Das für die Datei- und Druckerfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 verwendete SMB-Protokoll unterstützt die gegenseitige Authentifizierung. Die gegenseitige Authentifizierung beendet Angriffe zur Sitzungsentführung und unterstützt die Nachrichtenauthentifizierung. Aus diesem Grund werden auch "Man in the middle"-angriffe verhindert. Die SMB-Signierung ermöglicht diese Authentifizierung durch Einfügen von digitalen Signaturen. Die Signatur wird anschließend von Client und Server überprüft. Eine alternative Gegenmaßnahme zum Schutz des gesamten Netzwerkverkehrs besteht darin, digitale Signaturen mit

12 Seite 12 von 25 IPSec zu aktivieren. Es existieren Hardwarebeschleuniger für die IPSec-Verschlüsselung und -Signierung, anhand deren die Auswirkungen von Verschlüsselung und Signierung auf die Leistung der Server-CPU minimiert werden können. Für die SMB-Signierung stehen jedoch keine Hardwarebeschleuniger zur Verfügung. In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client die SMB-Signierung, wenn er Windows Server 2003-Server unter Verwendung der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden die SMB-Signierung jedoch nicht, wenn sie sich bei diesen Servern unter Verwendung der NTLMv2- Authentifizierung authentifizieren. Außerdem antworten Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients. Siehe Punkt 10: Netzwerksicherheit: LAN Manager-Authentifizierungsebene b. Risikoreiche Konfiguration Die folgende Konfiguration ist risikoreich: Aktivieren der Einstellung Microsoft-Netzwerk (Server): Kommunikation digita signieren (immer) auf Servern und auf Domänencontrollern, auf die von Client-Computern mit inkompatiblen Windows- Betriebssystemen oder mit Betriebssystemen von Fremdanbietern in lokalen oder externen Domänen zugegriffen wird. c. Gründe zum Aktivieren dieser Einstellung Alle Client-Computer, auf denen diese Einstellung direkt über die Registrierung oder über eine Gruppenrichtlinie aktiviert wird, unterstützen SMB-Signaturen. Auf allen Client-Computern, auf denen diese Einstellung aktiviert ist, wird entweder Windows 95 mit dem Verzeichnisdienste-Client, Windows 98, Windows NT 4.0, Windows 2000, Windows XP Professional oder Windows Server 2003 ausgeführt. Wenn Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) deaktiviert ist, stehen auch keine SMB-Signaturen zur Verfügung. Bei Deaktivierung aller SMB-Signaturen sind die Computer viel anfälliger für Session Hijacking-Angriffe. d. Gründe zum Deaktivieren dieser Einstellung Durch das Aktivieren dieser Einstellung können sich Dateikopiervorgänge sowie die Netzwerkgeschwindigkeit auf Client Computern verlangsamen. Durch das Aktivieren dieser Einstellung wird verhindert, dass Clients, die keine SMB-Signaturen aushandeln können, eine Verbindung zu Servern und Domänencontrollern herstellen können. Hierdurch schlagen Vorgänge wie der Beitritt zu einer Domäne, die Authentifizierung von Benutzern und Computern oder der Netzwerkzugriff durch Programme eventuell fehl. e. Symbolischer Name: RequireSMBSignServer f. Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD) g. Beispiele für Kompatibilitätsprobleme Windows 95: Auf Windows 95-Clients, auf denen kein Verzeichnisdienst-Client installiert ist, schlägt die Anmeldeauthentifizierung fehl. Die folgende Fehlermeldung wird angezeigt: Das angegebene Domänenkennwort ist ungültig, oder der Zugriff auf den Anmeldeserver wurde verweigert. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Fehlermeldung bei der Anmeldung eines Windows 95- oder Windows NT 4.0-Clients bei einer Windows Server 2003-Domäne Windows NT 4.0: Auf Client-Computern, auf denen Versionen von Windows NT 4.0 vor Service Pack 3 (SP3) ausgeführt werden, schlägt die Anmeldeauthentifizierung fehl. Die folgende Fehlermeldung wird angezeigt: Sie konnten nicht angemeldet werden. Überprüfen Sie Benutzernamen und Domäne, und geben Sie das Kennwort erneut ein. Einige Nicht-Microsoft SMB-Server unterstützen nur einen nicht verschlüsselten Kennwortaustausch während der Authentifizierung. (Ein solcher Austausch wird auch als "Nur-Text"-Austausch bezeichnet.) Beginnend mit Windows NT 4.0 SP3 sendet der SMB-Redirector während der Authentifizierung kein unverschlüsseltes Kennwort mehr an einen SMB- Server, sofern Sie nicht einen entsprechenden Registrierungseintrag hinzugefügt haben. Modifizieren Sie die Registrierung wie folgt, um unverschlüsselte Kennwörter für den SMB-Client auf Windows NT 4.0 SP3 Systemen und neueren Systemen zu aktivieren: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters Wertname: EnablePlainTextPassword Typ: REG_DWORD Wert: 1 Weitere Informationen zu verwandten Themen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: ( Fehler: Systemfehler 1240 ist aufgetreten. Mit diesem Konto ( Windows NT mit SP3 stellt keine Verbindung zu SMB-Server her Windows Server 2003: Standardmäßig sind die Sicherheitseinstellungen auf Domänencontrollern mit Windows Server 2003 so konfiguriert, dass ein Abfangen oder Manipulieren von Domänencontroller-Kommunikationsvorgängen durch böswillige Benutzer erschwert wird. Damit Benutzer erfolgreich mit einem Domänencontroller kommunizieren können, auf dem Windows Server 2003 ausgeführt wird, ist es erforderlich, dass Clientcomputer sowohl SMB-Signaturen als auch

13 Seite 13 von 25 SMB-Verschlüsselung oder Signaturen für den Verkehr über sichere Kanäle verwenden. Auf Clients, auf denen Windows NT 4.0 ausgeführt wird und SP2 (oder früher) installiert ist, sowie auf Clients mit dem Betriebssystem Windows 95 ist die SMB-Paketsignierung standardmäßig nicht aktiviert. Diese Clients können sich daher einem Windows Server Domänencontroller gegenüber möglicherweise nicht authentifizieren. Windows und Windows Server 2003-Richtlinieneinstellungen: In Abhängigkeit von den spezifischen Anforderungen und der Konfiguration Ihrer Installation empfehlen wir, auf der niedrigsten erforderlichen Hierarchieebene im Snap-In "Gruppenrichtlinien-Editor" der Microsoft Management Console die folgenden Richtlinieneinstellungen festzulegen: Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Sicherheitsoptionen Unverschlüsseltes Kennwort an SMB-Server von Fremdanbietern senden (Diese Einstellung ist für Windows 2000.) Microsoft-Netzwerk (Client): Unverschlüsseltes Kennwort an SMB-Server von Fremdanbietern senden (Diese Einstellung ist für Windows Server 2003.) Hinweis: Bei manchen CIFS-Servern von Fremdanbietern, zum Beispiel bei älteren Samba-Versionen, ist die Verwendung verschlüsselter Kennwörter nicht möglich. Die folgenden Clients sind inkompatibel mit der Einstellung Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer): Apple Computer, Inc., Mac OS X-Clients h. Neustart Microsoft MS-DOS-Netzwerk-Clients (z. B. Microsoft LAN Manager) Microsoft Windows für Workgroups-Clients Microsoft Windows 95-Clients ohne den Verzeichnisdienste-Client Microsoft Windows NT 4.0-Computer ohne SP3 oder höher Novell Netware 6 CIFS-Clients SAMBA SMB-Clients, die keine Unterstützung für SMB-Signaturen bieten Starten Sie den Computer oder den Serverdienst neu. Geben Sie hierzu in der Eingabeaufforderung die folgenden Befehle ein: Drücken Sie nach jedem Befehl die [EINGABETASTE]. net stop server net start server 7. Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen Die Sicherheitseinstellung Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen bestimmt, ob ein anonymer Benutzer SID-Attribute (Sicherheits-ID, SID) für einen anderen Benutzer anfordern kann. b. Risikoreiche Konfiguration Das Aktivieren der Einstellung Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen stellt eine risikoreiche Konfiguration dar. c. Gründe zum Aktivieren dieser Einstellung Wenn die Einstellung Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen deaktiviert wird, können Betriebssysteme oder Anwendungen einer früheren Version möglicherweise nicht mit Windows Server 2003-Domänen kommunizieren. Die folgenden Betriebssysteme, Dienste oder Anwendungen funktionieren eventuell nicht: Windows NT 4.0-RAS-Server Microsoft SQL-Server, die auf Windows NT 3.x- oder Windows NT 4.0-Computern ausgeführt werden RAS-Dienst, der auf Windows 2000-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-Computern ausgeführt wird, die sich in Windows NT 3.x- oder Windows NT 4.0- Domänen befinden Benutzer in Windows NT 4.0-Ressourcendomänen, die Benutzerkonten aus Kontendomänen mit Windows Server Domänencontrollern Berechtigungen für den Zugriff auf Dateien, freigegebene Ordner und Registrierungsobjekte gewähren möchten d. Gründe zum Deaktivieren dieser Einstellung Wenn diese Einstellung aktiviert ist, könnte ein böswilliger Benutzer die bekannte Administrator-SID verwenden, um den eigentlichen Namen des integrierten Administratorkontos abzurufen, selbst wenn dieses Konto umbenannt wurde. Diese Perso könnte anschließend mithilfe des Kontonamens einen Angriff zum Erraten des Kennworts durchführen. e. Symbolischer Name: Nicht zutreffend f. Registrierungspfad: Keiner. Der Pfad ist im Code der Benutzeroberfläche angegeben. g. Beispiele für Kompatibilitätsprobleme

14 Seite 14 von 25 Windows NT 4.0: Computer in Windows NT 4.0-Ressourcendomänen zeigen die Fehlermeldung "Unbekanntes Konto" im ACL Editor an, wenn Ressourcen, darunter freigegebene Order und Dateien sowie Registrierungsobjekte, mit Sicherheitsprinzipalen geschützt sind, die sich in Kontendomänen mit Windows Server 2003-Domänencontrollern befinden. 8. Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben Die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben bestimmt, welche zusätzlichen Berechtigungen für anonyme Verbindungen zum Computer gewährt werden. Windows gestattet anonymen Benutzern bestimmte Aktivitäten, wie beispielsweise das Aufzählen der Namen von SAM-Konten (Security Accounts Manager, SAM) und Netzwerkfreigaben der Domäne. Diese Einstellung ist sehr hilfreich, wenn ein Administrator Benutzern einer vertrauenswürdigen Domäne, die keine gegenseitige Vertrauensstellung unterhält, den Zugriff gewähren möchte. Ein anonymer Benutzer hat standardmäßig dieselben Zugriffsrechte, die auch der Gruppe "Jeder" für eine bestimmte Ressource gewährt wurden. In der Regel werden anonyme Verbindungen von älteren Clients oder Clients früherer Versionen bei der Einrichtung einer SMB-Sitzung verlangt. In diesen Fällen ergibt eine Netzwerkablaufverfolgung, dass die SMB-Prozess-ID (PID) der Client-Redirector ist; 0xFEFF in Windows 2000 oder 0xCAFE in Windows NT. RPC versucht eventuell ebenfalls, anonyme Verbindungen aufzubauen. Diese Einstellung hat keine Auswirkungen auf Domänencontroller. In Windows 2000 existiert eine ähnliche Einstellung. Dabei handelt es sich um die Einstellung Weitere Einschränkungen für anonyme Verbindungen, die den Registrierungswert RestrictAnonymous verwaltet. Dieser Wert befindet sich im folgenden Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA. Weitere Informationen zum Registrierungswert "RestrictAnonymous" finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: ( Verwenden des Registrierungswertes "RestrictAnonymous" in Windows ( Beschränken der Informationen, für anonym angemeldete Benutzer b. Risikoreiche Konfigurationen: Das Aktivieren der Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben stellt vom Kompatibilitätsaspekt her eine risikoreiche Konfiguration dar. Das Deaktivieren dieser Einstellung stellt vom Sicherheitsaspekt her eine risikoreiche Konfiguration dar. c. Gründe zum Aktivieren dieser Einstellung Ein unberechtigter Benutzer könnte über eine anonyme Verbindung die Kontennamen auflisten und anhand dieser Informationen versuchen, die Kennwörter zu erraten oder Social Engineering-Angriffe auszuführen. Bei Social Engineering- Angriffen wird versucht, Personen durch Vortäuschen falscher Tatsachen zur Offenlegung ihrer Kennwörter oder von Sicherheitsinformationen zu bringen. d. Gründe zum Deaktivieren dieser Einstellung Wenn diese Einstellung aktiviert ist, besteht keine Möglichkeit, Vertrauensstellungen mit Windows NT 4.0-Domänen einzurichten. Diese Einstellung verursacht außerdem Probleme mit untergeordneten Clients, wie z. B. Windows NT und Windows 95-Clients, die versuchen, Ressourcen auf dem Server zu verwenden. e. Symbolischer Name: RestrictAnonymousSAM f. Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD) g. Beispiele für Kompatibilitätsprobleme Die SMS-Netzwerkerkennung kann keine Betriebssysteminformationen abrufen und schreibt daher die Angabe "Unknown" (Unbekannt) in die Eigenschaft "OperatingSystemNameandVersion". Windows 95, Windows 98: Windows 95- und Windows 98-Clients können ihre Kennwörter nicht ändern. Windows NT 4.0: Windows NT 4.0-Mitgliedscomputer können nicht authentifiziert werden. Windows 95, Windows 98: Windows 95- und Windows 98-Computer können nicht von Microsoft-Domänencontrollern authentifiziert werden. Windows 95, Windows 98: Benutzer von Windows 95- und Windows 98-Computern können das Kennwort ihres Benutzerkontos nicht ändern. 9. Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben Die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben (auch als RestrictAnonymous bezeichnet) bestimmt, ob die anonyme Aufzählung von SAM-Konten (Security Accounts Manager, SAM) und Freigaben erlaubt wird. Windows gestattet anonymen Benutzern bestimmte Aktivitäten, wie beispielsweise das Aufzählen der Namen von Domänenkonten (Benutzer, Computer und Gruppen) und Netzwerkfreigaben. Diese Einstellung ist sehr hilfreich, wenn ein Administrator Benutzern einer vertrauenswürdigen Domäne, die keine gegenseitige

15 Seite 15 von 25 Vertrauensstellung unterhält, den Zugriff gewähren möchte. Wenn Sie die anonyme Aufzählung von SAM-Konten und Freigaben zulassen möchten, aktivieren Sie diese Einstellung. In Windows 2000 existiert eine ähnliche Einstellung. Dabei handelt es sich um die Einstellung Weitere Einschränkungen für anonyme Verbindungen, die den Registrierungswert RestrictAnonymous verwaltet. Dieser Wert befindet sich im folgenden Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA b. Risikoreiche Konfiguration Das Aktivieren der Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben stellt eine risikoreiche Konfiguration dar. c. Gründe zum Aktivieren dieser Einstellung Durch Aktivieren der Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben wird die Aufzählung von SAM-Konten und Freigaben durch Benutzer und Computer verhindert, die anonyme Konten verwenden. d. Gründe zum Deaktivieren dieser Einstellung Wenn diese Einstellung aktiviert ist, könnte ein unberechtigter Benutzer über eine anonyme Verbindung die Kontennamen auflisten und anhand dieser Informationen versuchen, die Kennwörter zu erraten oder Social Engineering-Angriffe auszuführen. Bei Social Engineering-Angriffen wird versucht, Personen durch Vortäuschen falscher Tatsachen zur Offenlegung ihrer Kennwörter oder von Sicherheitsinformationen zu bringen. Wenn diese Einstellung aktiviert ist, besteht keine Möglichkeit, Vertrauensstellungen mit Windows NT 4.0-Domänen einzurichten. Diese Einstellung verursacht außerdem Probleme mit untergeordneten Clients, wie z. B. Windows NT 3.51 und Windows 95-Clients, die versuchen, Ressourcen auf dem Server zu verwenden. Es ist unmöglich, den Benutzern von Ressourcendomänen Zugriff zu gewähren, weil die Administratoren in der vertrauenswürdigen Domäne nicht in der Lage sind, Kontolisten in der anderen Domäne aufzulisten. Benutzer, die anonym auf Datei- und Druckserver zugreifen, können die freigegebenen Netzwerkressourcen auf diesen Servern nicht auflisten. Sie müssen sich authentifizieren, bevor sie die Listen von freigegebenen Ordnern und Druckern anzeigen können. e. Symbolischer Name: RestrictAnonymous f. Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous g. Beispiele für Kompatibilitätsprobleme Windows NT 4.0: Benutzer können ihre Kennwörter auf Windows NT 4.0-Arbeitsstationen nicht ändern, wenn RestrictAnonymous auf Domänencontrollern in der Domäne des Benutzers aktiviert ist. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Benutzer kann Kennwort nicht ändern, wenn sich Benutzer kann Kennwort nicht ändern anmeldet Windows NT 4.0: Das Hinzufügen von Benutzern oder globalen Gruppen aus vertrauenswürdigen Windows Domänen zu lokalen Gruppen in Windows NT 4.0 mithilfe des Benutzer-Managers schlägt fehl. Die folgende Fehlermeldung wird angezeigt: Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Der "RestrictAnonymous" Registrierungswert kann für eine Windows 2000-Domäne zu Fehlern bei der Vertrauensstellung führen Windows NT 4.0: Windows NT 4.0-Computer können während des Setups oder mithilfe der Benutzeroberfläche für den Domänenbeitritt keiner Domäne beitreten. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Fehlermeldung: ein Controller für diese Domäne konnte nicht gefunden werden Windows NT 4.0: Windows NT 4.0: Das Einrichten einer untergeordneten 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: Domänencontroller für diese Domäne konnte nicht gefunden werden. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Konnte Domäne-Controller nicht finden, wenn Sie eine Vertrauensstellung einrichten Windows NT 4.0: Benutzer, die sich auf Windows NT 4.0 Terminal Server-Computern anmelden, werden nicht dem Stammverzeichnis zugeordnet, das im Benutzer-Manager für Domänen definiert ist, sondern sie werden dem

16 Seite 16 von 25 standardmäßigen Stammverzeichnis zugeordnet. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Terminal-Server-Benutzerprofil und Ordner-Basispfade werden nach SP4 oder später, das anwenden soll, ignoriert Windows NT 4.0: Windows NT 4.0-Sicherungs-Domänencontroller (Backup Domain Controller, BDC) können den Anmeldedienst nicht starten, um eine Liste der Sicherungssuchdienste abzurufen oder die SAM-Datenbank von Windows oder Windows Server 2003-Domänencontrollern derselben Domäne zu synchronisieren. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Der Net Logon-Dienst von einem Windows NT 4.0 BDC funktioniert nicht in einer Windows 2000-Domäne 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 explizite anonyme Berechtigung in der lokalen Sicherheitsrichtlinie des Client-Computers aktiviert ist. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Benutzer kann Druckereigenschaft nicht verwalten oder nicht anzeigen Windows 2000: Windows 2000-Domänenbenutzer können keine Netzwerkdrucker aus dem Active Directory hinzufügen. Sie können jedoch Drucker hinzufügen, nachdem sie die Drucker in der Strukturansicht ausgewählt haben. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Nachdem Sie Security Rollup-Paket 1 (SRP1) auf globalem Katalogserver installieren, können Globale Adressliste Outlook-Clients nicht anzeigen Windows 2000: Auf Windows 2000-Computern können im ACL-Editor keine Benutzer oder globalen Gruppen aus vertrauenswürdigen Windows NT 4.0-Domänen hinzugefügt werden. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Das RestrictAnonymous Value unterbricht die Vertrauensstellung in einer Umgebung von Mixed-Domain ADMT Version 2: Die Kennwortmigration für Benutzerkonten, die mit dem Active Directory Migration Tool (ADMT) Version 2 zwischen den Strukturen migriert werden, schlägt fehl. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Wie Problem kann mit Inter-forest behandelt werden Kennwort- Migration mit ADMTv2 Outlook-Clients: Die globale Adressliste erscheint für Microsoft Exchange Outlook-Clients leer. Weitere Informationen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: ( Nachdem Sie Security Rollup-Paket 1 (SRP1) auf globalem Katalogserver installieren, können Globale Adressliste Outlook-Clients nicht anzeigen ( Langsame SMB-Leistung beim Kopieren von Dateien von Windows XP auf einen Windows 2000-Domänencontroller SMS: Die Netzwerkerkennung von Microsoft Systems Management Server (SMS) kann keine Betriebssysteminformationen abrufen. Das Tool schreibt den Wert "Unknown" (Unbekannt) in die Eigenschaft "OperatingSystemNameandVersion" der SMS DDR-Eigenschaft des Erkennungsdatensatzes (Discovery Data Record, DDR). Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( SMS: Ermittlungsdatenmanager bestimmt wie, wann eine Anforderung von Clientkonfiguration generiert wird SMS: Wenn Sie den Assistenten für Benutzer in SMS Administrator für die Suche nach Benutzern und Gruppen verwenden, werden keine Benutzer oder Gruppen aufgelistet. Außerdem können erweiterte Clients nicht mit dem Verwaltungspunkt kommunizieren. Für den Verwaltungspunkt ist der anonyme Zugriff erforderlich. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( SMS: kein Benutzer oder Gruppen ist in dem Administrator- Benutzerassistent zusammengefasst SMS: Wenn Sie die Funktion für die Netzwerkerkennung in SMS 2.0 verwenden und die Netzwerkerkennungsoption Topology, Client und Clientbetriebssystem bei der Remote-Client-Installation aktiviert ist, werden die Computer zwar erkannt, jedoch nicht installiert. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( SMS: von Ressourcen nicht der Ermittlung, wenn anonyme Verbindungen deaktiviert sind 10. Netzwerksicherheit: LAN Manager-Authentifizierungsebene

17 Seite 17 von 25 a. Background Bei der LAN Manager (LM)-Authentifizierung handelt es sich um das Protokoll, anhand dessen Windows-Clients bei Netzwerkvorgängen, darunter Domänenbeitritte, der Zugriff auf Netzwerkressourcen sowie die Benutzer- oder Computerauthentifizierung, authentifiziert werden. Die LM-Authentifizierungsebene bestimmt, welches Challenge/Response Authentifizierungsprotokoll zwischen den Client- und Server-Computern ausgehandelt wird. Über die LM- Authentifizierungsebene wird außerdem bestimmt, welche Authentifizierungsprotokolle der Client für die Verhandlung verwendet, bzw. welche dieser Protokolle der Server akzeptiert. Der für "LmCompatibilityLevel" festgelegte Wert bestimmt, welches Anfrage/Antwort-Authentifizierungsprotokoll für Netzwerkanmeldungen verwendet wird. Dieser Wert wirkt sich auf die Ebene von Authentifizierungsprotokollen aus, die von Clients verwendet wird, auf die ausgehandelte Sicherheitsstufe für eine Sitzung und auf die Authentifizierungsebene, die von Servern akzeptiert wird. Siehe hierzu die folgende Tabelle: Zu den möglichen Einstellungen gehören: Wert Einstellung Beschreibung 0 LM- und NTLM-Antworten senden Clients verwenden die LM- und NTLM-Authentifizierung und nie die NTLMv2-Sitzungssicherheit; Domänencontroller akzeptieren LM-, NTLMund NTLMv2-Authentifizierung. 1 LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt) Clients verwenden LM- und NTLM-Authentifizierung und die NTLMv2- Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung. 2 Nur NTLM-Response senden Clients verwenden nur NTLM-Authentifizierung und NTLMv2- Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung. 3 Nur NTLM-Antworten senden Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2- Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung. 4 Nur NTLMv2-Antworten senden/lm verweigern Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2- Sitzungssicherheit, falls dies vom Server unterstützt wird. Domänencontroller verweigern LM (sie akzeptieren nur NTLM- und NTLMv2-Authentifizierung). 5 Nur NTLMv2-Antworten senden/lm und NTLM verweigern Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2- Sitzungssicherheit, falls dies vom Server unterstützt wird; Domänencontroller verweigern LM und NTLM (sie akzeptieren nur NTLMv2 Authentifizierung). Hinweis: In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client die SMB- Signierung, wenn er Windows Server 2003-Server unter Verwendung der NTLM-Authentifizierung authentifiziert. Diese Clients verwenden die SMB-Signierung jedoch nicht, wenn sie sich bei diesen Servern unter Verwendung der NTLMv2- Authentifizierung authentifizieren. Außerdem antworten Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients. Überprüfen Sie die LM-Authentifizierungsebene Sie müssen die Richtlinie auf dem Server so ändern, dass NTLM zulässig ist, oder Sie müssen den Clientcomputer so konfigurieren, dass er NTLMv2 unterstützt. Falls die Richtlinie auf dem Zielcomputer, zu dem Sie eine Verbindung herstellen möchten, auf (5) Nur NTLMv2-Antworten senden\lm und NTLM verweigern festgelegt ist, müssen Sie auf diesem Computer entweder eine niedrigere Einstellung festlegen, oder Sie müssen dort die gleiche Sicherheitsstufe festlegen, die auf dem Quellcomputer gilt, von dem aus Sie die Verbindung aufbauen möchten. Suchen Sie den Ort, an dem Sie die Authentifizierungsebene des LAN-Managers so ändern können, dass auf Client und Server die gleiche Stufe gilt. Nachdem Sie die Richtlinie gefunden haben, welche die Authentifizierungsebene des LAN-Managers bestimmt, und wenn Sie von und zu Computern mit früheren Windows-Versionen Verbindungen aufbauen möchten, verringern Sie die Einstellung mindestens bis auf (1) LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt). Sie müssen zum Beispiel entweder auf dem Domänencontroller suchen oder die Richtlinien auf dem Domänencontroller überprüfen. Suchen auf dem Domänencontroller Hinweis: Eventuell müssen Sie das folgende Verfahren auf allen Domänencontrollern anwenden. 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 den entsprechenden Wert in der Liste. Sind die effektive Einstellung und die lokale Einstellung identisch, wurde die Richtlinie auf dieser Ebene geändert. Unterscheiden sich die Einstellungen, müssen Sie die Richtlinie für den Domänencontroller darauf überprüfen, ob dort die Einstellung Netzwerksicherheit: LAN Manager-Authentifizierungsebene definiert ist. Ist dies nicht der Fall, sehen Sie

18 Seite 18 von 25 sich die Richtlinien des Domänencontrollers an. Prü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 für Domänencontroller die 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 den entsprechenden Wert in der Liste. Hinweis: Sie müssen eventuell auch die Richtlinien überprüfen, die auf der Standortebene, der Domänenebene oder der Ebene der Organisationseinheit verknüpft sind, um zu ermitteln, ob Sie die Authentifizierungsebene des LAN-Managers konfigurieren müssen. Wenn Sie eine Gruppenrichtlinie als Standarddomänenrichtlinie implementieren, gilt diese für alle Computer in der Domäne. Wenn Sie Gruppenrichtlinien als Richtlinien des Standarddomänencontrollers implementieren, gelten diese nur für die Server in der Organisationseinheit des Domänencontrollers. Es ist empfehlenswert, für die Authentifizierungsebene des LAN-Managers die niedrigste Stufe in der Hierarchie der Richtlinienanwendung festzulegen. Aktualisieren Sie die Richtlinie, nachdem Sie Änderungen vorgenommen haben. (Änderungen auf der Ebene der lokalen Sicherheitseinstellungen wirken sich sofort aus. Bevor Sie testen, müssen Sie jedoch die Clients neu starten.) Standardmäßig werden Gruppenrichtlinieneinstellungen auf Domänencontrollern alle fünf Minuten aktualisiert. Verwenden Sie den Befehl gpupdate, um unter Windows 2000 oder höher die sofortige Aktualisierung der Richtlinieneinstellungen zu erzwingen. Der Befehl gpupdate /force aktualisiert lokale Gruppenrichtlinieneinstellungen und solche Gruppenrichtlinieneinstellungen, die auf dem Active Directory-Verzeichnisdienst basieren (einschließlich Sicherheitseinstellungen). Dieser Befehl ersetzt die inzwischen veraltete Option /refreshpolicy für den Befehl secedit. Der Befehl gpupdate verwendet die folgende Syntax: gpupdate [/target:{computer Benutzer}] [/force] [/wait:wert] [/logoff] [/boot] Wenden Sie das neue Gruppenrichtlinienobjekt an, indem Sie den Befehl gpupdate verwenden, um manuell alle Richtlinieneinstellungen erneut festzulegen. Geben Sie hierzu den folgenden Befehl in eine Eingabeaufforderung ein, und drücken Sie anschließend die [EINGABETASTE]: GPUpdate /Force Sehen Sie sich das Anwendungsereignisprotokoll an, um sicherzustellen, dass die Richtlinieneinstellung erfolgreich angewende wurde. Verwenden Sie auf einem Computer, auf dem Windows-XP oder Windows Server 2003 ausgeführt wird, das Snap-In "Richtlinienergebnissatz", um die effektive Einstellung einzusehen. Klicken Sie hierzu auf Start und auf Ausführen, geben Sie rsop.msc ein, und klicken Sie anschließend auf OK. Besteht das Problem nach dem Ändern der Richtlinie immer noch, starten Sie den Server auf Windows-Basis neu und überprüfen Sie dann, ob das Problem behoben wurde. Hinweis: Falls Sie mehrere Domänencontroller auf Windows und Windows Server 2003-Basis haben, müssen Sie eventuell Active Directory replizieren, um sicherzustellen, dass diese Domänencontroller die Änderungen sofort übernommen haben. Es kann auch den Anschein haben, als sei für die Einstellung die niedrigste Stufe in der lokalen Sicherheitsrichtlinie festgelegt. Falls Sie die Einstellung mithilfe einer Sicherheitsdatenbank erzwingen können, können Sie auch die Authentifizierungsebene des LAN-Managers in der Registrierung festlegen, indem Sie den Eintrag LmCompatibilityLevel im folgenden Unterschlüssel der Registrierung bearbeiten: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa In Windows Server 2003 gibt es eine neue Standardeinstellung, die vorschreibt, dass nur NTLMv2 verwendet wird. Standardmäßig ist auf Domänencontrollern unter Windows Server 2003 und Windows 2000 Server SP3 die Richtlinie "Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)" aktiviert. Diese Einstellung erfordert, dass der SMB Server die SMB-Paketsignierung durchführt. Die Änderungen an Windows Server 2003 wurden vorgenommen, weil Domänencontroller, Dateiserver, Netzwerkinfrastrukturserver und Webserver in jeder Organisation andere Einstellungen erfordern, um maximale Sicherheit zu gewährleisten. Falls Sie die NTLMv2-Authentifizierung in Ihrem Netzwerk implementieren möchten, müssen Sie sicherstellen, dass alle Computer in der Domäne darauf konfiguriert sind, diese Authentifizierungsebene zu verwenden. Falls Sie Active Directory- Clienterweiterungen für Windows 95 oder Windows 98 und Windows NT 4.0 anwenden, verwenden diese Clienterweiterungen die verbesserten Funktionen, die in NTLMv2 verfügbar sind. Da Clientcomputer mit den folgenden Betriebssystemen von

19 Seite 19 von 25 Windows 2000-Gruppenrichtlinienobjekten nicht betroffen sind, müssen Sie solche Clients manuell konfigurieren: Microsoft Windows NT 4.0 Microsoft Windows Millennium Edition Microsoft Windows 98 Microsoft Windows 95 Hinweis: Falls Sie die Richtlinie Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern aktivieren oder den Registrierungsschlüssel NoLMHash setzen, können sich Clients auf Windows 95- und Windows 98-Basis, auf denen der Verzeichnisdienst-Client nicht installiert ist, nach einer Kennwortänderung nicht mehr bei der Dom anmelden. Viele CIFS-Server von Fremdanbietern, wie z. B. Novell Netware 6, sind nicht NTLMv2-fähig und verwenden ausschließlich NTLM. Bei Ebenen höher als 2 ist ein Verbindungsaufbau daher nicht möglich. Weitere Informationen zum manuellen Konfigurieren der Authentifizierungsebene des LAN-Managers finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: ( Deaktivieren der LM-Authentifizierung in Windows NT ( LMCompatibilityLevel und seinen Effekte ( So verhindern Sie, dass Windows LAN Manager-Hashwerte Ihres Kennworts in Active Directory und der lokalen SAM-Datenbank speichert ( Outlook setzt Auffordern für An-Meldeinformation Sie fort Weitere Informationen zu LM-Authentifizierungsebenen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Aktivieren der NTLM 2-Authentifizierung für Windows 95/98/2000 und NT b. Risikoreiche Konfigurationen Die folgenden Konfigurationen sind risikoreich: Nicht restriktive Einstellungen, die Kennwörter unverschlüsselt senden und die NTLMv2-Verhandlung verweigern Restriktive Einstellungen, die verhindern, dass inkompatible Clients oder Domänencontroller ein gemeinsames Authentifizierungsprotokoll aushandeln Anfordern der NTLMv2-Authentifizierung auf Mitgliedscomputern und Domänencontrollern, auf denen Versionen von Windows NT 4.0 vor Service Pack 4 (SP4) ausgeführt werden Anfordern der NTLMv2-Authentifizierung auf Windows 95- oder Windows 98-Clients, auf denen kein Windows- Verzeichnisdienst-Client installiert ist. Wenn Sie das Kontrollkästchen NTLMv2-Sitzungssicherheit erfordern im Snap-In "Gruppenrichtlinien-Editor" der Microsoft Management Console auf einem Computer mit Windows Server 2003 oder Windows 2000 Service Pack 3 aktivieren und die Authentifizierungsebene des LAN-Managers auf 0 reduzieren, entsteht ein Konflikt zwischen den beiden Einstellungen und in der Datei "Secpol.msc" oder der Datei "GPEdit.msc" kann die folgende Fehlermeldung angezeigt werden: Die lokale Richtliniendatenbank konnte nicht geöffnet werden. Beim Öffnen der Datenbank ist ein unbekannter Fehler aufgetreten. Weitere Informationen zum Dienstprogramm "Sicherheitskonfiguration und -analyse" finden Sie in den Hilfedateien von Windows 2000 und Windows Server Weitere Informationen zum Analysieren der Sicherheitsebenen in Windows 2000 und Windows Server 2003 finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: ( SO WIRD'S GEMACHT: Analysieren der Systemsicherheit in Windows ( Welcher VERFAHRENSWEISE: TO: Sie analysieren Systemsicherheit in Windows Server 2003 c. Gründe zum Ändern dieser Einstellung Sie möchten das niedrigste gemeinsame Authentifizierungsprotokoll ändern, das von den Clients und Domänencontrollern in Ihrer Organisation unterstützt wird. In Bereichen, in denen eine sichere Authentifizierung eine geschäftliche Anforderung ist, sollte die Verhandlung des LMund NTLM-Protokolls verweigert werden. d. Gründe zum Deaktivieren dieser Einstellung Die Authentifizierungsanforderungen für Clients und Server sind bis zu einem Punkt gestiegen, an dem keine Authentifizierung über ein gemeinsames Protokoll mehr stattfinden kann. e. Symbolischer Name: LmCompatibilityLevel f. Registrierungspfad:

20 Seite 20 von 25 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel g. Beispiele für Kompatibilitätsprobleme Windows Server 2003: Standardmäßig ist die Windows Server 2003 NTLMv2-Einstellung "NTLM-Anworten senden" aktiviert. In Windows Server 2003 wird daher nach der ursprünglichen Installation die Fehlermeldung "Zugriff verweigert" angezeigt, wenn Sie versuchen, eine Verbindung zu einem Cluster auf Windows NT 4.0-Basis oder zu Servern auf LanManager V2.1-Basis, wie z. B. "OS/2 Lanserver" herzustellen. Dieses Problem tritt auch dann auf, wenn Sie von einem Client einer früheren Version aus versuchen, eine Verbindung zu einem Server auf Windows Server 2003-Basis aufzubauen. Sie installieren Windows 2000 Security Rollup Package 1 (SRP1). SRP1 erzwingt die NTLM-Version 2 (NTLMv2). Dieses Rollup Package wurde nach Windows 2000 Service Pack 2 (SP2) freigegeben. Weitere Informationen zum SRP1 finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Windows 2000 Security Rollup Package 1 (SRP1), Januar 2002 Microsoft Outlook-Clients können nach Ihren Anmeldeinformationen gefragt werden, obwohl sie bereits bei der Domäne angemeldet sind. Wenn Benutzer dann ihre Anmeldeinformationen eingeben, wird ihnen die folgende Fehlermeldung angezeigt: Die Anmeldeinformationen sind ungültig. Überprüfen Sie Ihren Benutzernamen und die Domäne, und geben Sie das Kennwort erneut ein. Beim Starten von Outlook können Sie nach Ihren Anmeldeinformationen gefragt werden, obwohl für die Einstellung "Anmeldung-Netzwerksicherheit" die Option "Passthrough" oder die Option "Kennwortauthentifizierung" festgelegt ist. Nach Eingabe der korrekten Anmeldeinformationen wird möglicherweise die folgende Fehlermeldung angezeigt: Die Anmeldeinformationen sind ungültig. Eine Ablaufverfolgung mit dem Netzwerkmonitor ergibt möglicherweise, dass der globale Katalog einen Fehler bei einem Remoteprozeduraufruf (Remote Procedure Call/(RPC) mit dem Status of 0x5 gemeldet hat. Status 0x5 steht für "Zugriff verweigert". Windows 2000: Eine Ablaufverfolgung mit dem Netzwerkmonitor ergibt möglicherweise die folgenden Fehler in einer NetBIOS über TCP/IP (NetBT) -SMB-Sitzung (SMB = Server Message Block): SMB R-Suchverzeichnis-Dos-Fehler, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Ungültige Benutzerkennung (SMB R Search Directory Dos error, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Invalid user identifier) Windows 2000: Wenn eine Windows 2000-Domäne mit NTLMv2 der Stufe 2 oder höher von einer Windows NT 4.0- Domäne als vertrauenswürdig eingestuft wurde, können bei Windows 2000-Mitgliedscomputern in der Ressourcendomä Authentifizierungsfehler auftreten. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Authentifizierungsprobleme in Windows 2000 mit NTLM 2-Ebenen oberhalb 2 in einer Windows NT 4.0-Domäne Windows 2000 und Windows XP: Windows 2000 und Windows XP setzen die Option für die LAN-Manager- Authentifizierungsebene in der lokalen Sicherheitsrichtlinie standardmäßig auf 0. Die Einstellung 0 steht für "LM- und NTLM-Anworten senden". Hinweis: Windows NT 4.0-Cluster müssen für die Verwaltung LM verwenden. Windows 2000: Windows 2000-Cluster gestatten keine Authentifizierung eines beitretenden Knotens, wenn beide Knoten Mitglied einer Windows NT 4.0 Service Pack 6a (SP6a)-Domäne sind. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: ( Authentifizierungsprobleme in Windows 2000 mit NTLM 2-Ebenen oberhalb 2 in einer Windows NT 4.0-Domäne Das IIS Lockdown-Tool (HiSecWeb) setzt den Wert für "LMCompatibilityLevel" auf 5 und den Wert für "RestrictAnonymous" auf 2. Dienste für Macintosh Benutzerauthentifizierungsmodul (User Authentication Module/UAM) Das Microsoft-Benutzerauthentifizierungsmodul (User Authentication Module = UAM) bietet eine Methode zur Verschlüsselung von Kennwörtern für die Anmeldung bei Windows AFP-Servern (AppleTalk Filing Protocol). Das Apple- Benutzerauthentifizierungsmodul (User Authentication Module = UAM) ermöglicht nur eine minimale oder gar keine Verschlüsselung. Ihr Kennwort kann daher im lokalen Netzwerk oder im Internet leicht abgefangen werden. Das UAM ist zwar nicht erforderlich, es bietet jedoch eine verschlüsselte Authentifizierung gegenüber Windows 2000-Servern, auf denen Dienste für Macintosh ausgeführt werden. Diese Version beinhaltet die Unterstützung für eine NTLMv2 128-Bitverschlüsselte Authentifizierung und ein MacOS X 10.1-kompatibles Release.