Grundlegende Konzepte

Kapitel 6: Zugriffsverwaltung

Veröffentlicht: 11. Mai 2004 | Aktualisiert: 26. Jun 2006

Die Zugriffsverwaltung besteht aus Prozessen und Technologien für die Steuerung und Überwachung des Zugriffs auf Ressourcen in Übereinstimmung mit geltenden Richtlinien. Die Zugriffsverwaltung beinhaltet Folgendes:

• Authentifizierung

• Autorisierung

• Vertrauensstellung

• Sicherheitsüberwachung

Auf dieser Seite

Authentifizierung
Autorisierung
Vertrauensstellung und Zusammenschluss
Sicherheitsüberwachung

Authentifizierung

In der Microsoft Identity and Access Management-Plattform wird der Verzeichnisdienst Microsoft® Active Directory® zum Speichern von Identitätsinformationen empfohlen. Hierzu zählen auch die während des Authentifizierungsprozesses zur Überprüfung von Benutzeranmeldeinformationen verwendeten kryptografischen Schlüssel.

In Microsoft Windows Server™ 2003, Microsoft Windows® XP Professional und Windows-Sicherheitsdienste integrierte Anwendungen verwenden die Features des Betriebssystems für die Authentifizierung.

Windows-Authentifizierungsdienste

Die individuelle Implementierung von Authentifizierungsprotokollen für jede Anwendung ist sehr ineffizient und kann dazu führen, dass sich über die gesamte Organisation hinweg Sicherheitsfehler einschleichen. Ein besserer Ansatz ist die Erstellung von Anwendungen mit den Authentifizierungsmechanismen in der Windows-Plattform.

Um bestmögliche Ergebnisse zu erzielen, sollten sich Entwickler vor dem Entwerfen einer Anwendung mit den unterschiedlichen Authentifizierungstypen, den Auswirkungen der Verwendung unterschiedlicher Protokolle und den unterstützten Schnittstellen vertraut machen.

Architektur der Windows-Authentifizierungsdienste

Windows Server 2003 und Microsoft Windows XP implementieren einen vollständigen Satz von Authentifizierungsmethoden und Sicherheitsprotokollen, die vielen Authentifizierungsanforderungen gerecht werden. Microsoft .NET Passport, die Authentifizierung mit öffentlichem Schlüssel mittels Zertifikaten oder Smartcards und Benutzername-/Kennwortkombinationen bieten aufgrund der unterschiedlichen Anforderungen hinsichtlich der Anmeldeinformationen ein unterschiedliches Maß an Benutzerfreundlichkeit. Zudem besitzt jede Methode andere Sicherheitseigenschaften. Die verfügbaren Authentifizierungsprotokolle können auch durch den Datentransportmechanismus vorgegeben sein.

Das Sicherheitssystem für die Authentifizierungsdienste in der Microsoft Identity and Access Management-Plattform besteht aus mehreren Ebenen: Es reicht von Schnittstellen auf niedriger Ebene, die mehr Flexibilität und umfassendere Steuerungsmöglichkeiten bieten, bis hin zu weniger flexiblen Schnittstellen auf höherer Ebene, die aber eine einfachere API (Anwendungssprogrammierschnittstelle) besitzen. Die folgende Abbildung zeigt die Authentifizierungsprotokoll- und Anwendungs-API-Ebenen in diesem System.

Abbildung 6.1 Authentifizierungs-API- und Protokollhierarchie im Betriebssystem Windows

Abbildung vergrößern

Im oberen Teil der obigen Authentifizierungsanordnung stellen übergeordnete APIs und Dienste Mechanismen für die prozessübergreifende Kommunikation (IPC) bereit. Diese Mechanismen bieten einen sicheren authentifizierten Kanal für die Übertragung von Anwendungsdaten. Beispiele für solche Dienste und APIs sind DCOM (Distributed Component Object Model), Remoteprozeduraufrufe (RPC), Microsoft ASP.NET, ASP, WinInet usw.

Der RPC-Dienst von Microsoft ist ein leistungsstarker, effizienter und sicherer IPC-Mechanismus, der den Datenaustausch und den Aufruf von Funktionen aus einem anderen Prozess ermöglicht. Dieser andere Prozess kann auf demselben Computer, im LAN oder im Internet ausgeführt werden.

WinInet ist eine Anwendungsprotokollschnittstelle, die Internetsicherheitsprotokolle wie SSL (Secure Sockets Layer) über Internetprotokolle unterstützt. Die Implementierung der WinInet-Sicherheitsunterstützung verwendet SSPI (Security Support Provider Interface) zum sicheren Kanal (Windows NT®-Implementierung von SSL) des Sicherheitsanbieters.

In einigen Fällen ermöglichen die von diesen Diensten offen gelegten APIs dem Anwendungsentwickler die vollständige Kontrolle der Authentifizierung und des Datenschutzes. In DCOM-APIs kann der Entwickler z. B. ein spezifisches Authentifizierungsprotokoll wie das Kerberos-Protokoll oder NT LAN Manager (NTLM) Challenge/Response auswählen. Zudem kann festgelegt werden, ob Daten signiert (zum Schutz vor Angreifern, die die Daten ändern) oder verschlüsselt (zum Schutz vor Lauschangriffen auf die Daten) werden sollen. Andere Dienste und APIs werden nur von der Systemkonfiguration beeinflusst. Das beste Beispiel hierfür ist ASP.NET. ASP.NET wird auf einem Server mit Microsoft Internetinformationsdienste (IIS) 6.0 gehostet, der zur Verwendung des entsprechenden Authentifizierungsmechanismus für ein bestimmtes Szenario konfiguriert werden kann.

Security Support Provider Interface (SSPI)

Die auf niedrigster Ebene befindliche Anwendungsschnittstelle für die Authentifizierung ist SSPI, die Microsoft-Version der allgemeinen Sicherheitsdienst-API (Generic Security Service API, GSS-API). Weitere Informationen zur GSS-API finden Sie auf der Website der Internet Engineering Task Force (ITEF) unter Request for Comments auf den Seiten RFC 1508 und 1509 (in englischer Sprache).

Weitere Informationen zu SSPI finden Sie auf der MSDN-Website im Artikel The Security Support Provider Interface Revisited (in englischer Sprache).

Die grundlegende Idee von SSPI und GSS-API ist, dass die Netzwerkauthentifizierung zwischen zwei Parteien generell einem allgemeinen Muster folgt. Die Parteien müssen in einer bestimmten Reihenfolge Informationen austauschen. Da sie über viele unterschiedliche Protokolle kommunizieren können – Hypertext Transfer Protocol (HTTP), RPC, Server Message Block (SMB), Internet Inter-ORB Protocol (IIOP), DCOM, Java Remote Method Invocation (RMI) usw. – ist es nicht ratsam, einen einzigen Authentifizierungshandshake im Netzwerkprotokoll selbst fest zu implementieren. Stattdessen sollte von einer einfachen allgemeinen Schnittstelle „Authentifizierungstokens“ generiert werden, bei denen es sich nur um binäre Datenkonstruktionen zur Darstellung eines Aspekts der Authentifizierungssequenz handelt. Diese Tokens werden über das jeweils verwendete Anwendungsprotokoll ausgetauscht.

In RPC wird ein Handshake z. B. bereits zum Synchronisieren der Protokolle zwischen Client und Server verwendet. RPC bietet in diesem Handshake einfach Platz für nicht transparente Authentifizierungstokens zufälliger Größe. Ein Großteil der von SSPI und GSS-API ausgeführten Arbeit besteht im Generieren und Auswerten dieser Tokens.

Wie zuvor bereits erwähnt, werden von Windows Server- und Clientbetriebssystemen eine Vielzahl von Authentifizierungsprotokollen implementiert. Diese Protokolle sind „Sicherheitspakete“ (auch Authentifizierungspakete genannt) und bestehen aus DLLs, die von der lokalen Sicherheitsinstanz geladen werden. SSPI ist die Schnittstelle für alle mit den Windows Server- und Clientbetriebssystemen gelieferten Sicherheitspaketen. Von diesen Sicherheitspaketen wird normalerweise ein Netzwerkauthentifizierungsprotokoll wie Kerberos Version 5, NTLM Challenge/Response, Digestauthentifizierung, Secure Sockets Layer (SSL) oder Transport Layer Security (TLS) implementiert. Anwendungen können mithilfe dieser Protokolle eine sichere und nahtlose Integration mit Active Directory für die Authentifizierung herstellen, und zudem können sie die Funktionen der Protokolle zum Sichern von Anwendungsdaten verwenden.

SPNEGO (Secure Protocol Negotiation) ist ein spezieller Sicherheitspakettyp, der die erforderlichen Verhandlungen zwischen Authentifizierungsprotokollen führt. Für Anwendungen mit SSPI und Kerberos Version 5 oder NTLM wird anstelle der direkten Verwendung dieser Protokolle die Verwendung des SPNEGO-Pakets empfohlen. Weitere Informationen zu SPNEGO finden Sie auf der MSDN-Website auf der Seite Windows Security (in englischer Sprache).

Kerberos-Authentifizierung

Das Authentifizierungsprotokoll Kerberos Version 5 ist auf der IETF-Website unter „Request for Comments“ auf der Seite RFC 1510 definiert (in englischer Sprache). Das Protokoll ist extrem sicher und skalierbar und daher ideal für die Authentifizierung in einer integrierten Netzwerkumgebung geeignet.

Auf Windows-Servern und -Clients mit Microsoft Windows 2000 Server oder höher dient das Authentifizierungsprotokoll Kerberos Version 5 als Grundlage für die Authentifizierung bei Active Directory. Zudem ist es in SMB, HTTP und RPC sowie in die Client- und Serveranwendungen, die diese Protokolle verwenden, integriert. Die Windows-Plattform ermöglicht dem Benutzer eine nahtlose und integrierte Verwendung dieses leistungsstarken Sicherheitstools.

Das Protokoll Kerberos Version 5 ist sehr wichtig für die Identitäts- und Zugriffsverwaltungsplattform von Microsoft, da es auf einem offenen Standard beruht. Viele andere Anbieter haben ebenfalls Kerberos Version 5 basierend auf der Protokollimplementierung des MIT (Massachusetts Institute of Technology) implementiert. Dadurch wurde der Weg für die Authentifizierungsinteroperabilität zwischen Plattformen und Anwendungen von Microsoft und Produkten anderer Anbieter geebnet.

Windows unterstützt zwei Methoden zum Konfigurieren von Kerberos Version 5 für die Interoperabilität:

• Sie können eine Vertrauensstellung zwischen einer Windows-Domäne und einem MIT-basierten Bereich mit dem Kerberos 5-Protokoll einrichten. Durch diese Vertrauensstellung können sich Clients in diesem Bereich über den Vertrauensmechanismus bei Netzwerkressourcen in der Windows-Domäne authentifizieren.

• Nicht-Windows-Clients und -Server können Active Directory-Konten verwenden, um von einem Domänencontroller authentifiziert zu werden.

In einem Intranet bieten Kerberos 5-Protokollimplementierungen auf der Windows-Plattform dem Benutzer SSO-Funktionen (Single Sign-on) aufgrund der grundlegenden Eigenschaften des Authentifizierungsprotokolls und der spezifischen Features der Implementierung des Protokolls in Windows-Client- und Serverbetriebssystemen.

Kerberos Version 5 hat den großen Nachteil, dass die Kerberos-Authentifizierung nicht für die Verwendung im Internet konfiguriert werden kann. Aus diesem Grund kann das Protokoll keine universelle Lösung für die Anwendungsauthentifizierung und Sicherheit sein. Die Gründe hierfür werden im Abschnitt „Web-Single Sign-on“ dieses Kapitels ausführlicher beschrieben.

Weitere Informationen zum Authentifizierungsprotokoll Kerberos Version 5 finden Sie auf der Microsoft TechNet-Website auf der Seite Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability (in englischer Sprache).

Secure Sockets Layer (SSL) 3.0 und Transport Layer Security (TLS) 1.0

SSL 3.0 und TLS 1.0 sind eng miteinander verknüpfte Protokolle, mit denen Sie das allgemeine Problem der Sicherung eines Kommunikationskanals zwischen zwei Anwendungen lösen können. SSL 3.0 ist ein urheberrechtlich geschütztes Protokoll von Netscape Communications, während es sich bei TLS 1.0 um einen IETF-Standard handelt, dessen Definition Sie auf der IETF-Website unter „Request for Comments“ auf der Seite RFC 2246 (in englischer Sprache) finden. Die beiden Protokolle ähneln einander, TLS enthält jedoch einige wichtige Verbesserungen. Microsoft empfiehlt, möglichst TLS zu verwenden. Sowohl TLS als auch SSL bieten während der Einrichtung eines sicheren Datenkanals die Möglichkeit der Serverauthentifizierung. Die Clientauthentifizierung ist als Option verfügbar.

Die SSL- und TLS-Protokolle werden am häufigsten zum Gewährleisten des Datenschutzes und der Datenintegrität (Verschlüsselung) über das HTTP-Protokoll verwendet. SSL oder TLS werden ebenfalls von anderen Protokollen unterstützt. Das Lightweight Directory Access Protocol (LDAP) integriert z. B. SSL, um LDAP-über-SSL oder LDAPS herzustellen. Zudem können angepasste Anwendungen oder Anwendungen anderer Hersteller SSL oder TLS direkt über die SSPI verwenden und das SChannel-Sicherheitspaket auswählen.

SSL und TLS bieten eine auf Zertifikaten beruhende Authentifizierung und sichere Datenübertragungen mittels symmetrischer Verschlüsselungsschlüssel. Im Internet verwenden Organisationen SSL und TLS oft für die Serverauthentifizierung. Clients überprüfen die folgenden Bedingungen, um Server in SSL und TLS zu authentifizieren:

• Das Serverzertifikat ist gültig.

• Der Server hat den entsprechenden dem X.509-Zertifikat des Servers zugeordneten privaten Schlüssel vorgewiesen.

• Beim authentifizierten Server handelt es sich um den im Zertifikat angegebenen Server.

SSL und TLS unterstützen und integrieren auch die Clientauthentifizierung mit der Plattform Windows Server 2003 über X.509-Clientzertifikate. Die gleichzeitige Client- und Serverauthentifizierung wird gewöhnlich als gegenseitige Authentifizierung bezeichnet. Zum Durchführen der Clientauthentifizierung präsentiert der Client ein gültiges Clientzertifikat, das vom Server mit den für die Serverauthentifizierung beschriebenen Kriterien verglichen wird. Nach der Überprüfung des Clientzertifikats bietet Windows Server die Möglichkeit, das Zertifikat einem Active Directory-Konto zuzuordnen. Zertifikate können in Active Directory flexibel zugeordnet werden; sowohl Eins-zu-Eins- als auch Viele-zu-Eins-Zuordnungen sind möglich.

Im Vergleich zu anderen Authentifizierungsprotokollen besitzen SSL und TLS sehr gute Sicherheitseigenschaften, wenn digitale X.509-Zertifikate für die Authentifizierung verwendet werden.

Hinweis   SSL und TLS bieten Benutzern über die Windows-Anmeldeinformationsverwaltung Web-SSO. Diese Funktion wird weiter unten in diesem Kapitel beschrieben.

Passport-Authentifizierung

Microsoft Passport ist ein Webdienst, mit dem Benutzer anhand einer riesigen Datenbank von digitalen Identitäten authentifiziert werden. Benutzer verwalten ihre Passport-Identität über eine sichere Website. Passport bietet Authentifizierungs- und Web-SSO-Funktionen für viele Websites und wird auf zahlreichen Websites von Microsoft sowie auf anderen Sites verwendet.

Entwickler können ihre Anwendungen mit Passport verknüpfen, damit die Anwendungen nur Verbindungen von registrierten Passport-Benutzern akzeptieren. Wenn von Passport festgestellt wird, dass die Anmeldeinformationen eines Benutzers gültig sind, gibt es ein Authentifizierungsticket zurück, das die Anwendung zum Überprüfen der Identität des Benutzers entschlüsseln kann. Aufgrund von Datenschutzanforderungen wird bei einer typischen Passport-Authentifizierung nur eine eindeutige Passport-ID (PUID) an die jeweilige Anwendung zurückgegeben.

Normalerweise wird dann die PUID von der Anwendung einem lokal verwalteten Benutzerkonto zugeordnet, um eine in der Organisation gültige digitale Identität abzuleiten. Windows Server 2003 lässt sich bei Auswahl der Passport-Authentifizierungskonfigurationsoption in IIS 6.0 vollständig mit Passport integrieren. Zudem können Sie Passport-Benutzer Active Directory-Konten zuordnen, um eine vollständige Integration der Passport-Authentifizierung in das Windows-Sicherheitsmodell zu ermöglichen.

Die Passport-Authentifizierung bietet für mit dem Internet verbundene Anwendungen SSO-Funktionen. Zu diesem Zweck stellt Passport ein in einem HTTP-Cookie verschlüsseltes Authentifizierungsticket bereit. Das Vorhandensein des während der Browsersitzung aufrechterhaltenen Cookies ermöglicht die Authentifizierung bei mehreren Anwendungen, ohne dass sich der Benutzer wiederholt am Passport-Authentifizierungsdienst anmelden muss.

Weitere Informationen zu Passport finden Sie auf der MSDN-Website unter .NET Passport Service Guide Kit (in englischer Sprache).

Digestauthentifizierung

Die Digestauthentifizierung ist ein weiteres auf Standards beruhendes Authentifizierungsprotokoll. Es ist auf der IETF-Website unter „Request for Comments“ auf der Seite RFC 2617 (in englischer Sprache) definiert und ist als Authentifizierungspaket in Window Server 2003 enthalten. Die Digestauthentifizierung bietet in erster Linie Interoperabilität zwischen Windows- und Nicht-Windows-Plattformen für die Internetauthentifizierung.

In Windows Server 2003 wird die Digestauthentifizierung auch als einfacher Authentifizierungs- und Sicherheitsstufenmechanismus (Simple Authentication and Security Layer, SASL) implementiert. Eine Beschreibung finden Sie auf der IETF-Website unter „Request for Comments“ auf der Seite RFC 2831 (in englischer Sprache). SASL ist eine weitere Abstraktionsebene zwischen der Anwendung und dem zugrunde liegenden Protokoll, die die Verwendung anderer Authentifizierungsmechanismen ermöglicht, ohne die Anwendung ändern zu müssen. In mancher Hinsicht ähnelt SASL dem zuvor beschriebenen SPNEGO-Mechanismus. SASL wird hauptsächlich für die LDAP-Authentifizierung verwendet.

Die Digestauthentifizierung besitzt ähnliche Sicherheitseigenschaften wie das proprietäre NTLM-Protokoll. Sowohl die Digestauthentifizierung als auch NTLM sind Challenge/Response-Protokolle, bei denen der authentifizierende Server eine Anfrage mit einer bestimmten Menge von unvorhersehbaren Daten generieren muss. Der Client erstellt dann die Antwort, indem er die Anfrage mit einem aus dem Kennwort des Benutzers abgeleiteten Schlüssel verschlüsselt. Der Server oder ein vertrauenswürdiger Drittanbieterdienst wie Active Directory kann bestätigen, dass der Benutzer das korrekte Kennwort besitzt, indem die Antwort des Clients mit einem Wert verglichen wird, der aus den im Identitätsspeicher für den Benutzer vorhandenen Anmeldeinformationen berechnet wird. Stimmt die Antwort mit dem berechneten Wert überein, wird davon ausgegangen, dass der Benutzer das geheime Kennwort kennt, und er wird authentifiziert.

Im Allgemeinen ist die Digestauthentifizierung nicht so sicher wie das Kerberos Version 5-Protokoll, da zum Schutz des Challenge/Response-Mechanismus vor Angriffen sichere Kennwörter erforderlich sind. Da das Nur-Text-Kennwort während der Authentifizierung jedoch nicht an den Server gesendet wird, ist diese Methode besser als die formulargestützte Authentifizierung oder die Standardauthentifizierung. SSL und TLS werden häufig verwendet, um die Digestauthentifizierung vor Angriffen zu schützen.

Die Digestauthentifizierung lässt sich zwar in den meisten Szenarios nicht so gut skalieren wie Kerberos Version 5, sie kann jedoch in Situationen verwendet werden, in denen das Kerberos-Protokoll nicht funktioniert. Ein Beispiel hierfür ist die Authentifizierung bei externen Websites.

Die Digestauthentifizierung bietet SSO nur zum Schutz von Informationen, die über nur eine Web-URL verfügbar sind. Wenn Benutzer zu einer anderen Site oder sogar zu einem anderen Server auf derselben Site wechseln, müssen Sie ihre Anmeldeinformationen normalerweise erneut eingeben.

Formulargestützte Authentifizierung

Die formulargestützte Authentifizierung verwendet Anmeldeformulare auf Webseiten zur Erfassung von Benutzeranmeldeinformationen, und die Informationen werden nahezu immer in Form von Nur-Text-Benutzernamen und -Kennwörtern eingegeben. Als solches ist dieser Authentifizierungstyp kein Authentifizierungsprotokoll zwischen einem Client und einem Server – zumindest nicht in dem Sinne wie das Protokoll Kerberos Version 5 oder die im vorhergehenden Abschnitt beschriebene Digestauthentifizierung.

Die formulargestützte Authentifizierung erfordert extreme Sorgfalt, um eine Anwendung korrekt zu schützen, und Microsoft rät davon ab, diesen Authentifizierungstyp ohne SSL zu verwenden. Eine ausgenutzte Sicherheitslücke in einer mit der formulargestützten Authentifizierung arbeitenden Anwendung kann dem Angreifer das Abfangen des Nur-Text-Kennworts ermöglichen und somit ein schwerwiegendes Sicherheitsrisiko für Anwendungsdaten in der ganzen Organisation und für das Netzwerk selbst darstellen.

Da die Anwendung, die die formulargestützte Authentifizierung ausführt, Benutzeranmeldeinformationen als Nur-Text-Kennwort erhält, kann von ihr die Authentifizierung mit anderen Benutzerspeichern als Active Directory vorgenommen werden. Microsoft rät in den meisten Fällen von der Verwendung dieses Ansatzes ab, da die Identitäts- und Zugriffsverwaltungslösung durch zusätzliche Identitätsspeicher komplizierter wird.

Anwendungsentwickler, die die formulargestützte Authentifizierung implementieren, sollten Benutzer in Active Directory mit einem LDAP Bind-Befehl oder einer Windows-API wie LogonUser() authentifizieren, um die Benutzeranmeldeinformationen zu überprüfen und optional einen Sicherheitskontext zu generieren (siehe „Autorisierung“ weiter unten in diesem Kapitel).

Anwendungen, die die formulargestützte Authentifizierung implementieren, verwenden normalerweise HTTP-Cookies oder URL-Änderungen, um SSO-Funktionen für den Benutzer bereitzustellen. ASP.NET bietet Funktionen, mit denen Cookies mittels Verschlüsselung vor nicht autorisiertem Lesezugriff und mittels digitaler Signaturen vor Änderungen geschützt werden.

Der Artikel „Entwickeln identitätsabhängiger ASP.NET-Anwendungen“ dieser Serie enthält ausführliche Informationen dazu, wie Entwickler die formulargestützte Authentifizierung auf der Windows-Plattform verwenden können.

Standardauthentifizierung

Ähnlich wie die formulargestützte Authentifizierung ist die Standardauthentifizierung insofern nicht wirklich ein Netzwerkauthentifizierungsprotokoll, als sie die Anmeldeinformationen des Benutzers beim Authentifizieren bei einer Netzwerkressource nicht kryptografisch schützt. Der für die Authentifizierung zuständige Server erhält die Benutzeranmeldeinformationen wie bei der formulargestützten Authentifizierung als Nur-Text-Kennwort und verwendet dann Windows-APIs, um den Benutzer zu authentifizieren. Wie bei der formulargestützten Authentifizierung müssen der Entwickler und der Systemadministrator beim Bereitstellen dieser Authentifizierungstechnik großen Aufwand betreiben, um die Anwendung oder den Server vor Angriffen zu schützen. Aus diesem Grund rät Microsoft ausdrücklich davon ab, die Standardauthentifizierung ohne SSL zu verwenden. Die Standardauthentifizierung besitzt die gleichen SSO-Eigenschaften wie die Digestauthentifizierung.

Single Sign-on

Ein wichtiger Begriff im Zusammenhang mit der Authentifizierung ist das einmalige Anmelden (Single Sign-on, SSO). Zum Bereitstellen von SSO als Teil des Authentifizierungsprozesses sind mehrere Ansätze verfügbar:

• Desktop-integrierte SSO

• Web-SSO

• Anmeldeinformationszuordnung oder SSO für Unternehmen

SSO dient einzig dem Zweck, die Notwendigkeit der wiederholten Eingabe von Benutzeranmeldeinformationen zu beseitigen, und sagt nichts über die Sicherheitsstufe der verwendeten Authentifizierung aus. Aus Sicherheitsgründen sind einige SSO-Typen u. U. vorzuziehen.

Die Begriffe Extranet-SSO und Intranet-SSO bezeichnen die zum Implementieren von SSO in Extranet- oder Intranetszenarios verwendeten Techniken. Extranet-SSO ist normalerweise webgestützt, während Intranet-SSO viele Anwendungs- und Diensttypen wie Webanwendungen, Thick-Clientanwendungen und Terminalsitzungen beinhalten kann.

Desktop-integrierte Single Sign-on

Die sichere Anmeldung erfordert, dass Benutzer ihre Identität gegenüber einem Netzwerk beweisen, die wiederholte Eingabe eines Kennworts für den Zugriff auf mehrere Ressourcen ist für den Benutzer jedoch nicht wünschenswert. Die Microsoft Windows-Plattform nutzt die Fähigkeit, im gesamten Netzwerk nur eine (in Active Directory verwaltete) Benutzeridentität zu verwenden. Da die zum Anmelden bei der Arbeitsstation verwendeten Anmeldeinformationen häufig mit denen für den Zugriff auf Netzwerkressourcen identisch sind, werden die Anmeldeinformationen des Benutzers (Benutzername-/Kennwortkombination) in der lokalen Sicherheitsinstanz (Local Security Authority, LSA) auf dem Clientbetriebssystem zwischengespeichert. Wenn sich ein Benutzer an der Domäne anmeldet, verwendet die Windows-Authentifizierung die zwischengespeicherten Anmeldeinformationen, um bei der Authentifizierung bei Netzwerkressourcen SSO zu ermöglichen.

Eine gute Sicherheit erfordert, dass ein Benutzer für den Zugriff auf eine Netzwerkressource eine authentifizierte Identität vorweist. SSO ermöglicht Benutzern mit einer einmaligen Authentifizierung im System den Zugriff auf alle Anwendungen und Datenquellen, zu deren Verwendung sie ohne Eingabe einer anderen Kontokennung oder eines anderen Kennworts berechtigt sind.

Das Authentifizierungsprotokoll Kerberos Version 5, NTLM und Smartcard-Authentifizierungstechniken sind in den Desktopanmeldeprozess in Client- und Serverbetriebssystemen von Microsoft integriert, um Benutzern innerhalb einer Windows-Domäne oder einer Gesamtstruktur im Intranet einer Organisation SSO-Funktionen zu bieten. Active Directory dient als der vertrauenswürdige Dritte, der Servern die Überprüfung von Benutzern ermöglicht, ohne Informationen zu jedem Benutzer lokal speichern zu müssen.

Erweiterte Vertrauensstellungsmechanismen wie gesamtstrukturübergreifende Vertrauensstellungen in Windows Server 2003 ermöglichen Identitäten einer Gesamtstruktur das einmalige Anmelden beim Zugriff auf Ressourcen in anderen Gesamtstrukturen.

Web-SSO

Da immer mehr Firmen von Mitarbeitern, Partnern und Kunden verwendete extranet- und intranetgestützte Webanwendungen bereitstellen, müssen Benutzer die Möglichkeit zur SSO erhalten.

Webanwendungen unterscheiden sich von herkömmlichen „Thick“-Client-/Serveranwendungen, da sie sich zum Implementieren der Authentifizierung häufig auf den Webserver stützen. Dies ermöglicht einen allgemeinen Ansatz, bei dem nur einer Anwendung (dem Webserver) Authentifizierungsmechanismen hinzugefügt werden und gleichzeitig das Authentifizierungsproblem für eine Vielzahl von serverseitig gehosteten Anwendungen gelöst wird. In einer Intranetumgebung bieten Server- und Clientprodukte von Microsoft eine einmalige Webanmeldung bzw. Web-SSO, indem das Authentifizierungsprotokoll Kerberos Version 5 wie im Dokument „Intranet-Zugriffsverwaltung“ dieser Serie beschrieben in Internet Explorer und IIS 6.0 implementiert wird.

Bedauerlicherweise funktioniert die gut für Intranetszenarios geeignete Kerberos-Implementierung nicht bei Anwendungen mit Internetverbindung im Extranet einer Organisation. Der Unterschied zwischen Intranet- und Extranet-Web-SSO ist auf eine Kombination von drei Faktoren zurückzuführen:

• Schwierigkeiten bei der Bereitstellung eines Schlüsselverteilungscenters (Key Distribution Center, KDC) mit Internetverbindung, z. B. eines Active Directory-Domänencontrollers

• Tatsache, dass viele Browser die Kerberos-Authentifizierung über HTTP nicht unterstützen

• Sicherheitslücken im KDC-Protokoll

Eine detaillierte Beschreibung der Schwierigkeiten bei der Bereitstellung eines mit dem Internet verbundenen KDC geht über den Umfang dieses Artikels hinaus, das Problem behindert die Bereitstellung jedoch erheblich.

Das zweite Problem ist für Extranetbereitstellungen meist das schwerwiegendere Problem. Anders als bei internen Bereitstellungen, bei denen Softwarestandards erzwungen werden können, können nur wenige Organisationen sowohl den Typ als auch die Version der von externen Kunden und Geschäftspartnern für den Zugriff auf externe Anwendungen verwendeten Browsersoftware vorschreiben. Microsoft Internet Explorer Version 6.0 und höher ist der einzige im Handel erhältliche Browser, der die Kerberos-Authentifizierung über HTTP unterstützt.

Der Standardlösungsansatz zum Bereitstellen von SSO für mehrere Webanwendungen ist die Verwendung von so genannten Sitzungscookies. Informationen hierzu finden Sie auf der IETF-Website unter „Request for Comments“ in der Definition „HTTP State Management Mechanism“ auf der Seite RFC 2109 (in englischer Sprache). Lösungen zum Implementieren von Web-SSO in Extranetwebanwendungen sind von mehreren unabhängigen Softwareanbietern erhältlich.

Der zuvor beschriebene Microsoft Passport-Dienst bietet für Sites, die die Passport-Authentifizierung unterstützen, ebenfalls SSO-Funktionen.

Sie können Web-SSO-Techniken mit SSO-für-Unternehmen-Techniken kombinieren, z. B. mit einer SharePoint Portal Server-Website, die einen Webteil für den Zugriff auf ältere Anwendungsdaten in einem eindeutigen Authentifizierungsverzeichnis enthält. In diesem Beispiel bietet eine Web-SSO-Technik Zugriff auf die Website, und eine SSO-für-Unternehmen-Technik bietet Zugriff auf die älteren Anwendungsdaten.

Anmeldeinformationszuordnung und SSO für Unternehmen

SSO für Unternehmen definiert jede Technik, die eine Form von Anmeldeinformationszuordnung verwendet, um SSO-Funktionen bereitzustellen. Eine Anmeldeinformationszuordnung ist notwendig, da unterschiedliche Identitätsspeicher oder Verzeichnisse an der Authentifizierung beteiligt sind. Ein Dienst (der auf dem Client oder einem Server ausgeführt werden kann) meldet sich im Namen des Kontos an der Zielanwendung an und simuliert damit den Vorgang der einmaligen Anmeldung. Dieser Dienst muss in einem Anmeldeinformationszuordnungsspeicher oder einer Datenbank nach den entsprechenden Anmeldeinformationen (Konten, Kennwörter usw.) suchen.

Microsoft BizTalk® Server, Host Integration Server, SharePoint® Portal Server, die Windows-Anmeldeinformationsverwaltung und Produkte von unabhängigen Softwareanbietern wie PassLogix, Protocom und Version3 verwenden verschiedene SSO-für-Unternehmen-Techniken, um für ältere Systeme, für Anwendungen, die eigene Verzeichnisse zur Authentifizierung verwenden, und sogar für den Zugriff auf Ressourcen in nicht vertrauenswürdigen Windows-Domänen SSO bereitzustellen.

SSO für Unternehmen ist benutzerfreundlicher als die in vielen Organisationen verwendete Lösung ohne SSO mit vielen nicht vertrauenswürdigen Identitätsspeichern. Der Ansatz mit SSO für Unternehmen sollte in die Bereitstellungs- und Kennwortverwaltungsansätze integriert werden, um eine nahtlose Verwendung zu gewährleisten und die Anrufe beim Helpdesk gering zu halten. Dieser Ansatz bietet zudem die meisten Vorteile für Benutzer und minimiert die Betriebskosten.

Hinweis   Desktop-integrierte SSO ist der SSO für Unternehmen vorzuziehen, da sie eng in das verwendete Verzeichnis eingebunden ist und die zusätzliche Bereitstellung und Verwaltung von redundanten Verzeichnissen und einer Anmeldeinformationszuordnungsdatenbank nicht erfordert.

Weitere Informationen zur Anmeldeinformationszuordnung mithilfe von SSO für Unternehmen finden Sie im Artikel „Intranet-Zugriffsverwaltung“ dieser Serie.

Windows Anmeldeinformationsverwaltung

Windows XP Professional und Windows Server 2003 enthalten das Feature „Gespeicherte Benutzernamen und Kennwörter“, das auch Funktionen zur Anmeldeinformationsverwaltung bietet. Abhängig vom verwendeten Authentifizierungstyp können von dieser Komponente Benutzeranmeldeinformationen gespeichert und bei zukünftigen Zugriffsversuchen wieder verwendet werden.

Abbildung 6.2 „Gespeicherte Benutzernamen und Kennwörter“ ermöglicht SSO für mehrere Anmeldeinformationssätze

Wenn die Anwendung dem Benutzer das Speichern von Anmeldeinformationen nicht erlaubt, muss der Benutzer manuell auf „Gespeicherte Benutzernamen und Kennwörter“ zugreifen, um Anmeldeinformationen für diese Ressource einzurichten. Die Anmeldeinformationsverwaltung unterstützt die folgenden Typen von Anmeldeinformationen:

• Benutzername-/Kennwortkombinationen für das Protokoll Kerberos Version 5 und die NTLM-Authentifizierung

• Digitale X.509-Zertifikate für die Clientauthentifizierung mit SSL/TLS

• Microsoft Passport-Anmeldeinformationen für die Webauthentifizierung

Hinweis   Mithilfe der Windows-Anmeldeinformationsverwaltung können Sie SSO für die Authentifizierung mit SSL/TLS und X.509-Clientzertifikat bereitstellen. Wenn die Benutzer über mehrere gültige Zertifikate verfügen, wird standardmäßig eine Eingabeaufforderung angezeigt, in der sie zur Auswahl eines Zertifikats aufgefordert werden. Mit der Anmeldeinformationsverwaltung kann sichergestellt werden, dass bei der Authentifizierung für eine spezifische Ressource automatisch das richtige Zertifikat gesendet wird.

Weitere Informationen zur Windows-Anmeldeinformationsverwaltung finden Sie im Dokument „Intranet-Zugriffsverwaltung“ dieser Serie.

Autorisierung

Bei der Autorisierung wird von einer Anwendung oder Plattform Zugriff auf eine Ressource gewährt, indem die Berechtigungen des Benutzers mit der Sicherheitskonfiguration der Ressource verglichen werden. Ein Benutzer kann sich z. B. bei einem Dateiserver authentifizieren, und anschließend wird festgestellt, ob der Benutzer zum Lesen, Schreiben oder Löschen einer Datei berechtigt ist.

In das Betriebssystem Windows Server 2003 und Active Directory integrierte Anwendungen verwenden die vorkonfigurierten Features des Betriebsystems für die Autorisierung.

Windows Server 2003 unterstützt zwei Autorisierungsmechanismen: das auf Windows-Zugriffssteuerungslisten (ACL) basierende Identitätswechselmodell und den neuen rollenbasierten Autorisierungs-Manager. Darüber hinaus können Microsoft ASP.NET-Anwendungen ASP.NET-Rollen für die Autorisierung verwenden. Beide Mechanismen werden in den folgenden Abschnitten ausführlich behandelt.

Windows-Identitätswechsel und Zugriffssteuerungslisten

Mit Microsoft Windows NT 3.1 wurde das Identitätswechsel- und ACL-Modell eingeführt, um Autorisierungsfunktionen für Dienste und Anwendungen bereitzustellen. Das Identitätswechselmodell ist das Ergebnis einer engen Kopplung von Authentifizierungs- und Autorisierungsmechanismen, um ein nahtloses Benutzerdesign und eine einfache Verwaltung zu erzielen.

Der Benutzer wird von einem Authentifizierungspaket authentifiziert und dann wird ein „Sicherheitskontext“ für diesen Benutzer erstellt. Der Sicherheitskontext stellt die Identität, die Gruppen, denen der Benutzer angehört, und die Berechtigungen des Benutzers dar. Nachdem der Sicherheitskontext vom Authentifizierungspaket generiert wurde, wird er an die Anwendung oder den Dienst gesendet und zum Gewähren des Zugriffs auf Ressourcen verwendet. Dies bedeutet, dass der Dienst bei einem Zugriffsversuch die Identität des Benutzers lokal annehmen kann, indem er anstelle seines eigenen Kontexts den Sicherheitskontext des Benutzers verwendet, um Zugriff zu erhalten.

Dies ist ein wichtiges Konzept, da die meisten Dienste über umfassende Berechtigungen auf einem Computer verfügen. Der SMB-Dienst (Server Message Block), der Datei- und Druckdienste für Windows-Server bietet, arbeitet z. B. als lokales System und hat Zugriff auf jede Ressource. Um den Dateizugriff des Benutzers entsprechend den vom Besitzer der Datei oder vom Systemadministrator eingerichteten Regeln einzuschränken, wird vom SMB-Dienst die Identität des Remotebenutzers angenommen.

Der andere Teil des Windows-Autorisierungsmodells ist die objektbasierte ACL. Mit der ACL für ein Objekt werden die Zugriffsrechte von Sicherheitsprinzipalen (Benutzer oder Gruppen) für das Objekt definiert. Auf diese Weise kann z. B. definiert werden, dass ein Benutzer die Datei lesen kann, während ein anderer Benutzer sowohl zum Lesen als auch zum Löschen der Datei berechtigt ist.

Bei diesem Modell erfolgt beim Zugriff auf Objekte die endgültige Vermittlung durch das Betriebssystem, insbesondere den NT-Objekt-Manager. Hierzu wird vom NT-Objekt-Manager der Sicherheitskontext des Benutzers mit der ACL des Objekts verglichen. Da das Betriebssystem die letzte Instanz ist, eignen sich die Sicherheitseigenschaften des Identitätswechsel-/ACL-Modells für Szenarios, in denen mehrere Anwendungen auf eine Systemressource zugreifen können.

In den folgenden Bereichen ist das Identitätswechsel-/ACL-Modell jedoch verbesserungsfähig:

• Leistung. Für Dienste, von denen an viele unterschiedliche Benutzer gleichzeitig Inhalt geliefert wird, kann die Verwendung von Identitätswechseln zum Wechseln der Kontexte eine zusätzliche Serverbelastung erzeugen, die u. U. die Anwendungsskalierbarkeit beeinträchtigt.

• Flexibilität. Bei Verwendung des Identitätswechselmodells kann der Anwendungsentwickler oder Dienstadministrator keine neuen Gruppen oder Rollen für Benutzer erstellen, ohne die Gruppenmitgliedschaften auf der Domänenebene zu ändern. Domänenadministratoren sträuben sich dagegen, viele Gruppen für nur eine Anwendung zu erstellen. Die Folge ist, dass Anwendungsentwickler mit dem arbeiten müssen, was vorhanden ist.

• Geschäftsregeln. Das Identitätswechsel-/ACL-Modell drückt die Autorisierung für Objekte auf geeignete Weise aus, die Beschreibung von Geschäftsregellogik, z. B. der Uhrzeit oder anderer Laufzeitlogik ist jedoch schwierig. Möglicherweise möchten Sie z. B. eine Autorisierungsrichtlinie erzwingen, die nur bestimmten Benutzern in einer definierten Zeitspanne die Durchführung einer bestimmten Aktion erlaubt.

Zum Lösen dieser Probleme enthält Windows Server 2003 den Autorisierungs-Manager für Systemadministratoren und Anwendungsentwickler. Die Windows 2000-Version des Autorisierungs-Managers steht Ihnen auf der Website „Microsoft.com“ unter Windows 2000 Authorization Manager Runtime - Deutsch zum Download zur Verfügung.

Windows Server 2003 Autorisierungs-Manager

Der Autorisierungs-Manager in Windows Server 2003 ist eine neue rollenbasierte Zugriffssteuerungsschnittstelle (RBAC). Der Autorisierungs-Manager ermöglicht Entwicklern Folgendes:

• Vereinfachen der Verwaltung der Anwendungszugriffssteuerung

• Bereitstellen eines vereinfachten und natürlichen Entwicklungsmodells

• Ermöglichen von flexiblen und dynamischen Autorisierungsentscheidungen

Benutzern werden für eine bestimmte Aufgabe von der Autorisierungs-Manager-Schnittstelle verschiedene Rollen innerhalb der Anwendung zugeordnet und während der Annahme dieser Rollen wird ihnen Zugriff gewährt. Die folgende Abbildung zeigt drei unterschiedliche Benutzer, die auf eine Anwendung zugreifen. Jeder dieser Benutzer wird vom Autorisierungs-Manager einer im Autorisierungsrichtlinienspeicher definierten Rolle zugeordnet.

Abbildung 6.3 Definieren und Anwenden von Rollen im Autorisierungs-Manager

Der Autorisierungs-Manager bietet die Möglichkeit, logische Rollen und Aufgaben entsprechend den Anforderungen jeder Anwendung zu definieren und zu verwalten. Die Darstellung des Sicherheitsmodells als Organisationsstruktur vereinfacht die Verwaltung der Zugriffssteuerung. Aufgaben- und Rollendefinitionen erleichtern zudem das Modellieren von Anwendungsworkflows und bieten Entwicklern so durch den Autorisierungs-Manager eine natürliche und anwendungsspezifische Umgebung.

Vom Autorisierungs-Manager werden zudem zur Laufzeit gewährte Berechtigungen dynamisch qualifiziert. Diese Funktion löst das für LOB-Webanwendungen (Line-of-Business) wie Spesenberichtsanwendungen oder webgestützte Einkaufsanwendungen bestehende Autorisierungsproblem.

Für solche Anwendungen beinhaltet der Zugriff auf gut definierte permanente Objekte häufig keine Autorisierungsentscheidungen. Diese Anwendungen erfordern stattdessen die Überprüfung eines Workflows oder die Ausführung mehrerer unterschiedlicher Operationen, z. B. das Abfragen einer Datenbank oder Senden einer E-Mail-Nachricht. Solche Zugriffsentscheidungen basieren nicht nur auf Tokengruppenmitgliedschaften, sondern auch auf Geschäftslogik, z. B. dem gesendeten Betrag in einer Spesenanwendung oder einer Workflowabschlussprüfung. In solchen Anwendungen ohne gut definierte permanente Objekte ist kein Platz für ACLs vorhanden. Diese dynamischen Zugriffsentscheidungen sind in Form von dynamischen Geschäftsregeln (bezeichnet als BizRules) verfügbar, die vom Autorisierungs-Manager bereitgestellt werden.

BizRules werden häufig mit einem Visual Basic-Skript oder einer JScript®-Routine implementiert, das bzw. die ausgeführt wird, wenn bei der Ausführung der Anwendung Zugriffsrechte überprüft werden. Wenn die BizRules erfolgreich sind, führt die Anwendung die angeforderten Vorgänge aus.

Autorisierungs-Manager-Richtlinien zur Definition der von einer Anwendung verwendeten logischen Rollen und Aufgaben können entweder in einer Anwendungspartition in Active Directory bzw. im Active Directory-Anwendungsmodus oder in einer XML-Datei auf dem Server oder im Netzwerk gespeichert werden.

Weitere Informationen zur rollenbasierten Zugriffssteuerung (RBAC) mit dem Autorisierungs-Manager in Windows Server 2003 finden Sie auf der TechNet-Website auf der Seite Authorization Manager Concepts (in englischer Sprache).

IIS 6.0 stellt ein Beispiel dafür dar, wie eine Anwendung die rollenbasierte Umgebung des Autorisierungs-Managers verwenden kann. IIS 6.0 (im Lieferumfang von Windows Server 2003 enthalten) wird zum Implementieren der IIS 6.0-URL-Autorisierung mit dem Autorisierungs-Manager integriert. Aufgrund dieser Integration können Webanwendungsadministratoren den Zugriff auf URLs anhand von benutzerdefinierten Benutzerrollen, LDAP-Abfragen und BizRules steuern.

Die Autorisierung des Benutzerzugriffs auf Webseiten in IIS 6.0 erfordert u. U. die Verwaltung vieler DACLs (Discretionary Access Control Lists) für die von Webanwendungen verwendeten Ressourcen. Zu Ressourcen für Webanwendungen können Webseitendateien, Datenbankeinträge und Registrierungsschlüssel zählen. Für die Verwaltung von DACLs müssen Administratoren genau wissen, welche Back-End-Berechtigungsanforderungen jedes Objekt zur Ausführung sinnvoller Aufgaben in der Webanwendung benötigt.

Mit der URL-Autorisierung in IIS 6.0 können Administratoren die Zugriffsverwaltung vereinfachen, indem sie den Benutzerzugriff auf die URLs autorisieren, aus denen eine Webanwendung besteht. Wenn ein Client eine URL anfordert, überprüft die IIS 6.0-URL-Autorisierung den Zugriff des Benutzers basierend auf den Rollen des Benutzers. Bei Bedarf kann über die Webanwendung der Zugriff auf Ressourcen und andere Operationen mithilfe der rollenbasierten Umgebung des Autorisierungs-Managers weiter beschränkt werden.

ASP.NET-Autorisierung

ASP.NET bietet ein rollenbasiertes Autorisierungsmodell, das sowohl Active Directory-Gruppen als auch aus Anwendungen abgeleitete Rollen verwendet. Die Autorisierungs-Manager-RBAC und die rollenbasierte ASP.NET-Autorisierung besitzen einige Gemeinsamkeiten, sie werden jedoch über separate Mechanismen implementiert. ASP.NET-Rollen eignen sich am besten für eigenständige Anwendungen, die meist nicht zu einer größeren Anwendungsfamilie gehören.

Vertrauensstellung und Zusammenschluss

In bestimmten Situationen müssen Sie möglicherweise mehrere separate Identitätsspeicher verknüpfen, z. B., wenn Sie eine Partnerschaftslösung implementieren oder separate externe und interne Verzeichnisstrukturen verwenden müssen. Die Verknüpfung ermöglicht Benutzern, die sich bei einem Identitätsspeicher authentifizieren können, die Authentifizierung bei einem weiteren Speicher, obwohl sie in diesem nicht über eine digitale Identität verfügen. Diese Anordnung wird als Vertrauensstellung bezeichnet.

Vertrauensstellungen bestehen zwischen separaten Bereichen, wobei ein Bereich eine Sicherheitsgrenze definiert. In Windows NT- und Active Directory-Umgebungen können Vertrauensstellungen zwischen Domänen hergestellt werden. In Window Server 2003 können Sie höhere Vertrauensstellungsebenen zwischen Gesamtstrukturen einrichten. Domänen in einer Gesamtstruktur besitzen jedoch implizite Vertrauensstellungen zueinander.

In Windows Server 2003 und Active Directory integrierte Anwendungen verwenden die Features des Betriebssystems zum Herstellen und Verwalten von Vertrauensstellungen.

Verwalten von Vertrauensstellungen

Auf hoher Ebene bieten Vertrauensstellungen lediglich eine Möglichkeit der Authentifizierung zwischen Bereichen. Die Mechanismen der Vertrauensstellung sind kompliziert, da zum Gewährleisten brauchbarer Authentifizierungs- und Autorisierungsprozesse viele Arbeitsschritte zwischen unabhängigen Organisationen durchgeführt müssen.

Im Folgenden werden die in der Windows-Plattform verfügbaren Vertrauensstellungstypen und deren Verwendung zum Lösen von Identitäts- und Zugriffsverwaltungsproblemen beschrieben.

Externe Vertrauensstellungen

Mit dem Microsoft Windows NT 4.0-Server wurde das Konzept der Domänenvertrauensstellungen eingeführt. Die Windows NT-Domänenvertrauensstellung oder – wie sie heute bezeichnet wird – externe Vertrauensstellung ermöglichte es einer Windows NT-Domäne, einer anderen Windows NT-Domäne als Autorität zum Authentifizieren der Benutzer dieser Domäne zu vertrauen. Externe Vertrauensstellungen können uni- oder bidirektional sein, und die Vertrauensrichtung bestimmt, wie in der folgenden Abbildung dargestellt, die Richtung, in der die Authentifizierung und der Zugriff erfolgen können.

Abbildung 6.4 Beziehung zwischen vertrauenden und vertrauten Domänen

Das Windows NT Server 4.0-Modell war sehr flexibel und ermöglichte Abteilungen das bedarfsgesteuerte Implementieren von Windows NT 4.0-Domänen in einem von unten nach oben verlaufenden Basisbereitstellungsmuster. Die Verwaltung externer Vertrauensstellungen wurde mit der Zeit zu einem schwerwiegenden Problem, da sehr große Unternehmen immer mehr Domänen auf das Internet verlagerten. Da jede bereitgestellte Domäne n Vertrauensstellungen besitzen kann, nimmt die Gesamtanzahl von zu verwaltenden Vertrauensstellungen bei wachsender Domänenanzahl schnell zu. In einem kleinen Unternehmen mit vier Domänen müssen möglicherweise nur 12 unterschiedliche Vertrauensstellungen verwalten werden, dagegen müssen in einem großen Unternehmen mit 10 Domänen u. U. 90 Vertrauensstellungen verwalten werden. In einem Unternehmen mit 100 Domänen muss ggf. eine sehr viel größere Anzahl von Vertrauensstellungen verwalten werden.

Windows 2000 Server-Gesamtstrukturen

Zur Vereinfachung der Vertrauensstellungsverwaltung in vielen großen Organisationen wurde mit Microsoft Windows 2000 Server das Konzept der Active Directory-Gesamtstruktur eingeführt. Die Active Directory-Gesamtstruktur behält die Flexibilität des von unten nach oben ausgerichteten Windows NT Server 4.0-Vertrauensstellungsmodells bedarfsgerecht bei, vereinfacht wie in der folgenden Abbildung dargestellt jedoch die Ausführung der von oben nach unten gerichteten Vertrauensstellungsverwaltung erheblich.

Abbildung 6.5 Eine Windows 2000 Server-Gesamtstruktur

Die Abbildung zeigt eine Organisation mit nur einer Windows 2000 Server-Gesamtstruktur. Die Vertrauensstellungen innerhalb einer Gesamtstruktur sind implizite Vertrauensstellungen. Sie bieten die gleichen Funktionen wie bidirektionale externe Vertrauensstellungen, sie werden jedoch automatisch beim Hinzufügen von Domänen (Strukturen innerhalb einer Gesamtstruktur) zur Gesamtstruktur erstellt. Domänen in einer Gesamtstruktur sind hierarchisch, so dass das Netzwerk den Aufbau einer Organisation widerspiegeln kann.

Bedauerlicherweise stellte Windows 2000 Server keine endgültige Lösung für die Probleme im Zusammenhang mit Vertrauensstellungen. Es wurde davon ausgegangen, dass die meisten Unternehmen nur eine das gesamte Netzwerk und alle Ressourcen umfassende Gesamtstruktur bereitstellen. Dies war jedoch aus vielen verschiedenen Gründen nicht der Fall.

Beispielsweise verfügen einige sehr große Organisationen nicht über eine zentrale für die Verwaltung aller Ressourcen der Organisation verantwortliche vertrauenswürdige Administratorgruppe. In solchen Organisationen sind daher natürliche Sicherheitsgrenzen zwischen den unterschiedlichen Teilen der Organisation vorhanden, die von der Verzeichnisdienstarchitektur implementiert werden müssen. Ein weiteres weit verbreitetes Beispiel ist die Notwendigkeit von separaten Intranet- und Extranetgesamtstrukturen. Während das Extranet als Domäne in einer Intranetgesamtstruktur entworfen werden kann, möchten viele Organisationen das Extranet und das Intranet aus Sicherheitsgründen umfassender isolieren.

Weitere Informationen zu den Sicherheitsgrenzen von Windows-Domänen und -Gesamtstrukturen finden Sie auf der Website „Microsoft.com“ unter Creating and Enhancing Security Boundaries (in englischer Sprache).

Eine Organisation, die mehrere Gesamtstrukturen mit Windows 2000 Active Directory verwendet, aber Vertrauensstellungen zwischen den Domänen der unterschiedlichen Gesamtstrukturen einrichten möchte, muss explizite Vertrauensstellungen zwischen jeder Domäne in der einen Gesamtstruktur und jeder Domäne in der anderen Gesamtstruktur herstellen. Da diese Konfiguration nur unwesentlich einfacher ist als das Einrichten von Vertrauensstellungen zwischen jeder Windows NT Server 4.0-Domäne, war eindeutig eine bessere Lösung notwendig.

Windows Server 2003-Gesamtstrukturvertrauensstellung

Zum Vereinfachen von Gesamtstrukturbereitstellungen wurde mit Windows Server 2003 das Konzept der Gesamtstrukturvertrauensstellung eingeführt. Eine Gesamtstrukturvertrauensstellung ermöglicht Administratoren das Einrichten eines Zusammenschlusses zweier Active Directory-Gesamtstrukturen mit nur einer Vertrauensstellung, um einen nahtlosen Authentifizierungs- und Autorisierungsprozess zwischen den beiden Gesamtstrukturen zu bieten. Eine Gesamtstrukturvertrauensstellung ist eine einzige Vertrauensverbindung zwischen den Stammdomänen von zwei Gesamtstrukturen. Sie schafft eine transitive Vertrauensstellung zwischen allen Domänen einer jeweiligen Gesamtstruktur. Wenn beipielsweise Gesamtstruktur A Gesamtstruktur B vertraut, vertrauen bei Verwendung der Gesamtstrukturvertrauensstellung alle Domänen in Gesamtstruktur A allen Domänen in Gesamtstruktur B. Die folgende Abbildung veranschaulicht dieses Konzept:

Abbildung 6.6 Windows Server 2003-Gesamtstrukturvertrauensstellungen

Gesamtstrukturvertrauensstellungen sind jedoch nicht gesamtstrukturübergreifend transitiv. Wenn Gesamtstruktur A Gesamtstruktur B vertraut, und Gesamtstruktur B Gesamtstruktur C vertraut, vertraut Gesamtstruktur A nicht automatisch auch Gesamtstruktur C.

Weitere Informationen zur Verwendung und Konfiguration von gesamtstrukturübergreifenden Vertrauensstellungen in Windows Server 2003 finden Sie auf der Microsoft TechNet-Website auf der Seite Planning and Implementing Federated Forests in Window Server 2003 (in englischer Sprache).

Verwenden von Gesamtstrukturvertrauensstellungen

Gesamtstrukturvertrauensstellungen ermöglichen das Konzept der zusammengeschlossenen Gesamtstrukturen in Windows Server 2003. Wie bereits erwähnt, kann durch eine Gesamtstrukturvertrauensstellung eine transitive Vertrauensstellung zwischen allen Domänen in zwei Gesamtstrukturen eingerichtet werden. Die Vertrauensstellung wird zwischen den Stammdomänen beider Gesamtstrukturen hergestellt.

Bei den Gesamtstrukturvertrauensstellungen kann es sich um uni- oder bidirektionale Vertrauensstellungen handeln. In der obigen Abbildung besteht zwischen Gesamtstruktur A und Gesamtstruktur B eine bidirektionale Vertrauensstellung. Aus diesem Grund können sich Benutzer in Gesamtstruktur A für Ressourcen in Gesamtstruktur B und Benutzer in Gesamtstruktur B für Ressourcen in Gesamtstruktur A authentifizieren. Neben der Authentifizierung ermöglicht die Gesamtstrukturvertrauensstellung eine Autorisierung, damit die Ressourcenbesitzer in jeder Gesamtstruktur Prinzipale aus der anderen Gesamtstruktur DACLs und Gruppen hinzufügen oder basierend auf diesen Gruppen Rollen erstellen können.

Verwenden von Schattenkonten anstelle von Vertrauensstellungen

Aufgrund bestimmter Sicherheitsanforderungen ist es mitunter nicht möglich, Windows-Vertrauensstellungsmechanismen zwischen Gesamtstrukturen zu verwenden. In solchen Fällen können Sie in einem der Verzeichnisse Schattenkonten erstellen, um die Konten im anderen Verzeichnis zu spiegeln. Das Schattenkonto spiegelt normalerweise nur die für die spezifische Anwendung oder das jeweilige Szenario erforderlichen Identitätsinformationen aus dem Quellbereich. Zur Einhaltung der Sicherheitsanforderungen werden besonders wichtige Identitätsattribute nicht dargestellt. Wichtige Informationen sind z. B. die Sozialversicherungsnummer oder das Benutzerkennwort der Identität.

Das Konzept der Verwendung von Schattenkonten für Mitarbeiter ist möglicherweise nicht intuitiv. Betrachten Sie jedoch den Fall, in dem eine Organisation eine Intranetinstanz von Active Directory für die Mitarbeiterauthentifizierung verwendet, jedoch auch ein Extranet für Mitarbeiter bereitstellen möchte. Zum Authentifizieren von Benutzern im Extranet stehen folgende zwei Optionen zur Auswahl:

• Verwenden einer Gesamtstruktur- oder Domänenvertrauensstellung vom Perimeternetzwerk (auch bezeichnet als DMZ, demilitarisierte Zone oder überwachtes Subnetz) zum Intranet

• Erstellen von Schattenkonten im Perimeternetzwerk

Für die erste Option müssen mehrere Ports geöffnet werden, um einen Pfad durch die Firewall zu ermöglichen, der das Perimeternetzwerk vom Intranet trennt. Diese Option ist für viele Organisationen akzeptabel, andere benötigen jedoch eine vollständige Isolierung zwischen ihren Perimeternetzwerken und Intranets.

Für Organisationen, die eine strikte Netzwerkisolierung benötigen, ist die Verwendung eines Schattenkontos ggf. die beste Lösung. Microsoft empfiehlt, Schattenkonten mit einem automatisierten Mechanismus zu erstellen, z. B. den in Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS 2003 SP1) verfügbaren Mechanismen. Schattenkonten können in bestimmten Szenarios sogar die Netzwerksicherheit verbessern, wenn sie nicht-kennwortgestützte Authentifizierungsmechanismen für weniger sichere Server ermöglichen, z. B. die Server im Extranet. Beispiele hierfür sind die auf Secure Sockets Layer (SSL) 3.0 basierende Authentifizierung und die Clientzertifikatauthentifizierung Transport Layer Security (TLS) 1.0 oder Einwegkennwort-Authentifizierungsmechanismen wie das aus zwei Faktoren bestehende SecurID-Produkt von RSA Security Inc.

PKI-Vertrauensstellungen

Eine Infrastruktur öffentlicher Schlüssel (Public Key Infrastructure, PKI) ist ein System von digitalen Zertifikaten, Zertifizierungsstellen (Certification Authorities, CA) und anderen Registrierungsstellen, mit denen die Gültigkeit jeder an einer elektronischen Transaktion beteiligten Partei mithilfe der Kryptografie mit öffentlichen Schlüsseln überprüft und authentifiziert wird. Damit dieser Prozess stattfinden kann, muss jedoch jede Partei dem Zertifikataussteller (meistens eine Zertifizierungsstelle) vertrauen.

Für Windows-Benutzer, -Computer und -Dienste wird das Vertrauen in eine Zertifizierungsstelle dann hergestellt, wenn eine Kopie des Stammzertifikats im Speicher der vertrauenswürdigen Stammzertifizierungsstelle sowie ein gültiger Zertifizierungspfad vorhanden sind. Ein gültiger Zertifizierungspfad bedeutet, dass keines der Zertifikate im Zertifizierungspfad gesperrt oder abgelaufen ist. Der Zertifizierungspfad enthält jedes Zertifikat, das an eine Zertifizierungsstelle in der Zertifizierungshierarchie ausgestellt wurde. Diese Hierarchie reicht von einer untergeordneten Zertifizierungsstelle bis zur Stammzertifizierungsstelle.

Für eine Stammzertifizierungsstelle besteht der Zertifizierungspfad z. B. nur aus einem Zertifikat – dem eigenen selbst signierten Zertifikat. Für eine in der Hierarchie direkt unter der Stammzertifizierungsstelle befindliche untergeordnete Zertifizierungsstelle enthält der Zertifizierungspfad zwei Zertifikate: das eigene Zertifikat und das Zertifikat der Stammzertifizierungsstelle.

Das Importieren eines Stammzertifikats in den Speicher für vertrauenswürdige Stammzertifizierungsstellen ist die einfachste Methode, um eine PKI-Vertrauensstellung für einen Computer und die von ihm gehosteten Anwendungen einzurichten. Wenn auf einem Webserver bei Contoso Pharmaceuticals (eine fiktive Organisation) z. B. die Stammzertifikat-CA für Fabrikam Inc. (eine weitere fiktive Organisation) im Speicher für Stammzertifizierungsstellen installiert ist, vertraut der Contoso-Webserver jedem gültigen von der Fabrikam-Zertifizierungsstelle ausgestellten Zertifikat. Dieser Prozess stellt jedoch nur den die Vertrauensstellung betreffenden Teil der Transaktion her, und auf dem Webserver wird weder eine Identität noch ein Kontext eingerichtet. Um eine Zuordnung zwischen einer Identität und einem Kontext herzustellen, müssen andere Aktionen ausgeführt werden, z. B. das Zuordnen einiger Informationen im Zertifikat zu einem Sicherheitsprinzipal in Active Directory.

Weitere Informationen zur gegenseitigen Authentifizierung mithilfe der Active Directory-Zertifikatzuordnung finden Sie auf der Microsoft Windows 2000 Server-Website auf der Seite Step-by-Step Guide to Mapping Certificates to User Accounts (in englischer Sprache).

Die Bereitstellung eines Speichermechanismus für vertrauenswürdige Stammzertifizierungsstellen ist recht einfach. Allerdings entspricht dieser Ansatz u. U. nicht den Sicherheitsanforderungen in komplexen Szenarios für das Herstellen einer zusammengeschlossenen Vertrauensstellung zwischen zwei Organisationen wie Contoso und Fabrikam. Stellen Sie sich ein Szenario vor, in dem sowohl Contoso- als auch Fabrikam-Benutzer für den Zugriff auf die Website von Contoso gültige Zertifikate vorlegen können. Das externe Active Directory enthält in diesem Fall Zertifikatzuordnungen von den Zertifizierungsstellen von Contoso und Fabrikam.

Eine Methode ist das Herstellen einer Zuordnung basierend auf dem Antragsteller des Zertifikats, z. B.: E=fred@fabrikam.com. Das Problem bei diesem Ansatz ist, dass die Vertrauensstellung uneingeschränkt ist. Die uneingeschränkte Vertrauensstellung bedeutet, dass Contoso vollständig darauf vertraut, dass Fabrikam kein Zertifikat mit dem Antragsteller „E=fred@contoso.com“ ausstellt (wobei es sich bei „fred@contoso.com“ um einen Benutzer aus der Organisation Contoso handelt, nicht aus Fabrikam). In diesem Fall könnte der Zertifikatinhaber Zugriff auf vertrauliche Daten auf der Contoso-Site erhalten. Dieses Problem ist nicht darauf zurückzuführen, dass die PKI-Vertrauensstellung von Natur aus unsicher ist, sondern auf die zu weit gefassten Zertifikatdefinitionen. Die Antwort auf dieses Problem ist ein präziser steuerbarer PKI-Vertrauensmechanismus, der Fabrikam das Ausstellen von Zertifikaten für die Domäne „@fabrikam.com“ ermöglicht, nicht jedoch für die Domäne „@contoso.com“.

Qualifizierte Unterordnung

Eine echte wechselseitige Zertifizierung von CA-Hierarchien war in einem Windows 2000-Netzwerk nicht möglich. Die einzige verfügbare Alternative war die Definition von Zertifikatvertrauenslisten (CTL), die bestimmten Zertifizierungsstellen vertrauten und die Zertifikatverwendung einschränkten.

Die mit Windows 2003 Server eingeführte qualifizierte Unterordnung ist der Prozess der wechselseitigen Zertifizierung von CA-Hierarchien anhand von grundlegenden Richtlinien-, Namens- und Anwendungsbeschränkungen, um die von Partner-CA-Hierarchien oder einer sekundären Hierarchie in derselben Organisation akzeptierten Zertifikate zu beschränken. Mithilfe der qualifizierten Unterordnung kann ein CA-Administrator eindeutig definieren, welchen von der PKI eines Partners ausgestellten Zertifikaten seine Organisation vertraut. Die qualifizierte Unterordnung bietet auch Methoden, mit denen die Zertifikatausstellung innerhalb einer Organisation entsprechend bestimmten Richtlinienvorgaben aufgegliedert und gesteuert werden kann.

Die qualifizierte Unterordnung ermöglicht Ihnen auch das Herstellen von Vertrauensstellungen zwischen Zertifizierungsstellen in separaten Vertrauenshierarchien. Dieser Vertrauensstellungstyp wird auch als Gegenzertifizierung bezeichnet. Bei Verwendung einer solchen Vertrauensstellung ist die qualifizierte Unterordnung nicht auf untergeordnete Zertifizierungsstellen beschränkt. Vertrauensstellungen zwischen Hierarchien können mit einer untergeordneten Zertifizierungsstelle in einer Hierarchie und der Stammzertifizierungsstelle in einer anderen Hierarchie hergestellt werden.

Die qualifizierte Unterordnung ermöglicht Ihnen das Einrichten zusätzlicher Vertrauensbedingungen in und zwischen den Domänen in Ihrer PKI, um die Vertrauenshierarchie zu erweitern. Bei der qualifizierten Unterordnung können die qualifizierten untergeordneten Zertifizierungsstellen in Ihrer Vertrauenshierarchie unterschiedliche Regeln für die Ausstellung und Verwendung von Zertifikaten verwenden.

Ein Beispiel dafür, wie das zuvor beschriebene Problem der zu weit gefassten Zertifikatdefinitionen mithilfe von Vertrauensbedingungen gelöst werden kann, ist die Verwendung von Namespacebeschränkungen beim Einrichten der Gegenzertifizierung zwischen den Hierarchien von Contoso und Fabrikam. Auf diese Weise akzeptiert Contoso nur Zertifikate von Fabrikam-Zertifizierungsstellen, die die Domäne „fabrikam.com“ enthalten.

Weitere Informationen zur qualifizierten Unterordnung finden Sie auf der Microsoft TechNet-Website auf der Seite Qualified subordination overview (in englischer Sprache).

Implementieren von Zusammenschlüssen

Die zusammengeschlossene Identitätsverwaltung ist ein auf Standards basierender Technologie- und Informationstechnologieprozess, der die verteilte Identifikation, Authentifizierung und Autorisierung über die Grenzen von Organisationen und Plattformen hinweg gestattet. Zusammengeschlossene Systeme arbeiten organisationsübergreifend miteinander und verbinden Prozesse, in denen verschiedene Technologien, Identitätsspeicher, Sicherheitsansätze und Programmiermodelle verwendet werden. Bei einem zusammengeschlossenen System muss eine Organisation über einen standardisierten und sicheren Weg verfügen, um die den vertrauenswürdigen Partnern und Kunden zur Verfügung stehenden Dienste auszudrücken. Außerdem muss eine Organisation die Richtlinien implementieren, auf deren Grundlage sie ihre Geschäfte ausführt, wie z. B.:

• welche andere Organisationen und Benutzer als vertrauenswürdig eingestuft werden.

• welche Arten von Anmeldeinformationen und Anforderungen akzeptiert werden.

• welche Datenschutzrichtlinien durchgesetzt werden.

Mit Microsoft Window Server 2003 R2 wird Active Directory Federation Services (ADFS) eingeführt. Damit haben Organisationen die Möglichkeit, die Identitätsinformationen von Benutzern auf sichere Weise gemeinsam zu nutzen. ADFS bietet Web-SSO-Technologien, um einen Benutzer bei mehreren Webanwendungen für die Dauer einer Onlinesitzung zu authentifizieren. Um dies zu erreichen, werden von ADFS digitale Identitäten und Berechtigungen, oder „Ansprüche“, über Sicherheits- und Unternehmensgrenzen hinweg sicher freigegeben.

ADFS arbeitet sowohl mit Active Directory als auch ADAM, dem Active Directory-Anwendungsmodus. Genauer gesagt arbeitet ADFS mit unternehmensweiten Active Directory-Bereitstellungen oder ADAM-Instanzen. Bei Verwendung von Active Directory können von ADFS die leistungsfähigen Authentifizierungstechnologien in Active Directory, einschließlich Kerberos, digitalen X.509-Zertifikaten und Smartcards, genutzt werden. Bei Verwendung von ADAM werden Benutzer von ADFS mittels LDAP-Bind (Lightweight Directory Access Protocol) authentifiziert.

ADFS unterstützt die verteilte Authentifizierung und Autorisierung über das Internet. ADFS kann in die vorhandene Zugriffsverwaltungslösung einer Organisation oder Abteilung integriert werden, um die in der Organisation verwendeten Begriffe in Ansprüche zu übersetzen, die in einem Zusammenschluss vereinbart wurden. Mithilfe von ADFS können die zwischen Organisationen ausgetauschten Ansprüche erstellt, gesichert und überprüft werden. Außerdem können mit ADFS die Aktivitäten zwischen Organisationen und Abteilungen überwacht werden, um die Sicherheit von Transaktionen sicherzustellen.

Weitere Informationen über ADFS finden Sie auf der Microsoft-Website unter Overview of Active Directory Federation Services (ADFS) in Window Server 2003 R2 (in englischer Sprache).

Sicherheitsüberwachung

Die Überwachung ermöglicht das Verfolgen von Zugriffsverwaltungsereignissen und Änderungen an Verzeichnisobjekten. Die Sicherheitsüberwachung wird normalerweise zum Überwachen von Problemen und Sicherheitsverletzungen verwendet. Technologien wie das Windows-Sicherheitsereignisprotokoll, die Windows-Verwaltungsschnittstelle (WMI) und Produkte wie Microsoft Operations Manager 2005 SP1 (MOM) können für die umfassende Sicherheitsüberwachung und Berichterstattung verwendet werden.

Überwachen von Verzeichnisdiensten

Active Directory und ADAM sind vollständig in die Window Server 2003-Überwachung integriert. Das Windows-Sicherheitsereignisprotokoll enthält Änderungen an Verzeichnisobjekten und -attributen sowie Autorisierungsrichtlinien für Verzeichnisobjekte und -attribute, Schemas und Gruppenrichtlinien. Die Konfiguration der zu überwachenden Ereignisse ist von Ihnen genau steuerbar und kann auf erfolgreichen, fehlerhaften oder versuchten Aktionen basiert werden.

Überwachen der Authentifizierung

Von den zuvor beschriebenen Windows-Authentifizierungsmechanismen werden Überwachungsereignisse im Windows-Sicherheitsereignisprotokoll generiert. Sie können die gewünschten Überwachungsereignisse (z. B. Authentifizierung fehlgeschlagen oder erfolgreich) mit Gruppenrichtlinien konfigurieren, oder Sie können jeden Server manuell konfigurieren.

Window Server 2003 bietet zudem eine genaue Steuerung der Authentifizierungsereignisse, indem diese entsprechend dem Authentifizierungstyp in Kategorien zusammengefasst werden. Ein Überwachungstyp verfolgt z. B. Konsolenanmeldungen, während bei einem anderen Typ Authentifizierungsversuche bei Netzwerkressourcen überwacht werden. Authentifizierungsüberwachungsereignisse können auch für bestimmte Sicherheitsprinzipale verfolgt werden.

Nachdem sich der Benutzer beim Identitätsspeicher authentifiziert hat, muss bestimmt werden, auf welche Ressourcen der Benutzer zugreifen kann. Der für die Steuerung des Zugriffs auf Ressourcen zuständige Prozess ist die Autorisierung.

Überwachen der Autorisierung

Die Windows Server-Plattform bietet vollständige Unterstützung für die Überwachung von Autorisierungsaktionen. Für das Identitätswechsel-/ACL-Modell meldet der NT-Objekt-Manager gemäß der Überwachungskonfiguration Überwachungsereignisse für den Ressourcenzugriff. Sie können diese Konfiguration durch Gruppenrichtlinien oder manuell auf jedem Server erzwingen. Da diese Überwachungsereignisse vom System generiert werden, werden sie im System-Sicherheitsereignisprotokoll angezeigt.

Die Funktionen für die Überwachungskonfiguration sind präzise und ermöglichen z. B. nur die Überwachung von fehlgeschlagenen Zugriffsversuchen auf Dateien. Da die Authentifizierungs- und Autorisierungsmechanismen eng verknüpft sind, gibt das Autorisierungsüberwachungsereignis den auf die Ressource zugreifenden Sicherheitsprinzipal entsprechend seiner eindeutigen Sicherheits-ID (SID) an.

Der Autorisierungs-Manager unterstützt sowohl die Laufzeitüberwachung als auch die Überwachung von Autorisierungs-Manager-Richtlinienänderungen. Von der Laufzeitüberwachung werden anhand von Fehler- oder Erfolg-Überwachungsereignissen Berichte über die Anwendungsinitialisierung, die Kontexterstellung und -löschung sowie den Objektzugriff erstellt. Die Überwachung von Richtlinienänderungen des Autorisierungs-Managers kann jede Änderung am Richtlinienspeicher melden, einschließlich der Überwachungsereignisse für die Richtlinie und die Richtliniendefinition.

Die Authentifizierung und Autorisierung in nur einem Sicherheitsbereich oder einer Active Directory-Gesamtstruktur ist ein relativ unkomplizierter Prozess. Bei der Identitäts- und Zugriffsverwaltung besteht jedoch oft die Notwendigkeit, zwei separate Sicherheitsbereiche zu verbinden. Dies wiederum erfordert die Implementierung einer Form von Vertrauensstellung zwischen Verzeichnisdiensten oder Organisationen. Dieses Thema wird im nächsten Kapitel behandelt.

Überwachen von Vertrauensstellungen

Window Server 2003 überwacht die Vertrauenskonfiguration vollständig und detailliert. Sie können Ereignisse für das Erstellen, Löschen und Ändern von Vertrauensstellungen überwachen. Überwachungsereignisse für Vertrauensstellungen werden im Sicherheitsereignisprotokoll erfasst.

In diesem Beitrag

• Kapitel 1: Einführung
• Kapitel 2: Terminologie und Initiativen
• Kapitel 3: Microsoft-Technologien zur Identitäts- und Zugriffsverwaltung
• Kapitel 4: Verzeichnisdienste
• Kapitel 5: Verwaltung des Identitätslebenszyklus
• Kapitel 6: Zugriffsverwaltung
• Kapitel 7: Anwendungen
• Links
• Danksagung

Download

Laden Sie die vollständige Serie in englischer Sprache herunter.

Update Notifications

Lassen Sie sich automatisch über neue Veröffentlichungen zu Themen wie diesem informieren (in englischer Sprache).

Feedback

Senden Sie uns Ihre Kommentare oder Vorschläge (in englischer Sprache).

6 von 9