Sicherheitseinstellungen und Benutzerrechten können in lokale Richtlinien und Gruppenrichtlinien können Sie die Sicherheit auf Domänencontrollern und Mitgliedscomputern erhöhen geändert werden. Der Nachteil dieser erhöhten Sicherheit ist jedoch die Einführung von Inkompatibilitäten mit Clients, Diensten und Programmen.
Dieser Artikel beschreibt Inkompatibilitäten, die auftreten können, auf Client-Computern, die Windows XP oder eine frühere Version von Windows ausgeführt werden, wenn Sie bestimmte Sicherheitseinstellungen und Benutzerrechten in Windows Server 2003-Domäne oder einer früheren Windows Server-Domäne ändern.
Informationen über Group Policy für Windows 7, Windows Server 2008 R2 und Windows Server 2008 finden Sie unter die folgenden Artikeln:
Um das Bewusstsein für falsch konfigurierte Sicherheitseinstellungen zu erhöhen, verwenden Sie das Gruppenrichtlinienobjekt-Editor-Tool Sicherheitseinstellungen ändern. Wenn Sie den Gruppenrichtlinienobjekt-Editor verwenden, sind Zuweisungen von Benutzerrechten unter den folgenden Betriebssystemen verbessert:
Windows XP Professional Servicepack 2 (SP2)
Windows Server 2003 Servicepack 1 (SP1)
Die verbesserte Funktion ist ein Dialogfeld, das einen Link zu diesem Artikel enthält. Das Dialogfeld wird angezeigt, wenn Sie eine Sicherheitseinstellung ändern oder eine Zuweisung von Benutzerrechten auf eine Einstellung, die geringere Kompatibilität bietet und ist stärker eingeschränkt. Wenn Sie die gleiche Sicherheit Einstellung oder Benutzerrechte direkt mithilfe der Registrierungs oder mithilfe von Sicherheitsvorlagen ändern, ist die Wirkung identisch mit die Einstellung im Gruppenrichtlinienobjekt-Editor ändern. Das Dialogfeld mit die Verknüpfung zu diesem Artikel wird jedoch nicht angezeigt.
Dieser Artikel enthält Beispiele für Clients, Programme und Vorgänge, die durch bestimmte Sicherheitseinstellungen oder Benutzerrechte betroffen sind. Die Beispiele sind jedoch nicht autorisierend für alle Microsoft-Betriebssysteme, für alle Fremdanbieter-Betriebssysteme oder für alle Programmversionen, die betroffen sind. In diesem Artikel sind nicht alle Sicherheitseinstellungen und Benutzerrechten enthalten.
Es wird empfohlen, dass die Kompatibilität aller sicherheitsbezogenen Konfigurationsänderungen in einer Testgesamtstruktur überprüfen, bevor Sie sie in einer Produktionsumgebung einführen. Der Testgesamtstruktur muss die Produktionsgesamtstruktur auf folgende Weise widerspiegeln:
Client und Server-Betriebssystemversionen, Client und
Serverprogramme, Service Pack-Versionen, Hotfixes, Schemaänderungen, Sicherheit
Gruppen, Gruppenmitgliedschaften, Berechtigungen für Objekte in das Dateisystem freigegeben
Ordner, die Registrierung, Active Directory-Verzeichnisdienst, lokale und Gruppenrichtlinien
Richtlinieneinstellungen, Objektanzahl,-Typ und Speicherort
Verwaltungsaufgaben durchgeführt: administrative
Tools, die verwendet werden und Betriebssystemen, die zur Durchführung
Verwaltungsaufgaben
Operationen, die durchgeführt werden, wie die folgende:
Computer und Benutzeranmeldeauthentifizierung
Das Zurücksetzen von Kennwörtern von Benutzern, Computern und Administratoren
Durchsuchen
Festlegen von Berechtigungen für das Dateisystem, freigegebene für Ordner, für die Registrierung und für Active Directory-Ressourcen mit ACL-Editor in allen Client-Betriebssystemen in allen Konto oder Ressourcendomänen alle Client-Betriebssysteme von allen Konto oder Ressourcendomänen
Aus administrativen und nicht administrative Konten drucken
Damit können Kunden bewusst, dass sie ein Benutzerrecht bearbeiten oder Sicherheitsoption, die sich negativ auf haben könnte Auswirkungen auf ihr Netzwerk, wurden zwei Warnmechanismen "gpedit.msc" hinzugefügt. Wenn Administratoren ein Benutzerrecht bearbeiten, die das gesamte Unternehmen beeinträchtigen können, sehen sie ein neues Symbol, das ein "ACHTUNG"-Zeichen ähnelt. Sie erhalten auch eine Warnmeldung angezeigt, die eine Verknüpfung zu Microsoft Knowledge Base-Artikel 823659 angezeigt hat. Der Text dieser Meldung lautet wie folgt:
Das Ändern dieser Einstellung kann die Kompatibilität mit Clients, Diensten und Anwendungen auswirken. Weitere Informationen finden Sie unter <user right="" or="" security="" option="" being="" modified="">(Q823659)</user>
Wenn Sie über einen Link in Gpedit.msc zu diesem Knowledge Base-Artikel weitergeleitet wurden, stellen Sie sicher, dass Sie lesen und Verstehen der Begründung und die möglichen Auswirkungen einer Änderung dieser Einstellung. Die folgende Liste enthält die Benutzerrechte, die Text den Warnung enthalten:
Auf diesen Computer vom Netzwerk aus
Lokal anmelden
Auslassen der durchsuchenden Überprüfung
Aktivieren von Computern und Users for trusted delegation
Die folgende Liste enthält Sicherheitsoptionen, die die Warnung und eine Popup-Meldung:
Domänenmitglied: Digital verschlüsseln Sie oder signieren Sie (immer) Daten des sicheren Kanals
Domänenmitglied: Erfordern starken (Windows 2000 oder höher) Sitzungsschlüssel
-Domänencontroller: Signaturanforderungen für LDAP-server
Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)
Netzwerkzugriff: Ermöglicht die anonyme Sid / Namensübersetzung
Netzwerkzugriff: Ermöglichen Sie anonyme Aufzählung von SAM-Konten und Freigaben nicht
Netzwerksicherheit: LAN Manager-Authentifizierungsebene
Überwachung: System Herunterfahren zu Protokollen der Sicherheitsüberprüfungen
Netzwerkzugriff: Signaturanforderungen für LDAP-Clients
Den folgenden Abschnitten werden Inkompatibilitäten, die auftreten können, wenn Sie bestimmte Einstellungen in Windows NT 4.0-Domänen, Windows 2000-Domänen und Windows Server 2003-Domänen ändern.
Die folgende Liste beschreibt ein Benutzerrecht, identifiziert der Konfigurationseinstellungen, die Probleme verursachen können beschreibt, warum Sie das Benutzerrecht anwenden sollten, und warum Sie möglicherweise das Benutzerrecht entfernen möchten, und enthält Beispiele für Kompatibilitätsprobleme, die auftreten können, wenn der Benutzer richtig konfiguriert ist.
Auf diesen Computer vom Netzwerk aus
Hintergrund
Die Möglichkeit zur Interaktion mit entfernten Windows-basierten Computern muss das Benutzerrecht auf diesen Computer vom Netzwerk aus . Diesen Netzwerkvorgängen zählen folgende:
Active Directory-Replikation zwischen Domänencontrollern in einer gemeinsamen Domäne oder Gesamtstruktur
Authentifizierungsanforderungen an Domänencontroller von Benutzern und von Computern
Zugriff auf freigegebene Ordner, Drucker und andere Systemdienste, die auf remote-Computern im Netzwerk befinden
Benutzern, Computern und Dienstkonten gewinnen oder verlieren das Benutzerrecht auf diesen Computer vom Netzwerk explizit oder implizit hinzugefügt oder aus einer Sicherheitsgruppe, die dieses Benutzerrecht gewährt wurde. Z. B. ein Benutzerkonto oder ein Computerkonto kann explizit hinzugefügt werden eine benutzerdefinierte Sicherheitsgruppe oder einer vordefinierten Sicherheitsgruppe von einem Administrator oder implizit zugesetzt werden vom Betriebssystem vordefinierten Sicherheitsgruppe wie Domänenbenutzer, authentifizierte Benutzer oder Domänencontroller der Organisation.
Standardmäßig, Benutzerkonten und Computerkonten erhalten den Benutzer auf diesen Computer vom Netzwerk Recht, wenn berechnete Gruppen wie jeder oder, vorzugsweise, authentifizierte Benutzer und für Domänencontroller, die Gruppe Domänencontroller der Organisation in der Standard-Domänencontroller (Group Policy Object, GPO) definiert sind.
Risikoreiche Konfigurationen
Im folgenden werden die schädigende Konfigurationseinstellungen:
Entfernen die Sicherheit der Domänencontroller der Organisation
aus diesem Benutzerrecht
Entfernen die Gruppe Authentifizierte Benutzer oder eine
explizite Gruppe, die Benutzern, Computern und Dienstkonten den Benutzer ermöglicht
rechts über das Netzwerk eine Verbindung zu Computern
Entfernen alle Benutzer und Computer von diesem Benutzer
rechts
Gründe zum Gewähren dieses Benutzerrechts
Erteilen das Benutzerrecht auf diesen Computer vom Netzwerk aus der Gruppe der Unternehmensdomänencontroller erfüllt Authentifizierungsanforderungen, die Active Directory-Replikation für die Replikation zwischen Domänencontrollern in derselben Gesamtstruktur auftreten.
Dieses Benutzerrecht ermöglicht Benutzern und Computern
Zugriff auf freigegebene Dateien, Drucker und Systemdienste, darunter auch aktiv
Verzeichnis.
Dieses Benutzerrecht ist erforderlich, damit Benutzer zugreifen
e-Mail mit frühe Versionen von Microsoft Outlook Web Access (OWA).
Gründe für das Entfernen dieses Benutzerrechts
Benutzer, die ihren Computer zu verbinden, können die
somit Berechtigungen verfügen, kann Netzwerk Ressourcen auf Remotecomputern zugreifen
für. Dieses Benutzerrecht ist beispielsweise für einen Benutzer zum Zugreifen auf freigegebene erforderlich
Drucker und Ordner. Wenn dieses Benutzerrecht, jeder gewährt wird Gruppe
und wenn einige freigegebene Ordner sowohl Freigabe-als auch NTFS-Dateisystemberechtigungen
so konfiguriert, dass die gleiche Gruppe Lesezugriff hat, kann alle Dateien anzeigen
Diese freigegebenen Ordner. Dies ist jedoch eine unwahrscheinliche Situation für frische
Installationen von Windows Server 2003 da die standardmäßigen Freigabe- und NTFS
Berechtigungen in Windows Server 2003 enthalten nicht die Gruppe "Jeder". Für
Systeme, die von Microsoft Windows NT 4.0 oder Windows 2000 aktualisiert werden dies
Sicherheitsanfälligkeit möglicherweise ein höheres Risiko, da der Standardwert verwenden und die
Dateisystem-Berechtigungen für diese Betriebssysteme sind nicht so restriktiv wie
die Standardberechtigungen in Windows Server 2003.
Es gibt keinen Grund für das Entfernen von Enterprise
Gruppe der Domäne-Controller aus diesem Benutzerrecht.
Die Gruppe "Jeder" wird im Allgemeinen zu Gunsten von entfernt.
die Gruppe Authentifizierte Benutzer. Wenn die Gruppe "Jeder" entfernt wird, die
Gruppe "Authentifizierte Benutzer" muss dieses Benutzerrecht gewährt werden.
Windows NT 4.0-Domänen, die auf Windows 2000 aktualisiert werden gewährt den Benutzer auf diesen Computer vom Netzwerk nicht explizit Recht auf die Gruppe "Jeder", die Gruppe Authentifizierte Benutzer oder die Gruppe Domänencontroller der Organisation. Daher beim Entfernen der Gruppe "Jeder" aus Windows NT 4.0-Domänenrichtlinie, Active Directory-Replikation schlägt fehl mit Fehlermeldung "Zugriff verweigert" nach der Aktualisierung auf Windows 2000. Winnt32.exe in Windows Server 2003 vermeidet diese Fehlkonfiguration, indem gewährt wird, Domänencontroller der Organisation Gruppe dieses Benutzerrecht während der Aktualisierung von Windows NT 4.0 primären Domänencontroller (PDCs). Gewähren Sie der Gruppe der Unternehmensdomänencontroller dieses Benutzerrecht, wenn er nicht im Gruppenrichtlinienobjekt-Editor vorhanden ist.
Beispiele für Kompatibilitätsprobleme
Windows 2000 und WindowsServer 2003: Replikation die folgenden Partitionen wird mit Fehler "Zugriff verweigert" fehl Überwachungs-Tools wie REPLMON und REPADMIN oder Replikation Ereignisse im Ereignisprotokoll.
Active Directory-Schema-partition
Konfigurationspartition
Domänenpartition
Partition des globalen Katalogs
Anwendungspartition
Alle Microsoft-Netzwerkbetriebssysteme:Die Benutzerkonto-Authentifizierung von remote-Netzwerk-Client-Computern schlägt fehl, wenn der Benutzer oder eine Sicherheitsgruppe, der der Benutzer Mitglied ist dieses Benutzerrecht gewährt wurde.
Alle Microsoft-Netzwerkbetriebssysteme:Kontoauthentifizierung von remote-Netzwerkclients schlägt fehl, es sei denn, das Konto oder Sicherheitsgruppe, der das Konto angehört, dieses Benutzerrecht nicht gewährt wurde. Dieses Szenario betrifft Benutzerkonten, Computerkonten und Dienstkonten.
Alle Microsoft-Netzwerkbetriebssysteme:Entfernen alle Benutzerkonten aus diesem Benutzerrecht wird jedes Konto Anmelden an der Domäne oder den Zugriff auf Netzwerkressourcen verhindern. Wenn Gruppen wie Domänencontroller der Organisation berechnet werden, müssen jeder oder authentifizierte Benutzer entfernt werden, Sie explizit gewähren dieses Benutzerrecht Konten- bzw. Sicherheitsgruppen, denen das Konto ein Mitglied ist, auf Remotecomputern über das Netzwerk zugreifen. Dieses Szenario gilt für alle Benutzerkonten, Computerkonten und Dienstkonten.
Alle Microsoft-Netzwerkbetriebssysteme:Das lokale Administratorkonto verwendet ein "leeres" Kennwort. Netzwerkverbindungen mit leeren Kennwörtern ist für Administratorkonten in einer Domänenumgebung nicht zulässig. Mit dieser Konfiguration können Sie erwarten, eine Fehlermeldung "Zugriff verweigert" angezeigt.
Lokal anmelden zulassen
Hintergrund
Benutzer, die an der Konsole eines Windows-basierten Computers (mithilfe der Tastenkombination STRG + ALT + ENTF) anmelden und Konten, die versuchen, einen Dienst starten müssen lokale Anmeldeberechtigungen auf dem Host-Computer verfügen. Beispiele für lokale Anmeldevorgänge sind Administratoren, die auf den Konsolen von Mitgliedscomputern oder Domänencontrollern im gesamten Unternehmen und Domäne-Benutzer anmelden, die Mitgliedscomputer auf ihren Desktops mit nicht-privilegierte Konten anmelden. Benutzer, die eine Remotedesktopverbindung oder Terminal Services verwenden müssen der Benutzer Lokal anmelden zulassen auf Zielcomputern verfügen, auf denen Windows 2000 ausgeführt werden
oder Windows XP
Da diese Anmeldemodi als lokal auf dem Host-Computer betrachtet werden. Benutzer
die sind Anmelden an einen Server, der Terminal Server aktiviert wurde und wer nicht
haben Sie diesen Benutzer direkt eine interaktive Remotesitzung in Windows noch starten können
Server 2003-Domänen haben das Benutzerrecht Anmelden über Terminaldienste zulassen .
Risikoreiche Konfigurationen
Im folgenden werden die schädigende Konfigurationseinstellungen:
Entfernen von administrativen Sicherheitsgruppen, darunter Kontenoperatoren, Sicherungsoperatoren, Druckoperatoren oder Server-Operatoren, und der integrierten Administratorgruppe aus der Standarddomänencontroller Richtlinie.
Entfernen von Dienstkonten, die von Komponenten und Programmen auf Mitgliedscomputern und Domänencontrollern in der Domäne aus der Standarddomänencontroller Richtlinie verwendet werden.
Entfernen von Benutzern oder Sicherheitsgruppen, die sich anmelden
die Konsole von Mitgliedscomputern in der Domäne.
Entfernen von Dienstkonten, die in der lokalen Sicherheitskontenverwaltung (Security Accounts Manager, SAM)-Datenbank von Mitgliedscomputern oder Arbeitsgruppencomputern definiert sind.
Entfernen von nicht-integrierten Administratorkonten, die sich über die Terminaldienste authentifizieren, die auf einem Domänencontroller ausgeführt wird.
Alle Benutzerkonten hinzufügen explizit in der Domäne
oder implizit über jeder Gruppe, das Anmelderecht Lokal anmelden verweigern . Diese Konfiguration hat, dass Benutzer nicht anmelden
bei beliebigen Mitgliedscomputern oder zu einem beliebigen Domänencontroller in der Domäne.
Gründe zum Gewähren dieses Benutzerrechts
Benutzer müssen das Benutzerrecht Lokal anmelden zulassen auf der Konsole oder den Desktop in einer Arbeitsgruppe
Computer, eines Mitgliedscomputers oder eines Domänencontrollers.
Benutzer müssen dieses Benutzerrecht Anmeldung über Terminaldienste-Sitzung, die auf eine Windows 2000-Mitgliedscomputer oder-Domänencontroller ausgeführt wird.
Gründe für das Entfernen dieses Benutzerrechts
Fehler beim Zugriff auf die Konsole auf legitime beschränken
Benutzerkonten möglicherweise nicht autorisierte Benutzer herunterladen und ausführen
bösartiger Code Berechtigungen ändern.
Entfernen des Benutzerrechts Lokal anmelden zulassen wird verhindert, dass unberechtigte Anmeldung auf Konsolen von
Computer, wie beispielsweise Domänencontrollern oder Anwendungsservern.
Zum Entfernen dieses Anmelderechts wird verhindert, dass nicht-Domänen
Konten anmelden an der Konsole von Mitgliedscomputern in der
Domäne.
Beispiele für Kompatibilitätsprobleme
Windows 2000 terminal Servern:Das Benutzerrecht Lokal anmelden zulassen ist für Benutzer zur Anmeldung an Windows 2000 erforderlich
Terminal Server.
Windows NT 4.0, Windows 2000, Windows XP oder WindowsServer 2003:Benutzerkonten müssen dieses Benutzerrecht auf der Konsole von Computern anmelden, auf dem Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden gewährt werden.
Windows NT 4.0 und höher:Auf Computern, die Windows NT 4.0 ausführen und später, wenn Sie das Benutzerrecht Lokal anmelden zulassen jedoch implizit oder explizit hinzufügen auch die Berechtigung Lokale Anmeldung verweigern -Anmeldung, die Konten können nicht für die Anmeldung der
die Konsole der Domänencontroller.
Auslassen der durchsuchenden Überprüfung
Hintergrund
Das Benutzerrecht Wechselprüfung umgehen kann der Benutzer am NTFS-Ordner durchsuchen
file System oder in der Registrierung ohne Überprüfung der besonderen Zugriffsberechtigung Ordner durchsuchen . Das Benutzerrecht Wechselprüfung umgehen lässt nicht den Benutzer den Inhalt eines Ordners auflistet. Es ermöglicht dem Benutzer nur die Ordner durchlaufen.
Risikoreiche Konfigurationen
Im folgenden werden die schädigende Konfigurationseinstellungen:
Entfernen von nicht-Administratorkonten, die auf Windows 2000-basierte Terminaldienste-Computer oder Windows Server 2003-basierten Terminaldienste-Computer, auf denen Zugriffsberechtigungen für Dateien und Ordner im Dateisystem nicht anmelden.
Entfernen der Gruppe "Jeder" aus der Liste der Sicherheitsprinzipale, die dieser Benutzer standardmäßig rechts haben. Windows-Betriebssysteme und viele andere Programme, sind in der Annahme konzipiert, dass Personen, die legitimen den Computer Zugang zu das Benutzerrecht Wechselprüfung umgehen . Daher konnte entfernen jeder Gruppe aus der Liste der Sicherheitsprinzipale, die standardmäßig dieses Benutzerrecht verfügen zu einer Instabilität des Betriebssystems oder einem Programmfehler führen. Es empfiehlt sich, dass Sie diese Einstellung in der Standardeinstellung lassen.
Gründe zum Gewähren dieses Benutzerrechts
Die Standardeinstellung für das Benutzerrecht Wechselprüfung umgehen soll erlaubt es allen Benutzern Wechselprüfung umgehen. Für
erfahrene Windows-Systemadministratoren, dies ist das erwartete Verhalten und
Sie haben Datei Systemzugriffssteuerungslisten (SACLs) entsprechend konfigurieren. Die einzige
Szenario, in denen die Standardkonfiguration zu Missverständnissen führen kann, ist Wenn die
Konfiguration von Berechtigungen Administrator das Verhalten nicht verstehen und
erwartet, dass Benutzer, die einen übergeordneten Ordner zugreifen können nicht zugreifen kann
der Inhalt von untergeordneten Ordnern.
Gründe für das Entfernen dieses Benutzerrechts
Um zu versuchen, Zugriff auf die Dateien oder Ordner im Dateisystem zu verhindern, können Organisationen, die Sicherheit sehr besorgt sind versucht sein, Entfernen der Gruppe "Jeder" oder sogar die Gruppe Benutzer aus der Liste der Gruppen, die das Benutzerrecht Wechselprüfung umgehen .
Beispiele für Kompatibilitätsprobleme
Windows 2000, WindowsServer 2003:Wenn das Benutzerrecht Wechselprüfung umgehen entfernt wird oder auf Computern, die sind falsch konfiguriert ist
Ausführen von Windows 2000 oder Windows Server 2003 Gruppenrichtlinien Einstellungen in der SYVOL
Ordner werden nicht zwischen Domänencontrollern in der Domäne repliziert.
Windows 2000, Windows XP Professional, WindowsServer 2003:Computer mit Windows 2000, Windows XP Professional oder Windows Server 2003 protokolliert Ereignisse 1000 und 1202 und werden nicht Computerrichtlinie und Benutzerrichtlinie anwenden, wenn die erforderliche Dateisystemberechtigungen aus der SYSVOL-Struktur entfernt werden, wenn die Bypass Traverse Benutzerrechts entfernt wird oder falsch konfiguriert wird.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Ereignis-IDs 1000 und 1001 wird alle fünf Minuten im Anwendungsprotokoll protokolliert.
Windows 2000, WindowsServer 2003: Auf Computern mit Windows 2000 oder Windows Server
2003, die Kontingent Registerkarte in Windows Explorer, verschwinden beim
Sie können Eigenschaften für ein Volume anzeigen.
Windows 2000: Nicht-Administratoren, die mit einem Windows 2000-Terminalserver anmelden.
Sie erhalten die folgende Fehlermeldung angezeigt:
"Userinit.exe"
Anwendungsfehler. Die Anwendung konnte nicht ordnungsgemäß werden (0xc0000022)
Klicken Sie auf OK, um die Anwendung zu beenden.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Benutzer werden automatisch abgemeldet, wenn Terminaldienste anmelden wollen
Windows NT 4.0, Windows 2000, Windows XP, WindowsServer 2003:Benutzer, deren Computer Windows NT 4.0, Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden, möglicherweise nicht auf freigegebene Ordner oder Dateien in freigegebenen Ordnern zugreifen und sie erhalten Fehlermeldungen "Zugriff verweigert", wenn sie nicht das Benutzerrecht Wechselprüfung umgehen gewährt werden.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
"Zugriff verweigert" Fehlermeldung, wenn Benutzer versuchen, freigegebene Ordner zugreifen
Windows NT 4.0:Auf Windows NT 4.0-basierten Computern wird Entfernen des Benutzerrechts Wechselprüfung umgehen dazu führen, dass eine Dateikopie zu Dateistreams bei Dateikopiervorgängen. Wenn Sie
Dieses Benutzerrecht entfernen, beim Kopieren einer Datei von einem Windows-Client oder von einem
Macintosh-Client auf einem Windows NT 4.0-Domänencontroller, der Services ausgeführt wird
für Macintosh, der Ziel-Dateistream verloren und die Datei wird als ein
Nur-Text-Datei.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Entfernen von "Wechselprüfung umgehen" bewirkt, dass Dateistreams bei Dateikopiervorgängen kopieren
Microsoft Windows 95, Microsoft Windows 98:Auf einem Clientcomputer, auf denen Windows 95 oder Windows 98 ausgeführt wird die NET Use * / home Befehl schlägt fehl mit "Zugriff
Gewährt, verweigert"Fehlermeldung, wenn die Gruppe Authentifizierte Benutzer nicht ist das Benutzerrecht Wechselprüfung umgehen .
Outlook Web Access:Nicht-Administratoren werden nicht an Microsoft Outlook Web Access anmelden, und sie erhalten eine Fehlermeldung "Zugriff verweigert", wenn sie nicht das Benutzerrecht Wechselprüfung umgehen gewährt werden.
Die folgende Liste enthält eine Sicherheitseinstellung, und die verschachtelte Liste bietet eine Beschreibung der Sicherheitseinstellung, die Konfigurationseinstellungen, die möglicherweise Probleme verursachen, die beschreibt, warum die Sicherheitseinstellung angewendet werden soll und dann beschreibt Gründe, warum Sie die Sicherheitseinstellung entfernen möchten. Die verschachtelte Liste bietet dann einen symbolischen Name für die Sicherheit und der Pfad der Sicherheitseinstellung. Schließlich werden Beispiele für Kompatibilitätsprobleme bereitgestellt, die auftreten können, wenn die Sicherheitseinstellung konfiguriert ist.
Überwachung: System Herunterfahren zu Protokollen der Sicherheitsüberprüfungen
Hintergrund
Die Audit: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen legt fest, ob das System heruntergefahren wird, wenn Sie Sicherheitsereignisse protokollieren können. Diese Einstellung ist erforderlich für das Trusted Computer Security Evaluation Kriterien (TCSEC) Programm C2-Überprüfung und Common Criteria for Information Technology Security Evaluation überwachbare Ereignisse zu verhindern, wenn das System diese Ereignisse nicht protokollieren kann. Wenn Überwachungssystem auftritt, das System heruntergefahren und eine Stop-Fehlermeldung wird angezeigt.
Wenn der Computer Ereignisse aufgezeichnet werden kann die
Sicherheitsprotokoll, wichtige Beweise oder Problembehandlungsinformationen kann
nach einem Sicherheitsvorfall wird nicht zur Prüfung verfügbar sein.
Risikoreiche Konfiguration
Im folgenden ist eine schädliche Konfigurationseinstellung: die Audit: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen Einstellung aktiviert ist, und die Größe des Sicherheitsprotokolls ist beschränkt durch die Option nicht überschreiben (Protokoll manuell löschen) Ereignisse , die Option Ereignisse bei Bedarf überschreiben oder die Ereignisse, die älter sind als überschreiben Anzahl Tage Option in der Ereignisanzeige. Finden Sie unter "Beispiele für Kompatibilität
Abschnitt "Probleme mit Informationen zu bestimmten Risiken für Computer mit
die ursprüngliche Version von Windows 2000, Windows 2000-Dienst ausführen
Pack 1 (SP1), Windows 2000 SP2 oder Windows 2000 SP3.
Gründe zum Aktivieren dieser Einstellung
Wenn der Computer Ereignisse im Sicherheitsprotokoll aufgezeichnet werden kann, möglicherweise wichtige Beweise oder Problembehandlungsinformationen zur Prüfung nach einem Sicherheitsvorfall nicht verfügbar.
Gründe für diese Einstellung deaktivieren
Aktivieren der überwachen: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen Einstellung wird das System aus irgendeinem protokolliert werden können
aus irgendeinem Grund. In der Regel kann kein Ereignis protokolliert werden, wenn das Sicherheitsprotokoll ist
vollständige und wann wird die Aufbewahrungsmethode entweder die Option nicht überschreiben (Protokoll manuell löschen) Ereignisse oder die Ereignisse, die älter sind als überschreiben Anzahl Tage Option.
Der Verwaltungsaufwand bei Aktivierung der Audit: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen Einstellung ist sehr hoch, insbesondere dann, wenn Sie auch die Option nicht überschreiben (Protokoll manuell löschen) Ereignisse im Sicherheitsprotokoll aktivieren. Diese Einstellung bietet Einzelerfassung der Benutzeraktionen. Beispielsweise könnte ein Administrator Berechtigungen für alle Benutzer, Computer und Gruppen in einer Organisationseinheit (OU), in denen die Überwachung aktiviert wurde mithilfe des integrierten Administratorkontos oder anderes freigegebenes Konto, zurücksetzen und verweigern Sie anschließend, dass sie diese Berechtigungen zurückgesetzt. Ermöglicht das festlegen wird jedoch die Stabilität des Systems reduziert, da ein Server durch überfluten mit Anmeldeereignissen und anderen Sicherheitsereignissen, die in das Sicherheitsprotokoll geschrieben werden Herunterfahren gezwungen werden kann. Darüber hinaus, da das Herunterfahren nicht ordnungsgemäß erfolgt, kann irreparable Schäden am Betriebssystem, Programme oder Daten führen. Während NTFS garantiert, dass das Dateisystem Integrität während einem unvermittelten Herunterfahren gewährleistet ist, können sie garantieren, dass jede Datendatei für jedes Programm noch eine nutzbare Form beim Neustart des Systems werden.
Windows 2000:Aufgrund eines Fehlers beenden Computer, die die ursprüngliche Version von Windows 2000, Windows 2000 SP1, Windows 2000 SP2 oder Windows Server SP3 ausgeführt werden, die Protokollierung von Ereignissen, bevor die in der Option Maximale Protokollgröße für das Sicherheitsereignisprotokoll angegeben ist erreicht wird. Dieser Fehler ist behoben.
in Windows 2000 Service Pack 4 (SP4). Stellen Sie sicher, dass Windows 2000-Domäne
Prüfer müssen Windows 2000 Service Pack 4 installiert werden, bevor Sie in Erwägung ziehen
Durch Aktivieren dieser Einstellung.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Das Ereignisprotokoll beendet die Protokollierung von Ereignissen vor dem Erreichen der maximalen Protokollgröße
Windows 2000, WindowsServer 2003:Computer, auf denen Windows 2000 oder Windows Server 2003 ausgeführt werden können.
reagiert, und starten anschließend spontan neu, wenn die Audit: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen Einstellung ist aktiviert, das Sicherheitsprotokoll voll ist und ein vorhandener Ereignisprotokolleintrag nicht überschrieben werden kann. Beim Neustart des Computers wird die folgende Stop-Fehlermeldung angezeigt:
STOP: C0000244
{Überwachung fehlgeschlagen} Generierung einer Sicherheitsüberwachung ist fehlgeschlagen.
Zum Wiederherstellen muss ein Administrator anmelden, das Sicherheitsprotokoll (optional), archivieren
das Sicherheitsprotokoll löschen und anschließend diese Option (optional und bei Bedarf) zurücksetzen.
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 versuchen, zu einer Domäne anzumelden erhalten die
folgende Fehlermeldung angezeigt:
Ihr Konto ist, konfiguriert.
verhindern Sie, dass Sie diesen Computer verwenden. Bitte versuchen Sie einen anderen
Computer.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Fehlermeldung: Benutzer können auf einer Arbeitsstation anmelden
Windows 2000:Auf Windows 2000-basierten Computern nicht-Administratoren können nicht an RAS-Server anmelden, und sie erhalten eine Fehlermeldung, die der folgenden ähnelt:
Unbekannter Benutzer oder schlecht
Kennwort
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Fehlermeldung: Ihr Konto ist konfiguriert, um zu verhindern, dass Sie diesen Computer verwenden
Windows 2000:Auf Windows 2000-Domänencontrollern Intersite Messaging-Dienst (Ismserv.exe) beendet und kann nicht neu gestartet werden. DCDIAG meldet den Fehler "Failed testservices ISMserv", und Ereignis-ID 1083 wird im Ereignisprotokoll registriert.
Windows 2000:Windows 2000-Domänencontroller Active Directory-Replikation schlägt fehl und eine Meldung "Zugriff verweigert" wird angezeigt, wenn das Sicherheitsereignisprotokoll voll ist.
Microsoft Exchange 2000:Server, auf denen Exchange 2000 ist nicht möglich, die Informationsspeicher-Datenbank bereitzustellen, und Ereignis 2102 wird im Ereignisprotokoll registriert.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Exchange 2000-Fehlermeldungen werden wegen der SeSecurityPrivilege-Berechtigung und Policytest Probleme generiert.
Outlook, Outlook Web Access: Nicht-Administratoren werden nicht auf ihre e-Mail-Nachrichten über zugreifen
Microsoft Outlook oder Microsoft Outlook Web Access, und sie werden
die Fehlermeldung 503.
Domänencontroller: Signaturanforderungen für LDAP-Server
Hintergrund
Die -Domänencontroller: Signaturanforderungen für LDAP-Server Sicherheitseinstellung wird bestimmt, ob der Lightweight Directory Access Protocol (LDAP) Server LDAP-Clients Datensignaturen erfordert. Die möglichen Werte für diese Richtlinieneinstellung sind wie folgt:
Keine: Signieren von Daten ist nicht erforderlich, um mit dem Server zu binden. Wenn die
Client fordert Daten signieren, unterstützt der Server es.
Signatur erforderlich: Die LDAP-Datensignatur Option muss verhandelt werden, es sei denn, Transport
Layer Security/Secure Socket Layer (TLS/SSL) wird verwendet.
nicht definiert: Diese Einstellung ist nicht aktiviert oder deaktiviert.
Risikoreiche Konfigurationen
Im folgenden werden die schädigende Konfigurationseinstellungen:
In Umgebungen, in denen Clients keine LDAP-Signierung unterstützen, aktivieren Signatur erforderlich oder
wo clientseitige LDAP-Signierung auf dem Client nicht aktiviert ist
Anwenden der Windows 2000 oder WindowsServer
2003 Sicherheitsvorlage "Hisecdc.inf" in Umgebungen, in denen die Clients nicht
LDAP-Signatur unterstützen oder wenn clientseitige LDAP-Signierung nicht
Aktiviert
Anwenden der Windows 2000 oder WindowsServer
2003 Sicherheitsvorlage "Hisecws.inf" in Umgebungen, in denen die Clients nicht
LDAP-Signatur unterstützen oder wenn clientseitige LDAP-Signierung nicht
Aktiviert
Gründe zum Aktivieren dieser Einstellung
Nicht signierter Netzwerkverkehr ist anfällig für Man-in-the-Middle-Angriffe, in denen ein Eindringling Pakete zwischen dem 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 beliebigen einen Server, um Entscheidungen zu treffen, die auf falschen Abfragen vom LDAP-Client basieren. Sie können dieses Risiko in einem Unternehmensnetzwerk senken, indem Sie strenge physische Sicherheitsmaßnahmen zum Schutz die Netzwerkinfrastruktur implementieren. Internet Protocol Security (IPSec) Header-Authentifizierungsmodus können Man-in-the-Middle-Angriffe zu verhindern. Header-Authentifizierungsmodus führt die gegenseitige Authentifizierung und Integrität für IP-Verkehr.
Gründe für diese Einstellung deaktivieren
Clients, die LDAP-Signierung nicht unterstützen, wird nicht
werden Sie durchführen von LDAP-Abfragen gegen die Domänencontroller und globalen
katalogisiert, wenn NTLM-Authentifizierung ausgehandelt wird und die richtige Service packs
sind nicht auf Windows 2000-Domänencontrollern installiert werden.
Die Netzwerkablaufverfolgung des LDAP-Datenverkehrs zwischen Clients und Servern werden verschlüsselt. Dies erschwert das LDAP-Kommunikationen.
Windows 2000-basierten Servern muss Windows 2000 Service Pack 3 (SP3) oder installiert, wenn sie mit Programmen, ausgeführt von Client-Computern, auf denen Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt werden Unterstützung für LDAP-Signierung, die verwaltet werden. Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Windows 2000 Service Pack 4, Windows XP, WindowsServer 2003:Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt werden, funktionieren einige Active Directory-Verwaltungsprogramme nicht ordnungsgemäß für Domänencontroller, die Versionen von Windows 2000 ausgeführt werden, die sind vor Service Pack 3, während die NTLM-Authentifizierung ausgehandelt wird.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Windows 2000-Domänencontroller benötigen Servicepack 3 oder höher bei Einsatz der Windows Server 2003-Verwaltungsprogramme
Windows 2000 Service Pack 4, Windows XP, WindowsServer 2003:Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 ausgeführt werden, sind einige Active Directory-Verwaltungstools, die als Ziel-Domänencontroller, auf denen Versionen von Windows 2000 vor SP3 nicht korrekt ausgeführt wird, wenn sie IP-Adressen verwenden (z. B. "dsa.msc/Server =x.x.x.x"wo x.x.x.x ist eine IP-Adresse).
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Windows 2000-Domänencontroller benötigen Servicepack 3 oder höher bei Einsatz der Windows Server 2003-Verwaltungsprogramme
Windows 2000 Service Pack 4, Windows XP, WindowsServer 2003:Auf Clients, die Windows 2000 SP4, Windows XP oder Windows Server 2003 einige Active Directory-Verwaltungstools, abzielen sind Domänencontroller, auf denen Versionen von Windows 2000 vor SP3 nicht korrekt funktioniert.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Windows 2000-Domänencontroller benötigen Servicepack 3 oder höher bei Einsatz der Windows Server 2003-Verwaltungsprogramme
Domänenmitglied: Starker Sitzungsschlüssel für (Windows 2000 oder höher) erforderlich
Hintergrund
Die Domänenmitglied: Starker Sitzungsschlüssel für (Windows 2000 oder höher) erforderlich wird festgelegt, ob ein sicherer Kanal hergestellt werden kann
mit einem Domänencontroller, die sichere mit Kanalverkehr verwendet ein
starken 128-Bit-Sitzungsschlüssel. Durch Aktivieren dieser Einstellung wird verhindert, dass zur Gründung einer
sicheren Kanal zu einem Domänencontroller, der sicheren Kanal Kanalverkehr verwendet
Daten mit einem starken Schlüssel. Durch Deaktivieren dieser Einstellung kann 64-Bit-Sitzungsschlüssel.
Bevor Sie diese Einstellung auf ein Element aktivieren können
Workstation oder auf einem Server, alle Domänencontroller in der Domäne, die
Element gehört, muss Daten des sicheren Kanals mit einem starken verschlüsseln
128-Bit-Schlüssel. Dies bedeutet, dass diese Domänencontroller ausgeführt werden muss
Windows 2000 oder höher.
Risikoreiche Konfiguration
Aktivieren der Domänenmitglied: Starker Sitzungsschlüssel für (Windows 2000 oder höher) erforderlich Einstellung ist eine schädliche Konfigurationseinstellung.
Gründe zum Aktivieren dieser Einstellung
Sitzungsschlüssel, mit denen sichere einrichten
Kommunikationskanal zwischen den Mitgliedscomputern und Domänencontrollern sind viel
in Windows 2000 stärker als in früheren Versionen von Microsoft sind
Betriebssysteme.
Wenn es möglich ist, ist es eine gute Idee, nutzen diese stärkeren Sitzungsschlüssel zu Kommunikation über sichere Kanäle vor Lauschangriffen und Session hijacking-Netzwerkangriffen zu schützen. Lauschangriffe ist eine Form des Angriffs, bei denen Netzwerkdaten gelesen werden oder
Bei der Übertragung geändert. Die Daten können geändert werden, ausblenden oder ändern den Absender,
oder umgeleitet.
Wichtig Ein Computer mit Windows Server 2008 R2 oder Windows 7 unterstützt nur starke Schlüssel, wenn sichere Kanäle verwendet werden. Diese Einschränkung verhindert, dass eine Vertrauensstellung zwischen jeder Windows NT 4.0-Domäne und alle Windows Server 2008 R2-basierten Domäne. Darüber hinaus diese Einschränkung blockiert die Windows NT 4.0-basierten Domänenmitgliedschaft von Computern mit Windows 7 oder Windows Server 2008 R2 und umgekehrt.
Gründe für diese Einstellung deaktivieren
Die Domäne enthält Mitgliedscomputer, die anderen Betriebssystemen als Windows 2000, Windows XP oder Windows Server 2003 ausgeführt werden.
Windows NT 4.0:Auf Windows NT 4.0-basierten Computern tritt beim Zurücksetzen der sicheren Kanäle von Vertrauensstellungen zwischen Windows NT 4.0 und Windows 2000-Domänen mit NLTEST. Fehlermeldung "Zugriff verweigert" wird angezeigt:
Die Vertrauensstellung
Beziehung zwischen der primären Domäne und der vertrauenswürdigen Domäne
ist fehlgeschlagen.
Windows 7 und Server 2008 R2:Für Windows 7 und späteren Versionen und Windows Server 2008 R2 und höher wird diese Einstellung nicht mehr berücksichtigt, und der starke Schlüssel wird immer verwendet. Aus diesem Grund funktionieren Vertrauensstellungen mit Windows NT 4.0-Domänen nicht mehr.
Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals
Hintergrund
Aktivieren von Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals verhindert die Einrichtung eines sicheren Kanals zu einem Domänencontroller, die nicht signieren oder Verschlüsseln von Daten des sicheren Kanals. Um Authentifizierungsdatenverkehr vor Man-in-the-Middle-Angriffe, Replay-Angriffe und andere Arten von Netzwerkangriffen zu schützen, erstellen Windows-basierte Computer einen Kommunikationskanal, der als einen sicheren Kanal über den Anmeldedienst bezeichnet wird, um Computerkonten zu authentifizieren. Sichere Kanäle werden auch verwendet, wenn ein Benutzer in einer Domäne zu einer Netzwerkressource in einer Remotedomäne eine Verbindung herstellt. Diese Domänen Authentifizierung oder Pass-Through-Authentifizierung, ermöglicht einen Windows-basierten Computer, der eine Domäne haben
Greifen Sie auf die Benutzerkontodatenbank in seiner Domäne und in vertrauenswürdigen Domänen .
So aktivieren Sie die Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals Einstellung auf einem Mitgliedscomputer, alle Domänencontroller in der Domäne, die das Mitglied angehört muss zum Signieren oder Verschlüsseln von Daten des sicheren Kanals. Dies bedeutet, dass diese Domänencontroller Windows NT 4.0 mit Service Pack 6a ausgeführt werden müssen (SP6a) oder höher.
Aktivieren der Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals automatisch ermöglicht die Domänenmitglied: digital verschlüsseln oder Signieren von Daten des sicheren Kanals (wenn möglich) Einstellung.
Risikoreiche Konfiguration
Aktivieren der Domänenmitglied: digital verschlüsseln oder signieren (immer) Daten des sicheren Kanals in Domänen, in denen nicht alle Domänencontroller anmelden können, oder
Verschlüsseln von Daten des sicheren Kanals ist eine schädliche Konfigurationseinstellung.
Gründe zum Aktivieren dieser Einstellung
Nicht signierter Netzwerkverkehr ist anfällig für Man-in-the-Middle-Angriffe, in denen ein Eindringling Pakete zwischen dem Server und dem Client abfängt und modifiziert, bevor sie an dem Client weitergeleitet werden. Tritt dieses Verhalten auf einem Server (Lightweight Directory Access Protocol, LDAP), könnte der Angreifer einen Client Entscheidungen zu treffen, die auf falschen Datensätzen aus dem LDAP-Verzeichnis. Sie können das Risiko eines solchen Angriffs in einem Unternehmensnetzwerk senken, indem strenge physische Sicherheitsmaßnahmen zum Schutz die Netzwerkinfrastruktur. Darüber hinaus können Implementieren von Internet Protocol Security (IPSec) Header-Authentifizierungsmodus Man-in-the-Middle-Angriffe zu verhindern. In diesem Modus führt die gegenseitige Authentifizierung und Integrität für IP-Datenverkehr.
Gründe für diese Einstellung deaktivieren
Computer in lokalen oder externen Domänen unterstützen verschlüsselte sichere Kanäle.
Nicht alle Domänencontroller in der Domäne haben die
entsprechenden Service Packs installiert, unterstützen verschlüsselt sichere
Kanäle.
Fehlermeldung: das Konto ist nicht berechtigt, von dieser Arbeitsstation aus anzumelden
Windows NT 4.0:Windows NT 4.0-Domänen können nicht auf eine kompatible Vertrauensstellung mit einer Windows 2000-Domäne einrichten und erhalten die folgende Fehlermeldung angezeigt:
Das Konto darf nicht von diesem anmelden
Station.
Vorhandene untergeordnete Vertrauensstellungen authentifiziert Benutzer aus der vertrauenswürdigen Domäne möglicherweise auch nicht. Einige Benutzer möglicherweise Probleme beim Anmelden an der Domäne, und sie erhalten eine Fehlermeldung, die besagt, dass der Client die Domäne finden kann.
Windows XP:Windows XP-Clients, die Windows NT 4.0-Domänen angehören, werden keine Anmeldeversuche authentifizieren und möglicherweise die folgende Fehlermeldung angezeigt, oder möglicherweise die folgenden Ereignisse im Ereignisprotokoll registriert werden:
Es kann keine Verbindung zur Domäne entweder weil die
Domänencontroller ist ausgefallen oder nicht verfügbar ist oder weil Ihr Computer
Konto wurde nicht gefunden.
Ereignis
5723: Die Einrichtung einer Sitzung von Computer ComputerName Fehler beim authentifizieren. Der Name des Kontos, das in die Sicherheit
Datenbank ist ComputerName. Der folgende Fehler
ist aufgetreten: Zugriff verweigert.
3227-Ereignis: Die Einrichtung einer Sitzung auf dem Windows NT oder Windows
2000-Domänencontroller Servername für die Domäne Domain-Namen fehlgeschlagen: Server
Name unterstützt keine Signatur oder Abschluss der Sitzungs des Netzwerkanmeldedienstes.
Aktualisieren des Domänencontrollers, oder setzen des Registrierungseintrags "RequireSignOrSeal"
Dieser Computer auf 0.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Windows XP-Clients kann sich einer Windows NT 4.0-Domäne anmelden
Microsoft-Netzwerk:Microsoft Network-Clients erhalten eine der folgenden Fehlermeldungen angezeigt:
Anmeldefehler: Unbekannter Benutzername oder schlecht
Kennwort.
Es ist kein Benutzersitzungsschlüssel für die
angegebene Anmeldesitzung.
Microsoft-Netzwerkclient: Kommunikation digital signieren (immer)
Hintergrund
Server Message Block (SMB) ist die gemeinsame Nutzung von Ressourcen-Protokoll, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Grundlage für Network basic Input/Output System (NetBIOS) und viele andere Protokolle. SMB-Signatur authentifiziert den Benutzer und dem Server, der die Daten hostet. Wenn die beiden Seiten der Authentifizierungsprozess fehlschlägt, wird keine Datenübertragung statt.
Aktivieren von SMB-Signaturen beginnt während der Aushandlung der SMB-Protokoll. Die SMB-Signaturen-Richtlinien bestimmen, ob der Computer Client-Kommunikation immer digital signiert.
Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Gegenseitiger Authentifizierung schließt einen "Man-in-the-Middle"-Angriff. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft zu verhindern, dass Angriffe abgewehrt.
Um diese Authentifizierung zu erhalten, setzt die SMB-Signierung eine digitale Signatur in jeden SMB. Der Client und dem Server Überprüfen der digitalen Signatur.
Wenn SMB-Signierung verwenden möchten, müssen Sie Aktivieren von SMB-Signaturen oder SMB-Signierung auf SMB-Client und der SMB-Server erfordern.
Wenn SMB-Signierung auf einem Server, Clients, die SMB aktiviert ist-Signierung verwenden bei allen nachfolgenden Sitzungen das Paketsignierungsprotokoll auch aktiviert sind.
Wenn SMB-Signierung auf einem Server erforderlich ist, kann kein Client eine Sitzung herstellen, es sei denn, der Client aktiviert ist oder für SMB-Signaturen.
Aktivieren von digitalen Signaturen in Hochsicherheitsnetzwerken schützt den Identitätswechsel von Clients und Servern. Diese Art von Identitätswechseln wird als Session hijackingbezeichnet. Ein Angreifer mit Zugriff auf dasselbe Netzwerk wie der Client oder der Server verwendet Session hijacking-Tools zu unterbrechen, beenden oder eine laufende Sitzung zu stehlen. Ein Angreifer kann abfangen und Ändern von unsignierte SBM-Pakete, den Verkehr modifizieren und anschließend weiterleiten, sodass der Server eventuell unerwünschte Aktionen ausführt. Oder der Angreifer nach einer rechtmäßigen Authentifizierung als Server oder Client ausgeben und anschließend unberechtigten Zugang zu Daten verschaffen.
Das SMB-Protokoll, das verwendet wird, für die Dateifreigabe und Druckerfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 unterstützt die gegenseitige Authentifizierung. Gegenseitige Authentifizierung Angriffe zur Sitzungsentführung und unterstützt die Nachrichtenauthentifizierung. Daher verhindert Man-in-the-Middle-Angriffe. SMB-Signierung ermöglicht diese Authentifizierung durch digitale Signatur in jedes SMB-Paket eingefügt. Der Client und Server überprüfen die Signatur.
Hinweise
Als eine alternative Gegenmaßnahme können Sie digitale Signaturen mit IPSec zum Schutz der gesamte Netzwerkverkehr aktivieren. Es gibt Hardwarebeschleuniger für IPSec-Verschlüsselung und Signatur, die Sie verwenden können, um die Leistungsbeeinträchtigungen der Server CPU zu minimieren. Es gibt keine Hardwarebeschleuniger, die für SMB-Signaturen verfügbar sind.
Konfigurieren Sie die SMB-Signierung durch den Gruppenrichtlinienobjekt-Editor weil eine Ändern einer lokalen Registrierung keine Auswirkungen hat, wenn eine überschreibende Domänenrichtlinie gibt.
In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client die SMB-Signierung, wenn es mit Windows Server 2003-Servern mithilfe von NTLM-Authentifizierung authentifiziert. Allerdings verwenden Sie diese Clients nicht SMB-Signierung, wenn sie mit diesen Servern mithilfe von NTLMv2-Authentifizierung authentifizieren. Außerdem Antworten Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients. Weitere Informationen finden Sie unter Punkt 10: "Netzwerksicherheit: Lan Manager-Authentifizierungsebene."
Risikoreiche Konfiguration
Im folgenden ist eine schädliche Konfigurationseinstellung: belassen der Microsoft-Netzwerkclient: Kommunikation digital signieren (immer) Einstellung und die Microsoft-Netzwerkclient: Kommunikation digital signieren (Wenn Server zustimmt) Einstellung auf "Nicht definiert" festgelegt oder deaktiviert. 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.
Gründe zum Aktivieren dieser Einstellung
Aktivieren der Microsoft-Netzwerkclient: Kommunikation digital signieren (immer) erfordert, dass Clients SMB-Verkehr signieren, wenn Sie Server kontaktieren, die keine SMB-Signatur erfordern. Dies macht die Clients weniger anfällig gegenüber Session hijacking-Angriffe.
Gründe für diese Einstellung deaktivieren
Aktivieren der Microsoft-Netzwerkclient: Kommunikation digital signieren (immer) verhindert, dass Clients mit Zielservern, die keine SMB-Signaturen unterstützen kommunizieren.
Konfigurieren von Computern für alle nicht signierten SMB ignorieren
Kommunikation verhindert, dass ältere Programme und Betriebssysteme von
Herstellen einer Verbindung.
Windows NT 4.0:Den sicheren Kanal einer Vertrauensstellung zwischen einer Windows Server 2003-Domäne und einer Windows NT 4.0-Domäne mithilfe von NLTEST oder NETDOM Zurücksetzen ist nicht möglich, und Sie erhalten eine Fehlermeldung "Zugriff verweigert".
Windows XP:Kopieren von Dateien von Windows XP können Clients auf Windows 2000-basierten Server und Windows Server 2003-Server mehr Zeit benötigen.
Sie werden nicht von einem Netzlaufwerk einen
der Client mit dem diese Einstellung aktiviert ist, und Sie werden die folgende Fehlermeldung angezeigt:
Meldung:
Das Konto ist nicht autorisiert, sich anmelden
Dieser Station.
Neustart
Starten Sie den Computer neu, oder starten Sie den Arbeitsstationsdienst neu. Geben Sie hierzu die folgenden Befehle an einer Eingabeaufforderung. Drücken Sie nach jedem Befehl die EINGABETASTE.
NET Stop workstation Net Start workstation
Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)
Hintergrund
Server Messenger Block (SMB) ist die gemeinsame Nutzung von Ressourcen-Protokoll, das von vielen Microsoft-Betriebssystemen unterstützt wird. Es ist die Grundlage für Network basic Input/Output System (NetBIOS) und viele andere Protokolle. SMB-Signatur authentifiziert den Benutzer und dem Server, der die Daten hostet. Wenn die beiden Seiten der Authentifizierungsprozess fehlschlägt, wird keine Datenübertragung statt.
Aktivieren von SMB-Signaturen beginnt während der Aushandlung der SMB-Protokoll. Die SMB-Signaturen-Richtlinien bestimmen, ob der Computer Client-Kommunikation immer digital signiert.
Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt die gegenseitige Authentifizierung. Gegenseitiger Authentifizierung schließt einen "Man-in-the-Middle"-Angriff. Das Windows 2000-SMB-Authentifizierungsprotokoll unterstützt auch die Nachrichtenauthentifizierung. Die Nachrichtenauthentifizierung hilft zu verhindern, dass Angriffe abgewehrt.
Um diese Authentifizierung zu erhalten, setzt die SMB-Signierung eine digitale Signatur in jeden SMB. Der Client und dem Server Überprüfen der digitalen Signatur.
Wenn SMB-Signierung verwenden möchten, müssen Sie Aktivieren von SMB-Signaturen oder SMB-Signierung auf SMB-Client und der SMB-Server erfordern.
Wenn SMB-Signierung auf einem Server, Clients, die SMB aktiviert ist-Signierung verwenden bei allen nachfolgenden Sitzungen das Paketsignierungsprotokoll auch aktiviert sind.
Wenn SMB-Signierung auf einem Server erforderlich ist, kann kein Client eine Sitzung herstellen, es sei denn, der Client aktiviert ist oder für SMB-Signaturen.
Aktivieren von digitalen Signaturen in Hochsicherheitsnetzwerken schützt den Identitätswechsel von Clients und Servern. Diese Art von Identitätswechseln wird als Session hijackingbezeichnet. Ein Angreifer mit Zugriff auf dasselbe Netzwerk wie der Client oder der Server verwendet Session hijacking-Tools zu unterbrechen, beenden oder eine laufende Sitzung zu stehlen. Ein Angreifer kann abfangen und unsignierte Pakete für Subnet Bandwidth Manager (SBM) ändern, den Verkehr modifizieren und anschließend weiterleiten, sodass der Server eventuell unerwünschte Aktionen ausführt. Oder der Angreifer nach einer rechtmäßigen Authentifizierung als Server oder Client ausgeben und anschließend unberechtigten Zugang zu Daten verschaffen.
Das SMB-Protokoll, das verwendet wird, für die Dateifreigabe und Druckerfreigabe auf Computern mit Windows 2000 Server, Windows 2000 Professional, Windows XP Professional oder Windows Server 2003 unterstützt die gegenseitige Authentifizierung. Gegenseitige Authentifizierung Angriffe zur Sitzungsentführung und unterstützt die Nachrichtenauthentifizierung. Daher verhindert Man-in-the-Middle-Angriffe. SMB-Signierung ermöglicht diese Authentifizierung durch digitale Signatur in jedes SMB-Paket eingefügt. Der Client und Server überprüfen die Signatur.
Als eine alternative Gegenmaßnahme können Sie digitale Signaturen mit IPSec zum Schutz der gesamte Netzwerkverkehr aktivieren. Es gibt Hardwarebeschleuniger für IPSec-Verschlüsselung und Signatur, die Sie verwenden können, um die Leistungsbeeinträchtigungen der Server CPU zu minimieren. Es gibt keine Hardwarebeschleuniger, die für SMB-Signaturen verfügbar sind.
In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client die SMB-Signierung, wenn es mit Windows Server 2003-Servern mithilfe von NTLM-Authentifizierung authentifiziert. Allerdings verwenden Sie diese Clients nicht SMB-Signierung, wenn sie mit diesen Servern mithilfe von NTLMv2-Authentifizierung authentifizieren. Außerdem Antworten Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients. Weitere Informationen finden Sie unter Punkt 10: "Netzwerksicherheit: Lan Manager-Authentifizierungsebene."
Risikoreiche Konfiguration
Im folgenden ist eine schädliche Konfigurationseinstellung: Aktivieren der Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) auf Servern und auf Domänencontrollern, die durch inkompatible Windows-basierten Computern und Drittanbieter-Betriebssystem-basierten Clientcomputern in lokalen oder externen Domänen zugegriffen werden.
Gründe zum Aktivieren dieser Einstellung
Alle Client-Computer, die diese Einstellung aktivieren
direkt über die Registrierung oder über die Gruppenrichtlinieneinstellung unterstützen Sie SMB
Signieren. Mit anderen Worten, haben alle Client-Computer, die diese Einstellung aktiviert
Führen Sie entweder Windows 95 mit der DS-Client installiert, Windows 98, Windows NT 4.0,
Windows 2000, Windows XP Professional oder WindowsServer 2003.
Wenn Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) ist deaktiviert, die SMB-Signatur ist vollständig deaktiviert. Vollständig
Deaktivieren von SMB-Signierung verlässt Computer anfälliger für Session hijacking
Angriffe.
Gründe für diese Einstellung deaktivieren
Durch Aktivieren dieser Einstellung möglicherweise langsamer Dateikopie
und Netzwerkleistung auf Client-Computern.
Durch Aktivieren dieser Einstellung wird verhindert, dass Clients, die
Kommunikation mit Servern und Domäne SMB-Signaturen aushandeln kann nicht
Domänencontroller. Hierdurch können Vorgänge wie Domänenbeitritte, Benutzer und computer
Authentifizierung oder der Netzwerkzugriff durch Programme fehlschlagen.
Windows 95:Windows 95-Clients, die keine den Directory Services (DS)-Client installiert haben Anmeldeauthentifizierung fehl, und erhalten die folgende Fehlermeldung angezeigt:
Das eingegebene Kennwort ist nicht
korrigieren oder den Zugriff auf Ihre Anmeldung Server wurde verweigert.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Fehlermeldung, wenn Windows 95 oder Windows NT 4.0-Client auf Windows Server 2003-Domäne anmeldet
Windows NT 4.0: Client-Computern, auf denen Versionen von Windows NT 4.0
älter sind als Service Pack 3 (SP3) wird Anmeldeauthentifizierung fehl und wird
wird die folgende Fehlermeldung angezeigt:
Das System konnte nicht
Melden Sie sich. Stellen Sie sicher, dass Ihr Benutzername und Domäne korrekt sind, und geben Sie Ihre
Kennwort erneut ein.
Einige nicht - Microsoft SMB-Server unterstützen nur einen nicht verschlüsselten Kennwortaustausch während der Authentifizierung. (Dieser Börsen auch bekannt als "nur-Text-Austausch) Für Windows NT 4.0 SP3 und höher sendet der SMB-Redirector kein Unverschlüsseltes Kennwort während der Authentifizierung auf einem SMB-Server, wenn Sie einen bestimmten Registrierungseintrag hinzufügen. Um unverschlüsselte Kennwörter für den SMB-Client auf Windows NT 4.0 SP3 und neueren Systemen zu aktivieren, ändern Sie die Registrierung wie folgt: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters Wertname: EnablePlainTextPassword Datentyp: REG_DWORD Daten: 1
Weitere Informationen zu verwandten Themen finden Sie die folgenden Artikelnummern klicken, um die Artikel der Microsoft Knowledge Base:
Unverschlüsselte Kennwörter können dazu führen, dass Service Pack 3, eine Verbindung zu SMB-Servern
WindowsServer 2003: Standardmäßig werden Sicherheitseinstellungen auf Domänencontrollern, auf denen Windows Server 2003 ausgeführt konfiguriert, um zu verhindern, dass Kommunikation des Domänencontrollers Abfangen oder Manipulieren von böswilligen Benutzern manipuliert. Damit Benutzer erfolgreich mit einem Domänencontroller kommunizieren, der Windows Server 2003 ausgeführt wird, müssen die Clientcomputer SMB-Signierung und Verschlüsselung oder Signaturen für sichere Kanäle Datenverkehr verwenden. Standardmäßig führen Windows NT 4.0 mit Service Pack 2 (SP2) oder früher installiert Clients und Clients mit Windows 95 keinen SMB-Paketsignierung aktiviert. Deshalb diese Clients auf einem Windows Server 2003-basierten Domänencontroller authentifizieren können möglicherweise nicht.
Windows 2000 und Windows Server 2003-Richtlinieneinstellungen: Je nach Ihren spezifischen Installationsanforderungen und Ihrer Konfiguration wird empfohlen, dass Sie auf der niedrigsten erforderlichen in der Microsoft Management Console Gruppenrichtlinien-Editor-Snap-in-Hierarchie die folgenden Richtlinieneinstellungen festlegen:
Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden (diese Einstellung gilt für Windows 2000)
Microsoft-Netzwerkclient: Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden (diese Einstellung gilt für Windows Server 2003)
Hinweis In einige Drittanbieter-CIFS-Server, z. B. älteren Samba-Versionen kann verschlüsselte Kennwörter nicht verwendet werden.
Die folgenden Clients sind nicht kompatibel mit der Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) Einstellung:
Apple Computer, Inc., Mac OS X
Clients
Microsoft MS-DOS-Netzwerk-Clients (z. B.
Microsoft LAN Manager)
Microsoft Windows für Workgroups
Clients
Microsoft Windows 95-Clients ohne DS
Client installiert
Microsoft Windows NT 4.0-basierten Computern
ohne SP3 oder höher installiert.
Novell Netware 6 CIFS-clients
SAMBA SMB-Clients, die keine Unterstützung für SMB-Signaturen haben
Neustart
Starten Sie den Computer neu, oder starten Sie den Serverdienst neu. Geben Sie hierzu die folgenden Befehle an einer Eingabeaufforderung. Drücken Sie nach jedem Befehl die EINGABETASTE.
Die Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen Sicherheitseinstellung wird bestimmt, ob ein anonymer Benutzer anfordern kann
Sicherheitsattribute für (ID, SID) für einen anderen Benutzer.
Risikoreiche Konfiguration
Aktivieren der Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen Einstellung ist eine schädliche Konfigurationseinstellung.
Gründe zum Aktivieren dieser Einstellung
Wenn die Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen Einstellung ist deaktiviert, frühere Betriebssysteme oder Anwendungen
kann nicht mit Windows Server 2003-Domänen kommunizieren können. Zum Beispiel
die folgenden Betriebssysteme, Dienste oder Anwendungen funktionieren möglicherweise nicht:
Windows NT 4.0-basierten RAS-Dienst
Server
Microsoft SQL Server, die auf Windows NT 3.x-Computern oder Windows NT 4.0-basierten Computern ausgeführt werden
RAS-Dienst, der auf Windows 2000-Computern ausgeführt wird, die in Windows NT 3.x-Domänen oder Windows NT 4.0-Domänen befinden
SQL Server, die auf Windows 2000-Computern ausgeführt wird, die sich in Windows NT 3.x-Domänen oder Windows NT 4.0-Domänen befinden
Benutzer in Windows NT 4.0-Ressourcendomänen möchten
Erteilen von Berechtigungen für Dateien, freigegebene Ordner und Registrierungsobjekte Benutzer zugreifen
Konten aus Kontendomänen, die Windows Server 2003-Domäne enthalten.
Controller
Gründe für diese Einstellung deaktivieren
Wenn diese Einstellung aktiviert ist, könnte ein böswilliger Benutzer bekannte Administrator-SID verwenden, um den tatsächlichen Namen des integrierten Administratorkontos abzurufen, selbst wenn das Konto umbenannt wurde. Diese Person konnte den Kontonamen dann verwenden, um einen Angriff Erraten von Kennwörtern zu initiieren.
Symbolischer Name: N/A
Registrierungspfad: Keine. Der Pfad wird im Code der Benutzeroberfläche angegeben.
Beispiele für Kompatibilitätsprobleme
Windows NT 4.0:Computer in Windows NT 4.0-Ressourcendomänen werden die Fehlermeldung "Unbekanntes Konto" im ACL-Editor angezeigt, wenn Ressourcen, einschließlich von freigegebenen Ordnern, freigegebenen Dateien und Registrierungsobjekte, mit Sicherheitsprinzipalen geschützt sind, die sich in Kontendomänen befinden, die Windows Server 2003-Domänencontroller enthalten.
Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben
Hintergrund
Die Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben Einstellung bestimmt, welche zusätzlichen Berechtigungen für anonyme Verbindungen zum Computer gewährt werden. Windows gestattet anonymen Benutzern bestimmte Aktivitäten, wie z. B. das Aufzählen der Namen der Workstation und Server (Security Accounts Manager, SAM) Konten und Netzwerkfreigaben. Z. B. können ein Administrator diese Benutzer in einer vertrauenswürdigen Domäne Zugriff gewähren, die keine gegenseitige Vertrauensstellung unterhält. Nachdem eine Sitzung hergestellt wurde, möglicherweise ein anonymer Benutzer den gleichen Zugriff jeder erhalten Gruppe entsprechend der Einstellung in der Netzwerkzugriff: Let Everyone Permissions apply to anonymous Users Einstellung oder discretionary Access Control List (DACL) des Objekts.
In der Regel werden anonyme Verbindungen von früheren Versionen von Clients (Vorgängerversions Clients) während der Installation der SMB-Sitzung angefordert. In diesen Fällen zeigt eine Netzwerkablaufverfolgung, dass die SMB-Prozess-ID (PID) ist, dass der Client-Redirector wie 0xFEFF in Windows 2000 oder 0xCAFE in Windows NT RPC anonyme Verbindungen auch versucht.
WichtigDiese Einstellung hat keine Auswirkungen auf die Domäne
Domänencontroller. Auf Domänencontrollern wird dieses Verhalten durch das Vorhandensein von "NT-AUTORITÄT\ANONYMOUS-Anmeldung" in "Prä-Windows 2000 kompatibler Zugriff" gesteuert.
In Windows 2000 eine ähnliche Einstellung mit der Bezeichnung Weitere Einschränkungen für anonyme Verbindungen verwaltet die
"RestrictAnonymous"
Registrierungswert. Der Speicherort dieses Wertes ist wie folgt
Weitere Informationen zum Registrierungswert "RestrictAnonymous" finden Sie die folgenden Artikelnummern klicken, um die Artikel der Microsoft Knowledge Base:
Beschränken der Informationen für anonym angemeldete Benutzer
Risikoreiche Konfigurationen
Aktivieren der Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben Einstellung ist eine schädliche Konfigurationseinstellung aus Sicht der Kompatibilität. Deaktivierung ist eine schädliche Konfigurationseinstellung aus Gründen der Sicherheit.
Gründe zum Aktivieren dieser Einstellung
Ein nicht autorisierter Benutzer könnte Kontennamen anonym auflisten und anhand dieser Informationen versuchen, die Kennwörter zu erraten oder Social Engineering -Angriffe auszuführen. Social Engineering ist Fachsprache täuschen Menschen preiszugeben bedeutet, die ihre
Kennwörter oder andere Sicherheitsinformationen.
Gründe für diese Einstellung deaktivieren
Wenn diese Einstellung aktiviert ist, ist es unmöglich, Vertrauensstellungen mit Windows NT 4.0-Domänen einzurichten. Diese Einstellung verursacht außerdem Probleme mit älteren Clients (z. B. Windows NT 3.51-Clients und Windows 95-Clients), die Ressourcen auf dem Server verwenden möchten.
SMS-Netzwerkermittlung werden kann nicht abgerufen
Systeminformationen und Schreiben Sie "Unbekannt" wird in der
OperatingSystemNameandVersion-Eigenschaft.
Windows 95, Windows 98:Windows 95 und Windows 98-Clients werden nicht auf ihre Kennwörter ändern können.
Windows NT 4.0:Windows NT 4.0-Mitgliedscomputer werden nicht authentifiziert werden können.
Windows 95, Windows 98:Windows 95- und Windows 98-basierten Computern werden nicht von Microsoft-Domänencontrollern authentifiziert werden können.
Windows 95, Windows 98:Benutzer von Windows 95- und Windows 98-basierten Computern werden nicht die Kennwörter für ihre Benutzerkonten ändern können.
Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben
Hintergrund
Die Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben Einstellung (auch als RestrictAnonymousbezeichnet) bestimmt, ob anonyme Aufzählung von Sicherheitskonten
Manager (SAM)-Konten und Freigaben zulässig ist. Windows gestattet anonymen Benutzern
Führen Sie bestimmte Aktivitäten aus, wie z. B. das Aufzählen der Namen von Domänenkonten
(Benutzer, Computer und Gruppen) und Netzwerkfreigaben. Dies ist nützlich für
Beispiel: Wenn ein Administrator in einer vertrauenswürdigen Benutzern Zugriff gewähren möchte
Domäne, die keine gegenseitige Vertrauensstellung unterhält. Wenn Sie nicht zulassen möchten
Anonyme Aufzählung von SAM-Konten und Freigaben, aktivieren Sie diese Einstellung.
In Windows 2000 eine ähnliche Einstellung mit der Bezeichnung Weitere Einschränkungen für anonyme Verbindungen verwaltet die
"RestrictAnonymous"
Registrierungswert. Der Speicherort dieses Wertes ist wie folgt:
Aktivieren der Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben Einstellung ist eine schädliche Konfigurationseinstellung.
Gründe zum Aktivieren dieser Einstellung
Aktivieren der Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben Einstellung wird die Aufzählung von SAM-Konten und Freigaben durch Benutzer verhindert
und Computer, die anonyme Konten verwenden.
Gründe für diese Einstellung deaktivieren
Wenn diese Einstellung aktiviert ist, ein nicht autorisierter Benutzer
könnte Kontennamen anonym auflisten und anhand dieser Informationen versuchen
Kennwörter erraten oder Social Engineering -Angriffe auszuführen. Social Engineering ist Fachsprache täuschen Menschen preiszugeben bedeutet, die ihre
Kennwort oder andere Sicherheitsinformationen.
Wenn diese Einstellung aktiviert ist, wird es unmöglich sein.
Vertrauensstellungen mit Windows NT 4.0-Domänen hergestellt werden. Diese Einstellung verursacht außerdem
Probleme mit kompatiblen Clients wie Windows NT 3.51 und Windows 95-clients
die Ressourcen auf dem Server verwenden möchten.
Es wird nicht möglich, Benutzern von Ressourcendomänen Zugriff gewähren, da Administratoren in der vertrauenden Domäne nicht Listen von Konten in der anderen Domäne aufgelistet werden können. Benutzer, die anonym auf Datei- und Druckserver zugreifen werden nicht auf die freigegebenen Netzwerkressourcen auf diesen Servern auflisten können. Bevor sie die Listen von freigegebenen Ordnern und Druckern anzeigen können, müssen die Benutzer authentifizieren.
Windows NT 4.0: Benutzer werden nicht in der Lage, ihre Kennwörter von Windows NT ändern
4.0-Arbeitsstationen, wenn RestrictAnonymous auf Domänencontrollern in der Domäne des Benutzers aktiviert ist. Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Benutzer können Kennwort nicht ändern, bei der Anmeldung
Windows NT 4.0:Hinzufügen von Benutzern oder globalen Gruppen aus vertrauenswürdigen Windows 2000-Domänen zu lokalen Gruppen von Windows NT 4.0 im Benutzer-Manager schlägt fehl, und die folgende Fehlermeldung wird angezeigt:
Es stehen momentan keine Anmeldeserver
zum Verarbeiten der Anmeldeanforderung verfügbar.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Des Registrierungswertes "RestrictAnonymous" kann die Vertrauensstellung zu einer Windows 2000-Domäne aufheben.
Windows NT 4.0:Windows NT 4.0-basierten Computern werden nicht beitreten von Domänen während des Setups oder mithilfe der Benutzeroberfläche der Domäne beitreten.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Fehlermeldung: ein Domänencontroller für diese Domäne konnte nicht gefunden werden
Windows NT 4.0:Eine untergeordnete Vertrauensstellung mit Windows NT 4.0-Ressourcendomänen schlägt fehl. Die folgende Fehlermeldung wird angezeigt, wenn RestrictAnonymous auf die vertrauenswürdige Domäne aktiviert ist:
Konnte nicht
gefunden Sie Domänencontroller für diese Domäne werden.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Domänencontroller konnte nicht gefunden werden, beim Einrichten einer Vertrauensstellung
Windows NT 4.0:Benutzer anmelden bei Windows NT 4.0 Terminal Server-Computern werden das Standardbasisverzeichnis statt das Basisverzeichnis zugeordnet, die im Benutzer-Manager für Domänen definiert ist.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Terminal Server-Benutzerprofile und Basisordner Pfade werden ignoriert, nach der Installation von SP4 oder höher
Windows NT 4.0:Windows NT 4.0-Reservedomänencontroller (BDCs) können nicht den Anmeldedienst gestartet, eine Liste der Sicherungssuchdienste abzurufen oder die SAM-Datenbank von Windows 2000 oder Windows Server 2003-Domänencontrollern in derselben Domäne zu synchronisieren.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Net Logon-Dienst von einem Windows NT 4.0-BDCS funktioniert nicht unter Windows 2000-Domäne.
Windows 2000:Windows 2000-Mitgliedscomputer in Windows NT 4.0-Domänen werden nicht Drucker in externen Domänen anzeigen, wenn die Einstellung kein Zugriff ohne explizite anonyme Berechtigung in der lokalen Sicherheitsrichtlinie des Client aktiviert ist
Computer.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Benutzer kann nicht verwalten oder Anzeigen von Druckereigenschaften
Windows 2000:Windows 2000-Domänen-Benutzer werden keine Netzwerkdrucker aus Active Directory hinzugefügt; Allerdings werden sie zum Hinzufügen von Druckern, nachdem sie sie aus der Strukturansicht ausgewählt.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Outlook-Clients können keine globalen Adressliste anzeigen, nach der Installation des Security Rollup Package 1 (SRP1) auf globale Katalogserver
Windows 2000:Auf Windows 2000-basierten Computern werden ACL-Editor keine Benutzer oder globalen Gruppen aus vertrauenswürdigen Windows NT 4.0-Domänen hinzufügen.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Der Wert "RestrictAnonymous" unterbricht die Vertrauensstellung in einer gemischten Domänenumgebung
ADMT, Version 2:Kennwortmigration für Benutzerkonten, die mit Active Directory Migration Tool (ADMT) Version 2 Gesamtstrukturen migriert werden, schlägt fehl.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Langsame SMB-Leistung beim Kopieren von Dateien von Windows XP auf einem Windows 2000-Domänencontroller
SMS:Netzwerkerkennung von Microsoft Systems Management Server (SMS) werden nicht den Betriebssystem-Informationen abrufen können. Daher wird "Unbekannt" in der Eigenschaft "OperatingSystemNameandVersion" der SMS DDR-Eigenschaft des Discovery Data Record (DDR) schreiben.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Wie wann eine Clientkonfigurationsanforderung generiert Ermittlungsdaten-Manager bestimmt
SMS: Wenn Sie den SMS-Administrator-Benutzer-Assistenten Durchsuchen für Benutzer und Gruppen verwenden, werden keine Benutzer oder Gruppen aufgelistet. Darüber hinaus können keine erweiterte Clients mit dem Verwaltungspunkt kommunizieren. Anonymer Zugriff ist auf dem Verwaltungspunkt erforderlich.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Keine Benutzer oder Gruppen sind in den Assistenten für die Benutzer aufgeführt.
SMS: Wenn Sie das Feature für die Netzwerkerkennung in SMS 2.0 verwenden und
in der Remote Client-Installation mit der Topologie, Client und Client-Betriebssysteme Netzwerk Discovery Option eingeschaltet können Computer erkannt werden
aber möglicherweise nicht installiert werden.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Ressourcen werden nicht erkannt, wenn anonyme Verbindungen deaktiviert sind
Netzwerksicherheit: Lan Manager-Authentifizierungsebene
Hintergrund
LAN Manager (LM)-Authentifizierung ist das Protokoll, das zur Authentifizierung von Windows-Clients bei Netzwerkvorgängen, darunter Domänenbeitritte, Zugriff auf Netzwerkressourcen sowie Benutzer- oder Computerauthentifizierung verwendet wird. Die LM-Authentifizierungsebene bestimmt, welches Anfrage/Antwort-Authentifizierungsprotokoll zwischen Client und Server-Computern ausgehandelt wird. Die LM-Authentifizierungsebene bestimmt, welche Authentifizierungsprotokolle, die der Client versucht auszuhandeln oder, die der Server akzeptiert. Der Wert für "LmCompatibilityLevel" bestimmt, welches Anfrage/Antwort-Authentifizierungsprotokoll für Netzwerkanmeldungen verwendet wird. Dieser Wert wirkt sich auf der Ebene von Authentifizierungsprotokollen, die Clients verwenden, die Ebene der ausgehandelten Sitzungssicherheit und die Ebene der Authentifizierung von Servern akzeptiert wird.
Die folgenden sind Einstellungen möglich.
Tabelle minimierenTabelle vergrößern
Wert
Einstellung
Beschreibung
0
& LM-und NTLM-Antworten senden
Clients verwenden LM- und NTLM-Authentifizierung und nie NTLMv2-Sitzungssicherheit verwenden. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
1
Senden & LM-und NTLM - NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt
Clients verwenden LM- und NTLM-Authentifizierung und NTLMv2-Sitzungssicherheit verwenden, wenn der Server unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
2
Nur NTLM-Antworten senden
Clients verwenden nur NTLM-Authentifizierung und NTLMv2-Sitzungssicherheit verwenden, wenn der Server unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
3
Nur NTLMv2-Antworten senden
Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit verwenden, wenn der Server unterstützt. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.
4
Nur NTLMv2-Antworten senden / LM verweigern
Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit verwenden, wenn der Server unterstützt. Domänencontroller verweigern die LM und akzeptieren nur NTLM- und NTLMv2-Authentifizierung.
5
Nur NTLMv2-Antworten senden / LM & NTLM verweigern
Clients verwenden nur NTLMv2-Authentifizierung und NTLMv2-Sitzungssicherheit verwenden, wenn der Server unterstützt. Domänencontroller lehnen LM- und NTLM und akzeptieren nur NTLMv2-Authentifizierung.
Hinweis In Windows 95, Windows 98 und Windows 98 Second Edition verwendet der Verzeichnisdienst-Client die SMB-Signierung, wenn es mit Windows Server 2003-Servern mithilfe von NTLM-Authentifizierung authentifiziert. Allerdings verwenden Sie diese Clients nicht SMB-Signierung, wenn sie mit diesen Servern mithilfe von NTLMv2-Authentifizierung authentifizieren. Außerdem Antworten Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients.
Überprüfen Sie die LM-Authentifizierungsebene: Müssen Sie die Richtlinie zum Zulassen von NTLM auf dem Server ändern oder Sie müssen den Client-Computer zur Unterstützung von NTLMv2 konfigurieren.
Wenn die Richtlinie (5) senden\LM NTLM verweigern & auf dem Zielcomputer, die Sie herstellen möchten festgelegt ist, müssen entweder niedrigere Einstellung festlegen, auf dem Computer oder legen Sie die Sicherheit auf die gleiche Einstellung, die auf dem Quellcomputer, die Sie verbinden aus.
Suchen Sie den Ort des LAN-Managers können Sie die ändern Authentifizierungsebene auf dem Client und Server auf derselben Ebene festgelegt. Nachdem die Richtlinie, die der LAN Manager-Authentifizierungsebene, Sie, finden Wenn die Verbindung zu und von Computern mit frühere Versionen von Windows, senken den Wert, der mindestens (1) senden LM & NTLM - Version mit NTLM 2-Sitzungssicherheit wenn ausgehandelt. Eine Auswirkung inkompatibler Einstellungen ist, dass, wenn der Server NTLMv2 erfordert (Wert 5), aber der Client ist so konfiguriert, dass LM und NTLMv1 nur (Wert 0) verwenden, der Benutzer-Authentifizierung versucht Erfahrungen eines Anmeldefehlers hat, die ein ungültiges Kennwort und die, die die Anzahl falscher Kennwörter erhöht. Wenn Kontosperrung konfiguriert ist, kann der Benutzer schließlich gesperrt.
Beispielsweise haben eventuell auf dem Domänencontroller zu suchen, oder Sie haben Richtlinien des Domänencontrollers zu untersuchen.
Suchen Sie auf dem Domänencontroller
Hinweis Sie müssen möglicherweise das folgende Verfahren auf allen Domänencontrollern anwenden.
Klicken Sie auf Start, zeigen Sie auf Programme, und klicken Sie dann auf Verwaltung.
Klicken Sie unter Lokale Sicherheitseinstellungen, erweitern Sie Lokale Richtlinien.
Klicken Sie auf Sicherheitsoptionen.
Doppelklicken Sie auf Netzwerksicherheit: LAN Manager-Authentifizierungsebene, und klicken Sie dann auf einen Wert in der Liste.
Wenn die effektive Einstellung und die lokale Einstellung identisch sind, wurde die Richtlinie auf dieser Ebene geändert. Die Einstellungen unterschiedlich sind, müssen Sie überprüfen die Domänencontroller-Richtlinie bestimmt, ob die Netzwerksicherheit: LAN Manager-Authentifizierungsebene Einstellung definiert ist. Wenn es dort nicht definiert ist, untersuchen Sie die Richtlinien des Domänencontrollers.
Überprüfen SieRichtlinien des Domänencontrollers
Klicken Sie auf Start, zeigen Sie auf Programme, und klicken Sie dann auf Verwaltung.
In der Sicherheit des Domänencontrollers Richtlinien, erweitern Sie Sicherheitseinstellungen, und erweitern Sie dann Lokale Richtlinien.
Klicken Sie auf Sicherheitsoptionen.
Doppelklicken Sie auf Netzwerksicherheit: LAN Manager-Authentifizierungsebene, und klicken Sie dann auf einen Wert in der Liste.
Hinweis
Sie müssen auch die Richtlinien überprüfen, die auf der Standortebene, der Domänenebene oder der Organisationseinheit verknüpft sind (OU) Ebene, um zu bestimmen, in dem Sie die Authentifizierungsebene des LAN-Managers konfigurieren müssen.
Wenn Sie eine Gruppenrichtlinieneinstellung als die Standarddomänenrichtlinie implementieren, wird die Richtlinie auf allen Computern in der Domäne angewendet.
Wenn Sie eine Gruppenrichtlinieneinstellung als die Standarddomänencontroller Richtlinie implementieren, gilt die Richtlinie nur für die Server in der Organisationseinheit des Domänencontrollers.
Es ist eine gute Idee, legen Sie die Authentifizierungsebene des LAN-Managers in der niedrigsten erforderlichen Umfang in die Hierarchie der Richtlinienanwendung-Entität.
Aktualisieren Sie die Richtlinie, nachdem Sie Änderungen vornehmen. (Wenn die Änderung auf der Ebene der lokalen Sicherheit Einstellungen vorgenommen wird, ist die Änderung sofort. Allerdings müssen Sie die Clients starten, bevor Sie testen.)
Standardmäßig werden Gruppenrichtlinieneinstellungen auf Domänencontrollern alle fünf Minuten aktualisiert. Um die Aktualisierung der Richtlinieneinstellungen unter Windows 2000 oder höher sofort zu erzwingen, verwenden Sie den Befehl Gpupdate .
Der Befehl Gpupdate/force aktualisiert lokale Gruppenrichtlinieneinstellungen und Gruppenrichtlinieneinstellungen, die auf Active Directory-Dienst, einschließlich Sicherheitseinstellungen. Dieser Befehl ersetzt die Option jetzt veraltete /refreshpolicy/refreshpolicy für den Befehl Secedit .
Der Befehl Gpupdate verwendet die folgende Syntax: Gpupdate [/ target: {Computer|Benutzer[}] [/ force] [/ wait:Wert] [/ Logoff] [/ Boot]
Übernehmen Sie das neue Gruppenrichtlinienobjekt (GPO) mithilfe des Befehls Gpupdate manuell alle Richtlinieneinstellungen erneut anwenden. Zu diesem Zweck geben Sie Folgendes an der Eingabeaufforderung, und drücken Sie dann die EINGABETASTE:
GPUpdate/Force
Betrachten Sie das Anwendungsereignisprotokoll, um sicherzustellen, dass die Richtlinieneinstellung erfolgreich angewendet wurde.
Unter Windows XP und Windows Server 2003 können die Richtlinienergebnissatz-Snap-in Sie die effektive Einstellung anzuzeigen. Dazu klicken Sie aufStart, klicken Sie auf Ausführen, Typ RSoP.msc, und klicken Sie dann auf OK.
Wenn das Problem weiterhin besteht, nachdem Sie die Änderung der Richtlinie vornehmen, starten Sie den Windows-basierten Server, und überprüfen Sie, ob das Problem behoben ist.
Hinweis Haben Sie mehrere Windows 2000-basierten Domänencontrollern oder Windows Server 2003-basierten Domänencontrollern, müssen Sie möglicherweise Active Directory replizieren, um sicherzustellen, dass diese Domänencontroller die Änderungen sofort übernommen haben.
Alternativ kann die Einstellung angezeigt, auf die niedrigste Einstellung in der lokalen Sicherheitsrichtlinie festgelegt werden. Wenn Sie die Einstellung mithilfe einer Sicherheitsdatenbank erzwingen können, können Sie alternativ die Authentifizierungsebene des LAN-Manager in der Registrierung festlegen, bearbeiten Sie den Eintrag " LmCompatibilityLevel " in den folgenden Registrierungsunterschlüssel:
Windows Server 2003 verfügt über eine neue Standardeinstellung auf nur NTLMv2 verwendet. Standardmäßig Windows Server 2003 und Windows 2000 Server SP3-basierten Domänencontrollern aktiviert haben die "Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)" Richtlinie. Diese Einstellung erfordert den SMB-Server SMB-Paketsignierung durchführt.
Änderungen an Windows Server 2003 wurden vorgenommen, weil der Domänencontroller, Dateiserver, Netzwerkinfrastrukturserver und Webserver in jeder Organisation unterschiedliche Einstellungen erfordern, um ihre Sicherheit zu maximieren.
Wenn Sie die NTLMv2-Authentifizierung in Ihrem Netzwerk implementieren möchten, müssen Sie sicherstellen, dass alle Computer in der Domäne diese Authentifizierungsebene verwendet. Wenn Sie Active Directory Client Extensions für Windows 95 oder Windows 98 und Windows NT 4.0 anwenden, verwenden diese Clienterweiterungen die verbesserten Funktionen, die in NTLMv2 verfügbar sind. Da Clientcomputer, die den folgenden Betriebssystemen ausgeführt werden, nicht von Windows 2000 Group Policy Objects betroffen sind, müssen Sie diese Clients manuell konfigurieren:
Microsoft Windows NT 4.0
Microsoft Windows Millennium Edition
Microsoft Windows 98
Microsoft Windows 95
Hinweis Aktivieren Sie die Netzwerksicherheit: keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern Richtlinie oder eine Gruppe der NoLMHash Registrierungsschlüssel, Windows 95- und Windows 98 basierende Clients, die nicht den Verzeichnisdienstclient installiert kann nach einer Kennwortänderung an der Domäne anmelden.
Viele Fremdanbieter-CIFS-Server, z. B. Novell Netware 6 sind nicht NTLMv2-fähig und verwenden ausschließlich NTLM. Größer als 2 Ebenen erlauben daher keine Konnektivität.
Weitere Informationen zum manuellen Konfigurieren der Authentifizierungsebene des LAN-Manager klicken Sie auf die folgenden Artikelnummern klicken, um die Artikel der Microsoft Knowledge Base:
Outlook weiterhin für Anmeldeinformationen aufgefordert
Weitere Informationen zu LM-Authentifizierungsebenen finden Sie die folgende Artikelnummer klicken, um den Artikel in der Microsoft Knowledge Base anzuzeigen:
Im folgenden werden die schädigende Konfigurationseinstellungen:
Nicht restriktive Einstellungen, die Kennwörter in senden
Klartext und die verweigern NTLMv2-Verhandlung
Restriktive Einstellungen, die nicht kompatibel zu verhindern.
Clients oder Domänencontroller nicht kein gemeinsames Authentifizierungsprotokoll aushandeln
Anfordern der NTLMv2-Authentifizierung auf Mitgliedscomputern
Domänencontroller, auf denen Versionen von Windows NT 4.0
vor Service Pack 4 (SP4)
Anfordern der NTLMv2-Authentifizierung unter Windows 95
Clients oder Windows 98-Clients, die nicht Windows-Verzeichnis
Services-Client installiert.
Wenn Sie aktivieren die NTLMv2-Sitzungssicherheit erfordern das Kontrollkästchen in der Microsoft Management Console Gruppenrichtlinieneditor Snap-in auf einem Windows Server 2003 oder Windows 2000 Service Pack 3-basierten Computer, und Sie verringern die LAN Manager-Authentifizierungsebene auf 0, die zwei Einstellungen in Konflikt stehen und möglicherweise die folgende Fehlermeldung in der Datei Secpol.msc oder die Datei "gpedit.msc":
Windows kann nicht die lokale Richtliniendatenbank öffnen. Unbekannter Fehler beim Versuch, die Datenbank zu öffnen.
Weitere Informationen über das Snap-In Sicherheitskonfiguration und Analyse-Tool finden Sie unter Windows 2000 oder Windows Server 2003-Hilfe-Dateien.
Weitere Informationen zum Analysieren die Sicherheitsstufen unter Windows 2000 und Windows Server 2003, klicken Sie auf die folgenden Artikelnummern klicken, um die Artikel der Microsoft Knowledge Base:
Gewusst wie: Analysieren der Systemsicherheit in Windows Server 2003
Gründe zum Ändern dieser Einstellung
Sie möchten den kleinsten gemeinsamen erhöhen
Authentication-Protokoll, das von Clients und Domänencontrollern unterstützt wird
Ihre Organisation.
Sicherer Authentifizierung ist, in denen ein Unternehmen
erforderlich, sollte die Aushandlung des LM- und die NTLM verweigert
Protokolle.
Gründe für diese Einstellung deaktivieren
Client Server Authentifizierungsanforderungen oder beides wurden auf den Punkt erhöht, in dem Authentifizierung über ein gemeinsames Protokoll durchgeführt werden kann.
WindowsServer 2003:Standardmäßig ist die Windows Server 2003 NTLMv2 NTLM-Anworten senden festlegen aktiviert. Daher erhält Windows Server 2003 die Fehlermeldung "Zugriff verweigert" nach der ersten Installation, wenn Sie versuchen, Verbindung zu einem Windows NT 4.0-Cluster oder zu LanManager v2. 1-basierten Servern wie OS/2-Lanserver. Dieses Problem tritt auf, wenn Sie versuchen, aus einer früheren Version-Client zu einem Windows Server 2003-basierten Server herstellen.
Sie installieren Windows 2000 Security Rollup Package 1 (SRP1).SRP1 erzwingt die NTLM Version 2 (NTLMv2). Dieses Rollup Package wurde nach der Veröffentlichung von Windows 2000 Service Pack 2 (SP2) freigegeben. Weitere Informationen zum SRP1 finden Sie die folgende Artikelnummer klicken, um den Artikel in der Microsoft Knowledge Base anzuzeigen:
Windows 2000 Security Rollup Package 1, Januar 2002
Windows 7 und Windows Server 2008 R2: viele Drittanbieter-CIFS-Server, z. B. Novell Netware 6 oder Linux-basierten Samba-Server sind nicht NTLMv2-fähig und verwenden ausschließlich NTLM. Aus diesem Grund erlauben Ebenen höher als "2" keine Konnektivität. In dieser Version des Betriebssystems wurde nun die Standardeinstellung für "LmCompatibilityLevel" auf "3" geändert. So bei der Aktualisierung von Windows eventuell diese Drittanbieter-Filer funktioniert nicht.
Microsoft Outlook-Clients möglicherweise zur Eingabe von Anmeldeinformationen aufgefordert, obwohl sie an der Domäne angemeldet sind. Wenn Benutzer ihre Anmeldeinformationen eingeben, erhalten sie die folgende Fehlermeldung: Windows 7 und Windows Server 2008 R2
Die Anmeldeinformationen sind ungültig. Stellen Sie sicher, dass Benutzername und Domäne korrekt sind, und geben Ihr Kennwort erneut.
Beim Starten von Outlook können Sie Anmeldeinformationen für aufgefordert, selbst wenn Ihre Anmeldung-Netzwerksicherheit Passthrough oder Kennwortauthentifizierung eingestellt ist. Nachdem Sie die richtigen Anmeldeinformationen eingeben, erhalten Sie die folgende Fehlermeldung angezeigt:
Die Anmeldeinformationen sind ungültig.
Eine Netzwerkmonitor-Ablaufverfolgung kann zeigen, dass der globale Katalog einen remote Procedure Call (RPC) Fehler mit dem Status 0 x 5 ausgestellt. Status 0 x 5 bedeutet "Zugriff verweigert".
Windows 2000:Eine Netzwerkmonitor-Aufzeichnung kann die folgenden Fehler in NetBIOS über TCP/IP (NetBT) Server Message Block (SMB) Sitzung anzeigen:
SMB R Search Directory Dos Error, (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) Ungültige Benutzerkennung
Windows 2000: Wenn eine Windows 2000-Domäne mit NTLMv2 der Stufe 2 oder höher als vertrauenswürdig eingestuft ist.
von einer Windows NT 4.0-Domäne Windows 2000-Mitgliedscomputer in der Ressource
Domäne kann Authentifizierungsfehler auftreten.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Authentifizierungsprobleme in Windows 2000 mit NTLM 2-Ebenen als 2 in einer Windows NT 4.0-Domäne
Windows 2000 und Windows XP: Standardmäßig wird Windows 2000 und Windows XP die Option LAN-Manager-Authentifizierungsebene lokale Sicherheitsrichtlinie auf 0 festgelegt. Die Einstellung 0 bedeutet "Send LM- und NTLM-Antworten."
Hinweis Windows NT 4.0-basierten Clustern müssen für die Verwaltung LM verwenden.
Windows 2000: Windows 2000-Cluster Authentifizierung kein beitretenden Knotens Wenn
beide Knoten sind Teil einer Windows NT 4.0 Service Pack 6a (SP6a) Domäne.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Authentifizierungsprobleme in Windows 2000 mit NTLM 2-Ebenen als 2 in einer Windows NT 4.0-Domäne
Das IIS Lockdown-Tool (HiSecWeb) legt den Wert LMCompatibilityLevel auf 5 und der Wert RestrictAnonymous auf 2 fest.
Dienste für Macintosh
-Benutzerauthentifizierungsmodul (UAM): Microsoft-UAM (Benutzerauthentifizierungsmodul) stellt eine Methode zum Verschlüsseln der Kennwörter, die Sie verwenden, um die Anmeldung bei Windows AFP (AppleTalk Filing Protocol)-Servern.
Die Apple-Benutzerauthentifizierungsmodul (UAM) ermöglicht nur eine minimale oder gar keine Verschlüsselung. Daher konnte Ihr Kennwort im LAN oder im Internet leicht abgefangen werden.
Obwohl das UAM nicht erforderlich ist, bietet es verschlüsselten Authentifizierung auf Windows 2000-Servern, die Dienste für Macintosh ausgeführt.
Diese Version enthält Unterstützung für NTLMv2 128-Bit-verschlüsselte Authentifizierung und ein MacOS X 10.1-kompatibles Release.
Standardmäßig erlaubt die Windows Server 2003 Services for Macintosh-Server nur Microsoft Authentication.
Weitere Informationen klicken Sie auf die folgenden Artikelnummern klicken, um die Artikel der Microsoft Knowledge Base:
Mac OS X-Benutzer können freigegebene Macintosh-Ordner auf einem Windows Server 2003-basierten Server nicht öffnen.
WindowsServer 2008, WindowsServer 2003, Windows XP und Windows 2000: Wenn den Wert LMCompatibilityLevel 0 oder 1, und konfigurieren Sie den NoLMHash-Wert 1 konfiguriert, können Anwendungen und Komponenten Zugriff durch NTLM verweigert. Dieses Problem tritt auf, weil der Computer konfiguriert ist, LM ermöglichen jedoch keine LM-gespeicherten Kennwörtern zu verwenden.
Wenn Sie den NoLMHash-Wert 1 konfigurieren, konfigurieren Sie den Wert LMCompatibilityLevel um 2 oder höher sein.
Netzwerksicherheit: Signaturanforderungen für LDAP-Clients
Hintergrund
Die Netzwerksicherheit: Signaturanforderungen für LDAP-Clients Einstellung bestimmt die Ebene der Signatur von Daten, die auf angefordert wird
für Kunden, die BINDUNG des Lightweight Directory Access Protocol (LDAP) ausgeben
fordert wie folgt:
Keine: die LDAP-BIND-Anforderung wird mit der vom Aufrufer angegebene ausgegeben
Optionen.
Signatur aushandeln: Wenn die Secure Sockets Layer/Transport Layer Security (SSL/TLS)
wurde nicht gestartet, wird die LDAP-BIND-Anforderung mit den LDAP-Daten initiiert
Signaturoption legen Sie außerdem auf die vom Aufrufer festgelegten Optionen. Wenn SSL/TLS besitzt
wurde gestartet, wird die LDAP-BIND-Anforderung mit der vom Aufrufer angegebene initiiert
Optionen.
Signatur erforderlich: Dies entspricht der Signatur aushandeln. Jedoch, wenn der LDAP-Server intermediate's SaslBindInProgress
Antwort bedeutet nicht, dass LDAP-Verkehrssignaturen erforderlich ist, wird des Aufrufers
mitgeteilt, dass die LDAP-BIND-Anforderung ist fehlgeschlagen.
Risikoreiche Konfiguration
Aktivieren der Netzwerksicherheit: Signaturanforderungen für LDAP-Clients Einstellung ist eine schädliche Konfigurationseinstellung. Wenn Sie festlegen, dass den Server LDAP-Signaturen erforderlich sind, müssen Sie auch LDAP-Signierung auf dem Client konfigurieren. Nicht Konfigurieren des Clients zur Verwendung von LDAP-Signaturen verhindert die Kommunikation mit dem Server. Dadurch wird die Benutzerauthentifizierung, Gruppenrichtlinien Einstellungen, Anmeldeskripts und andere Funktionen fehlschlagen.
Gründe zum Ändern dieser Einstellung
Nicht signierter Netzwerkverkehr ist anfällig für Man-in-the-Middle-Angriffe, in denen ein Eindringling Pakete zwischen Client und Server abfängt, ändert sie und anschließend an den Server weiterleitet. In diesem Fall auf einem LDAP-Server könnte ein Angreifer einen Server basierend auf falschen Abfragen vom LDAP-Client antwortet. Sie können dieses Risiko in einem Unternehmensnetzwerk senken, indem Sie strenge physische Sicherheitsmaßnahmen zum Schutz die Netzwerkinfrastruktur implementieren. Darüber hinaus kann Ihnen helfen, alle Arten von Man-in-the-Middle-Angriffe zu verhindern, indem digitale Signaturen für alle Netzwerkpakete über IPSec-Authentifizierungsheader.
Ereignisprotokoll: Maximalgröße des Sicherheitsprotokolls
Hintergrund
Die Ereignisprotokoll: Maximalgröße des Sicherheitsprotokolls Sicherheitseinstellung gibt die maximale Größe des Ereignisses Sicherheit
Protokoll. Dieses Protokoll hat eine maximale Größe von 4 GB. Um diese Einstellung zu finden, erweitern Sie Windows-Einstellungen, und erweitern Sie dann Sicherheit
Einstellungen.
Risikoreiche Konfigurationen
Im folgenden werden die schädigende Konfigurationseinstellungen:
Beschränken der Größe des Sicherheitsprotokolls und der Sicherheit
Aufbewahrungsmethode melden Sie sich bei der Audit: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen aktiviert ist. Finden Sie in der "Audit: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen" Abschnitt dieses Artikels Weitere Informationen.
Die Größe des Sicherheitsprotokolls so einschränken, dass die Sicherheit
relevante Ereignisse überschrieben werden.
Gründe für diese Einstellung erhöhen
Geschäfts-und Sicherheitsanforderungen können vorschreiben, dass Sie
Erhöhen Sie die Größe des Sicherheitsprotokolls um zusätzliche Sicherheitsdetails zu erfassen oder zu
Behalten Sie die Sicherheitsprotokolle für einen längeren Zeitraum.
Gründe für diese Einstellung zu verringern
Protokolle der Ereignisanzeige sind Speicherabbilddateien. Die maximale
Größe eines Ereignisprotokolls ist eingeschränkt, durch die Größe des physischen Speichers in der
lokalen Computer und den virtuellen Speicher, die in das Ereignisprotokoll verfügbar ist
Prozess. Die Protokollgröße über die Größe des virtuellen Speichers erhöhen, die
verfügbar in der Ereignisanzeige erhöht nicht die Anzahl der Protokolleinträge, die
verwaltet.
Beispiele für Kompatibilitätsprobleme
Windows 2000:Computer, auf denen Versionen von Windows 2000 sind
vor Service Pack 4 (SP4) Protokollieren von Ereignissen im Ereignisprotokoll vor eventuell nicht mehr
Größe erreicht, die in der Einstellung maximale Größe des Sicherheitsprotokolls in der Ereignisanzeige angegeben ist, wenn die Option nicht überschreiben (Protokoll manuell löschen) Ereignisse aktiviert ist.
Weitere Informationen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
Die Ereignisprotokoll: Sicherheitsprotokoll- Sicherheitseinstellung wird bestimmt, die "Umbruchmethode" für die
Sicherheitsprotokoll. Um diese Einstellung zu finden, erweitern Sie Windows-Einstellungen,
und erweitern Sie dann Sicherheitseinstellungen.
Risikoreiche Konfigurationen
Im folgenden werden die schädigende Konfigurationseinstellungen:
Nicht erfolgte Speicherung Sicherheitsereignisse aller vor
Sie werden überschrieben
Konfigurieren die Maximalgröße des Sicherheitsprotokolls zu klein setzen, sodass die Sicherheitsereignisse werden
überschrieben
Beschränken der Größe des Sicherheitsprotokolls und Aufbewahrung
-Methode auf, wenn die Audit: Herunterfahren des Systems zu den Protokollen der Sicherheitsüberprüfungen Sicherheit aktiviert ist
Gründe zum Aktivieren dieser Einstellung
Aktivieren Sie diese Einstellung nur, wenn die Überschreiben Sie Ereignisse, die nach Tagen Aufbewahrungsmethode. Wenn Sie ein fragt Ereignissystem der Korrelation für Ereignisse verwenden, stellen Sie sicher, dass die Anzahl der Tage mindestens dreimal die Abfragehäufigkeit ist. Dies tun, um fehlerhafte Abfragezyklen auftreten können.
Netzwerkzugriff: "Jeder" für anonyme Benutzer-Berechtigungen ermöglichen
Hintergrund
Standardmäßig der Netzwerkzugriff: Let Everyone Permissions apply to anonymous Users ist unter Windows Server 2003 Nicht definiert eingestellt. Standardmäßig Windows Server 2003 enthält keinen anonymen Zugriffstoken in jeder Gruppe.
[REG_DWORD] = 0 x 0 Erstellen von Pausen Vertrauensstellungen zwischen Windows Server 2003 und Windows NT 4.0, wenn die Windows Server 2003-Domäne die Domäne des Kontos ist und die Windows NT 4.0-Domäne die Ressourcendomäne ist. Dies bedeutet, dass das Konto unter Windows NT 4.0 vertraut wird und der Ressourcendomäne vertrauen auf der Seite Windows Server 2003. Dieses Verhalten tritt auf, weil der Prozess, die Vertrauensstellung zu starten, nachdem die ursprüngliche anonyme Verbindung ACL ist mit jedem token, die anonyme SID unter Windows NT 4.0 enthält würde.
Gründe zum Ändern dieser Einstellung
Der Wert auf 0 x 1 festgelegt oder mithilfe eines Gruppenrichtlinienobjekts auf die Organisationseinheit des Domänencontrollers zu festgelegt werden muss: Network Access: Let Everyone Berechtigungen gelten für anonyme Benutzer - aktiviert ermöglichen die Bildung von Vertrauensstellungen.
Hinweis Die meisten anderen Sicherheitseinstellungen steigen in Wert und nicht auf 0 x 0 in den Zustand. Sicherer wäre die Registrierung auf dem PDC-Emulation nicht auf allen Domänencontrollern ändern. Wenn die primary Domain Controller-Emulationsfunktion aus irgendeinem Grund verschoben wird, muss die Registrierung auf dem neuen Server aktualisiert werden.
Nach dem Festlegen dieses Werts ist ein Neustart erforderlich.
Die Sitzungssicherheit definiert die Mindestanforderungen an Sicherheitsstandards für Client- und Serversitzungen. Es ist eine gute Idee, überprüfen die folgenden Sicherheitsrichtlinieneinstellungen im Gruppenrichtlinieneditor für Microsoft Management Console-Snap-in:
Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Clients (einschließlich sicherer RPC)-Servern
Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Clients (einschließlich sicherer RPC)-clients
Die Optionen für diese Einstellungen sind wie folgt:
Nachrichtenintegrität erfordern
Nachrichtenvertraulichkeit erfordern
Erfordern Sie NTLM Version 2-Sitzungssicherheit
128-Bit-Verschlüsselung erforderlich
Die Standardeinstellung ist keine Anforderungen.
Diese Richtlinien bestimmen die Mindestsicherheitsstandards für eine Kommunikationssitzung von-Anwendungen auf einem Server für einen Client.
Historisch unterstützt Windows NT zwei Arten der Challenge/Response-Authentifizierung für Netzwerkanmeldungen:
LM-Challenge/response
NTLM Version 1 Challenge/response
LM ermöglicht die Interoperabilität mit der installierten Basis von Clients und Servern. NTLM bietet höhere Sicherheit für Verbindungen zwischen Clients und Servern.
Die entsprechenden Registrierungsschlüssel lauten folgendermaßen:
Fehler bei der Zeitsynchronisierung. Die Zeit ist um mehr als 30 Minuten auf einem betroffenen Computer aus. Stellen Sie sicher, dass die Uhr des Clientcomputers mit der Uhr des Domänencontrollers synchronisiert wird.
Wir empfehlen die Installation von Service Pack 6a (SP6a) auf Windows NT 4.0-Clients, die in einer Windows Server 2003-basierten Domäne zusammenarbeiten. Windows 98 Second Edition-basierten Clients, Windows 98-basierten Clients und Windows 95-basierten Clients müssen den Client für Verzeichnisdienste, um NTLMv2 ausführen ausführen. Wenn Windows NT 4.0-basierten Clients keinen Windows NT 4.0 SP6 installiert oder Windows 95-basierten Clients, Windows 98-basierten Clients und Windows 98 SE-Clients ist nicht der Verzeichnisdienstclient installiert haben, deaktivieren Sie SMB-Signierung in der Standarddomänencontroller Richtlinie auf die Organisationseinheit des Domänencontrollers festlegen und verknüpfen Sie diese Richtlinie dann mit allen Organisationseinheiten, die anderen Domänencontroller zu.
Die Directory Services Client für Windows 98 Second Edition, Windows 98 und Windows 95 werden SMB-Signierung mit Windows 2003 Server NTLM-Authentifizierung, aber nicht unter die NTLMv2-Authentifizierung durchführen. Außerdem werden Windows 2000-Server nicht auf SMB-Signierungsanforderungen von diesen Clients Antworten.
Obwohl wir nicht empfehlen, können Sie verhindern, SMB-Signaturen erforderlich, dass auf allen Domänencontrollern, die in einer Domäne Windows Server 2003 ausgeführt. Um diese Sicherheitseinstellung zu konfigurieren, gehen Sie folgendermaßen vor:
Öffnen Sie die Standarddomänencontroller Richtlinie.
Öffnen Sie den Ordner Computer Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\sicherheitsoptionen .
Klicken Sie auf die Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) Richtlinieneinstellung, und klicken Sie dann auf deaktiviert.
Wichtig Dieser Abschnitt, die Methode oder die Aufgabe enthält Schritte, die erklären, wie Sie die Windows-Registry ändern. Es können schwerwiegende Probleme auftreten, wenn Sie die Windows-Registry falsch ändern. Stellen Sie daher sicher, dass Sie diese Schritte sorgfältig ausführen. Für zusätzlichen Schutz sichern Sie die Registrierung, bevor Sie Änderungen vornehmen. Anschließend können Sie die Registrierung wiederherstellen, wenn ein Problem auftritt. Für Weitere Informationen zum Sichern und Wiederherstellen der Registrierung, klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:
Klicken Sie auf der EnableSecuritySignature Eintrag.
Auf der Bearbeiten Menü, klicken Sie auf Ändern.
In der Wertdaten Geben Sie im Feld 0, und klicken Sie dann auf OK.
Beenden Sie den Registrierungs-Editor.
Den Computer neu starten oder beenden und starten Sie den Serverdienst neu. Zu diesem Zweck geben Sie die folgenden Befehle an einer Eingabeaufforderung, und drücken Sie nach jedem Befehl: NET Stop server Net Start server
Hinweis Der entsprechende Schlüssel auf dem Clientcomputer ist in den folgenden Registrierungsunterschlüssel:
Die Informationen in diesem Artikel beziehen sich auf:
Microsoft Windows Server 2003, Standard Edition (32-bit x86)
Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
Microsoft Windows Server 2003, Enterprise x64 Edition
Microsoft Windows XP Professional
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Professional Edition
Microsoft Windows NT Server 4.0 Standard Edition
Microsoft Windows NT Workstation 4.0 Developer Edition
Microsoft Windows 98 Standard Edition
Microsoft Windows 95
Keywords:
kbinfo kbmt KB823659 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 823659
(http://support.microsoft.com/kb/823659/en-us/
)
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Danke! Dieses Feedback hilft uns dabei, die Supportartikel weiter zu verbessern. Weitere Informationen finden Sie auf der Hilfe und Support-Startseite.
Zum Anfang
