Bedrohungen und Gegenmaßnahmen

Kapitel 5: Sicherheitsoptionen

Im Gruppenrichtlinienabschnitt „Sicherheitsoptionen“ werden die Computersicherheitseinstellungen aktiviert bzw. deaktiviert. Dazu zählen die Einstellungen für digitale Datensignaturen, Namen von Administrator- und Gastkonten, Zugriff auf Disketten- und CD-ROM-Laufwerke, Verhalten bei Treiberinstallation und Anmeldeaufforderungen. In der Microsoft® Excel®-Arbeitsmappe „Standardkonfiguration für Sicherheit und Dienste unter Windows“ (im Rahmen der herunterladbaren Version dieses Handbuchs verfügbar) werden die Standardeinstellungen dokumentiert.

Auf dieser Seite

Einstellungen der Sicherheitsoptionen
Weitere Informationen

Einstellungen der Sicherheitsoptionen

Die Einstellungen der Sicherheitsoptionen können im Gruppenrichtlinienobjekt-Editor in folgendem Verzeichnis konfiguriert werden:

Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\
Lokale Richtlinien\Sicherheitsoptionen

Konten: Administratorkontostatus

Mit dieser Richtlinieneinstellung wird das Administratorkonto für normale Betriebsbedingungen aktiviert oder deaktiviert. Beim Starten des Computers im abgesicherten Modus ist das Administratorkonto immer aktiviert, unabhängig davon, wie diese Richtlinieneinstellung konfiguriert wurde.

Für die Einstellung Konten: Administratorkontostatus sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

In einigen Organisationen kann die Erstellung und Aktualisierung eines Plans zur regelmäßigen Kennwortänderung für lokale Konten eine schwierige Verwaltungsaufgabe darstellen. Daher müssen Sie u. U. das vordefinierte Administratorkonto deaktivieren und auf regelmäßige Kennwortänderungen verzichten, um das Konto vor Angriffen zu schützen. Ein weiterer Grund für die Deaktivierung dieses Kontos ist die Tatsache, dass es unabhängig von der Anzahl der fehlgeschlagenen Anmeldeversuche nicht gesperrt werden kann. Dadurch ist es ein Hauptziel für Brute-Force-Angriffe zum Erraten von Kennwörtern. Darüber hinaus hat dieses Konto eine allgemein bekannte Sicherheits-ID (SID), und mit den über Drittanbieter verfügbaren Programmen ist eine Authentifizierung anhand der SID anstelle des Kontonamens möglich. Dies bedeutet, dass ein Angreifer auch nach Umbenennung des Administratorkontos einen Brute-Force-Angriff durchführen kann, wenn er bei der Anmeldung die SID verwendet.

Gegenmaßnahme

Setzen Sie die Einstellung Konten: Administratorkontostatus auf Deaktiviert, damit das vordefinierte Administratorkonto nicht mehr beim normalen Systemstart verwendet werden kann.

Mögliche Auswirkung

Die Deaktivierung des Administratorkontos kann unter bestimmten Umständen Wartungsprobleme hervorrufen. Wenn z. B. der sichere Kanal zwischen einem Mitgliedscomputer und dem Domänencontroller in einer Domänenumgebung aus irgendwelchen Gründen ausfällt und kein anderes lokales Administratorkonto vorhanden ist, müssen Sie den Computer im abgesicherten Modus neu starten, um das Problem zu beheben.

Wenn das aktuelle Administratorkennwort nicht den Kennwortanforderungen entspricht, ist die erneute Aktivierung des deaktivierten Administratorkontos nicht möglich. In diesem Fall muss ein anderes Mitglied der Gruppe Administratoren das Kennwort für das Administratorkonto mit dem Tool „Lokale Benutzer und Gruppen“ neu festlegen.

Konten: Gastkontenstatus

Durch diese Richtlinieneinstellung wird festgelegt, ob das Gastkonto aktiviert oder deaktiviert ist.

Für die Einstellung Konten: Gastkontenstatus sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Über das Gaststandardkonto können sich nicht authentifizierte Netzwerkbenutzer als Gast und ohne Kennwort anmelden. Diese nicht autorisierten Benutzer können auf alle Ressourcen zugreifen, die dem Gastkonto im Netzwerk zur Verfügung stehen. Dies bedeutet, dass auf alle Netzwerkfreigaben mit Zugriffsberechtigungen für das Gastkonto oder die Gruppen Gäste und Jeder im Netzwerk zugegriffen werden kann, wobei Daten u. U. offen gelegt oder beschädigt werden können.

Gegenmaßnahme

Setzen Sie die Einstellung Konten: Gastkontenstatus auf Deaktiviert, damit das vordefinierte Gastkonto nicht mehr verwendet werden kann.

Mögliche Auswirkung

Alle Netzwerkbenutzer müssen sich authentifizieren, bevor sie auf freigegebene Ressourcen zugreifen können. Wenn das Gastkonto deaktiviert und die Option Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten auf Nur Gast gesetzt wird, schlagen die Netzwerkanmeldungen, die z. B. von Microsoft Network Server (SMB-Dienst) durchgeführt werden, fehl. Diese Richtlinieneinstellung hat in den meisten Organisationen nur geringfügige Auswirkungen, da dies die Standardeinstellung unter Microsoft Windows® 2000, Windows XP und Windows Server™ 2003 ist.

Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken

Durch diese Richtlinieneinstellung wird festgelegt, ob interaktive Remoteanmeldungen über Netzwerkdienste wie Terminaldienste, Telnet und FTP (File Transfer Protocol) für lokale Konten mit leeren Kennwörtern möglich sind. Bei Aktivierung dieser Richtlinieneinstellung muss ein lokales Konto über ein nicht leeres Kennwort verfügen, damit eine interaktive Anmeldung oder eine Netzwerkanmeldung über einen Remoteclient durchgeführt werden kann.

Für die Einstellung Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Hinweis: Diese Richtlinieneinstellung hat keine Auswirkungen auf interaktive Anmeldungen, die direkt an der Konsole durchgeführt werden, sowie auf Anmeldungen, die Domänenkonten verwenden.

Vorsicht: Bei Anwendungen von Drittanbietern, die interaktive Remoteanmeldungen verwenden, kann diese Richtlinieneinstellung umgangen werden.

Sicherheitsanfälligkeit

Leere Kennwörter stellen eine ernsthafte Bedrohung der Computersicherheit dar und sollten daher durch Unternehmensrichtlinien und geeignete technische Maßnahmen unmöglich gemacht werden. Die Standardeinstellungen für Windows Server 2003-Active Directory®-Verzeichnisdienstdomänen erfordern komplexe Kennwörter mit mindestens sieben Zeichen. Wenn ein Benutzer mit der Berechtigung, neue Konten zu erstellen, die domänenbasierten Kennwortrichtlinien umgeht, ist die Erstellung von Konten mit leeren Kennwörtern trotzdem möglich. Ein Benutzer kann z. B. einen eigenständigen Computer einrichten, eines oder mehrere Konten mit leeren Kennwörtern erstellen und anschließend mit diesem Computer der Domäne beitreten. Die lokalen Konten mit leeren Kennwörtern können dann weiterhin verwendet werden. Jeder Benutzer, der den Namen eines dieser ungeschützten Kontos kennt, kann sich mit einem solchen Konto anmelden.

Gegenmaßnahme

Aktivieren Sie die Einstellung Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken.

Mögliche Auswirkung

Keine. Hierbei handelt es sich um die Standardkonfiguration.

Konten: Administratorkonto umbenennen

Durch diese Richtlinieneinstellung wird festgelegt, ob ein anderer Kontoname mit der SID des Administratorkontos verknüpft ist.

Für die Einstellung Konten: Administrator umbenennen sind folgende Werte möglich:

• Benutzerdefinierter Text

• Nicht definiert

Sicherheitsanfälligkeit

Das Administratorkonto ist auf allen Computern mit den Betriebssystemen Windows 2000, Windows Server 2003 und Windows XP Professional vorhanden. Bei Umbenennung des Kontos ist es für nicht autorisierte Personen etwas schwieriger, die Kombination von Name und Kennwort für dieses Konto mit Administratorrechten zu erraten.

Das vordefinierte Administratorkonto kann nicht gesperrt werden, unabhängig von der Anzahl der Angriffsversuche mit einem falschen Kennwort. Dadurch ist das Administratorkonto ein beliebtes Ziel für Brute-Force-Angriffe zum Erraten des Kennworts. Der Wert dieser Gegenmaßnahme ist relativ gering, weil das Konto eine allgemein bekannte Sicherheits-ID (SID) hat und weil mit Programmen von Drittanbietern eine Authentifizierung anhand der SID anstelle des Kontonamens möglich ist. Dies bedeutet, dass ein Angreifer auch nach Umbenennung des Administratorkontos einen Brute-Force-Angriff durchführen kann, wenn er bei der Anmeldung die SID verwendet.

Gegenmaßnahme

Geben Sie in der Einstellung Konten: Administrator umbenennen einen neuen Namen an, um das Administratorkonto umzubenennen.

Hinweis: In späteren Kapiteln ist diese Richtlinieneinstellung weder in den Sicherheitsvorlagen konfiguriert, noch wird ein neuer Benutzername für dieses Konto im Handbuch vorgeschlagen. In den Vorlagen wird diese Richtlinieneinstellung ausgelassen, um zu verhindern, dass die zahlreichen Unternehmen, die diese Anleitung verwenden, denselben neuen Benutzernamen in den jeweiligen Umgebungen implementieren.

Mögliche Auswirkung

Sie müssen Benutzer mit der entsprechenden Autorisierung über den neuen Kontonamen unterrichten. (Bei der Anleitung für diese Einstellung wird davon ausgegangen, dass das Administratorkonto entgegen der Empfehlung weiter oben in diesem Kapitel nicht deaktiviert wurde.)

Konten: Gastkonto umbenennen

Durch die Einstellung Konten: Gastkonto umbenennen wird festgelegt, ob mit der SID des Gastkontos ein abweichender Kontoname verknüpft ist.

Die möglichen Werte für diese Gruppenrichtlinieneinstellung sind:

• Benutzerdefinierter Text

• Nicht definiert

Sicherheitsanfälligkeit

Das Gastkonto ist auf allen Computern mit den Betriebssystemen Windows 2000, Windows Server 2003 und Windows XP Professional vorhanden. Bei Umbenennung des Kontos ist es für nicht autorisierte Personen etwas schwieriger, die Kombination von Name und Kennwort für dieses Konto mit Administratorrechten zu erraten.

Gegenmaßnahme

Geben Sie in der Einstellung Konten: Gastkonto umbenennen einen neuen Namen an, um das Gastkonto umzubenennen.

Hinweis: In späteren Kapiteln ist diese Richtlinieneinstellung weder in den Sicherheitsvorlagen konfiguriert, noch wird ein neuer Benutzername für dieses Konto im Handbuch vorgeschlagen. In den Vorlagen wird diese Richtlinieneinstellung ausgelassen, um zu verhindern, dass die zahlreichen Unternehmen, die diese Anleitung verwenden, denselben neuen Benutzernamen in den jeweiligen Umgebungen implementieren.

Mögliche Auswirkung

Die Auswirkungen sind gering, da das Gastkonto in der Standardeinstellung von Windows 2000, Windows XP und Windows Server 2003 deaktiviert ist.

Überwachung: Zugriff auf globale Systemobjekte prüfen

Bei Aktivierung dieser Richtlinieneinstellung wird eine Standard-SACL (System Access Control List, Systemzugriffssteuerungsliste) angewendet, wenn der Computer Systemobjekte (z. B. Mutexe, Ereignisse, Semaphore und MS-DOS-Geräte) erstellt. Wenn Sie darüber hinaus die Überwachungseinstellung Objektzugriffsversuche überwachen aktivieren (siehe Kapitel 3 dieses Handbuchs), wird der Zugriff auf diese Systemobjekte überwacht.

Globale Systemobjekte (im Englischen auch als „base system object“ oder „base named object“ bezeichnet) sind Kernelobjekte mit begrenzter Gültigkeitsdauer, deren Namen durch die Anwendung oder Systemkomponente festgelegt wird, die sie erstellt hat. Diese Objekte werden üblicherweise zum Synchronisieren von mehreren Anwendungen oder Teilen einer komplexen Anwendung verwendet. Aufgrund des Namens sind diese Objekte global verfügbar und für alle Prozesse des Computers sichtbar. Alle Objekte verfügen über eine Sicherheitsbeschreibung, in der Regel jedoch über eine Null-SACL. Wenn Sie diese Richtlinieneinstellung zur Startzeit aktivieren, wird den Objekten bei deren Erstellung eine SACL vom Kernel zugewiesen wird.

Für die Einstellung Überwachung: Zugriff auf globale Systemobjekte prüfen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein global sichtbares und benanntes Objekt kann bei unzureichender Absicherung von einem schädlichen Programm angegriffen werden, das den Namen des Objekts kennt. Wenn für ein Synchronisationsobjekt wie z. B. ein Mutex eine unzureichende DACL (Discretionary Access Control List) verwendet wird, kann ein schädliches Programm auf den Mutex über dessen Namen zugreifen und das Programm, das das Objekt erstellt hat, zu Fehlfunktionen veranlassen. Dieses Risiko ist jedoch sehr gering.

Gegenmaßnahme

Aktivieren Sie die Einstellung Überwachung: Zugriff auf globale Systemobjekte prüfen.

Mögliche Auswirkung

Bei Aktivierung der Einstellung Überwachung: Zugriff auf globale Systemobjekte prüfen kann eine große Anzahl von Sicherheitsereignissen generiert werden, insbesondere bei stark beanspruchten Domänencontrollern und Anwendungsservern. Dies kann zu längeren Antwortzeiten der Server und zu zahlreichen Einträgen mit geringer Bedeutung im Sicherheitsereignisprotokoll führen. Diese Richtlinieneinstellung kann nur aktiviert oder deaktiviert werden. Eine Filterung der zu protokollierenden Ereignisse ist nicht möglich. Auch Organisationen mit ausreichenden Ressourcen zur Analyse der Ereignisse, die durch diese Richtlinieneinstellung generiert werden, können normalerweise nicht auf den Quellcode oder eine Verwendungsbeschreibung für die benannten Objekte zugreifen. Daher bietet es den meisten Organisationen keine Vorteile, diese Richtlinieneinstellung auf Aktiviert zu setzen.

Überwachung: Die Verwendung des Sicherungs- und Wiederherstellungsrechts überprüfen

Durch diese Richtlinieneinstellung wird festgelegt, ob die Verwendung aller Benutzerrechte (einschließlich Sicherung und Wiederherstellung) überwacht wird, wenn die Einstellung Rechteverwendung überwachen aktiviert ist. Bei Aktivierung beider Richtlinien wird für jede Datei, die gesichert oder wiederhergestellt wird, ein Überwachungsereignis generiert.

Bei Aktivierung dieser Richtlinieneinstellung in Verbindung mit der Einstellung Rechteverwendung überwachen wird jedes Ausüben von Benutzerrechten im Sicherheitsprotokoll erfasst. Bei Deaktivierung dieser Richtlinieneinstellung werden die Benutzeraktionen mit Sicherungs- und Wiederherstellungsrechten auch dann nicht überwacht, wenn die Einstellung Rechteverwendung überwachen aktiviert ist.

Für die Einstellung Überwachung: Die Verwendung des Sicherungs- und Wiederherstellungsrechts überprüfen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Bei Aktivierung dieser Option und gleichzeitiger Aktivierung der Einstellung Rechteverwendung überwachen wird für jede Datei, die gesichert oder wiederhergestellt wird, ein Überwachungsereignis generiert. Anhand dieser Informationen können Sie ein Konto identifizieren, das versehentlich oder in böswilliger Absicht zur nicht autorisierten Wiederherstellung von Daten verwendet wurde.

Gegenmaßnahme

Aktivieren Sie die Einstellung Überwachung: Die Verwendung des Sicherungs- und Wiederherstellungsrechts überprüfen. Wahlweise können Sie auch die automatische Protokollsicherung durch Konfigurieren des Registrierungsschlüssels „AutoBackupLogFiles“ implementieren. Dies wird im Microsoft Knowledge Base-Artikel „Ereignisprotokoll beendet Protokollierung vor Erreichen der maximalen Protokollgröße“ unter https://support.microsoft.com/kb/312571/en-us beschrieben.

Mögliche Auswirkung

Bei Aktivierung dieser Richtlinieneinstellung kann eine große Anzahl von Sicherheitsereignissen generiert werden, wodurch die Serverreaktion verlangsamt wird und zahlreiche Ereignissen mit geringer Bedeutung im Sicherheitsereignisprotokoll erfasst werden. Wenn Sie für die Sicherheitsprotokollgröße einen höheren Wert festlegen, um ein häufiges Herunterfahren des Systems zu verhindern, kann eine extrem große Protokolldatei die Systemleistung beeinträchtigen.

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

Durch diese Richtlinieneinstellung wird festgelegt, ob der Computer heruntergefahren wird, wenn Sicherheitsereignisse nicht protokolliert werden können. Die TCSEC-C2-Zertifizierung (Trusted Computer System Evaluation Criteria) und die Common-Criteria-Zertifizierung erfordern, dass der Computer das Auftreten von zu überwachenden Ereignissen verhindern kann, wenn deren Protokollierung durch das Überwachungssystem nicht möglich ist. Microsoft erfüllt diese Anforderung durch Anhalten des Computers und Anzeigen einer Abbruchmeldung, wenn ein Fehler im Überwachungssystem auftritt. Bei Aktivierung dieser Richtlinieneinstellung wird der Computer angehalten, wenn eine Sicherheitsüberwachung aus irgendwelchen Gründen nicht protokolliert werden kann. Normalerweise schlägt die Protokollierung eines Ereignisses fehl, wenn das Sicherheitsüberwachungsprotokoll voll ist und als Aufbewahrungsmethode Ereignisse nicht überschreiben oder Ereignisse auf Tagen basierend überschreiben festgelegt ist.

Bei Aktivierung dieser Richtlinieneinstellung wird folgende Abbruchmeldung angezeigt, wenn das Sicherheitsprotokoll voll ist und ein vorhandener Eintrag nicht überschrieben werden kann:

STOP: C0000244 {Überwachung fehlgeschlagen}

Ein Versuch zur Erzeugung einer Sicherheitsüberwachung ist fehlgeschlagen.

Zur Fehlerbehebung muss sich ein Administrator anmelden, das Protokoll archivieren (optional), das Protokoll löschen und diese Option deaktivieren, um einen Neustart des Computer zu ermöglichen. In diesem Fall kann es erforderlich sein, das Sicherheitsereignisprotokoll manuell zu löschen, bevor Sie diese Richtlinieneinstellung auf Aktiviert setzen können.

Für die Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Wenn der Computer Ereignisse nicht im Sicherheitsprotokoll speichern kann, stehen nach einer Sicherheitsverletzung wichtige Beweise oder Problembehandlungsinformationen nicht zur Verfügung. Außerdem kann ein Angreifer eine große Anzahl von Sicherheitsereignisprotokoll-Meldungen erzeugen, um das Herunterfahren eines Computers zu erzwingen.

Gegenmaßnahme

Aktivieren Sie die Einstellung Überwachung: System sofort herunterfahren, wenn Sicherheitsüberprüfungen nicht protokolliert werden können.

Mögliche Auswirkung

Die Aktivierung dieser Richtlinieneinstellung kann mit einem erhöhten Verwaltungsaufwand verbunden sein, insbesondere wenn Sie gleichzeitig als Aufbewahrungsmethode für das Sicherheitsprotokoll den Wert Ereignisse nicht überschreiben (Protokoll manuell löschen) festlegen. Durch diese Konfiguration wird eine Bedrohung durch Abstreiten (ein Sicherungsoperator kann die Sicherung oder Wiederherstellung von Daten verweigern) zu einer Sicherheitsanfälligkeit gegenüber Dienstverweigerungsangriffen, da das Herunterfahren eines Servers durch die Fülle von Anmeldeereignissen und anderen Sicherheitsereignissen, die im Sicherheitsprotokoll gespeichert werden, erzwungen werden kann. Darüber hinaus kann das unvermittelte Herunterfahren zu irreparablen Beschädigungen des Betriebssystems, der Anwendungen oder der Daten führen. Das NTFS-Dateisystem garantiert zwar die Integrität des Dateisystems beim unvermittelten Herunterfahren des Computers, es kann jedoch beim Neustart keine Garantie für die Verwendbarkeit von gespeicherten Anwendungsdaten übernehmen.

DCOM: Computerzugriffseinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax

Mit dieser Richtlinieneinstellung können Administratoren zusätzliche computerweite Zugriffssteuerungen definieren, um den Zugriff auf alle DCOM-basierten Anwendungen auf einem Computer zu steuern (DCOM = Distributed Component Object Model). Durch diese Steuerelemente werden alle Aufrufs-, Aktivierungs- oder Startanforderungen auf dem Computer begrenzt. Am einfachsten lässt sich diese Art der Zugriffssteuerung als zusätzliche Zugriffsüberprüfung beschreiben, die anhand einer computerweiten Zugriffssteuerungsliste (ACL) für jeden Aufruf, jede Aktivierung oder jeden Start auf allen COM-Servern auf dem Computer durchgeführt wird. Wenn die Zugriffsüberprüfung fehlschlägt, wird der Aufruf, die Aktivierung oder die Startanforderung verweigert. (Diese Überprüfung erfolgt zusätzlich zu jeder Zugriffsüberprüfung, die anhand der serverspezifischen Zugriffssteuerungslisten durchführt wird.) Dadurch wird ein minimaler Autorisierungsstandard geboten, der für den Zugriff auf einen COM-Server auf dem Computer erfüllt sein muss. Die Einstellung DCOM: Computerzugriffseinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax steuert die Zugriffsberechtigungen hinsichtlich der Aufrufsrechte.

Mit diesen computerweiten Zugriffssteuerungslisten können schwache Sicherheitseinstellungen außer Kraft gesetzt werden, die von einer bestimmten Anwendung über CoInitializeSecurity oder von anwendungsspezifischen Sicherheitseinstellungen definiert werden. Sie bieten einen minimalen Sicherheitsstandard, der unabhängig von den serverspezifischen Einstellungen erfüllt sein muss.

Diese Zugriffssteuerungslisten stellen einen zentralen Speicherort zur Verfügung, für den der Administrator eine allgemeine Autorisierungsrichtlinie festlegen kann, die für alle COM-Server auf dem Computer gilt.

Die Einstellung DCOM: Computerzugriffseinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax bietet zwei verschiedene Möglichkeiten zur Definition einer Zugriffssteuerungsliste. Sie können die Sicherheitsbeschreibung in SDDL (Security Descriptor Definition Language) eingeben. Wahlweise können Sie auch Benutzer und Gruppen auswählen und ihnen die Berechtigungen für lokalen Zugriff oder Remotezugriff gewähren bzw. verweigern. Microsoft empfiehlt die Verwendung der integrierten Benutzeroberfläche, um den Inhalt der Zugriffssteuerungsliste zu definieren, der mit dieser Einstellung angewendet werden soll.  

Sicherheitsanfälligkeit

Viele COM-Anwendungen enthalten sicherheitsspezifischen Code (z. B. um CoInitializeSecurity aufzurufen), verwenden jedoch schwache Einstellungen, mit denen oftmals der nicht authentifizierte Zugriff auf den Prozess möglich ist. In früheren Windows-Versionen können Administratoren diese Einstellungen nicht zur Durchsetzung einer stärkeren Sicherheit außer Kraft setzen, ohne dabei die Anwendung zu ändern. Angreifer können versuchen, die schwache Sicherheit in einer einzelnen Anwendung auszunutzen, indem sie die Anwendung über COM-Aufrufe angreifen.

Darüber hinaus enthält die COM-Infrastruktur den RPCSS-Systemdienst, der beim Starten des Computers ausgeführt wird und danach immer aktiv bleibt. Dieser Dienst verwaltet die Aktivierung der COM-Objekte und der ausgeführten Objekttabelle. Außerdem bietet er Hilfsdienste für DCOM-Remoting. Hierbei werden die RPC-Schnittstellen einem Sicherheitsrisiko ausgesetzt, bei denen ein Remoteaufruf möglich ist. Da einige COM-Server den nicht authentifizierten Remotezugriff zulassen (siehe vorhergehender Abschnitt), können diese Schnittstellen von jedem Benutzer aufgerufen werden, auch wenn dieser nicht authentifiziert ist. RPCSS kann daher über nicht authentifizierte Remotecomputer angegriffen werden.

Gegenmaßnahme

Legen Sie zum Schutz einzelner COM-basierter Anwendungen oder Dienste für die Einstellung DCOM: Computerzugriffseinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax eine geeignete computerweite Zugriffssteuerungsliste fest.

Mögliche Auswirkung

Unter Windows XP mit SP2 und Windows Server 2003 mit SP1 werden (wie in den jeweiligen Dokumentationen erläutert) standardmäßige COM-Zugriffssteuerungslisten implementiert. Wenn Sie einen COM-Server implementieren und die Standardsicherheitseinstellungen außer Kraft setzen, stellen Sie sicher, dass den geeigneten Benutzern die richtigen Berechtigungen in der anwendungsspezifischen Zugriffssteuerungsliste mit den Aufrufberechtigungen zugewiesen wird. Andernfalls müssen Sie die anwendungsspezifische Zugriffssteuerungsliste mit den Berechtigungen ändern, um den geeigneten Benutzern die Aktivierungsrechte zu erteilen, damit Anwendungen und Windows-Komponenten, die DCOM verwenden, ordnungsgemäß ausgeführt werden können.

Hinweis: Weitere Informationen zu den standardmäßigen COM-Computerzugriffseinschränkungen, die unter Windows XP mit SP2 angewendet werden, finden Sie im Handbuch „Verwalten der Funktionen von Windows XP Service Pack 2 mithilfe von Gruppenrichtlinien“ (in englischer Sprache) unter www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx. Informationen zu den Einschränkungen, die unter Windows Server 2003 mit SP1 angewendet werden, finden Sie im Abschnitt „DCOM Security Enhancements“ im Handbuch „Änderungen an der Funktionalität in Microsoft Windows Server 2003 Service Pack 1“ (in englischer Sprache) unter www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/ed9975ba-3933-4e28-bcb4-72b80d7865b7.mspx. Weitere Informationen zu den Startberechtigungen finden Sie auf der Seite „Startberechtigt“ (in englischer Sprache) auf der Microsoft MSDN®-Website unter https://go.microsoft.com/fwlink/?LinkId=20924.

DCOM: Computerstarteinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax

Diese Richtlinieneinstellung ähnelt der Einstellung DCOM: Computerzugriffseinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax in der Hinsicht, dass Administratoren mit dieser Einstellung zusätzliche computerweite Zugriffssteuerungen definieren können, die den Zugriff auf alle DCOM-basierten Anwendungen auf dem Computer steuern. Der Unterschied besteht darin, dass die in dieser Richtlinieneinstellung angegebenen Zugriffssteuerungslisten lokale und Remote-COM-Startanforderungen (und keine Zugriffsanforderungen) auf dem Computer steuern. Am einfachsten lässt sich diese Art der Zugriffssteuerung als zusätzliche Zugriffsüberprüfung beschreiben, die anhand einer computerweiten Zugriffssteuerungsliste (ACL) für jeden Start auf allen COM-Servern auf dem Computer durchgeführt wird. Wenn die Zugriffsüberprüfung fehlschlägt, wird der Aufruf, die Aktivierung oder die Startanforderung verweigert. (Diese Überprüfung erfolgt zusätzlich zu jeder Zugriffsüberprüfung, die anhand der serverspezifischen Zugriffssteuerungslisten durchführt wird.) Dadurch wird ein minimaler Autorisierungsstandard geboten, der für den Start eines COM-Servers auf dem Computer erfüllt sein muss. Die weiter oben erwähnte Richtlinie ist insofern anders, als sie eine minimale Zugriffsüberprüfung bietet, die bei Zugriffsversuchen auf einen bereits gestarteten COM-Server angewendet wird.

Mit diesen computerweiten Zugriffssteuerungslisten können schwache Sicherheitseinstellungen außer Kraft gesetzt werden, die von einer bestimmten Anwendung über CoInitializeSecurity oder von anwendungsspezifischen Sicherheitseinstellungen definiert werden. Sie bieten einen minimalen Sicherheitsstandard, der unabhängig von den spezifischen Einstellungen des COM-Servers erfüllt sein muss. Diese Zugriffssteuerungslisten stellen einen zentralen Speicherort zur Verfügung, für den der Administrator eine allgemeine Autorisierungsrichtlinie festlegen kann, die für alle COM-Server auf dem Computer gilt.

Die Einstellung DCOM: Computerstarteinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax bietet zwei verschiedene Möglichkeiten zur Definition einer Zugriffssteuerungsliste. Sie können die Sicherheitsbeschreibung in SDDL (Security Descriptor Definition Language) eingeben. Wahlweise können Sie auch Benutzer und Gruppen auswählen und ihnen die Berechtigungen für lokalen Zugriff oder Remotezugriff gewähren bzw. verweigern. Microsoft empfiehlt die Verwendung der integrierten Benutzeroberfläche, um den Inhalt der Zugriffssteuerungsliste zu definieren, der mit dieser Einstellung angewendet werden soll.

Sicherheitsanfälligkeit

Viele COM-Anwendungen enthalten sicherheitsspezifischen Code (z. B. um CoInitializeSecurity aufzurufen), verwenden jedoch schwache Einstellungen, mit denen oftmals der nicht authentifizierte Zugriff auf den Prozess möglich ist. In früheren Windows-Versionen können Administratoren diese Einstellungen nicht zur Durchsetzung einer stärkeren Sicherheit außer Kraft setzen, ohne dabei die Anwendung zu ändern. Angreifer können versuchen, die schwache Sicherheit in einer einzelnen Anwendung auszunutzen, indem sie die Anwendung über COM-Aufrufe angreifen.

Darüber hinaus enthält die COM-Infrastruktur den RPCSS-Systemdienst, der beim Starten des Computers ausgeführt wird und danach immer aktiv bleibt. Dieser Dienst verwaltet die Aktivierung der COM-Objekte und der ausgeführten Objekttabelle. Außerdem bietet er Hilfsdienste für DCOM-Remoting. Hierbei werden die RPC-Schnittstellen einem Sicherheitsrisiko ausgesetzt, bei denen ein Remoteaufruf möglich ist. Da einige COM-Server die nicht authentifizierte Remoteaktivierung von Komponenten zulassen (siehe vorhergehender Abschnitt), können diese Schnittstellen von jedem Benutzer aufgerufen werden, auch wenn dieser nicht authentifiziert ist. RPCSS kann daher über nicht authentifizierte Remotecomputer angegriffen werden.

Gegenmaßnahme

Legen Sie zum Schutz einzelner COM-basierter Anwendungen oder Dienste für die Einstellung DCOM: Computerstarteinschränkungen in Security Descriptor Definition Language (SDDL)-Syntax eine geeignete computerweite Zugriffssteuerungsliste fest.

Mögliche Auswirkung

Unter Windows XP mit SP2 und Windows Server 2003 mit SP1 werden (wie in den jeweiligen Dokumentationen erläutert) standardmäßige COM-Zugriffssteuerungslisten implementiert. Wenn Sie einen COM-Server implementieren und die Standardsicherheitseinstellungen außer Kraft setzen, stellen Sie sicher, dass den geeigneten Benutzern die Aktivierungsberechtigungen in der anwendungsspezifischen Zugriffssteuerungsliste mit den Startberechtigungen zugewiesen wird. Andernfalls müssen Sie die anwendungsspezifische Zugriffssteuerungsliste mit den Startberechtigungen ändern, um den geeigneten Benutzern die Aktivierungsrechte zu erteilen, damit Anwendungen und Windows-Komponenten, die DCOM verwenden, ordnungsgemäß ausgeführt werden können.

Hinweis: Weitere Informationen zu den standardmäßigen COM-Computerstarteinschränkungen, die unter Windows XP mit SP2 angewendet werden, finden Sie im Handbuch „Verwalten der Funktionen von Windows XP Service Pack 2 mithilfe von Gruppenrichtlinien“ (in englischer Sprache) unter www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx. Informationen zu den Einschränkungen, die unter Windows Server 2003 mit SP1 angewendet werden, finden Sie im Abschnitt „DCOM Security Enhancements“ im Handbuch „Änderungen an der Funktionalität in Microsoft Windows Server 2003 Service Pack 1“ (in englischer Sprache) unter www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/ed9975ba-3933-4e28-bcb4-72b80d7865b7.mspx. Weitere Informationen zu den Startberechtigungen finden Sie auf der Seite „Startberechtigung“ (in englischer Sprache) auf der MSDN-Website unter https://go.microsoft.com/fwlink/?LinkId=20924.

Geräte: Entfernen ohne vorherige Anmeldung erlauben

Durch diese Richtlinieneinstellung wird festgelegt, ob Benutzer sich anmelden müssen, um eine Berechtigung zum Entfernen eines tragbaren Computers aus einer Dockingstation zu erhalten. Bei Aktivierung dieser Richtlinieneinstellung können Benutzer den Computer durch Drücken Auswurftaste am angedockten, tragbaren Gerät sicher abdocken. Bei Deaktivierung dieser Richtlinieneinstellung müssen Benutzer sich anmelden, um eine Berechtigung zum Abdocken des Computers zu erhalten. Nur Benutzer mit dem Recht zum Entfernen eines Computers aus der Dockingstation können diese Berechtigung erhalten.

Hinweis: Diese Richtlinieneinstellung sollte nur für tragbare Computer deaktiviert werden, die nicht mechanisch abgedockt werden können. Computer mit der Möglichkeit zum mechanischen Abdocken können vom Benutzer physisch entfernt werden, unabhängig von der Verwendung der Abdockfunktion von Windows.

Für die Einstellung Geräte: Entfernen ohne vorherige Anmeldung erlauben sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Bei Aktivierung dieser Richtlinieneinstellung kann jeder Benutzer mit physischem Zugriff auf tragbare Computer in Dockingstationen diese Computer entfernen und u. U. manipulieren. Für Computer ohne Dockingstationen hat diese Richtlinieneinstellung keine Auswirkungen.

Gegenmaßnahme

Deaktivieren Sie die Einstellung Geräte: Entfernen ohne vorherige Anmeldung erlauben.

Mögliche Auswirkung

Benutzer mit angedockten Computern müssen sich an der lokalen Konsole anmelden, bevor sie ihre tragbaren Computer abdocken können.

Geräte: Formatieren und Auswerfen von Wechselmedien zulassen

Durch diese Richtlinieneinstellung wird festgelegt, wer Wechselmedien formatieren und auswerfen darf.

Für die Einstellung Geräte: Formatieren und Auswerfen von Wechselmedien zulassen sind folgende Werte möglich:

• Administratoren

• Administratoren und Hauptbenutzer

• Administratoren und interaktive Benutzer

• Nicht definiert

Sicherheitsanfälligkeit

Benutzer können Daten auf Wechselmedien möglicherweise auf einen Computer verschieben, auf dem Sie Administratorrechte haben. Der Benutzer kann in diesem Fall beliebige Dateien in Besitz nehmen, sich selbst Vollzugriff erteilen und beliebige Dateien anzeigen oder ändern. Der Vorteil dieser Richtlinieneinstellung wird durch die Tatsache gemindert, dass Medien bei den meisten Wechselspeichergeräten auch durch Drücken einer mechanischen Taste ausgeworfen werden können.

Gegenmaßnahme

Legen Sie für die Einstellung Geräte: Formatieren und Auswerfen von Wechselmedien zulassen den Wert Administratoren fest.

Mögliche Auswirkung

NTFS-formatierte Wechselmedien können nur von Administratoren ausgeworfen werden.

Geräte: Anwendern das Installieren von Druckertreibern nicht erlauben

Ein Computer kann nur dann auf einem Netzwerkdrucker drucken, wenn der Treiber für diesen Netzwerkdrucker auf dem lokalen Computer installiert ist. Durch die Einstellung Geräte: Anwendern das Installieren von Druckertreibern nicht erlauben wird festgelegt, welche Benutzer beim Hinzufügen eines Netzwerkdruckers einen Druckertreiber installieren können. Wenn Sie diese Richtlinieneinstellung aktivieren, sind nur Mitglieder der Gruppen Administratoren und Hauptbenutzer berechtigt, beim Hinzufügen eines Netzwerkdruckers einen Druckertreiber zu installieren. Wenn Sie diese Richtlinieneinstellung deaktivieren, kann jeder Benutzer beim Hinzufügen eines Netzwerkdruckers einen Druckertreiber installieren. Diese Richtlinieneinstellung verhindert, dass normale Benutzer nicht vertrauenswürdige Druckertreiber herunterladen und installieren können.

Hinweis: Diese Richtlinieneinstellung hat keine Auswirkungen, wenn ein Administrator einen vertrauenswürdigen Pfad zum Herunterladen von Druckertreibern konfiguriert hat. Bei Konfiguration vertrauenswürdiger Pfade versucht das Drucksubsystem, den vertrauenswürdigen Pfad zum Herunterladen des Treibers zu verwenden. Gelingt der Download auf dem vertrauenswürdigen Pfad, kann der Treiber von jedem Benutzer installiert werden. Schlägt der Download fehl, wird der Treiber nicht installiert und der Netzwerkdrucker nicht hinzugefügt.

Für die Einstellung Geräte: Anwendern das Installieren von Druckertreibern nicht erlauben sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

In einigen Organisationen kann es sinnvoll sein, den Benutzern das Installieren von Druckertreibern auf ihren Arbeitsstationen zu ermöglichen. Bei Servern sollte den Benutzern diese Berechtigung jedoch nicht erteilt werden. Die Installation eines Druckertreibers auf einem Server kann dazu führen, dass der Computer instabil wird. Bei Servern sollte diese Berechtigung nur Administratoren erteilt werden. Ein böswilliger Benutzer könnte versuchen, durch Installieren eines ungeeigneten Druckertreibers eine Beschädigung des Computers herbeizuführen. Es kann auch sein, dass ein Benutzer versehentlich schädlichen Code installiert, der als Druckertreiber getarnt ist.

Gegenmaßnahme

Setzen Sie die Einstellung Geräte: Anwendern das Installieren von Druckertreibern nicht erlauben auf Aktiviert.

Mögliche Auswirkung

Ausschließlich Benutzer mit Administratorrechten, Hauptbenutzer oder Serveroperatoren dürfen Drucker auf den Servern installieren. Wenn diese Richtlinieneinstellung aktiviert ist, der Treiber für einen Netzwerkdrucker jedoch bereits auf dem lokalen Computer vorhanden ist, können Benutzer den Netzwerkdrucker trotzdem hinzufügen.

Geräte: Zugriff auf CD-ROM-Laufwerke auf lokal angemeldete Benutzer beschränken

Durch diese Richtlinieneinstellung wird festgelegt, ob ein CD-ROM-Laufwerk gleichzeitig für lokale Benutzer und Remotebenutzer zugänglich ist. Wenn diese Richtlinieneinstellung aktiviert ist, können nur interaktiv angemeldete Benutzer auf Wechselmedien im CD-ROM-Laufwerk zugreifen. Wenn diese Richtlinieneinstellung aktiviert und niemand interaktiv angemeldet ist, kann über das Netzwerk auf das CD-ROM-Laufwerk zugegriffen werden.

Für die Einstellung Geräte: Zugriff auf CD-ROM-Laufwerke auf lokal angemeldete Benutzer beschränken sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein Remotebenutzer kann möglicherweise auf eine bereitgestellte CD-ROM zugreifen, die vertrauliche Informationen enthält. Das Risiko ist verhältnismäßig gering, da CD-ROM-Laufwerke nicht automatisch als Netzwerkfreigaben zur Verfügung gestellt werden, sondern von Administratoren gezielt freigegeben werden müssen. In einigen Fällen kann es jedoch sinnvoll sein, dass Administratoren den Netzwerkbenutzern die Berechtigung zum Anzeigen von Daten oder Ausführen von Anwendungen über Wechselmedien auf dem Server verweigern können.

Gegenmaßnahme

Aktivieren Sie die Einstellung Geräte: Zugriff auf CD-ROM-Laufwerke auf lokal angemeldete Benutzer beschränken.

Mögliche Auswirkung

Benutzer, die über das Netzwerk eine Verbindung mit dem Server herstellen, können die auf dem Server installierten CD-ROM-Laufwerke nicht verwenden, wenn ein Benutzer an der lokalen Konsole des Servers angemeldet ist. Systemprogramme, die den Zugriff auf das CD-ROM-Laufwerk erfordern, können nicht ausgeführt werden. Wenn z. B. der Dienst „Volumeschattenkopie“ versucht, auf alle bei Computerinitialisierung vorhandenen CD-ROM-Laufwerke und Diskettenlaufwerke zuzugreifen und der Zugriff auf eines dieser Laufwerke nicht möglich ist, kann der Dienst nicht ausgeführt werden. Dieser Umstand ist die Ursache für das Fehlschlagen des Windows-Sicherungsprogramms, wenn für den Sicherungsauftrag Volumeschattenkopien angegeben werden. Sicherungssysteme von Drittanbietern, die Volumenschattenkopien verwenden, schlagen ebenfalls fehl. Diese Richtlinieneinstellung ist nicht für Computer geeignet, die Netzwerkbenutzern als CD-Jukebox zur Verfügung stehen.

Geräte: Zugriff auf Diskettenlaufwerke auf lokal angemeldete Benutzer beschränken

Durch diese Richtlinieneinstellung wird festgelegt, ob Wechselmedien im Diskettenlaufwerk gleichzeitig für lokale Benutzer und Remotebenutzer zugänglich sind. Wenn diese Richtlinieneinstellung aktiviert ist, können nur interaktiv angemeldete Benutzer auf Wechselmedien im Diskettenlaufwerk zugreifen. Wenn diese Richtlinieneinstellung aktiviert und niemand interaktiv angemeldet ist, kann über das Netzwerk auf das Diskettenlaufwerk zugegriffen werden.

Für die Einstellung Geräte: Zugriff auf Diskettenlaufwerke auf lokal angemeldete Benutzer beschränken sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein Remotebenutzer kann möglicherweise auf eine bereitgestellte Diskette zugreifen, die vertrauliche Informationen enthält. Das Risiko ist verhältnismäßig gering, da Diskettenlaufwerke nicht automatisch als Netzwerkfreigaben zur Verfügung gestellt werden, sondern von Administratoren gezielt freigegeben werden müssen. In einigen Fällen kann es jedoch sinnvoll sein, dass Administratoren den Netzwerkbenutzern die Berechtigung zum Anzeigen von Daten oder Ausführen von Anwendungen über Wechselmedien auf dem Server verweigern können.

Gegenmaßnahme

Aktivieren Sie die Einstellung Geräte: Zugriff auf Diskettenlaufwerke auf lokal angemeldete Benutzer beschränken.

Mögliche Auswirkung

Benutzer, die über das Netzwerk eine Verbindung mit dem Server herstellen, können die auf dem Server installierten Diskettenlaufwerke nicht verwenden, wenn ein Benutzer an der lokalen Konsole des Servers angemeldet ist. Systemprogramme, die den Zugriff auf das Diskettenlaufwerk erfordern, können nicht ausgeführt werden. Wenn z. B. der Dienst „Volumeschattenkopie“ versucht, auf alle bei Computerinitialisierung vorhandenen CD-ROM-Laufwerke und Diskettenlaufwerke zuzugreifen und der Zugriff auf eines dieser Laufwerke nicht möglich ist, kann der Dienst nicht ausgeführt werden. Dieser Umstand ist die Ursache für das Fehlschlagen des Windows-Sicherungsprogramms, wenn für den Sicherungsauftrag Volumeschattenkopien angegeben werden. Sicherungssysteme von Drittanbietern, die Volumenschattenkopien verwenden, schlagen ebenfalls fehl.

Geräte: Verhalten bei der Installation von nicht signierten Treibern

Durch diese Richtlinieneinstellung wird festgelegt, was geschieht, wenn versucht wird, über die Setup-API (Application Programming Interface) einen Gerätetreiber zu installieren, der vom Windows Hardware Quality Lab (WHQL) nicht zertifiziert und signiert wurde.

Für die Einstellung Geräte: Verhalten bei der Installation von nichtsignierten Treibern sind folgende Werte möglich:

• Ohne Warnung akzeptieren

• Warnen, aber Installation erlauben

• Installation nicht erlauben

• Nicht definiert

Sicherheitsanfälligkeit

Durch diese Richtlinieneinstellung wird die Installation von nicht signierten Treibern verhindert, oder der Administrator wird gewarnt, wenn ein solcher Treiber installiert wird. Dadurch kann verhindert werden, dass über die Setup-API Treiber installiert werden, die nicht für die Ausführung unter Windows XP oder Windows Server 2003 zertifiziert sind. Angriffe, bei denen versucht wird, schädliche SYS-Dateien zu kopieren und für den Start als Systemdienst zu registrieren, können durch diese Richtlinieneinstellung nicht verhindert werden.

Gegenmaßnahme

Legen Sie für die Einstellung Geräte: Verhalten bei der Installation von nichtsignierten Treibern den Wert Warnen, aber Installation erlauben fest. Dies ist die Standardkonfiguration für Windows XP mit SP2. Die Standardkonfiguration für Windows Server 2003 ist Nicht definiert.

Mögliche Auswirkung

Benutzer, die über ausreichende Berechtigungen zum Installieren von Gerätetreibern verfügen, können nicht signierte Gerätetreiber installieren. Diese Funktion kann jedoch u. U. Stabilitätsprobleme für Server verursachen. Ein weiteres potenzielles Problem bei der Konfiguration Warnen, aber Installation erlauben liegt in der Ausführung von unbeaufsichtigten Installationsskripts, die bei der Installation von nicht signierten Treibern fehlschlagen.

Domänencontroller: Serveroperatoren das Einrichten von geplanten Tasks erlauben

Durch diese Richtlinieneinstellung wird festgelegt, ob Serveroperatoren Aufträge mit der AT-Zeitplanfunktion senden können.

Hinweis: Diese Sicherheitsoption betrifft nur die AT-Zeitplanfunktion. Sie bezieht sich nicht auf den Taskplaner.

Für die Einstellung Domänencontroller: Serveroperatoren das Einrichten von geplanten Tasks erlauben sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Bei Aktivierung dieser Richtlinieneinstellung werden die von Serveroperatoren über den AT-Dienst erstellten Aufträge im Kontext desselben Kontos ausgeführt, das für diesen Dienst verwendet wird. In der Standardeinstellung ist dies das lokale Systemkonto. Wenn Sie diese Richtlinieneinstellung aktivieren, können Serveroperatoren Aufgaben ausführen, die über das Systemkonto, aber normalerweise nicht von ihnen ausgeführt werden können, wie z. B. das Hinzufügen ihres eigenen Kontos zur lokalen Gruppe Administratoren.

Gegenmaßnahme

Deaktivieren Sie die Einstellung Domänencontroller: Serveroperatoren das Einrichten von geplanten Tasks erlauben.

Mögliche Auswirkung

Für die meisten Organisationen sind die Auswirkungen gering. Benutzer (einschließlich der Mitglieder in der Gruppe Server-Operatoren) können geplante Aufträge weiterhin über den Taskplaner-Assistenten erstellen. Diese Aufträge werden jedoch im Kontext des Kontos ausgeführt, mit dem sich der Benutzer beim Einrichten des Auftrags authentifiziert.

Domänencontroller: Signaturanforderungen für LDAP-Server

Durch diese Richtlinieneinstellung wird festgelegt, ob der LDAP-Server (Lightweight Directory Access Protocol) von LDAP-Clients das Aushandeln einer Signatur erfordert.

Für die Einstellung Domänencontroller: Signaturanforderungen für LDAP-Server sind folgende Werte möglich:

• Keine. Eine Signatur ist zur Bindung an den Server nicht erforderlich. Wenn der Client eine Signatur anfordert, wird dies vom Server unterstützt.

• Signatur anfordern. Die LDAP-Signatur muss ausgehandelt werden, wenn TLS/SSL (Transport Layer Security/Secure Socket Layer) nicht verwendet wird.

• Nicht definiert.

Sicherheitsanfälligkeit

Nicht signierter Netzwerkdatenverkehr ist Man-in-the-Middle-Angriffen ausgesetzt. Bei solchen Angriffen fängt ein Eindringling Pakete zwischen Server und Client ab und leitet Sie verändert an den Server weiter. Bei einem LDAP-Server bedeutet dies, dass ein Angreifer einen Client veranlassen kann, Entscheidungen zu treffen, die auf falschen Datensätzen im LDAP-Verzeichnis basieren. Um dieses Risiko in einem Unternehmensnetzwerk zu verringern, können Sie zum Schutz der Netzwerkinfrastruktur strenge physische Sicherheitsmaßnahmen implementieren. Darüber hinaus können Man-in-the-Middle-Angriffe durch die Implementierung einer IPSec-Authentifizierung (Internet Protocol Security), die eine gegenseitige Authentifizierung durchführt und die Datenpaketintegrität für IP-Datenverkehr sicherstellt, wesentlich erschwert werden.

Gegenmaßnahme

Legen Sie für die Einstellung Domänencontroller: Signaturanforderungen für LDAP-Server den Wert Signatur anfordern fest.

Mögliche Auswirkung

Clients, die keine LDAP-Signatur unterstützen, können keine LDAP-Abfragen an die Domänencontroller ausführen. Auf allen Windows 2000-Computern in Ihrer Organisation, die von Windows Server 2003- oder Windows XP-Computern verwaltet werden und die Windows NT®-Anfrage/Antwort-Authentifizierung (NTLM) verwenden, muss Windows 2000 Service Packs 3 (SP3) installiert sein. Wahlweise kann auf diesen Clients auch die Registrierung geändert werden. Informationen dazu finden Sie im Microsoft Knowledge Base-Artikel Q325465 „Windows 2000-Domänencontroller benötigen SP3 oder höher bei Verwendung der Windows Server 2003-Verwaltungsprogramme“ unter https://support.microsoft.com/default.aspx?scid=325465. Außerdem unterstützen einige Betriebssysteme von Drittanbietern keine LDAP-Signatur. Bei Aktivierung dieser Richtlinieneinstellung können Clientcomputer, die diese Betriebssysteme verwenden, u. U. nicht auf die Domänenressourcen zugreifen.

Domänencontroller: Änderungen von Computerkontenkennwörtern verweigern

Durch diese Richtlinieneinstellung wird festgelegt, ob ein Domänencontroller Anforderungen zum Ändern der Computerkontenkennwörter zulässt oder verweigert.

Für die Einstellung Domänencontroller: Änderungen von Computerkontenkennwörtern verweigern sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Bei Aktivierung dieser Richtlinieneinstellung auf allen Domänencontrollern in einer Domäne können Domänenmitglieder ihre Computerkontenkennwörter nicht ändern, wodurch diese Kennwörter einem erhöhten Angriffsrisiko ausgesetzt sind.

Gegenmaßnahme

Deaktivieren Sie die Einstellung Domänencontroller: Änderungen von Computerkontenkennwörtern verweigern.

Mögliche Auswirkung

Keine. Hierbei handelt es sich um die Standardkonfiguration.

Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (mehrere in Zusammenhang stehende Einstellungen)

Durch die folgenden Richtlinieneinstellungen wird festgelegt, ob ein sicherer Kanal mit einem Domänencontroller eingerichtet werden kann, der nicht in der Lage ist, den Datenverkehr des sicheren Kanals zu signieren oder zu verschlüsseln:

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

• Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln (wenn möglich)

• Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich)

Bei Aktivierung der Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) wird die Einrichtung eines sicheren Kanals mit einem Domänencontroller verhindert, der den Datenverkehr des sicheren Kanals nicht signieren oder verschlüsseln kann.

Um den Authentifizierungsdatenverkehr vor Man-in-the-Middle- und Replay-Angriffen oder sonstigen Netzwerkangriffen zu schützen, erstellen Windows-Computer einen Kommunikationskanal mit NetLogon, der als sicherer Kanal (Secure Channel) bezeichnet wird. Dieser Kanal wird zur Authentifizierung von Computerkonten sowie von Benutzerkonten verwendet, wenn ein Remotebenutzer eine Verbindung zu einer Netzwerkressource herstellt und das Benutzerkonto zu einer vertrauenswürdigen Domäne gehört. Die Authentifizierung wird als Pass-Through-Authentifizierung bezeichnet und ermöglicht einem Computer, der einer Domäne beigetreten ist, den Zugriff auf die Benutzerkontendatenbank in dieser Domäne und in jeder anderen vertrauenswürdigen Domäne.

Hinweis: Zur Aktivierung der Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) auf einer Mitgliedsarbeitsstation oder einem Server müssen alle Domänencontroller in der Domäne, zu der das Mitglied gehört, in der Lage sein, den Datenverkehr des sicheren Kanals zu signieren und zu verschlüsseln. Um diese Bedingung zu erfüllen, müssen alle diese Domänencontroller unter Windows NT 4.0 mit Service Pack 6a oder einer höheren Version des Windows-Betriebssystem ausgeführt werden.

Bei Aktivierung der Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) wird automatisch die Einstellung Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich) aktiviert.

Für diese Richtlinieneinstellung sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Wenn ein Windows Server 2003-, Windows XP-, Windows 2000- oder Windows NT-Computer einer Domäne beitritt, wird ein Computerkonto erstellt. Nach dem Beitritt zur Domäne verwendet der Computer bei jedem Neustart das Kennwort für dieses Konto, um einen sicheren Kanal mit dem Domänencontroller für seine Domäne zu erstellen. Über den sicheren Kanal gesendete Anforderungen werden authentifiziert, und vertrauliche Informationen (z. B. Kennwörter) werden verschlüsselt. Für den Kanal wird jedoch keine Integritätsprüfung ausgeführt, und nicht alle Informationen werden verschlüsselt. Wenn ein Computer so konfiguriert wird, dass Daten des sicheren Kanals immer verschlüsselt oder signiert werden müssen, der Domänencontroller zur Signatur oder Verschlüsselung von Datenteilen des sicheren Kanals jedoch nicht in der Lage ist, können der Computer und der Domänencontroller keinen sicheren Kanal einrichten. Wenn der Computer so konfiguriert ist, dass Daten des sicheren Kanals nach Möglichkeit verschlüsselt oder signiert werden, kann ein sicherer Kanal eingerichtet werden. Der Grad der Verschlüsselung oder Signatur muss jedoch ausgehandelt werden.

Gegenmaßnahme

• Setzen Sie die Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) auf Aktiviert.

• Setzen Sie die Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln (wenn möglich) auf Aktiviert.

• Setzen Sie die Einstellung Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich) auf Aktiviert.

Mögliche Auswirkung

Sofern sie unterstützt wird, ist die digitale Verschlüsselung und Signatur des sicheren Kanals eine empfohlene Methode. Durch den sicheren Kanal werden die Anmeldeinformationen beim Senden zum Domänencontroller geschützt. Allerdings unterstützen nur Windows NT 4.0 Service Pack 6a (SP6a) und höhere Versionen des Windows-Betriebssystems eine digitale Verschlüsselung und Signatur des sicheren Kanals. Windows 98 Second Edition-Clients unterstützen diese Option nicht, es sei denn Dsclient ist installiert. Daher kann die Einstellung Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) nicht auf Domänencontrollern aktiviert werden, die Windows 98-Clients als Mitglieder der Domäne unterstützen. Folgende Auswirkungen sind möglich:

• Die Option zur Erstellung oder Entfernung der Vertrauensstellungen von Computern mit einer älteren Windows-Version kann deaktiviert sein.

• Die Option zur Anmeldung von Clients mit einer älteren Windows-Version wird deaktiviert.

• Die Option zur Authentifizierung von Benutzern anderer Domänen einer vertrauenswürdigen Domäne mit einer älteren Windows-Version wird deaktiviert.

Sie können diese Richtlinieneinstellung aktivieren, nachdem Sie alle Windows 9x-Clients aus der Domäne entfernt und alle Windows NT 4.0-Server und -Domänencontroller in vertrauenswürdigen/vertrauenden Domänen auf Windows NT 4.0 mit SP6a aktualisiert haben. Die anderen beiden Richtlinieneinstellungen Domänenmitglied: Daten des sicheren Kanals digital verschlüsseln (wenn möglich) und Domänenmitglied: Daten des sicheren Kanals digital signieren (wenn möglich) können auf allen Computern in der Domäne aktiviert werden, die diese Einstellungen unterstützen. Dies hat keine Auswirkungen auf Clients mit einer älteren Windows-Version und auf Anwendungen.

Domänenmitglied: Änderungen von Computerkontenkennwörtern deaktivieren

Durch diese Richtlinieneinstellung wird festgelegt, ob Domänenmitglieder ihre Computerkontenkennwörter regelmäßig ändern müssen. Bei Aktivierung dieser Richtlinieneinstellung kann das Domänenmitglied das Computerkontenkennwort nicht ändern. Bei Deaktivierung dieser Richtlinieneinstellung kann das Domänenmitglied das Computerkontenkennwort gemäß des für die Einstellung Domänenmitglied: Maximalalter von Computerkontenkennwörtern festgelegten Wertes ändern. (Die Standardeinstellung ist alle 30 Tage.)

Vorsicht: Aktivieren Sie diese Richtlinieneinstellung nicht. Die Computerkontenkennwörter werden zur Einrichtung der Kommunikation über einen sicheren Kanal zwischen Mitgliedern und Domänencontrollern und innerhalb der Domäne zwischen den Domänencontrollern selbst verwendet. Nach der Einrichtung dieser Kommunikation werden über den sicheren Kanal vertrauliche Daten ausgetauscht, die für Authentifizierungs- und Autorisierungsentscheidungen notwendig sind.

Diese Richtlinieneinstellung sollte nicht zur Unterstützung von Dual-Boot-Szenarien aktiviert werden, bei denen dasselbe Computerkonto verwendet wird. Verwenden Sie zur Unterstützung eines solchen Szenarios für zwei Installationen, die zur selben Domäne gehören, verschiedene Computernamen für die Installationen. Diese Richtlinieneinstellung wurde Windows hinzugefügt, um die Lagerung von vorinstallierten Computern zur späteren Produktionseinführung für Organisationen zu vereinfachen. Auf diese Weise müssen die Computer der Domäne nicht erneut hinzugefügt werden. Diese Richtlinieneinstellung wird auch manchmal für abgebildete Computer oder für Computer mit Änderungsschutz auf Hardware- oder Softwareebene verwendet. Bei Anwendung der richtigen Abbilderstellungsverfahren ist die Verwendung dieser Richtlinie für abgebildete Computer überflüssig.

Für die Einstellung Domänenmitglied: Änderungen von Computerkontenkennwörtern deaktivieren sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Die Standardkonfiguration für zur Domäne gehörende Windows Server 2003-Computer erfordert alle 30 Tage automatisch eine Änderung der Kontenkennwörter. Bei Deaktivierung dieser Richtlinieneinstellung werden für Computer mit Windows Server 2003 dieselben Kennwörter wie für ihre jeweiligen Computerkonten verwendet. Bei Computern, die ihre Kontenkennwörter nicht mehr automatisch ändern können, besteht das Risiko, dass ein Angreifer das Kennwort für das Domänenkonto des Computers herausfindet.

Gegenmaßnahme

Stellen Sie sicher, dass die Einstellung Domänenmitglied:Änderungen von Computerkontenkennwörtern deaktivieren auf Deaktiviert gesetzt ist.

Mögliche Auswirkung

Keine. Hierbei handelt es sich um die Standardkonfiguration.

Domänenmitglied: Maximalalter von Computerkennwörtern

Durch diese Richtlinieneinstellung wird das maximal zulässige Alter für Computerkontenkennwörter festgelegt. Die Einstellung gilt auch für Windows 2000-Computer, sie ist auf diesen Computern jedoch nicht über die Tools des Sicherheitskonfigurations-Managers verfügbar.

Für die Einstellung Domänenmitglied: Maximalalter von Computerkontenkennwörtern sind folgende Werte möglich:

• Benutzerdefinierte Anzahl von Tagen zwischen 0 und 999

• Nicht definiert

Sicherheitsanfälligkeit

In Active Directory-Domänen hat jeder Computer ein Konto und ein Kennwort, genau wie jeder Benutzer. Standardmäßig ändern Domänenmitglieder ihre Domänenkennwörter automatisch alle 30 Tage. Eine erhebliche Erhöhung dieses Intervalls oder die Einstellung auf 0, damit die Kennwörter von Computern nicht mehr geändert werden müssen, gibt Angreifern mehr Zeit, um über Brute-Force-Angriffe das Kennwort von Computerkonten zu erraten.

Gegenmaßnahme

Legen Sie für die Einstellung Domänenmitglied: Maximalalter von Computerkontenkennwörtern einen Wert von 30 Tagen fest.

Mögliche Auswirkung

Keine. Hierbei handelt es sich um die Standardkonfiguration.

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

Durch diese Richtlinieneinstellung wird festgelegt, ob ein sicherer Kanal mit einem Domänencontroller eingerichtet werden kann, der nicht in der Lage ist, den Datenverkehr des sicheren Kanals mit einem starken 128-Bit-Sitzungsschlüssel zu verschlüsseln. Bei Aktivierung dieser Richtlinieneinstellung wird die Einrichtung eines sicheren Kanals mit einem Domänencontroller verhindert, der den Datenverkehr des sicheren Kanals nicht mit einem starken Schlüssel verschlüsseln kann. Bei Deaktivierung dieser Richtlinieneinstellung sind 64-Bit-Sitzungsschlüssel zulässig.

Hinweis: Zur Aktivierung dieser Richtlinieneinstellung auf einer Mitgliedsarbeitsstation oder einem Server müssen alle Domänencontroller in der Domäne, zu der das Mitglied gehört, in der Lage sein, den Datenverkehr des sicheren Kanals mit einem starken 128-Bit-Schlüssel zu verschlüsseln. Dies bedeutet, dass alle diese Domänencontroller unter Windows 2000 oder höher ausgeführt werden müssen.

Für die Einstellung Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Sitzungsschlüssel, die zum Einrichten einer Kommunikation über einen sicheren Kanal zwischen Domänencontrollern und Mitgliedscomputern verwendet werden, sind in Windows 2000 viel stärker als in früheren Microsoft-Betriebssystemen.

Sie sollten nach Möglichkeit die Vorteile der starken Sitzungsschlüssel nutzen, damit die Kommunikation über einen sicheren Kanal vor Sitzungsübernahme- und Lauschangriffen im Netzwerk geschützt wird. (Lauschangriffe sind Angriffe auf Netzwerkdaten, um diese während der Übertragung zu lesen oder zu manipulieren. Der Absender der Daten kann ausgeblendet oder geändert werden, oder die Daten werden vollständig umgeleitet.)

Gegenmaßnahme

Setzen Sie die Einstellung Domänenmitglied: Starker Sitzungsschlüssel erforderlich (Windows 2000 oder höher) auf Aktiviert.

Bei Aktivierung dieser Richtlinieneinstellung erfordert der ausgehende Datenverkehr des sicheren Kanals einen starken Verschlüsselungsschlüssel (Windows 2000 oder höher). Bei Deaktivierung dieser Richtlinieneinstellung wird die Schlüsselstärke ausgehandelt. Aktivieren Sie diese Richtlinieneinstellung nur, wenn die Domänencontroller in allen vertrauenswürdigen Domänen starke Schlüssel unterstützen. In der Standardeinstellung ist diese Richtlinie deaktiviert.

Mögliche Auswirkung

Computer, bei denen diese Richtlinieneinstellung aktiviert ist, können keiner Windows NT 4.0-Domäne beitreten, und die ordnungsgemäße Funktionsweise von Vertrauensstellungen zwischen Active Directory-Domänen und Domänen des Typs Windows NT ist nicht sichergestellt. Darüber hinaus können Computer, die diese Richtlinieneinstellung nicht unterstützen, keiner Domäne beitreten, in der diese Richtlinieneinstellung auf Domänencontrollern aktiviert ist.

Interaktive Anmeldung: Letzten Benutzernamen nicht anzeigen

Durch diese Richtlinieneinstellung wird festgelegt, ob im Dialogfeld Windows-Anmeldung der Name des zuletzt am Computer angemeldeten Benutzers angezeigt wird. Bei Aktivierung dieser Richtlinieneinstellung wird der Name des zuletzt erfolgreich angemeldeten Benutzer nicht angezeigt. Bei Deaktivierung dieser Richtlinieneinstellung wird der Name des zuletzt angemeldeten Benutzer angezeigt.

Für die Einstellung Interaktive Anmeldung: Letzten Benutzernamen nicht anzeigen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein Angreifer mit Zugriff auf die Konsole (z. B. physischem Zugriff oder Zugriff über eine Terminaldienstverbindung zum Server) kann den Namen des zuletzt am Server angemeldeten Benutzers anzeigen. In diesem Fall kann der Angreifer versuchen, das Kennwort über Wörterbuchangriffe oder Brute-Force-Angriffe zu erraten, um sich anzumelden.

Gegenmaßnahme

Setzen Sie die Einstellung Interaktive Anmeldung: Letzten Benutzernamen nicht anzeigen auf Aktiviert.

Mögliche Auswirkung

Benutzer müssen bei jeder Serveranmeldung den Benutzernamen eingeben.

Interaktive Anmeldung: Kein STRG+ALT+ENTF erforderlich

Durch diese Richtlinieneinstellung wird festgelegt, ob Benutzer die Tastenkombination STRG+ALT+ENTF drücken müssen, bevor sie sich anmelden. Bei Aktivierung dieser Richtlinieneinstellung erfolgt die Benutzeranmeldung ohne diese Tastenkombination. Bei Deaktivierung dieser Richtlinieneinstellung müssen Benutzer die Tastenkombination STRG+ALT+ENTF drücken, bevor sie sich bei Windows anmelden, es sei denn, sie verwenden bei der Windows-Anmeldung eine Smartcard. Eine Smartcard ist ein fälschungssicheres Gerät zum Speichern von Sicherheitsinformationen.

Für die Einstellung Interaktive Anmeldung: Kein STRG+ALT+ENTF erforderlich sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Microsoft hat diese Funktion entwickelt, um die Windows-Anmeldung für Benutzer mit eingeschränkter Bewegungsfähigkeit zu erleichtern. Wenn die Tastenkombination STRG+ALT+ENTF nicht gedrückt werden muss, sind die Benutzer Angriffen zum Abfangen von Kennwörtern ausgesetzt. Wenn die Tastenkombination STRG+ALT+ENTF vor der Anmeldung erforderlich ist, werden die Benutzerkennwörter über einen vertrauenswürdigen Pfad kommuniziert.

Ein Angreifer kann einen Trojaner installieren, der wie das Standarddialogfeld für die Windows-Anmeldung aussieht, und damit das Kennwort des Benutzers abfangen. Der Angreifer kann sich dann unter Verwendung des betroffenen Kontos anmelden und dessen Benutzerberechtigungen ausnutzen.

Gegenmaßnahme

Setzen Sie die Einstellung Interaktive Anmeldung: Kein STRG+ALT+ENTF erforderlich auf Deaktiviert.

Mögliche Auswirkung

Wenn keine Smartcard zur Anmeldung verwendet wird, müssen Benutzer drei Tasten gleichzeitig drücken, bevor das Anmeldedialogfeld angezeigt wird.

Interaktive Anmeldung: Nachricht für Benutzer, die sich anmelden wollen

Die Einstellungen Interaktive Anmeldung: Nachricht für Benutzer, die sich anmelden wollen und Interaktive Anmeldung: Nachrichtentitel für Benutzer, die sich anmelden wollen hängen eng miteinander zusammen. Die erste Richtlinieneinstellung legt eine Textnachricht fest, die den Benutzern bei der Anmeldung angezeigt wird. Die zweite Richtlinieneinstellung legt den Titel fest, der in der Titelleiste des Fensters mit der Textnachricht angezeigt wird. Viele Organisationen verwenden diesen Text aus rechtlichen Gründen, z. B. um Benutzer auf die Auswirkungen eines Missbrauchs von Firmeninformationen hinzuweisen oder um sie davor zu warnen, dass ihre Aktionen überwacht werden.

Vorsicht: Windows XP Professional unterstützt Anmeldebanner, die länger als 512 Zeichen sein und außerdem Wagenrücklauf/Zeilenvorschub-Sequenzen enthalten können. Windows 2000-Clients können diese Nachrichten jedoch nicht interpretieren und anzeigen. Zum Erstellen einer Richtlinie für Anmeldenachrichten auf Windows 2000-Computern muss ein Computer verwendet werden, der unter Windows 2000 ausgeführt wird. Wenn Sie auf einem Computer mit Windows XP Professional versehentlich eine Richtlinie für Anmeldenachrichten erstellen und die Anmeldenachrichten auf Windows 2000-Computern nicht ordnungsgemäß angezeigt werden, gehen Sie folgendermaßen vor:

• Setzen Sie die Einstellung auf den Wert Nicht definiert zurück.

• Setzen Sie die Einstellung mit einem Windows 2000-Computer zurück.

Die einfache Änderung der ursprünglich unter Windows XP Professional definierten Anmeldenachricht auf einem Windows 2000-Computer ist nicht möglich. Sie müssen die Einstellung erst auf Nicht definiert zurücksetzen.

Für diese Richtlinieneinstellungen sind folgende Werte möglich:

• Benutzerdefinierter Text

• Nicht definiert

Sicherheitsanfälligkeit

Das Anzeigen einer Warnmeldung vor der Anmeldung kann einen Angriff u. U. verhindern, da der Angreifer vor der Sicherheitsverletzung über sein Fehlverhalten aufgeklärt wird. Dies kann auch dazu beitragen, dass Firmenrichtlinien stärker berücksichtigt werden, da Mitarbeiter während des Anmeldevorgangs über die entsprechende Richtlinie informiert werden.

Gegenmaßnahme

Legen Sie für die Einstellungen Interaktive Anmeldung: Nachricht für Benutzer, die sich anmelden wollen und Interaktive Anmeldung: Nachrichtentitel für Benutzer, die sich anmelden wollen einen für Ihre Organisation angemessenen Wert fest.

Hinweis: Alle angezeigten Warnmeldungen sollten von den juristischen Vertretern und der Personalabteilung der Organisation genehmigt werden.

Mögliche Auswirkung

Den Benutzern wird vor der Anmeldung an der Serverkonsole eine Nachricht in einem Dialogfeld angezeigt.

Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist)

Durch diese Richtlinieneinstellung wird die Anzahl der verschiedenen Benutzer festgelegt, die sich mit zwischengespeicherten Kontoinformationen bei einer Windows-Domäne anmelden können. Anmeldeinformationen für Domänenkonten können lokal zwischengespeichert werden, damit sich ein Benutzer selbst dann anmelden kann, wenn ein Domänencontroller bei späteren Anmeldungen nicht erreichbar ist. Durch diese Richtlinieneinstellung wird die Anzahl der verschiedenen Benutzer festgelegt, deren Anmeldeinformationen lokal zwischengespeichert werden.

Wenn ein Domänencontroller nicht erreichbar ist und die Anmeldeinformationen zwischengespeichert sind, wird dem Benutzer folgende Nachricht angezeigt:

Es konnte kein Domänencontroller für Ihre Domäne kontaktiert werden. Sie haben sich unter Verwendung zwischengespeicherter Konteninformationen angemeldet. Profiländerungen seit Ihrer letzten Anmeldung sind möglicherweise nicht verfügbar.

Wenn ein Domänencontroller nicht erreichbar ist und die Anmeldeinformationen nicht zwischengespeichert sind, wird dem Benutzer folgende Nachricht angezeigt:

Das System kann Sie jetzt nicht anmelden, da die Domäne <DOMÄNENNAME> nicht verfügbar ist.

Für die Einstellung Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist) sind folgende Werte möglich:

• Benutzerdefinierte Anzahl zwischen 0 und 50

• Nicht definiert

Sicherheitsanfälligkeit

Der für diese Richtlinieneinstellung festgelegte Wert gibt die Anzahl der Benutzer an, deren Anmeldeinformationen auf dem Server lokal zwischengespeichert werden. Wird für die Anzahl der Wert 10 festgelegt, werden vom Server die Anmeldeinformationen für 10 Benutzer zwischengespeichert. Wenn sich ein elfter Benutzer am Computer anmeldet, wird die älteste zwischengespeicherte Anmeldesitzung vom Server überschrieben.

Für Benutzer mit Zugriff auf die Serverkonsole werden die Anmeldeinformationen auf diesem Server zwischengespeichert. Ein Angreifer mit Zugriff auf das Dateisystem des Servers kann nach den zwischengespeicherten Informationen suchen und die Benutzerkennwörter mit einem Brute-Force-Angriff ermitteln.

Um das Risiko eines solchen Angriffs zu verringern, werden die Informationen von Windows verschlüsselt, und der physische Standort wird verschleiert.

Gegenmaßnahme

Legen Sie für die Einstellung Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist) den Wert 0 fest, wodurch die lokale Zwischenspeicherung von Anmeldeinformationen deaktiviert wird. Als zusätzliche Gegenmaßnahmen können starke Kennwortrichtlinien und physisch sichere Standorte für Computer erzwungen werden.

Mögliche Auswirkung

Wenn kein Domänencontroller zur Authentifizierung zur Verfügung steht, können sich die Benutzer an keinem Computer anmelden. Einige Organisationen werden bei Endbenutzercomputern für diese Einstellung möglicherweise den Wert 2 festlegen, insbesondere für mobile Benutzer. Der Konfigurationswert 2 bedeutet, dass die Anmeldeinformationen des Benutzers auch dann noch zwischengespeichert sind, wenn ein Mitglied der IT-Abteilung sich kurz zuvor an dem Computer für Systemwartungsarbeiten angemeldet hat. Mit dieser Methode können Benutzer sich an ihrem Computern anmelden, auch wenn sie derzeit keine Verbindung zum Netzwerk der Organisation hergestellt haben.

Interaktive Anmeldung: Anwender vor Ablauf des Kennworts zum Ändern des Kennworts auffordern

Durch diese Richtlinieneinstellung wird die Anzahl der Tage festgelegt, die Benutzer im Voraus auf den Ablauf ihrer Kennwörter hingewiesen werden. Durch diese Vorabwarnung hat der Benutzer Zeit, ein ausreichend sicheres Kennwort zu entwickeln.

Für die Einstellung Interaktive Anmeldung: Anwender vor Ablauf des Kennworts zum Ändern des Kennworts auffordern sind folgende Werte möglich:

• Benutzerdefinierte Anzahl von Tagen zwischen 1 und 999

• Nicht definiert

Sicherheitsanfälligkeit

Microsoft empfiehlt, ein regelmäßiges Ablaufen von Benutzerkennwörtern zu konfigurieren. Die Benutzer müssen eine Warnung erhalten, um zu verhindern, dass sie versehentlich aufgrund des Ablaufens ihres Kennworts auf dem Computer gesperrt werden. Dieser Umstand könnte bei Benutzern, die lokal auf das Netzwerk zugreifen, zu Verwirrungen führen, und über DFÜ- oder VPN-Verbindungen (Virtual Private Network) ist der Zugriff auf das Netzwerk Ihrer Organisation möglicherweise gar nicht mehr möglich.

Gegenmaßnahme

Legen Sie für die Einstellung Interaktive Anmeldung: Anwender vor Ablauf des Kennworts zum Ändern des Kennworts auffordern einen Wert von 14 Tagen fest.

Mögliche Auswirkung

Die Benutzer werden bei jeder Anmeldung bei der Domäne in einem Dialogfeld dazu aufgefordert, das Kennwort zu ändern, wenn ihr Kennwort so konfiguriert ist, dass es in 14 oder weniger Tagen abläuft.

Interaktive Anmeldung: Domänencontrollerauthentifizierung zum Aufheben der Sperrung der Arbeitsstation erforderlich

Zum Entsperren eines gesperrten Computers sind die Anmeldeinformationen erforderlich. Durch die Richtlinieneinstellung Interaktive Anmeldung: Domänencontrollerauthentifizierung zum Aufheben der Sperrung der Arbeitsstation erforderlich wird bei Domänencontrollern festgelegt, ob zum Entsperren eines Computers die Verbindung zu einem Domänencontroller notwendig ist. Bei Aktivierung dieser Einstellung muss ein Domänencontroller das zum Entsperren des Computers verwendete Domänenkonto authentifizieren. Bei Deaktivierung dieser Einstellung müssen die Anmeldeinformationen nicht von einem Domänencontroller bestätigt werden, damit ein Benutzer den Computer entsperren kann. Wenn jedoch für die Einstellung Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist) ein Wert größer als 0 festgelegt wurde, werden die zwischengespeicherten Anmeldeinformationen zum Entsperren des Computers verwendet.

Hinweis: Diese Einstellung gilt für Computer, auf denen Windows 2000 ausgeführt wird. Sie ist auf diesen Computern jedoch nicht über die Tools des Sicherheitskonfigurations-Managers verfügbar.

Für die Einstellung Interaktive Anmeldung: Domänencontrollerauthentifizierung zum Aufheben der Sperrung der Arbeitsstation erforderlich sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

In der Standardeinstellung werden die Anmeldeinformationen für alle lokal authentifizierten Benutzer im Arbeitsspeicher zwischengespeichert. Diese zwischengespeicherten Anmeldeinformationen werden vom Computer für jeden Anmeldeversuch zum Aufheben der Konsolensperrung verwendet. Bei Verwendung von zwischengespeicherten Anmeldeinformationen werden alle kürzlich vorgenommenen Kontoänderungen (z. B. Zuweisung von Benutzerrechten, Kontosperrung oder Kontodeaktivierung) nicht berücksichtigt oder erst nach der Kontoauthentifizierung angewendet. Benutzerberechtigungen werden nicht aktualisiert, und vor allem können deaktivierte Konten weiterhin zum Entsperren der Computerkonsole verwendet werden.

Gegenmaßnahme

Setzen Sie die Einstellung Interaktive Anmeldung: Domänencontrollerauthentifizierung zum Aufheben der Sperrung der Arbeitsstation erforderlich auf Aktiviert, und legen Sie für die Einstellung Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist) den Wert 0 fest.

Mögliche Auswirkung

Wenn die Konsole eines Computers gesperrt ist, entweder durch einen Benutzer oder automatisch durch ein Bildschirmschoner-Zeitlimit, kann die Sperrung der Konsole nur durch eine erneute Authentifizierung des Benutzers am Domänencontroller aufgehoben werden. Wenn kein Domänencontroller erreichbar ist, können die Benutzer die Sperrung ihrer Arbeitsstationen nicht aufheben. Wenn Sie für die Einstellung Interaktive Anmeldung: Anzahl zwischenzuspeichernder vorheriger Anmeldungen (für den Fall, dass der Domänencontroller nicht verfügbar ist) den Wert 0 festlegen, können sich Benutzer, deren Domänencontroller nicht verfügbar sind (z. B. mobile Benutzer oder Remotebenutzer), nicht anmelden.

Interaktive Anmeldung: Smartcard erforderlich

Durch diese Richtlinieneinstellung wird festgelegt, dass Benutzer sich mit einer Smartcard am Computer anmelden müssen.

Hinweis: Diese Einstellung gilt für Computer, auf denen Windows 2000 ausgeführt wird. Sie ist auf diesen Computern jedoch nicht über die Tools des Sicherheitskonfigurations-Managers verfügbar.

Für die Einstellung Interaktive Anmeldung: Smartcard erforderlich sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Durch die Anforderung, dass die Benutzer lange, komplexe Kennwörter zur Authentifizierung verwenden müssen, wird die Netzwerksicherheit erhört, insbesondere wenn die Benutzer ihre Kennwörter regelmäßig ändern müssen. Dieser Ansatz verringert das Risiko, dass ein Angreifer das Kennwort eines Benutzers durch einen Brute-Force-Angriff erraten kann. Es ist jedoch schwer, die Verwendung von sicheren Kennwörtern bei den Benutzern durchzusetzen. Außerdem sind selbst sichere Kennwörter dem Risiko von erfolgreichen Brute-Force-Angriffen ausgesetzt, wenn dem Angreifer ausreichend Zeit und ein Computer mit entsprechender Verarbeitungsleistung zur Verfügung stehen.  Die Sicherheit verbessert sich erheblich, wenn anstelle von Kennwörtern Smartcards zur Authentifizierung verwendet werden, da es mit der derzeit verfügbaren Technologie für einen Angreifer nahezu unmöglich ist, eine Benutzeridentität vorzutäuschen. Smartcards, die die Eingabe einer PIN (Personal Identification Number) erfordern, dienen einer Authentifizierung mit zwei Faktoren. Dies bedeutet, dass der Benutzer sowohl die Smartcard besitzen als auch die zugehörige PIN kennen muss. Für einen Angreifer, der den Datenverkehr zur Authentifizierung zwischen dem Computer des Benutzers und dem Domänencontroller aufzeichnet, ist es äußerst schwierig, die Daten zu entschlüsseln. Auch wenn dies gelingen sollte, wird bei der nächsten Netzwerkanmeldung des Benutzers ein neuer Sitzungsschlüssel zum Verschlüsseln des Datenverkehrs zwischen dem Benutzer und dem Domänencontroller generiert.

Gegenmaßnahme

Geben Sie für vertrauliche Konten Smartcards an die Benutzer aus, und setzen Sie die Einstellung Interaktive Anmeldung: Smartcard erforderlich auf Aktiviert.

Mögliche Auswirkung

Alle Benutzer müssen Smartcards zur Netzwerkanmeldung verwenden. Zu diesem Zweck muss die Organisation eine zuverlässige Infrastruktur öffentlicher Schlüssel (PKI, Public Key Infrastructure) installiert haben und über ausreichend Smartcards und Lesegeräte für alle Benutzer verfügen. Diese Anforderungen stellen eine erhebliche Herausforderung dar, da die Planung und Bereitstellung dieser Technologien Sachverstand und ausreichende Ressourcen erfordern. Windows Server 2003 verfügt jedoch über die hoch entwickelten Zertifikatsdienste zur Implementierung und Verwaltung von Zertifikaten. Bei Kombination der Zertifikatsdienste mit Windows XP werden Funktionen wie die automatische Registrierung und Erneuerung von Benutzern und Computern verfügbar.

Interaktive Anmeldung: Verhalten beim Entfernen von Smartcards

Durch diese Richtlinieneinstellung wird festgelegt, was geschieht, wenn die Smartcard eines angemeldeten Benutzers aus dem Smartcard-Lesegerät entfernt wird.

Für die Einstellung Interaktive Anmeldung: Verhalten beim Entfernen von Smartcards sind folgende Werte möglich:

• Keine Aktion

• Arbeitsstation sperren

• Abmeldung erzwingen

• Nicht definiert

Sicherheitsanfälligkeit

Wenn Smartcards für die Authentifizierung verwendet werden, sollten die Computer beim Entfernen der Karte automatisch gesperrt werden. Dadurch sind Computer auch dann vor dem Zugriff durch unbefugte Angreifer geschützt, wenn die Benutzer das manuelle Sperren der Arbeitsstation vergessen haben.

Gegenmaßnahme

Legen Sie für die Einstellung Interaktive Anmeldung: Verhalten beim Entfernen von Smartcards den Wert Arbeitsstation sperren fest.

Wenn Sie für diese Richtlinieneinstellung im Dialogfeld Eigenschaften die Option Arbeitsstation sperren wählen, wird die Arbeitsstation beim Entfernen der Smartcard gesperrt. Die Benutzer können den Arbeitsplatz verlassen und ihre Smartcards mitnehmen und trotzdem eine geschützte Sitzung aufrechterhalten.

Wenn für diese Richtlinieneinstellung im Dialogfeld Eigenschaften die Option Abmelden erzwingen ausgewählt wurde, wird der Benutzer beim Entfernen der Smartcard automatisch abgemeldet.

Mögliche Auswirkung

Die Benutzer müssen bei der Rückkehr an ihre Arbeitsstationen die Smartcard wieder einführen und ihre PIN erneut eingeben.

Microsoft-Netzwerk (Client und Server): Kommunikation digital signieren (vier in Zusammenhang stehende Einstellungen)

Für die digitale Signatur der SMB-Kommunikation (Server Message Block) stehen vier separate Einstellungen zur Verfügung:

• Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)

• Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)

• Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)

• Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt)

Für diese Richtlinieneinstellungen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Die Implementierung einer digitalen Signatur in Hochsicherheitsnetzwerken verringert die Gefahr, das jemand unerlaubt die Identität von Servern und Clients annimmt. Diese Art von Identitätsannahme wird auch als „Session Hijacking“ (Sitzungsübernahme) bezeichnet. Hierbei werden Tools verwendet, mit denen Angreifer, die Zugriff auf dasselbe Netzwerk wie der Server oder Client haben, die aktuelle Sitzung unterbrechen, beenden oder übernehmen können. Angreifer können nicht signierte SMB-Pakete abfangen und ändern und anschließend den Datenverkehr so manipulieren und weiterleiten, dass der Server u. U. unerwünschte Aktionen ausführt. Der Angreifer könnte auch nach einer legitimen Authentifizierung als Server oder Client auftreten und nicht autorisierten Datenzugriff erhalten.

SMB wird als Protokoll zur gemeinsamen Ressourcennutzung von vielen Microsoft-Betriebssystemen unterstützt. Es bildet die Grundlage von NetBIOS und vielen anderen Protokollen. Eine SMB-Signatur authentifiziert sowohl den Benutzer als auch den Server, auf dem die Daten gehostet werden. Wenn die Authentifizierung einer Seite fehlschlägt, findet keine Datenübertragung statt.

Hinweis: Eine weitere Gegenmaßnahme zum Schutz des gesamten Netzwerkdatenverkehrs ist die Implementierung einer digitalen Signatur mit IPSec. Für die IPSec-Verschlüsselung und -Signatur sind hardwaregestützte Beschleunigerkarten verfügbar, die zur Verringerung der Leistungsbeeinträchtigungen bei Server-CPUs verwendet werden können. Für die SMB-Signatur sind solche Beschleunigerkarten nicht verfügbar.

Gegenmaßnahme

Konfigurieren Sie die Einstellungen folgendermaßen:

• Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) – Deaktiviert

• Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) – Deaktiviert

• Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) – Aktiviert

• Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) – Aktiviert

In einigen Quellen wird empfohlen, alle Einstellungen auf Aktiviert zu setzen. Durch diese Konfiguration kann jedoch die Leistung auf Clientcomputern verringert und die Kommunikation mit älteren SMB-Anwendungen und Betriebssystemen verhindert werden.

Mögliche Auswirkung

Die Implementierung der SMB-Datei und des Druckfreigabeprotokolls unter Windows 2000 Server, Windows 2000 Professional, Windows Server 2003 und Windows XP Professional unterstützt die gegenseitige Authentifizierung. Dadurch werden Angriffe zur Sitzungsübernahme verhindert, und es wird die Nachrichtenauthentifizierung zur Verhinderung von Man-in-the-Middle-Angriffen unterstützt. Die SMB-Signatur stellt diese Authentifizierung bereit, indem in jedes SMB-Paket eine anschließend vom Client und Server überprüfte digitale Signatur eingefügt wird. Die Implementierung der SMB-Signatur kann sich negativ auf die Leistung auswirken, da jedes Paket signiert und überprüft werden muss. Wenn Computer so konfiguriert sind, dass sie die gesamte nicht signierten SMB-Kommunikation ignorieren, können ältere Anwendungen und Betriebssysteme keine Verbindung herstellen. Wenn Sie alle SMB-Signaturen vollständig deaktivieren, sind die Computer nicht vor Angriffen zur Sitzungsübernahme geschützt.

Microsoft-Netzwerk (Client): Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden

Durch diese Richtlinieneinstellung wird es dem SMB-Redirector ermöglicht, Nur-Text-Kennwörter an Nicht-Microsoft-SMB-Server zu senden, die die Kennwortverschlüsselung während der Authentifizierung nicht unterstützen.

Für die Einstellung Microsoft-Netzwerk (Client): Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Bei Aktivierung dieser Richtlinieneinstellung kann der Server Kennwörter im Nur-Text-Format über das Netzwerk an andere Computer übermitteln, die SMB-Dienste unterstützen. Diese anderen Computer verwenden möglicherweise keine der SMB-Sicherheitsfunktionen, die in Windows Server 2003 enthalten sind.

Gegenmaßnahme

Setzen Sie die Einstellung Microsoft-Netzwerk (Client): Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden auf Deaktiviert.

Mögliche Auswirkung

Einige sehr alte Anwendungen und Betriebssysteme (z. B. MS-DOS, Windows für Workgroups 3.11 und Windows 95a) sind u. U. nicht in der Lage, mit den Servern Ihrer Organisation über das SMB-Protokoll zu kommunizieren.

Microsoft-Netzwerk (Server): Leerlaufzeitspanne bis zum Anhalten der Sitzung

Durch diese Richtlinieneinstellung wird die durchgehende Leerlaufzeitspanne festgelegt, nach der eine SMB-Sitzung aufgrund von Inaktivität angehalten wird. Administratoren können mit dieser Richtlinieneinstellung steuern, zu welchem Zeitpunkt eine nicht aktive Sitzung vom Computer angehalten wird. Die Sitzung wird automatisch wiederhergestellt, wenn der Client seine Aktivität wieder aufnimmt. Beim Wert 0 wird die Leerlaufsitzung so schnell wie möglich getrennt. Der maximale Wert ist 99999, also 208 Tage. Die Option wird also durch diesen Wert deaktiviert.

Für die Einstellung Microsoft-Netzwerk (Server): Leerlaufzeitspanne bis zum Anhalten der Sitzung sind folgende Werte möglich:

• Benutzerdefinierter Zeitraum in Minuten

• Nicht definiert

Sicherheitsanfälligkeit

Jede SMB-Sitzung beansprucht Serverressourcen, und zahlreiche Nullsitzungen verlangsamen den Server und können sogar dazu führen, dass der Server ausfällt. Ein Angreifer könnte wiederholt SMB-Sitzungen einrichten, bis die SMB-Dienste des Servers verlangsamt werden oder der Server nicht mehr reagiert.

Gegenmaßnahme

Legen Sie für die Einstellung Microsoft-Netzwerk (Server): Leerlaufzeitspanne bis zum Anhalten der Sitzung einen Wert von 15 Minuten fest.

Mögliche Auswirkung

Die Auswirkungen sind gering, da SMB-Sitzungen automatisch wiederhergestellt werden, wenn der Client wieder aktiv wird.

Microsoft-Netzwerk (Server): Clientverbindungen aufheben, wenn die Anmeldezeit überschritten wird

Durch diese Richtlinieneinstellung wird festgelegt, ob Benutzer abgemeldet werden, die außerhalb der für ihr Benutzerkonto gültigen Anmeldezeiten beim lokalen Computer angemeldet sind. Sie betrifft die SMB-Komponente. Wenn Sie diese Richtlinieneinstellung aktivieren, werden Clientsitzungen mit dem SMB-Dienst nach Ablauf der Anmeldezeit des Clients beendet. Wenn Sie diese Richtlinieneinstellung deaktivieren, werden bestehende Clientsitzungen nach Ablauf der Anmeldezeit des Clients aufrechterhalten. Wenn Sie diese Richtlinieneinstellung aktivieren, sollte auch die Einstellung Netzwerksicherheit: Abmeldung nach Ablauf der Anmeldezeit erzwingen aktiviert werden.

Für die Einstellung Microsoft-Netzwerk (Server): Clientverbindungen aufheben, wenn die Anmeldezeit überschritten wird sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Die Aktivierung dieser Richtlinieneinstellung ist sinnvoll, wenn in Ihrer Organisation Anmeldezeiten für Benutzer festgelegt wurden. Andernfalls können Benutzer, die außerhalb ihrer Anmeldezeiten keinen Zugriff auf das Netzwerk haben sollen, diese Ressourcen über während der zulässigen Verbindungszeit eingerichteten Sitzungen weiter verwenden.

Gegenmaßnahme

Aktivieren Sie die Einstellung Microsoft-Netzwerk (Server): Clientverbindungen aufheben, wenn die Anmeldezeit überschritten wird.

Mögliche Auswirkung

Diese Richtlinieneinstellung hat keine Auswirkungen, wenn in Ihrer Organisation keine Anmeldezeiten festgelegt wurden. Bei Verwendung von Anmeldezeiten werden die bestehenden Benutzersitzungen nach Ablauf der Anmeldezeiten automatisch beendet.

Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen

Durch diese Richtlinieneinstellung wird festgelegt, ob ein anonymer Benutzer die SID-Attribute für einen anderen Benutzer anfordern kann.

Für die Einstellung Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Bei Aktivierung dieser Richtlinieneinstellung kann ein Benutzer mit lokalem Zugriff die allgemein bekannte SID des Administrators verwenden, um den wirklichen Namen des vordefinierten Administratorkontos selbst dann in Erfahrung zu bringen, wenn das Administratorkonto umbenannt wurde. Diese Person könnte den Kontonamen dann zum Erraten des Kennworts verwenden.

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerkzugriff: Anonyme SID-/Namensübersetzung zulassen auf Deaktiviert.

Mögliche Auswirkung

Da diese Richtlinieneinstellung auf Mitgliedscomputern standardmäßig deaktiviert ist, hat sie keine Auswirkungen auf diese Computer. Die Standardkonfiguration für Domänencontroller ist Aktiviert. Bei Deaktivierung dieser Richtlinieneinstellung auf Domänencontrollern können ältere Computer u. U. nicht mehr mit Windows Server 2003-Domänen kommunizieren. Folgende Computer könnten u. U. nicht funktionieren:

• Windows NT 4.0-basierte RAS-Server (Remote Access Service)

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

• RAS- oder Microsoft SQL Server, die auf Windows 2000-Computern ausgeführt werden und Windows NT 3.x- oder Windows NT 4.0-Domänen angehören.

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

Durch diese Richtlinieneinstellung wird festgelegt, welche zusätzlichen Berechtigungen für anonyme Verbindungen zum Computer erteilt werden. Windows ermöglicht anonymen Benutzern die Ausführung von bestimmten Aktivitäten, z. B. das Auflisten von Domänenkonten und Netzwerkfreigaben. Diese Funktion ist hilfreich, wenn z. B. ein Administrator den Benutzern in einer vertrauenswürdigen Domäne Zugriff gewähren möchte, die keine gegenseitige Vertrauensstellung unterhält. Auch wenn diese Einstellung aktiviert ist, haben anonyme Benutzer weiterhin Zugriff auf alle Ressourcen mit Berechtigungen, in denen die vordefinierte Gruppe ANONYMOUS-ANMELDUNG explizit enthalten ist.

Unter Windows 2000 gibt es eine ähnliche Richtlinieneinstellung mit der Bezeichnung Weitere Einschränkungen für anonyme Verbindungen. Diese Einstellung verwaltet den Wert RestrictAnonymous im Registrierungsschlüssel HKLM\SYSTEM\CurrentControlSet\Control\LSA. Die Windows 2000-Richtlinieneinstellung wird unter Windows Server 2003 durch die Richtlinieneinstellungen Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben und Netzwerkzugriff: Anonyme Aufzählung von SAM-Kontenund Freigaben nicht erlauben ersetzt. Durch sie werden die Registrierungswerte RestrictAnonymousSAM und RestrictAnonymous verwaltet, die sich beide im Registrierungsschlüssel HKLM\System\CurrentControlSet\Control\Lsa\ befinden.

Für die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein nicht autorisierter Benutzer kann Kontonamen anonym auflisten und anhand dieser Informationen Social-Engineering-Angriffe durchführen oder Kennwörter erraten. (Bei Social-Engineering-Angriffen wird versucht, Benutzer dazu zu verleiteten, Kennwörter oder andere Sicherheitsinformationen preiszugeben.)

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben auf Aktiviert.

Mögliche Auswirkung

Mit Windows NT 4.0-Domänen kann keine Vertrauensstellung hergestellt werden. Darüber hinaus werden bei Clientcomputern mit älteren Windows-Betriebssystemen (z. B. Windows NT 3.51 oder Windows 95) beim Zugriff auf Serverressourcen Probleme auftreten.

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

Durch diese Richtlinieneinstellung wird festgelegt, ob die anonyme Aufzählung von SAM-Konten (Security Accounts Manager, Sicherheitskontenverwaltung) und Freigaben zulässig ist. Windows ermöglicht anonymen Benutzern die Ausführung bestimmter Aktivitäten, z. B. das Auflisten von Domänenkonten und Netzwerkfreigaben (siehe vorhergehender Abschnitt). Diese Funktion ist hilfreich, wenn z. B. ein Administrator den Benutzern in einer vertrauenswürdigen Domäne Zugriff gewähren möchte, die keine gegenseitige Vertrauensstellung unterhält. Sie können diese Richtlinieneinstellung aktiveren, wenn das anonyme Auflisten von SAM-Konten und Netzwerkfreigaben nicht zulässig sein soll. Auch wenn sie aktiviert ist, haben anonyme Benutzer weiterhin Zugriff auf alle Ressourcen mit Berechtigungen, in denen die vordefinierte Gruppe ANONYMOUS-ANMELDUNG explizit enthalten ist.

Unter Windows 2000 gibt es eine ähnliche Richtlinieneinstellung mit der Bezeichnung Weitere Einschränkungen für anonyme Verbindungen. Diese Einstellung verwaltet den Wert RestrictAnonymous im Registrierungsschlüssel HKLM\SYSTEM\CurrentControlSet\Control\LSA. Die Windows 2000-Richtlinieneinstellung wird unter Windows Server 2003 durch die Richtlinieneinstellungen Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten nicht erlauben und Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben ersetzt. Durch sie werden die Registrierungswerte RestrictAnonymousSAM und RestrictAnonymous verwaltet, die sich beide im Registrierungsschlüssel HKLM\System\CurrentControlSet\Control\Lsa\ befinden.

Für die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein nicht autorisierter Benutzer könnte Kontennamen und freigegebene Ressourcen anonym auflisten und anhand dieser Informationen Kennwörter erraten oder Social-Engineering-Angriffe durchführen.

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerkzugriff: Anonyme Aufzählung von SAM-Konten und Freigaben nicht erlauben auf Aktiviert.

Mögliche Auswirkung

Über eine einseitige Vertrauensstellung kann Benutzern einer anderen Domäne kein Zugriff gewährt werden, da die Administratoren der vertrauenden Domäne keine Auflistung der Konten in der anderen Domäne erstellen können. Benutzer, die anonym auf Datei- und Druckserver zugreifen, können die freigegebenen Netzwerkressourcen auf diesen Servern nicht auflisten. Zur Auflistung der freigegebenen Verzeichnisse und Drucker müssen sie sich authentifizieren.

Netzwerkzugriff: Speicherung von Anmeldeinformationen oder .NET-Passports für die Netzwerkauthentifikation nicht erlauben

Durch diese Richtlinieneinstellung wird festgelegt, ob Kennwörter oder Anmeldeinformationen nach der Domänenauthentifizierung zur späteren Verwendung mit der Funktion „Gespeicherte Benutzernamen und Kennwörter“ gespeichert werden können. Bei Aktivierung dieser Richtlinieneinstellung werden Kennwörter und Anmeldeinformationen nicht mit der Windows-Funktion „Gespeicherte Benutzernamen und Kennwörter“ gespeichert.

Für die Einstellung Netzwerkzugriff: Speicherung von Anmeldeinformationen oder .NET-Passports für die Netzwerkauthentifikation nicht erlauben sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Der Benutzer kann auf zwischengespeicherte Kennwörter zugreifen, wenn er am Computer angemeldet ist. Obwohl dies offensichtlich erscheint, kann ein Problem auftreten, wenn der Benutzer unwissentlich schädlichen Code ausführt, mit dem die Kennwörter gelesen und an einen nicht autorisierten Benutzer weitergeleitet werden.

Hinweis: Das Risiko von erfolgreichen Angriffen, bei denen schädlicher Code ausgeführt wird, ist in Organisationen, die eine effiziente Antiviruslösung auf Unternehmensebene implementieren und diese mit angemessenen Richtlinien für Softwareeinschränkungen kombinieren, deutlich geringer. Weitere Informationen zu Richtlinien für Softwareeinschränkungen finden Sie in Kapitel 8, „Richtlinien für Softwareeinschränkungen“.

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerkzugriff: Speicherung von Anmeldeinformationen oder .NET-Passports für die Netzwerkauthentifikation nicht erlauben auf Aktiviert.

Mögliche Auswirkung

Benutzer werden bei jeder Anmeldung bei ihrem Passportkonto oder bei anderen Netzwerkressourcen, auf die sie nicht über ihr Domänenkonto zugreifen können, zur Eingabe ihrer Kennwörter gezwungen. Diese Richtlinieneinstellung sollte keine Auswirkungen für Benutzer haben, die auf Netzwerkressourcen zugreifen, die den Zugriff über das Active Directory-Domänenkonto der Benutzer zulassen.

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

Durch diese Richtlinieneinstellung wird festgelegt, welche zusätzlichen Berechtigungen für anonyme Verbindungen zum Computer erteilt werden. Bei Aktivierung dieser Richtlinieneinstellung können anonyme Benutzer die Namen von Domänenkonten und Netzwerkfreigaben auflisten und bestimmte andere Aktivitäten durchführen. Diese Funktion ist hilfreich, wenn z. B. ein Administrator den Benutzern in einer vertrauenswürdigen Domäne Zugriff gewähren möchte, die keine gegenseitige Vertrauensstellung unterhält.

In der Standardeinstellung enthält das für anonyme Verbindungen erstellte Token keine Jeder-SID. Daher sind die der Gruppe Jeder zugewiesenen Berechtigungen nicht für anonyme Benutzer gültig. Bei Aktivierung dieser Richtlinieneinstellung wird die Jeder-SID dem für anonyme Verbindungen erstellten Token hinzugefügt. Anonyme Benutzer können dann auf alle Ressourcen zugreifen, für die der Gruppe Jeder die entsprechenden Berechtigungen zugewiesen wurden.

Für die Einstellung Netzwerkzugriff: Die Verwendung von 'Jeder'-Berechtigungen für anonyme Benutzer ermöglichen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein nicht autorisierter Benutzer kann Kontonamen und freigegebene Ressourcen anonym auflisten und anhand dieser Informationen Kennwörter erraten, Social-Engineering-Angriffe durchführen oder Dienstverweigerungen verursachen.

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerkzugriff: Die Verwendung von 'Jeder'-Berechtigungen für anonyme Benutzer ermöglichen auf Deaktiviert.

Mögliche Auswirkung

Keine. Hierbei handelt es sich um die Standardkonfiguration.

Netzwerkzugriff: Named Pipes, auf die anonym zugegriffen werden kann

Durch diese Richtlinieneinstellung wird festgelegt, welche Kommunikationssitzungen oder Pipes über Attribute und Berechtigungen verfügen, die anonymen Zugriff zulassen.

Für die Einstellung Netzwerkzugriff: Named Pipes, auf die anonym zugegriffen werden kann sind folgende Werte möglich:

• Benutzerdefinierte Liste der Freigaben

• Nicht definiert

Damit diese Richtlinieneinstellung wirksam ist, müssen Sie auch die Einstellung Netzwerkzugriff: Anonymen Zugriff auf Named Pipes und Freigaben einschränken aktivieren.

Sicherheitsanfälligkeit

Die Zugriffsbeschränkung über Named Pipes, wie COMNAP und LOCATOR, verhindert einen nicht autorisierten Zugriff auf das Netzwerk. Die Standardliste der Named Pipes und deren jeweiliger Zweck sind in der folgenden Tabelle aufgeführt.

Tabelle 5.1: Named Pipes der Standardeinstellung, auf die anonym zugegriffen werden kann

Named Pipe	Zweck
COMNAP	Named Pipe für SNABase SNA (Systems Network Architecture) stellt eine Sammlung von Netzwerkprotokollen dar, die ursprünglich für Mainframecomputer von IBM entwickelt wurden.
COMNODE	Named Pipe für SNA Server
SQL\QUERY	Standard-Named-Pipe für SQL Server
SPOOLSS	Named Pipe für den Druckwarteschlangendienst
EPMAPPER	Named Pipe für Endpunktzuordnung
LOCATOR	Named Pipe für RPC-Locatordienst
TrkWks	Named Pipe für Überwachung verteilter Verknüpfungen (Client)
TrkSvr	Named Pipe für Überwachung verteilter Verknüpfungen (Server)

Gegenmaßnahme

Legen Sie für die Einstellung Netzwerkzugriff: Named Pipes, auf die anonym zugegriffen werden kann einen Nullwert fest. (Aktivieren Sie die Einstellung, aber geben Sie im Textfeld keine Named Pipes ein.)

Mögliche Auswirkung

Bei dieser Konfiguration wird der Nullsitzungszugriff über Named Pipes deaktiviert, und Anwendungen, die diese Funktion benötigen oder nicht authentifizierte Zugriff auf Named Pipes erfordern, können nicht mehr ausgeführt werden. Bei Microsoft Commercial Internet System 1.0 wird der Internet Mail-Dienst beispielsweise in dem Inetinfo-Prozess ausgeführt. Inetinfo wird im Kontext des lokalen Systemkontos gestartet. Bei einer Microsoft SQL Server-Datenbankabfrage durch den Internet Mail-Dienst wird das lokale Systemkonto verwendet. Dieses verwendet Nullanmeldeinformationen, um auf SQL-Pipes auf dem Computer zuzugreifen, auf dem SQL Server ausgeführt wird.

Informationen zur Vermeidung dieses Problems finden Sie im Microsoft Knowledge Base-Artikel „Zugreifen auf Netzwerkdateien über IIS-Anwendungen“ (in englischer Sprache) unter https://support.microsoft.com/default.aspx?scid=207671.

Netzwerkzugriff: Registrierungspfade, auf die von anderen Computern aus zugegriffen werden kann

Durch diese Richtlinieneinstellung wird festgelegt, auf welche Registrierungspfade zugegriffen werden kann, wenn eine Anwendung oder ein Prozess den Schlüssel WinReg zur Feststellung der Zugriffsberechtigungen auswertet.

Für die Einstellung Netzwerkzugriff: Registrierungspfade, auf die von anderen Computern aus zugegriffen werden kann sind folgende Werte möglich:

• Benutzerdefinierte Liste der Pfade

• Nicht definiert

Sicherheitsanfälligkeit

Die Registrierung ist als Datenbank für Computerkonfigurationsdaten zu verstehen. Viele der Informationen sind vertraulich. Ein Angreifer kann diese Informationen für nicht autorisierte Aktivitäten verwenden. Zur Verringerung des Risikos für einen solchen Angriff werden in der gesamten Registrierung geeignete Zugriffssteuerungslisten (ACLs) verwendet, um die Registrierung auf diese Weise vor nicht autorisiertem Benutzerzugriff zu schützen.

Gegenmaßnahme

Legen Sie für die Einstellung Netzwerkzugriff: Registrierungspfade, auf die von anderen Computern aus zugegriffen werden kann einen Nullwert fest. (Aktivieren Sie die Einstellung, aber geben Sie im Textfeld keine Pfade ein.)

Mögliche Auswirkung

Remoteverwaltungstools (z. B. Microsoft Baseline Security Analyzer und Microsoft Systems Management Server) benötigen Remotezugriff auf die Registrierung, damit diese Computer ordnungsgemäß überwacht und verwaltet werden können. Wenn Sie die Standard-Registrierungspfade aus der Liste der zugänglichen Pfade entfernen, können diese Remoteverwaltungstools möglicherweise nicht mehr ausgeführt werden.

Hinweis: Wenn Sie den Remotezugriff zulassen möchten, müssen Sie auch den Remoteregistrierungsdienst aktivieren.

Netzwerkzugriff: Registrierungspfade und -unterpfade, auf die von anderen Computern aus zugegriffen werden kann

Durch diese Richtlinieneinstellung wird festgelegt, auf welche Registrierungspfade und -unterpfade zugegriffen werden kann, wenn eine Anwendung oder ein Prozess den Schlüssel WinReg zur Feststellung der Zugriffsberechtigungen auswertet.

Für die Einstellung Netzwerkzugriff: Registrierungspfade und -unterpfade, auf die von anderen Computern aus zugegriffen werden kann sind folgende Werte möglich:

• Benutzerdefinierte Liste der Pfade

• Nicht definiert

Sicherheitsanfälligkeit

Wie bereits erwähnt, enthält die Registrierung vertrauliche Computerkonfigurationsdaten, die von einem Angreifer für nicht autorisierte Aktivitäten verwendet werden können. Dadurch, dass die in der gesamten Registrierung zugewiesenen Standard-Zugriffssteuerungslisten ziemlich einschränkend wirken und zum Schutz der Registrierung vor nicht autorisiertem Benutzerzugriff beitragen, wird das Risiko eines solchen Angriffs verringert.

Gegenmaßnahme

Legen Sie für die Einstellung Netzwerkzugriff: Registrierungspfade und -unterpfade, auf die von anderen Computern aus zugegriffen werden kann einen Nullwert fest. (Aktivieren Sie die Einstellung, aber geben Sie im Textfeld keine Pfade ein.)

Mögliche Auswirkung

Remoteverwaltungstools (z. B. Microsoft Baseline Security Analyzer und Microsoft Systems Management Server) benötigen Remotezugriff auf die Registrierung, damit diese Computer ordnungsgemäß überwacht und verwaltet werden können. Wenn Sie die Standard-Registrierungspfade aus der Liste der zugänglichen Pfade entfernen, können diese Remoteverwaltungstools möglicherweise nicht mehr ausgeführt werden.

Hinweis: Wenn Sie den Remotezugriff zulassen möchten, müssen Sie auch den Remoteregistrierungsdienst aktivieren.

Netzwerkzugriff: Anonymen Zugriff auf Named Pipes und Freigaben einschränken

Wenn diese Richtlinieneinstellung aktiviert ist, wird der anonyme Zugriff auf die Freigaben und Pipes begrenzt, die in den Einstellungen Netzwerkzugriff: Named Pipes, auf die anonym zugegriffen werden kann und Netzwerkzugriff: Freigaben, auf die anonym zugegriffen werden kann genannt werden. Durch diese Richtlinieneinstellung wird der Nullsitzungszugriff auf Computerfreigaben gesteuert, indem RestrictNullSessAccess mit dem Wert 1 im Registrierungsschlüssel HKLM\System\CurrentControlSet\Services\LanManServer\Parameters hinzugefügt wird. Mit diesem Registrierungswert können Nullsitzungsfreigaben aktiviert bzw. deaktiviert werden. Dadurch wird festgelegt, ob der Serverdienst den nicht authentifizierten Clientzugriff auf die genannten Ressourcen begrenzt.

Für die Einstellung Netzwerkzugriff: Anonymen Zugriff auf Named Pipes und Freigaben einschränken sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Nullsitzungen sind ein Sicherheitsrisiko, das über die einzelnen Freigaben (einschließlich der Standardfreigaben) auf den Computern in Ihrer Umgebung ausgenutzt werden kann.

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerkzugriff: Anonymen Zugriff auf Named Pipes und Freigaben einschränken auf Aktiviert.

Mögliche Auswirkung

Bei Aktivierung dieser Richtlinieneinstellung wird der Nullsitzungszugriff auf die Serverpipes und -freigaben, die in den Einträgen NullSessionPipes und NullSessionShares aufgeführt sind, für nicht authentifizierte Benutzer eingeschränkt.

Netzwerkzugriff: Freigaben, auf die anonym zugegriffen werden kann

Durch diese Richtlinieneinstellung werden die Netzwerkfreigaben festgelegt, auf die anonyme Benutzer zugreifen können.

Für die Einstellung Netzwerkzugriff: Freigaben, auf die anonym zugegriffen werden kann sind folgende Werte möglich:

• Benutzerdefinierte Liste der Freigaben

• Nicht definiert

Sicherheitsanfälligkeit

Die Aktivierung dieser Einstellung ist mit einem sehr hohen Risiko verbunden. Jeder Benutzer im Netzwerk erhält Zugriff auf die aufgeführten Freigaben, was zur Offenlegung oder Beschädigung vertraulicher Daten führen kann.

Gegenmaßnahme

Legen Sie für die Einstellung Netzwerkzugriff: Freigaben, auf die anonym zugegriffen werden kann einen Nullwert fest.

Mögliche Auswirkung

Da dies die Standardkonfiguration ist, sollte es zu keinen oder nur geringen Auswirkungen kommen. Nur authentifizierte Benutzer haben Zugriff auf freigegebene Ressourcen auf dem Server.

Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten

Durch diese Richtlinieneinstellung wird festgelegt, wie Netzwerkanmeldungen über lokale Konten authentifiziert werden. Wenn Sie für diese Richtlinieneinstellung den Wert Klassisch festlegen, werden die Anmeldeinformationen des lokalen Kontos zur Authentifizierung der Netzwerkanmeldung verwendet. Wenn Sie für diese Richtlinieneinstellung den Wert Nur Gast festlegen, werden Netzwerkanmeldungen über lokale Konten automatisch dem Gastkonto zugeordnet. Mit der Option Klassisch können Sie den Zugriff auf Ressourcen genau steuern und den diversen Benutzern verschiedene Zugriffsberechtigungen für dieselbe Ressource erteilen. Bei Aktivierung der Option Nur Gast werden hingegen alle Benutzer gleich behandelt (Authentifizierung über das Gastbenutzerkonto) und erhalten dieselben Zugriffsberechtigungen für bestimmte Ressourcen, entweder „Nur lesen“ oder „Ändern“.

Die Standardkonfiguration unter Windows XP Professional auf eigenständigen Computern ist Nur Gast. Die Standardeinstellung bei Windows XP-Computern in einer Domäne und bei Windows Server 2003-Computern ist Klassisch.

Hinweis: Diese Richtlinieneinstellung hat keine Auswirkungen auf Netzwerkanmeldungen über Domänenkonten. Ebenso werden interaktive Remoteanmeldungen über Dienste wie Telnet oder die Terminaldienste nicht beeinflusst.

Wenn der Computer keiner Domäne angehört, werden durch diese Richtlinieneinstellung auch die Registerkarten Freigabe und Sicherheit in Windows Explorer entsprechend dem verwendeten Freigabe- und Sicherheitsmodell angepasst.

Diese Einstellung hat keine Auswirkungen auf Windows 2000-Computer.

Für die Einstellung Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten sind folgende Werte möglich:

• Klassisch - lokale Benutzer authentifizieren sich als sie selbst

• Nur Gast - lokale Benutzer authentifizieren sich als Gast

• Nicht definiert

Sicherheitsanfälligkeit

Bei Aktivierung der Option Nur Gast melden sich alle Benutzer, der über das Netzwerk auf Ihren Computer zugreifen können, mit Gastberechtigungen an Ihrem Computer an. Meist haben die Benutzer dann keinen Schreibzugriff auf die freigegebenen Ressourcen auf diesem Computer. Obwohl diese Einschränkung die Sicherheit erhöht, erschwert sie für autorisierte Benutzer den Zugriff auf freigegebene Ressourcen auf diesen Computern, da die Zugriffssteuerungslisten (ACLs) für diese Ressourcen auch Zugriffssteuerungseinträge (ACEs, Access Control Entries) für das Gastkonto enthalten müssen. Bei Aktivierung der Option Klassisch sollten lokale Konten mit einem Kennwort geschützt werden. Andernfalls kann bei Aktivierung des Gastzugriffs jeder Benutzer über diese Benutzerkonten auf freigegebene Systemressourcen zugreifen.

Gegenmaßnahme

Legen Sie bei Netzwerkservern für die Einstellung Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Konten den Wert Klassisch - lokale Benutzer authentifizieren sich als sie selbst fest. Legen Sie für diese Richtlinieneinstellung auf Endbenutzercomputern den Wert Nur Gast - lokale Benutzer authentifizieren sich als Gast fest.

Mögliche Auswirkung

Keine. Hierbei handelt es sich um die Standardkonfiguration.

Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern

Durch diese Richtlinieneinstellung wird festgelegt, ob bei der nächsten Kennwortänderung die Hashwerte für das neue Kennwort von LAN Manager gespeichert werden können.

Für die Einstellung Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Durch einen erfolgreichen Angriff auf die SAM-Datei können Angreifer Benutzernamen und Kennwort-Hashwerte in Erfahrung bringen. Bei solchen Angriffen werden zur Kennwortentschlüsselung spezielle Tools verwendet. Anschließend wird mit dem Kennwort eine andere Benutzeridentität vorgetäuscht, um Zugriff auf die Netzwerkressourcen zu erhalten. Bei Aktivierung dieser Richtlinieneinstellung können Angriffe dieser Art zwar nicht gänzlich verhindert werden, die Erfolgsaussichten eines solchen Angriffs können jedoch deutlich verringert werden.

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerksicherheit: Keine LAN Manager-Hashwerte für nächste Kennwortänderung speichern auf Aktiviert. Erzwingen Sie eine Änderung aller Benutzerkennwörter bei der nächsten Anmeldung an der Domäne, um die LAN Manager-Hashwerte zu entfernen.

Mögliche Auswirkung

Ältere Betriebssysteme, wie z. B. Windows 95, Windows 98 und Windows ME, sowie einige Anwendungen von Drittanbietern können nicht ausgeführt werden.

Netzwerksicherheit: Abmeldung nach Ablauf der Anmeldezeit erzwingen

Durch diese Richtlinieneinstellung wird festgelegt, ob Benutzer abgemeldet werden, die außerhalb der für ihr Benutzerkonto gültigen Anmeldezeiten beim lokalen Computer angemeldet sind. Sie betrifft die SMB-Komponente. Wenn Sie diese Richtlinieneinstellung aktivieren, werden Clientsitzungen mit dem SMB-Server nach Ablauf der Anmeldezeit des Clients beendet. Wenn Sie diese Richtlinieneinstellung deaktivieren, werden bestehende Clientsitzungen nach Ablauf der Anmeldezeit des Clients aufrechterhalten.

Für die Einstellung Netzwerksicherheit: Abmeldung nach Ablauf der Anmeldezeit erzwingen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Wenn diese Richtlinieneinstellung deaktiviert ist, werden Benutzer nach Ablauf der zugewiesenen Anmeldezeit nicht abgemeldet.

Gegenmaßnahme

Setzen Sie die Einstellung Netzwerksicherheit: Abmeldung nach Ablauf der Anmeldezeit erzwingen auf Aktiviert. Diese Einstellung gilt nicht für Administratorkonten.

Mögliche Auswirkung

Bei Ablauf der Anmeldezeit des Benutzers werden SMB-Sitzungen beendet. Der Benutzer kann sich erst wieder am Computer anmelden, wenn der nächste ihm zugewiesene Zugriffszeitraum beginnt.

Netzwerksicherheit: LAN Manager-Authentifizierungsebene

LAN Manager (LM) ist eine frühere Client/Server-Software von Microsoft, mit der PCs in einem Netzwerk zusammengeschlossen werden können. Zu den bereitgestellten Netzwerkfunktionen gehören Datei- und Druckerfreigabe, Sicherheitsfunktionen für Benutzer sowie Programme für die Netzwerkverwaltung. In Active Directory-Domänen ist das Kerberos-Protokoll das standardmäßige Authentifizierungsprotokoll. Wenn Kerberos jedoch nicht als Authentifizierungsprotokoll ausgehandelt werden kann, wird LM, NTLM oder NTLMv2 verwendet.

Die LAN Manager-Authentifizierung berücksichtigt die Varianten LM, NTLM und NTLMv2 (NTLM, Version 2) und wird als Authentifizierungsprotokoll für alle Windows-Clients zur Ausführung folgender Vorgänge verwendet:

• Beitritt zu einer Domäne

• Authentifizierung zwischen Active Directory-Gesamtstrukturen

• Authentifizierung in anderen Domänen

• Authentifizierung bei Windows 2000-, Windows Server 2003- oder Windows XP-Computern

• Authentifizierung bei nicht zur Domäne gehörenden Computern

Für die Einstellung Netzwerksicherheit: LAN Manager-Authentifizierungsebene sind folgende Werte möglich:

• LM- und NTLM-Antworten senden

• LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt)

• Nur NTLM-Antworten senden

• Nur NTLMv2-Antworten senden

• Nur NTLMv2-Antworten senden\LM verweigern

• Nur NTLMv2-Antworten senden\LM & NTLM verweigern

• Nicht definiert

Durch die Einstellung Netzwerksicherheit: LAN Manager-Authentifizierungsebene wird festgelegt, welches Protokoll für Anfrage/Antwort-Authentifizierungen bei Netzwerkanmeldungen verwendet wird. Diese Auswahl betrifft wie im Folgenden beschrieben die Authentifizierungsprotokollebene für Clients, die von den Computern ausgehandelte Sitzungssicherheitsebene und die von Servern akzeptierte Authentifizierungsebene:

• LM- und NTLM-Antworten senden. Clients verwenden LM- und NTLM-Authentifizierung, jedoch nie die NTLMv2-Sitzungssicherheit. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• LM- und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt). Clients verwenden LM- und NTLM-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Nur NTLM-Antworten senden. Clients verwenden nur die NTLM-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Nur NTLMv2-Antworten senden. Clients verwenden nur die NTLMv2-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Nur NTLMv2-Antworten senden\LM verweigern. Clients verwenden nur die NTLMv2-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren ausschließlich NTLM- und NTLMv2-Authentifizierung (LM-Authentifizierung wird nicht zugelassen).

• Nur NTLMv2-Antworten senden\LM & NTLM verweigern. Clients verwenden nur die NTLMv2-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren ausschließlich NTLMv2-Authentifizierung (LM- und NTLM-Authentifizierung werden nicht zugelassen).

Diese Einstellungen entsprechen folgenden, in anderen Microsoft-Dokumenten beschriebenen Ebenen:

• Ebene 0: LM- und NTLM-Antworten senden, NTLMv2-Sitzungssicherheit nicht verwenden. Clients verwenden LM- und NTLM-Authentifizierung, jedoch nie die NTLMv2-Sitzungssicherheit. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Ebene 1: NTLMv2-Sitzungssicherheit verwenden, wenn ausgehandelt. Clients verwenden LM- oder NTLM-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Ebene 2: Nur NTLM-Antworten senden. Clients verwenden nur die NTLM-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Ebene 3: Nur NTLMv2-Antworten senden. Clients verwenden die NTLMv2-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren LM-, NTLM- und NTLMv2-Authentifizierung.

• Ebene 4: Domänencontroller verweigern LM-Antworten. Clients verwenden die NTLM-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren ausschließlich NTLM- und NTLMv2-Authentifizierung (LM-Authentifizierung wird nicht zugelassen).

• Ebene 5: Domänencontroller verweigern LM- und NTLM-Antworten (nur NTLMv2 wird akzeptiert). Clients verwenden die NTLMv2-Authentifizierung sowie die NTLMv2-Sitzungssicherheit, wenn sie vom Server unterstützt wird. Domänencontroller akzeptieren ausschließlich NTLMv2-Authentifizierung (LM- und NTLM-Authentifizierung werden nicht zugelassen).

Sicherheitsanfälligkeit

Clients unter Windows 2000, Windows Server 2003 und Windows XP sind standardmäßig so konfiguriert, dass sie LM- und NTLM-Authentifizierungsantworten senden. (Win 9x-Clients senden ausschließlich LM-Antworten.) Mit den Standardservereinstellungen können sich alle Clients auf Servern authentifizieren und auf deren Ressourcen zugreifen. Dies bedeutet jedoch auch, dass die schwächste Form von Authentifizierungsantworten, nämlich LM-Antworten, über das Netzwerk gesendet werden. Damit besteht die Gefahr, dass der Datenverkehr abgefangen wird und Benutzerkennwörter entschlüsselt werden.

In den Betriebssystemen Windows 9x und Windows NT kann das Kerberos-Protokoll, Version 5, nicht für die Authentifizierung verwendet werden. Daher werden diese Computer in einer Windows Server 2003-Domäne standardmäßig sowohl über LM- als auch über NTLM-Protokolle authentifiziert. Sie können jedoch durch die Verwendung von NTLMv2 ein sichereres Authentifizierungsprotokoll für Windows 9x und Windows NT erzwingen. Zum Schutz des Authentifizierungsprozesses werden NTLMv2-Antworten bei der Anmeldung über einen sicheren Kanal gesendet. Selbst wenn Sie NTLMv2 für ältere Clients und Server verwenden, werden Windows-basierte Clients und Server als Mitglieder einer Domäne von Windows Server 2003-Domänencontrollern über das Kerberos-Authentifizierungsprotokoll authentifiziert.

Weitere Informationen zur Aktivierung von NTLMv2 finden Sie im Microsoft Knowledge Base-Artikel „Aktivieren der NTLM 2-Authentifizierung“ unter https://support.microsoft.com/default.aspx?scid=239869. Unter Microsoft Windows NT 4.0 wird Service Pack 4 (SP4) zur Unterstützung von NTLMv2 benötigt. Auf Windows 9x-Plattformen muss der Verzeichnisdienst-Client zur Unterstützung von NTLMv2 installiert werden.

Gegenmaßnahme

Legen Sie für die Einstellung Netzwerksicherheit: LAN Manager-Authentifizierungsebene den Wert Nur NTLMv2-Antworten senden fest. Wenn alle Clients NTLMv2 unterstützen, wird diese Authentifizierungsebene von Microsoft und einer Reihe unabhängiger Organisationen empfohlen.

Mögliche Auswirkung

Clients, die die NTLMv2-Authentifizierung nicht unterstützen, können in der Domäne nicht über LM und NTLM authentifiziert werden und erhalten somit keinen Zugriff auf Domänenressourcen.

Hinweis: Informationen zu einem Hotfix, durch den ein fehlerfreies Funktionieren dieser Einstellung in Netzwerken gewährleistet wird, in denen Windows NT 4.0-Computer zusammen mit Windows 2000-, Windows XP- und Windows Server 2003-Computern verwendet werden, finden Sie im Microsoft Knowledge Base-Artikel „Authentifizierungsprobleme in Windows 2000 mit NTLM 2-Ebenen oberhalb von 2 in einer Windows NT 4.0-Domäne“ (in englischer Sprache) unter https://support.microsoft.com/kb/305379/en-us.

Netzwerksicherheit: Signaturanforderungen für LDAP-Clients

Durch diese Richtlinieneinstellung wird die Datensignaturebene festgelegt, die Clients bei LDAP BIND-Anforderungen erfüllen müssen:

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

• Signatur aushandeln. Wenn TLS/SSL (Transport Layer Security/Secure Sockets Layer) nicht gestartet wurde, wird die LDAP BIND-Anforderung mit den vom Aufrufer festgelegten Optionen und zusätzlich mit der LDAP-Datensignaturoption initiiert. Wurde TLS/SSL gestartet, wird die LDAP BIND-Anforderung mit den vom Aufrufer festgelegten Optionen initiiert.

• Signatur anfordern. Diese Ebene entspricht der Einstellung Signatur aushandeln. Wenn jedoch der LDAP-Server in der saslBindInProgress-Antwort nicht anzeigt, dass eine LDAP-Datenverkehrssignatur benötigt wird, wird dem Aufrufer gemeldet, dass die LDAP BIND-Befehlsanforderung fehlgeschlagen ist.

Hinweis: Diese Richtlinieneinstellung hat keine Auswirkungen auf ldap_simple_bind oder ldap_simple_bind_s. Microsoft-LDAP-Clients unter Windows XP Professional verwenden zur Kommunikation mit einem Domänencontroller weder ldap_simple_bind noch ldap_simple_bind_s.

Für die Einstellung Netzwerksicherheit: Signaturanforderungen für LDAP-Clients sind folgende Werte möglich:

• Keine

• Signatur aushandeln

• Signatur anfordern

• Nicht definiert

Sicherheitsanfälligkeit

Nicht signierter Netzwerkverkehr ist anfällig für Man-in-the-Middle-Angriffe, bei denen ein Eindringling Pakete zwischen Client und Server abfängt, ändert und dann an den Server weiterleitet. Bei einem LDAP-Server bedeutet diese Anfälligkeit, dass ein Angreifer einen Server veranlassen kann, Entscheidungen zu treffen, die auf falschen oder veränderten LDAP-Abfragedaten basieren. Zur Verringerung dieses Risiko in Ihrem Netzwerk können Sie zum Schutz der Netzwerkinfrastruktur strenge physische Sicherheitsmaßnahmen implementieren. Darüber hinaus werden Man-in-the-Middle-Angriffe wesentlich erschwert, wenn für alle Netzwerkpakete über IPSec-Authentifizierungsheader digitale Signaturen angefordert werden.

Gegenmaßnahme

Legen Sie für die Einstellung Domänencontroller: Signaturanforderungen für LDAP-Server den Wert Signatur anfordern fest.

Mögliche Auswirkung

Neben dem Server müssen Sie auch den Client so konfigurieren, dass LDAP-Signaturen angefordert werden. Wenn Sie den Client nicht entsprechend konfigurieren, kommt keine Kommunikation mit dem Server zustande. Dadurch können viele Funktionen ausfallen, z. B. Benutzerauthentifizierung, Gruppenrichtlinien und Anmeldeskripts.

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

Diese Richtlinieneinstellung ermöglicht es einem Clientcomputer, die Aushandlung von Nachrichtenvertraulichkeit (Verschlüsselung), Nachrichtenintegrität, 128-Bit-Verschlüsselung und NTLMv2-Sitzungssicherheit zu verlangen. Diese Werte sind abhängig von dem Wert, der für die Richtlinieneinstellung Netzwerksicherheit: LAN Manager-Authentifizierungsebene festgelegt wurde.

Für die Einstellung Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Clients (einschließlich sicherer RPC-Clients) sind folgende Werte möglich:

• Nachrichtenvertraulichkeit erfordern. Die Verbindung schlägt fehl, wenn keine Verschlüsselung ausgehandelt wird. Verschlüsselte Daten können erst gelesen werden, wenn sie entschlüsselt werden.

• Nachrichtenintegrität erfordern. Die Verbindung schlägt fehl, wenn keine Nachrichtenintegrität ausgehandelt wird. Die Integrität einer Nachricht kann anhand einer Nachrichtensignatur ermittelt werden. Durch die Nachrichtensignatur wird bestätigt, dass eine Nachricht nicht geändert wurde. Zu diesem Zweck wird der Nachricht eine kryptografische Signatur angehängt, die den Absender identifiziert und den Nachrichteninhalt numerisch darstellt.

• 128-Bit-Verschlüsselung erfordern. Die Verbindung schlägt fehl, wenn keine 128-Bit-Verschlüsselung ausgehandelt wird.

• NTLMv2-Sitzungssicherheit erfordern. Die Verbindung schlägt fehl, wenn kein NTLMv2-Protokoll ausgehandelt wird.

• Nicht definiert.

Sicherheitsanfälligkeit

Sie können alle Optionen für diese Richtlinieneinstellung aktivieren, um den Netzwerkverkehr, der den NTLM-Sicherheitsdienst (NTLM SSP) verwendet, vor einer Offenlegung oder Manipulation durch Angreifer zu schützen, die Zugriff auf das Netzwerk erlangt haben. Mit anderen Worten, diese Optionen schützen vor Man-in-the-Middle-Angriffen.

Gegenmaßnahme

Aktivieren Sie alle vier Optionen, die für die Richtlinieneinstellung Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Clients (einschließlich sicherer RPC-Clients) verfügbar sind.

Mögliche Auswirkung

Clientcomputer, von denen diese Einstellungen erzwungen werden, können nicht mit älteren Servern kommunizieren, die diese Einstellungen nicht unterstützen.

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

Diese Richtlinieneinstellung ermöglicht es einem Server, die Aushandlung von Nachrichtenvertraulichkeit (Verschlüsselung), Nachrichtenintegrität, 128-Bit-Verschlüsselung und NTLMv2-Sitzungssicherheit zu verlangen. Diese Werte sind abhängig von dem Wert, der für die Sicherheitseinstellung Netzwerksicherheit: LAN Manager-Authentifizierungsebene festgelegt wurde.

Für die Einstellung Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Server (einschließlich sicherer RPC-Server) sind folgende Werte möglich:

• Nachrichtenvertraulichkeit erfordern. Die Verbindung schlägt fehl, wenn keine Verschlüsselung ausgehandelt wird. Verschlüsselte Daten können bis zur Entschlüsselung von keiner Person gelesen werden.

• Nachrichtenintegrität erfordern. Die Verbindung schlägt fehl, wenn keine Nachrichtenintegrität ausgehandelt wird. Die Integrität einer Nachricht kann anhand einer Nachrichtensignatur ermittelt werden. Durch die Nachrichtensignatur wird bestätigt, dass eine Nachricht nicht geändert wurde. Zu diesem Zweck wird der Nachricht eine kryptografische Signatur angehängt, die den Absender identifiziert und den Nachrichteninhalt numerisch darstellt.

• 128-Bit-Verschlüsselung erfordern. Die Verbindung schlägt fehl, wenn keine 128-Bit-Verschlüsselung ausgehandelt wird.

• NTLMv2-Sitzungssicherheit erfordern. Die Verbindung schlägt fehl, wenn kein NTLMv2-Protokoll ausgehandelt wird.

• Nicht definiert.

Sicherheitsanfälligkeit

Sie können alle Optionen für diese Richtlinieneinstellung aktivieren, um den Netzwerkverkehr, der den NTLM-Sicherheitsdienst (NTLM SSP) verwendet, vor einer Offenlegung oder Manipulation durch Angreifer zu schützen, die Zugriff auf das Netzwerk erlangt haben. Mit anderen Worten, diese Optionen schützen vor Man-in-the-Middle-Angriffen.

Gegenmaßnahme

Aktivieren Sie alle vier Optionen, die für die Richtlinieneinstellung Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSP-basierte Server (einschließlich sicherer RPC-Server) verfügbar sind.

Mögliche Auswirkung

Ältere Clients, die diese Sicherheitseinstellungen nicht unterstützen, können nicht mit dem Computer kommunizieren.

Wiederherstellungskonsole: Automatische administrative Anmeldungen zulassen

Durch diese Richtlinieneinstellung wird festgelegt, ob das Kennwort für das Administratorkonto eingegeben werden muss, bevor Zugriff auf den Computer gewährt wird. Bei Aktivierung dieser Einstellung wird das Administratorkonto automatisch an der Wiederherstellungskonsole des Computers angemeldet. Es ist kein Kennwort erforderlich.

Für die Einstellung Wiederherstellungskonsole: Automatische administrative Anmeldungen zulassen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Die Wiederherstellungskonsole ermöglicht die Problembehandlung und Reparatur bei Computern, die nicht mehr gestartet werden können. Mit der Aktivierung der automatischen Anmeldung ist jedoch ein hohes Risiko verbunden. Jeder Benutzer kann zum Server gehen, diesen durch Ausschalten herunterfahren und neu starten. Wenn dieser Benutzer dann im Menü Neu starten den Befehl Wiederherstellungskonsole wählt, hat er Vollzugriff auf den Server.

Gegenmaßnahme

Setzen Sie die Einstellung Wiederherstellungskonsole: Automatische administrative Anmeldungen zulassen auf Deaktiviert.

Mögliche Auswirkung

Benutzer müssen für den Zugriff auf die Wiederherstellungskonsole einen Benutzernamen und ein Kennwort eingeben.

Wiederherstellungskonsole: Kopieren von Disketten und Zugriff auf alle Laufwerke und alle Ordner zulassen

Bei Aktivierung dieser Richtlinieneinstellung wird der Befehl SET der Wiederherstellungskonsole verfügbar, mit dem Sie die folgenden Umgebungsvariablen für die Wiederherstellungskonsole festlegen können.

• AllowWildCards. Aktiviert die Platzhalterunterstützung für einige Befehle (z. B. für den Befehl DEL).

• AllowAllPaths. Ermöglicht den Zugriff auf alle Dateien und Ordner auf dem Computer.

• AllowRemovableMedia. Ermöglicht das Kopieren von Dateien auf Wechselmedien wie Disketten.

• NoCopyPrompt. Unterdrückt die Anzeige einer Eingabeaufforderung beim Überschreiben einer vorhandenen Datei.

Für die Einstellung Wiederherstellungskonsole: Kopieren von Disketten und Zugriff auf alle Laufwerke und alle Ordner zulassen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Ein Angreifer, der in der Lage ist, das System an der Wiederherstellungskonsole neu zu starten, kann vertrauliche Daten stehlen und alle Überwachungsaufzeichnungen sowie Spuren des unbefugten Zugriffs beseitigen.

Gegenmaßnahme

Setzen Sie die Einstellung Wiederherstellungskonsole: Kopieren von Disketten und Zugriff auf alle Laufwerke und alle Ordner zulassen auf Deaktiviert.

Mögliche Auswirkung

Benutzer, die einen Server über die Wiederherstellungskonsole gestartet und sich am vordefinierten Administratorkonto angemeldet haben, können keine Dateien und Ordner auf Diskette kopieren.

Herunterfahren: Herunterfahren des Systems ohne Anmeldung zulassen

Durch diese Richtlinieneinstellung wird festgelegt, ob ein Computer ohne Anmeldung beim Windows-Betriebssystem heruntergefahren werden kann. Bei Aktivierung dieser Richtlinieneinstellung ist im Windows-Anmeldebildschirm der Befehl Herunterfahren verfügbar. Bei Deaktivierung dieser Richtlinieneinstellung wird die Option Herunterfahren nicht im Windows-Anmeldebildschirm angezeigt. Bei dieser Konfiguration müssen Benutzer in der Lage sein, sich erfolgreich am Computer anzumelden, und Sie müssen über das Benutzerrecht System herunterfahren verfügen, damit sie einen Computer herunterfahren können.

Für die Einstellung Herunterfahren: Herunterfahren des Systems ohne Anmeldung zulassen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Benutzer mit lokalem Zugriff auf die Konsole können den Computer herunterfahren.

Angreifer können auch zur lokalen Konsole gehen, den Server neu starten und dadurch einen vorübergehenden Denial-of-Service verursachen. Darüber hinaus können Angreifer den Server auch herunterfahren. Sämtliche Anwendungen und Dienste des Servers sind dann nicht mehr verfügbar.

Gegenmaßnahme

Setzen Sie die Einstellung Herunterfahren: Herunterfahren des Systems ohne Anmeldung zulassen auf Deaktiviert.

Mögliche Auswirkung

Operatoren müssen sich am Server anmelden, damit sie ihn herunterfahren oder neu starten können.

Herunterfahren: Auslagerungsdatei des virtuellen Arbeitspeichers löschen

Durch diese Richtlinieneinstellung wird festgelegt, ob die Auslagerungsdatei des virtuellen Arbeitsspeichers beim Herunterfahren des Computers gelöscht wird. Für den virtuellen Arbeitsspeicher wird eine Systemauslagerungsdatei verwendet, um gerade nicht benötigte Speicherdaten zeitweilig auf die Festplatte auszulagern. Während des Betriebs wird diese Datei vom Betriebssystem exklusiv geöffnet und gut geschützt. Auf Computern, die auch mit einem anderen Betriebssystem gestartet werden können, sollten Sie jedoch sicherstellen, dass die Systemauslagerungsdatei beim Herunterfahren des Computers gelöscht wird. Dadurch wird gewährleistet, dass ein nicht autorisierter Benutzer, der nach dem Herunterfahren direkt auf die Auslagerungsdatei zugreifen kann, keinen Zugriff auf vertrauliche Informationen aus dem Arbeitsspeicher erhält, die möglicherweise in der Auslagerungsdatei gespeichert sind.

Bei Aktivierung dieser Richtlinieneinstellung wird die Auslagerungsdatei des Systems beim ordnungsgemäßen Herunterfahren gelöscht. Außerdem wird durch diese Richtlinieneinstellung erzwungen, dass die Ruhezustanddatei (hiberfil.sys) gelöscht wird, wenn die Ruhezustandfunktion auf einem tragbaren Computer deaktiviert ist.

Für die Einstellung Herunterfahren: Auslagerungsdatei des virtuellen Arbeitspeichers löschen sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Wichtige Informationen im tatsächlichen Arbeitsspeicher können regelmäßig in die Auslagerungsdatei geschrieben werden, um Windows Server 2003 bei der Behandlung von Multitasking-Funktionen zu unterstützen. Ein Angreifer, der physischen Zugang zu einem heruntergefahrenen Server hat, könnte den Inhalt der Auslagerungsdatei einsehen. Der Angreifer kann den Systemdatenträger auf einen anderen Computer verschieben und dann den Inhalt der Auslagerungsdatei analysieren. Auch wenn das ein zeitraubendes Verfahren ist, können dadurch Daten offen gelegt werden, die vom RAM in der Auslagerungsdatei zwischengespeichert wurden.

Vorsicht: Ein Angreifer mit physischem Zugriff auf den Server kann diese Gegenmaßnahme umgehen, indem er einfach das Netzkabel des Servers herauszieht.

Gegenmaßnahme

Setzen Sie die Einstellung Herunterfahren: Auslagerungsdatei des virtuellen Arbeitspeichers löschen auf Aktiviert. Bei dieser Konfiguration wird die Auslagerungsdatei von Windows Server 2003 gelöscht, wenn der Computer herunterfährt. Der für diesen Vorgang benötigte Zeitraum hängt von der Größe der Auslagerungsdatei ab. Es kann mehrere Minuten dauern, bis der Computer vollständig heruntergefahren ist.

Mögliche Auswirkung

Das Herunterfahren und Neustarten des Servers dauert länger, insbesondere auf Servern mit großen Auslagerungsdateien. Auf einem Server mit 2 GB RAM und einer 2 GB großen Auslagerungsdatei kann aufgrund dieser Richtlinieneinstellung das Herunterfahren 20 bis 30 Minuten oder länger dauern. In einigen Organisationen werden dadurch die internen Vereinbarungen über die Bereitstellung von Diensten verletzt. Seien Sie daher vorsichtig, wenn Sie diese Gegenmaßnahme in Ihre Umgebung implementieren.

Systemkryptografie: Starken Schlüsselschutz für auf dem Computer gespeicherte Benutzerschlüssel erzwingen

Durch diese Richtlinieneinstellung wird festgelegt, ob Benutzer private Schlüssel (z. B. ihren S/MIME-Schlüssel) ohne Kennwort verwenden können.

Für die Einstellung Systemkryptografie: Starken Schlüsselschutz für auf dem Computer gespeicherte Benutzerschlüssel erzwingen sind folgende Werte möglich:

• Keine Benutzereingabe erforderlich, wenn neue Schlüssel gespeichert und verwendet werden

• Benutzer wird zur Eingabe aufgefordert, wenn der Schlüssel zum ersten Mal verwendet wird

• Benutzer müssen jedes Mal, wenn sie einen Schlüssel verwenden, ein Kennwort eingeben

• Nicht definiert

Sicherheitsanfälligkeit

Sie können diese Richtlinieneinstellung so konfigurieren, dass Benutzer bei jeder Verwendung eines Schlüssels ein Kennwort (das mit dem Domänenkennwort nicht identisch ist) eingeben müssen. Durch diese Konfiguration ist es für einen Angreifer schwieriger, auf lokal gespeicherte Benutzerschlüssel zuzugreifen, auch wenn er die Kontrolle über den Computer des Benutzers übernimmt und das Anmeldekennwort aufdeckt.

Gegenmaßnahme

Legen Sie für die Einstellung Systemkryptografie: Starken Schlüsselschutz für auf dem Computer gespeicherte Benutzerschlüssel erzwingen den Wert Benutzer müssen jedes Mal, wenn sie einen Schlüssel verwenden, ein Kennwort eingeben fest.

Mögliche Auswirkung

Benutzer müssen immer ein Kennwort eingeben, wenn Sie auf einen auf ihrem Computer gespeicherten Schlüssel zugreifen möchten. Wenn ein Benutzer z. B. seine E-Mail digital mit einem S-MIME-Zertifikat signiert, ist er gezwungen, jedes Mal, wenn er eine signierte E-Mail-Nachricht sendet, das Kennwort für dieses Zertifikat einzugeben. Für einige Organisationen ist der mit dieser Einstellung verbundene Aufwand möglicherweise zu groß. Sie sollten jedoch zumindest die Einstellung Benutzer wird zur Eingabe aufgefordert, wenn der Schlüssel zum ersten Mal verwendet wird verwenden.

Systemkryptografie: FIPS-konformen Algorithmus für Verschlüsselung, Hashing und Signatur verwenden

Durch diese Richtlinieneinstellung wird festgelegt, ob der TLS/SSL-Sicherheitsdienst nur die sichere Verschlüsselungssammlung TLS_RSA_WITH_3DES_EDE_CBC_SHA unterstützt. Dies bedeutet, dass der Dienst das TLS-Protokoll nur als Client und als Server unterstützt, falls zutreffend. Er verwendet für die TLS-Datenverkehrsverschlüsselung nur den dreifachen DES-Verschlüsselungsalgorithmus, für den TLS-Schlüsselaustausch und die TLS-Authentifizierung nur den öffentlichen RSA-Schlüsselalgorithmus und für die TLS-Hashinganforderungen nur den SHA1-Hashingalgorithmus.

Bei Aktivierung dieser Einstellung unterstützt der EFS-Dienst (Encrypting File System, verschlüsselndes Dateisystem) nur den dreifachen DES-Verschlüsselungsalgorithmus, um Dateidaten zu verschlüsseln. In einer Windows Server 2003-Implementierung von EFS wird standardmäßig der AES-Verschlüsselungsstandard (Advanced Encryption Standard) mit einem 256-Bit-Schlüssel verwendet. In einer Windows XP-Implementierung wird DESX verwendet.

Für die Einstellung Systemkryptografie: FIPS-konformen Algorithmus für Verschlüsselung,Hashingund Signatur verwenden sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Sie können diese Richtlinieneinstellung aktivieren, um sicherzustellen, dass der Computer die leistungsstärksten verfügbaren Algorithmen für digitale Verschlüsselung, Hashing und Signatur verwendet. Bei Verwendung dieser Algorithmen wird das Risiko verringert, dass digital verschlüsselte oder signierte Daten durch einen nicht autorisierten Benutzer gefährdet werden.

Gegenmaßnahme

Setzen Sie die Einstellung Systemkryptografie: FIPS-konformen Algorithmus für Verschlüsselung,Hashingund Signatur verwenden auf Aktiviert.

Mögliche Auswirkung

Clientcomputer, auf denen diese Richtlinieneinstellung aktiviert ist, können mit Servern, die diese Algorithmen nicht unterstützen, nicht über digital verschlüsselte oder signierte Protokolle kommunizieren. Die Netzwerkclients, die diese Algorithmen nicht unterstützen, können keine Server verwenden, die diese Algorithmen für die Netzwerkkommunikation erfordern. Viele Apache-basierte Webserver sind z. B. nicht für eine Unterstützung der TLS-Protokolle konfiguriert. Wenn Sie diese Einstellung aktivieren, müssen Sie auch den Internet Explorer für TLS konfigurieren. Diese Richtlinieneinstellung hat auch Auswirkungen auf die für RDP (Remote Desktop Protocol) verwendete Verschlüsselungsebene. Die Remotedesktopverbindung verwendet das RDP-Protokoll für die Kommunikation mit Servern, die Terminaldienste ausführen, und mit Clientcomputern, die für die Remotesteuerung konfiguriert sind. RDP-Verbindungen können nur hergestellt werden, wenn beide Computer dieselben Verschlüsselungsalgorithmen verwenden.

So aktivieren Sie die TLS-Verwendung in Internet Explorer

1. Öffnen Sie im Internet Explorer im Menü Extras das Dialogfeld Internetoptionen.

2. Klicken Sie auf die Registerkarte Erweitert.

3. Aktivieren Sie das Kontrollkästchen TLS 1.0 verwenden.

Sie können diese Richtlinieneinstellung auch über die Gruppenrichtlinie oder durch Verwenden des Internet Explorer-Administratorkits konfigurieren.

Systemobjekte: Standardbesitzer für Objekte, die von Mitgliedern der Administratorengruppe erstellt werden

Durch diese Richtlinieneinstellung wird festgelegt, ob die Administratorengruppe oder ein Objektersteller der Standardbesitzer aller erstellten Systemobjekte ist.

Für die Einstellung Systemobjekte: Standardbesitzer für Objekte, die von Mitgliedern der Administratorengruppe erstellt werden sind folgende Werte möglich:

• Administratorengruppe

• Objektersteller

• Nicht definiert

Sicherheitsanfälligkeit

Wenn Sie für diese Richtlinieneinstellung den Wert Administratorengruppefestlegen, ist es nicht möglich, einzelne, für die Erstellung des neuer Systemobjekte verantwortliche Benutzer zu ermitteln.

Gegenmaßnahme

Legen Sie für die Einstellung Systemobjekte: Standardbesitzer für Objekte, die von Mitgliedern der Administratorengruppe erstellt werden den Wert Objektersteller fest.

Mögliche Auswirkung

Beim Erstellen von Systemobjekten spiegeln die Besitzrechte wider, über welches Konto das Objekt erstellt wurde (anstelle der allgemeineren Administratorengruppe). Diese Richtlinieneinstellung hat zur Folge, dass Objekte „verwaisen“, wenn das entsprechende Benutzerkonto gelöscht wird. Wenn z. B. ein Mitglied der IT-Abteilung das Unternehmen verlässt, haben alle Objekte, die von diesem Benutzer an beliebiger Stelle in der Domäne erstellt wurden, keinen Besitzer mehr. Diese Situation ist mit einem erhöhten Verwaltungsaufwand verbunden, da Administratoren sich die Besitzrechte an den verwaisten Objekten manuell zuweisen müssen, um ihre Berechtigungen zu aktualisieren. Der potenzielle Verwaltungsaufwand kann jedoch verringert werden, wenn Sie sicherstellen, dass neuen Objekten immer die Berechtigung Vollzugriff zugewiesen wird, wenn es sich z. B. um die Gruppe Domänen-Admins handelt.

Systemobjekte: Groß-/Kleinschreibung für Nicht-Windows-Subsysteme ignorieren

Durch diese Richtlinieneinstellung wird festgelegt, ob für alle Subsysteme das Ignorieren der Groß-/Kleinschreibung erzwungen wird. Für das Microsoft Win32®-Subsystem wird die Groß-/Kleinschreibung ignoriert. Der Kernel unterstützt jedoch die Beachtung der Groß-/Kleinschreibung für andere Subsysteme, z. B. für POSIX (Portable Operating System Interface für UNIX). Bei Aktivierung dieser Einstellung wird das Ignorieren der Groß-/Kleinschreibung für alle Verzeichnisobjekte, symbolischen Verknüpfungen und E/A-Objekte sowie für Dateiobjekte erzwungen. Auch bei Deaktivierung dieser Einstellung wird für das Win32-Subsystem die Groß-/Kleinschreibung weiterhin ignoriert.

Für die Einstellung Systemobjekte: Groß-/Kleinschreibung für Nicht-Windows-Subsysteme ignorieren sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Bei Deaktivierung dieser Richtlinieneinstellung kann ein POSIX-Benutzer durch Mischen von Groß- und Kleinbuchstaben eine Datei mit einem bereits vorhandenen Namen erstellen, da unter Windows die Groß-/Kleinschreibung ignoriert wird, das POSIX-Subsystem jedoch zwischen Groß- und Kleinschreibung unterscheidet. Diese Situation kann zu Verwirrungen bei den Benutzern führen, die mit normalen Win32-Programmen versuchen, auf diese Dateien zuzugreifen, da nur eine der Dateien verfügbar ist.

Gegenmaßnahme

Setzen Sie die Einstellung Systemobjekte: Groß-/Kleinschreibung für Nicht-Windows-Subsysteme ignorieren auf Aktiviert.

Mögliche Auswirkung

Alle Subsysteme werden gezwungen, die Groß-/Kleinschreibung zu ignorieren. Diese Konfiguration kann bei Benutzern, die mit einem der UNIX-basierten Betriebssysteme vertraut sind, die die Groß-/Kleinschreibung berücksichtigen, zu Verwirrung führen.

Systemobjekte: Standardberechtigungen interner Systemobjekte (z. B. symbolischer Verknüpfungen) verstärken

Durch diese Richtlinieneinstellung wird die Stärke der Standard-DACL für Objekte festgelegt. Windows verwaltet eine globale Liste der freigegebenen Systemressourcen (z. B. MS-DOS-Gerätenamen, Mutexe und Semaphore), damit Objekte gesucht und zwischen Prozessen freigegeben werden können.

Für die Einstellung Systemobjekte: Standardberechtigungen interner Systemobjekte (z. B. symbolischer Verknüpfungen) verstärken sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Durch diese Einstellung wird die Stärke der Standard-DACL für Objekte festgelegt. Windows Server 2003 verwaltet eine globale Liste der freigegebenen Computerressourcen, damit Objekte gesucht und zwischen Prozessen freigegeben werden können. Jeder Objekttyp wird mit einer Standard-DACL erstellt, die festlegt, welcher Benutzer mit welchen Berechtigungen auf die Objekte zugreifen kann. Bei Aktivierung dieser Richtlinieneinstellung wird die Standard-DACL verstärkt, da Benutzer ohne Administratorrechte freigegebene Objekte anzeigen, jedoch nur die von ihnen selbst erstellten Objekte ändern können.

Gegenmaßnahme

Setzen Sie die Einstellung Systemobjekte: Standardberechtigungen interner Systemobjekte (z. B. symbolischer Verknüpfungen)verstärken auf Aktiviert.

Mögliche Auswirkung

Keine. Hierbei handelt es sich um die Standardkonfiguration.

Systemeinstellungen: Optionale Subsysteme

Durch diese Richtlinieneinstellung wird festgelegt, durch welche Subsysteme die Anwendungen unterstützt werden. Mit dieser Sicherheitseinstellung können Sie die für Ihre Umgebung erforderlichen Subsysteme in ausreichender Anzahl definieren.

Für die Einstellung Systemeinstellungen: optionale Subsysteme sind folgende Werte möglich:

• Benutzerdefinierte Liste der Subsysteme

• Nicht definiert

Sicherheitsanfälligkeit

Das POSIX-Subsystem ist ein Standard des IEEE (Institute of Electrical and Electronic Engineers), durch das eine Gruppe von Betriebssystemdiensten festgelegt wird. Es ist erforderlich, wenn der Server Anwendungen unterstützt, die dieses Subsystem verwenden.

Das POSIX-Subsystem ist Ursache für ein Sicherheitsrisiko in Bezug auf Prozesse, die u. U. über mehrere Anmeldungen hinweg aktiv bleiben. Wenn ein Benutzer einen Prozess startet und sich dann abmeldet, besteht die Möglichkeit, dass der nächste Benutzer, der sich am Computer anmeldet, Zugriff auf den Prozess des vorherigen Benutzers erhält. Es besteht die Gefahr, dass jede Aktion, die der zweite Benutzer mit diesem Prozess durchführt, mit den Berechtigungen des ersten Benutzers ausgeführt wird.

Gegenmaßnahme

Legen Sie für die Einstellung Systemeinstellungen: optionale Subsysteme einen Nullwert fest. Die Standardeinstellung ist POSIX.

Mögliche Auswirkung

Anwendungen, die das POSIX-Subsystem verwenden, werden nicht mehr ausgeführt. Wenn z. B. SFU (Microsoft Services for Unix) eine aktualisierte Version des erforderlichen POSIX-Subsystems installiert, müssen Sie diese Einstellung für jeden Server, der SFU verwendet, in einer Gruppenrichtlinie zurücksetzen.

Systemeinstellungen: Zertifikatsregeln zur Durchsetzung von Softwareeinschränkungsrichtlinien auf Windows-Programme anwenden

Durch diese Richtlinieneinstellung wird festgelegt, ob digitale Zertifikate verarbeitet werden, wenn Richtlinien für Softwareeinschränkungen aktiviert sind und ein Benutzer oder Prozess versucht, Software mit einer EXE-Dateinamenerweiterung auszuführen. Über diese Einstellung werden Zertifikatsregeln (eine Art Richtlinienregeln für Softwareeinschränkungen) aktiviert beziehungsweise deaktiviert. Mit Richtlinien für Softwareeinschränkungen können Sie eine Zertifikatsregel erstellen, um das Ausführen von mit Authenticode®-signierter Software basierend auf dem digitalen Zertifikat der Software zuzulassen oder zu sperren. Damit Zertifikatsregeln in Richtlinien für Softwareeinschränkungen funktionieren können, müssen Sie diese Sicherheitseinstellung aktivieren.

Für die Einstellung Systemeinstellungen: Zertifikatsregeln zur Durchsetzung von Softwareeinschränkungsrichtlinien auf Windows-Programme anwenden sind folgende Werte möglich:

• Aktiviert

• Deaktiviert

• Nicht definiert

Sicherheitsanfälligkeit

Richtlinien für Softwareeinschränkungen helfen dabei, Benutzer und Computer davor zu schützen, nicht autorisierten Code wie Viren oder Trojaner auszuführen.

Gegenmaßnahme

Setzen Sie die Einstellung Systemeinstellungen: Zertifikatsregeln zur Durchsetzung von Softwareeinschränkungsrichtlinien auf Windows-Programme anwenden auf Aktiviert.

Mögliche Auswirkung

Bei Aktivierung von Zertifikatsregeln überprüfen die Richtlinien für Softwareeinschränkungen anhand einer Zertifikatssperrliste (CRL), ob das Zertifikat und die Signatur der Software gültig sind. Dieser Überprüfungsvorgang kann sich beim Starten von signierten Programmen negativ auf die Leistung auswirken. Zum Deaktivieren dieser Funktion können Sie im entsprechenden Gruppenrichtlinienobjekt die Richtlinie für Softwareeinschränkungen bearbeiten. Deaktivieren Sie im Dialogfeld Eigenschaften von Vertrauenswürdigen Herausgebern die Kontrollkästchen Herausgeber und Zeitstempel.

Weitere Informationen

Die folgenden Links bieten weitere Informationen zu Sicherheitsoptionen unter Windows Server 2003 und Windows XP.

• Weitere Informationen zu den standardmäßigen COM-Computerzugriffseinschränkungen unter Windows XP finden Sie im Handbuch „Verwalten der Funktionen von Windows XP Service Pack 2 mithilfe von Gruppenrichtlinien: Sicherheitsbezogene Richtlinieneinstellungen“ (in englischer Sprache) unter www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngsecps.mspx.

• Informationen zu den standardmäßigen COM-Zugriffseinschränkungen unter Windows Server 2003 mit SP1 finden Sie im Abschnitt „DCOM Security Enhancements“ im Handbuch „Änderungen an der Funktionalität in Microsoft Windows Server 2003 Service Pack 1“ (in englischer Sprache) unter www.microsoft.com/technet/prodtechnol/windowsserver2003/library/BookofSP1/.

• Weitere Informationen zur Aktivierung von NTLMv2 finden Sie im Microsoft Knowledge Base-Artikel „Aktivieren der NTLM 2-Authentifizierung“ unter https://support.microsoft.com/default.aspx?scid=239869.

• Weitere Informationen dazu, wie sichergestellt werden kann, dass in gemischten Netzwerken mit Windows 2000- und Windows NT® 4.0-Computern sicherere LAN Manager-Authentifizierungseinstellungen verwendet werden, finden Sie im Microsoft Knowledge Base-Artikel „Authentifizierungsprobleme in Windows 2000 mit NTLM 2-Ebenen oberhalb von 2 in einer Windows NT 4.0-Domäne“ (in englischer Spache) unter https://support.microsoft.com/?scid=305379.

• Weitere Informationen zu LAN Manager-Kompatibilitätsstufen finden Sie im Microsoft Knowledge Base-Artikel „Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments“ (in englischer Spache) unter https://support.microsoft.com/?scid=823659.

• Weitere Informationen zur NTLMv2-Authentifizierung finden Sie im Microsoft Knowledge Base-Artikel „How to Enable NTLM 2 Authentication“ (in englischer Spache) unter https://support.microsoft.com/?scid=239869.

• Weitere Informationen zum lokalen Wiederherstellen der Standardsicherheitseinstellungen finden Sie im Microsoft Knowledge Base-Artikel „How to Reset Security Settings Back to the Defaults“ (in englischer Sprache) unter https://support.microsoft.com/?scid=313222.

• Weitere Informationen zum Wiederherstellen der Standardsicherheitseinstellungen in den vordefinierten Gruppenrichtlinienobjekten der Domäne finden Sie im Microsoft Knowledge Base-Artikel „How to Reset User Rights in the Default Domain Group Policy in Windows Server 2003“ (in englischer Sprache) unter https://support.microsoft.com/?scid=324800.

In diesem Beitrag

• Überblick
• Kapitel 1: Einführung zu Bedrohungen und Gegenmaßnahmen: Sicherheitseinstellungen unter Windows Server 2003 und Windows XP
• Kapitel 2: Richtlinien auf Domänenebene
• Kapitel 3: Überwachungsrichtlinie
• Kapitel 4: Benutzerrechte
• Kapitel 5: Sicherheitsoptionen
• Kapitel 6: Ereignisprotokoll
• Kapitel 7: Systemdienste
• Kapitel 8: Richtlinien für Softwareeinschränkungen
• Kapitel 9: Administrative Vorlagen für Windows XP und Windows Server 2003
• Kapitel 10: Zusätzliche Registrierungseinträge
• Kapitel 11: Zusätzliche Gegenmaßnahmen
• Kapitel 12: Zusammenfassung
• Danksagungen

Download

Handbuch „Bedrohungen und Gegenmaßnahmen“ herunterladen (engl.)

Benachrichtigung über Neuerungen

Melden Sie sich an, um sich über Updates und neue Versionen zu informieren

Feedback

Senden Sie uns Ihre Kommentare oder Vorschläge

6 von 14