Plattform und Infrastruktur

Kapitel 4: Entwerfen der Infrastruktur

Veröffentlicht: Mai 11, 2004 | Aktualisiert : Juni 26, 2006

Contoso hat Identitäts- und Zugriffsverwaltungsplattformen verschiedener Anbieter, einschließlich Microsoft, ausgewertet. Aufgrund der Unternehmensanforderungen hat man sich bei Contoso entschieden, standardmäßig die Microsoft Identity and Access Management-Plattform einzusetzen. In diesem Kapitel wird der dafür erforderliche Infrastrukturentwurf behandelt.

Auf dieser Seite

Lösungskonzept
Lösungsarchitektur
Szenarios aktivierter Lösungen

Lösungskonzept

Die Funktionen, die für Contoso am wichtigsten sind, werden durch folgende Merkmale der Microsoft Identity and Access Management-Plattform bereitgestellt:

• Der Microsoft® Active Directory®-Verzeichnisdienst ist mit RFC 3377-LDAP (Version 3.0) von IETF (Internet Engineering Task Force) kompatibel.

• Das Extranet-Active Directory, in dem Informationen über Kunden- und Partnerkonten gespeichert sind, kann sich im Umkreisnetzwerk befinden und die Mitarbeiterauthentifizierung ohne Vertrauensstellung mit dem internen Verzeichnis unterstützen.

• Active Directory verfügt über mehrere Optionen für die starke Verschlüsselung von Benutzeranmeldeinformationen. Aufgrund der Integration in starke Netzwerkauthentifizierungsprotokolle wie dem Kerberos 5-Authentifizierungsprotokoll oder der Clientauthentifizierung über SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security) werden Anmeldeinformationen niemals außerhalb des Verzeichnisses verteilt.

• Active Directory in Microsoft Windows Server™ 2003 unterstützt auf Kennwörtern basierende Anmeldeinformationen über das Kerberos 5-Protokoll und Digest-Authentifizierungsprotokolle. Außerdem unterstützt Active Directory PKI-Anmeldeinformationen (Public Key Infrastructure) für die Clientauthentifizierung über Kerberos 5-, SSL- oder TLS-Protokolle.

• Active Directory sorgt durch die Nutzung der Kerberos 5-, SSL- und TLS-Protokolle für nahtlose Authentifizierung.

• Desktopclient-Betriebssysteme wie Microsoft Windows® 2000 Professional, Windows® XP Professional und Arbeitsstationen, auf denen UNIX oder Linux ausgeführt wird, können problemlos mit dem Serverbetriebssystem für Authentifizierung und Autorisierung über das Kerberos 5-Protokoll, LDAP (Lightweight Directory Access Protocol) und andere auf Standards basierende Protokolle eingesetzt werden.

• Windows Server 2003 und viele Clientbetriebssysteme werden gemeinsam zum Authentifizieren von Benutzern mit einem Satz an Standardanmeldeinformationen eingesetzt, die während des Anmeldevorgangs berechnet oder abgerufen werden. Diese Authentifizierung findet aus Sicht des Benutzers auf transparente Weise statt und erfüllt die Benutzeranforderungen für SSO.

• Von Windows Server 2003 werden Zugriffssteuerungslisten (Access Control List, ACL) und die rollenbasierte Autorisierung implementiert. Active Directory verfügt über stabile und flexible Mechanismen zum Ausdrücken von Berechtigungen durch Gruppenmitgliedschaft.

• Von den Verzeichnis- und Sicherheitsdiensten von Windows Server 2003 werden mehrere Vertrauensstufen einschließlich der gesamtstrukturübergreifenden Vertrauensstellung, der externen Vertrauensstellung, der PKI-Vertrauensstellung und der bereichsübergreifenden Vertrauensstellung mit UNIX-Kerberos-Bereichen implementiert.

• Windows Server 2003 mit Active Directory verfügt über genaue Überwachungsfunktionen, die für sämtliche Authentifizierungs-, Vertrauens-, Autorisierungs- und Konfigurationsvorgänge verwendet werden können, die auf dem System ausgeführt werden.

Lösungsarchitektur

Die Lösungsarchitektur weist folgende Komponenten auf:

• Verzeichnisdienste

• Authentifizierungsmethoden

• Autorisierungsmethoden

• Vertrauensmechanismen

• Verwaltung des Identitätslebenszyklus

• Identitätsbewusste Anwendungen

Verzeichnisdienste

Damit die Contoso-Plattform für die Identitäts- und Zugriffsverwaltung auch erfolgreich betrieben werden kann, muss das Contoso-Team die autorisierende Quelle zum Erstellen von Identitätsinformationen sowie einen autorisierenden Ort zum Speichern von Anwendungs- und Identitätsinformationen bestimmen. Außerdem ist vom Team ein geeigneter Attributinformationsfluss zwischen Verzeichnissen zu implementieren.

Die derzeitige Konfiguration der Verzeichnisdienste der Organisationsinfrastruktur enthält folgende Komponenten:

• Active Directory-Intranetgesamtstruktur

• Active Directory-Extranetgesamtstruktur

• Sun One Directory Server 5.1 (früher als iPlanet Directory Server bekannt)

Die Active Directory-Extranetgesamtstruktur kann nicht als autorisierender Verzeichnisdienst verwendet werden, weil es nur Schattenkonten für Mitarbeiter enthält. Sun One Directory Server 5.1 soll außer Betrieb gesetzt werden, sobald die Anwendung, für die diese Software noch erforderlich ist, so umgeschrieben wurde, dass sie mit Active Directory eingesetzt werden kann.

Die Active Directory-Intranetgesamtstruktur dient als zentrales Repository für die Benutzerkonten von Contoso. Aus diesem Grund hat man sich im Unternehmen entschieden, dass das Intranet-Active Directory als autorisierende Quelle für sämtliche verzeichnis- und anwendungsspezifischen Informationen dienen soll.

Das Contoso-Team wird ein Identitätsintegrationsprodukt verwenden, um bestimmte Verzeichnisobjekte aus folgenden Gründen zu replizieren:

• Erstellen von Konten für alle Mitglieder der Verkaufsabteilung in der Extranetgesamtstruktur

• Feststellen mithilfe eines Attributs in Active Directory, welche Mitarbeiter vom kürzlich erworbenen Unternehmen zu Contoso kamen

• Replizieren dieser Konten in Lotus Notes Release 6.5.4 und Sun ONE Directory Server 5.1

Active Directory-Intranetgesamtstruktur

Die Intranetgesamtstruktur besteht aus einer leeren Stammdomäne (corp.contoso.com) und einer einzigen untergeordneten Domäne (na.corp.contoso.com). Die Domäne na.corp.contoso.com enthält folgende Organisationseinheiten (Organizational Unit, OU):

• Mitarbeiter

• Solaris-Arbeitsstationen

• Windows-Clients

• Gruppen

• Deaktiviert

• Kontakte

Die schrittweisen Anleitungen zum Installieren von Active Directory unter Windows Server 2003 und zum Erstellen der OUs befinden sich in der Produktdokumentation.

Active Directory-Extranetgesamtstruktur

Die externe Gesamtstruktur besteht aus einer einzigen Domäne: perimeter.contoso.com. Die Domäne perimeter.contoso.com wird auf der Funktionsebene von Windows Server 2003 ausgeführt und enthält folgende OUs:

• Mitarbeiter

• Testbenutzer

• Gruppen

Zwischen der internen und der externen Gesamtstruktur ist keine Vertrauensstellung vorhanden. Die Gründe dafür werden im Abschnitt „Vertrauensstellung“ weiter unten in diesem Kapitel erläutert.

Der Abbildung 4.1 können Sie die Active Directory-Strukturen für Contoso zu entnehmen.

Abbildung 4.1 Logische Active Directory-Struktur für Contoso

Weitere Informationen über Active Directory finden Sie auf der Seite Windows Server 2003 Active Directory (in englischer Sprache).

Weitere Anleitungen finden Sie auf der Seite Designing and Deploying Directory and Security Services (in englischer Sprache).

Authentifizierungsmethoden

Authentifizierungsmethoden wurden bei Contoso unter Berücksichtigung der Merkmale der einzelnen Methoden und der Umgebung, in der sie eingesetzt werden, ausgewählt. Wie aus den folgenden beiden Abbildungen hervorgeht, wurden für das Intranetverzeichnis eine einzige Authentifizierungsmethode und für das Extranetverzeichnis drei Methoden ausgewählt.

Abbildung 4.2 Authentifizierungs- und Autorisierungsmechanismen für das Intranet in der Contoso-Infrastruktur

Abbildung vergrößern

Abbildung 4.3 Authentifizierungs- und Autorisierungsmechanismen für das Extranet in der Contoso-Infrastruktur

Authentifizieren beim Intranetverzeichnis

Der Hauptauthentifizierungsmechanismus für das interne Netzwerk ist das Kerberos 5-Protokoll, das von Windows Server 2003 und Windows XP Professional systemeigen unterstützt wird. Viele andere Plattformen enthalten Kerberos-Protokollbibliotheken. Dies ist besonders bei unterschiedlichen Distributionen von UNIX, einschließlich Linux, der Fall. Contoso wird - wenn möglich - das Kerberos 5-Protokoll verwenden, da es ein auf Standards basierendes, äußerst sicheres Netzwerkprotokoll ist. Von vielen Plattformen wird die Kerberos 5-Protokollauthentifizierung implementiert, weshalb dieses Protokoll eine gute Grundlage für Interoperabilität darstellt.

Alle verwalteten Clientcomputer des internen Netzwerks, einschließlich Computer, auf denen die Windows XP Professional- und Sun Solaris-Betriebssysteme ausgeführt werden, melden sich über das Kerberos 5-Protokoll bei Konten der internen Gesamtstruktur an. Nach dem Anmelden authentifizieren sich Benutzer erneut über das Kerberos 5-Protokoll bei bestimmten Ressourcen.

Authentifizieren beim Extranetverzeichnis

Vom externen Netzwerk werden verschiedene Arten von Authentifizierung verwendet, da das Kerberos 5-Authentifizierungsprotokoll in der Contoso-Umgebung derzeit nicht für Webclients auf Anwendungen mit Internetverbindung unterstützt wird. Von den drei externen Anwendungen mit Internetverbindung, die im Contoso-Umkreisnetzwerk gehostet werden, werden folgende Authentifizierungsmethoden verwendet:

• Microsoft Passport

• Auf Microsoft Windows Forms basierende Authentifizierung

• Clientzertifikatsauthentifizierung mit SSL (Secure Sockets Layer) und TLS (Transport Layer Security)

Von allen drei Authentifizierungsmechanismen wird die Active Directory-Extranetgesamtstruktur als Identitätsspeicher verwendet. Die Extranetdomäne enthält Benutzerkonten mit Zuordnungen für Passport und Clientzertifikatsauthentifizierung sowie Anmeldeinformationen über geheime Kennwörter für die auf Windows Forms basierende Authentifizierung.

Autorisierungsmethoden

Für die Hauptautorisierungsmethode verwendet Contoso Zugriffssteuerungslisten (Access Control List, ACL) auf Datei- und Druckservern (in Abbildung 4.3 nicht enthalten). Bei Contoso wird jedoch auch die rollenbasierte Zugriffssteuerung durch den Authorisierungs-Manager in Windows Server 2003 genutzt. Der Authorisierungs-Manager wird zusammen mit Internet Information Services 6.0 (IIS 6.0) verwendet, damit für den Zugriff auf Webanwendungen sowohl die Autorisierung auf URL-Ebene als auch detaillierte Berechtigungen auf Anwendungsebene verwendet werden können.

Contoso wird Sicherheitsgruppen verwenden, um Benutzer beispielsweise nach Abteilung oder Position zu organisieren. Durch diese Sicherheitsgruppen lassen sich Benutzern leichter Berechtigungen gewähren, und es fallen weniger Verwaltungsarbeiten an, wenn Benutzer innerhalb der Organisation die Stelle wechseln.

Vertrauensstellung

Beim Implementieren des Zusammenschlusses zwischen dem externen Verzeichnis und dem internen Infrastrukturverzeichnis standen dem Contoso-Team folgende Alternativen zur Auswahl:

• Gesamtstrukturübergreifende Vertrauensstellungen

• PKI-qualifizierte Unterordnung

• Schattenkonten

Gesamtstrukturübergreifende Vertrauensstellungen

Mit Windows Server 2003 können Vertrauensstellungen zwischen Gesamtstrukturen verwendet werden. In der Contoso-Umgebung wurde diese Option in Erwägung gezogen, damit Mitarbeiter, die die externen Anwendungen verwenden, sich über die Vertrauensstellung beim internen Verzeichnis authentifizieren können.

Langfristig gesehen möchte man im Unternehmen Anwendungen erstellen und bereitstellen, für die die End-to-End-Authentifizierung genutzt wird. Bevor dieses Ziel erreicht werden kann, muss zunächst die Sicherheit des internen Netzwerks gründlich analysiert und anschließend die entsprechende Maßnahme zum Beheben eventueller Probleme durchgeführt werden.

Das Contoso-Team hat letztendlich entschieden, keine solche Vertrauensstellung in der Umgebung der Organisation herzustellen. Diese Entscheidung ist auf einige Sicherheitsbedenken, die für das Contoso-Szenario gelten, zurückzuführen und darauf, dass für die Anwendungsszenarios des Unternehmens eine solche Vertrauensstellung derzeit nicht erforderlich ist. Im Fall von Contoso ist man hauptsächlich an der Sicherheit des internen Netzwerks interessiert und weniger an weiteren Anwendungsfunktionen, die durch eine Vertrauensstellung zwischen der externen und der internen Gesamtstruktur zur Verfügung stehen würden.

Andererseits könnten in Ihrer Organisation Szenarios gelten, für die gesamtstrukturübergreifende Vertrauensstellungen implementiert werden müssen. Beispielsweise ist es möglich, dass sich externe Benutzer bei einem externen Server anmelden und auf Informationen zugreifen müssen, die sich auf dem Intranet Ihrer Organisation befinden. In diesem Fall könnten Sie dafür sorgen, dass die Benutzeridentität mit der Anwendungsanforderung vom Webserver auf die Anwendungsdatenquelle übertragen wird. Ein derartiges Szenario ist möglich, wenn die neuen Kerberos 5-Protokolldelegationsfunktionen und die in Windows Server 2003 enthaltenen Mechanismen für gesamtstrukturübergreifende Vertrauensstellungen verwendet werden.

PKI-qualifizierte Unterordnung

Durch die Infrastruktur für öffentliche Schlüssel (Public Key Infrastructure, PKI) können in einer Organisation Daten auf sichere Weise über ein öffentliches Netzwerk ausgetauscht werden, indem die öffentlichen Schlüssel verschlüsselt werden. Eine PKI besteht aus Zertifizierungsstellen (Certification Authorities, CA), von denen digitale Zertifikate, Verzeichnisse, in denen die Zertifikate gespeichert werden (einschließlich Active Directory in Windows 2000 Server und Windows Server 2003), und X.509-Zertifikate ausgestellt werden. X.509-Zertifikate werden an Sicherheitsentitäten auf dem Netzwerk ausgestellt. Die PKI sorgt für die Überprüfung von zertifikatbasierten Anmeldeinformationen und dafür, dass die Anmeldeinformationen nicht gesperrt, beschädigt oder geändert werden.

Bei der qualifizierten Unterordnung handelt es sich um das gegenseitige Zertifizieren von CA-Hierarchien. Dabei wird unter Verwendung grundlegender Einschränkungen sowie Einschränkungen in Bezug auf Richtlinien, die Benennung und Anwendungen bestimmt, welche Zertifikate von Partner-CA-Hierarchien oder einer sekundären Hierarchie innerhalb derselben Organisation angenommen werden. Sie können durch die qualifizierte Unterordnung bestimmen, welchen von der PKI eines Partners ausgestellten Zertifikaten in Ihrer Organisation Vertrauen geschenkt wird. Durch die qualifizierte Unterordnung stehen außerdem Methoden zum Aufgliedern und Steuern der Zertifikatsausgabe innerhalb einer Organisation zur Verfügung, bei denen Richtlinien berücksichtigt werden.

Contoso hat eine dreistufige PKI-Infrastruktur implementiert, die gemäß bewährten Microsoft-Praktiken aus einer ausstellenden Zertifizierungsstelle, einer Offline-Zwischenzertifizierungsstelle und einer Offline-Stammzertifizierungsstelle besteht. IIS-Administratoren von Contoso haben dann Serverzertifikate von der Ausgabezertifizierungsstelle angefordert, um die SSL-Verschlüsselung auf den Internetwebanwendungen von IIS zu aktivieren. Contoso hat darüber hinaus für Mitarbeiter in Active Directory die Richtlinie zum automatischen Registrieren der Benutzerzertifikate, Active Directory Mapper und die Clientzertifikatszuordnung in IIS aktiviert.

Weitere Informationen über gesamtstrukturübergreifende Vertrauensstellungen und die PKI-qualifizierte Unterordnung finden Sie auf den folgenden Seiten von „Microsoft.com“:

• Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 (in englischer Sprache)

• Public Key Policies Concepts (in englischer Sprache)

• Public Key Policies How To... (Schritt-für-Schritt-Anleitung zu Richtlinien für öffentliche Schlüssel, in englischer Sprache)

Weitere Informationen über das Bereitstellen von Microsoft Zertifikatdienste finden Sie in Kapitel 16 (Designing a Public Key Infrastructure), die an folgender Stelle (in englischer Sprache) heruntergeladen werden kann:

Schattenkonten

Beim Entwurf des Zusammenschlusses, für den sich Contoso entschieden hat, werden interne Benutzer (Mitarbeiter) in den Anwendungen des Umkreisnetzwerks durch das Erstellen von Schattenkonten im externen Active Directory authentifiziert. Diese Schattenkonten dienen nur der zertifikatbasierten Authentifizierung. Die Schattenkonten enthalten bestimmte Autorisierungsinformationen, die für die Extranetanwendung erforderlich sind (z. B. Name und Gruppenmitgliedschaft), nicht jedoch das Kontokennwort des Benutzers.

Die Mitarbeiter der Verkaufsabteilung verwenden diese Schattenkonten, um auf eine Anwendung zuzugreifen, die im Umkreisnetzwerk gehostet wird. Da die Schattenkonten für den Zugriff auf die externe Anwendung genügen, ist zwischen der externen und der internen Gesamtstruktur keine Vertrauensstellung erforderlich.

Verwaltung des Identitätslebenszyklus

Zum Verwalten des Lebenszyklus digitaler Identitäten hat Contoso MIIS 2003 mit SP1 (Microsoft Identity Integration Server 2003 Enterprise Edition mit Service Pack 1) ausgewählt. Dieses Produkt bietet die erforderliche Identitätsintegrationsunterstützung für effizientes Synchronisieren, Bereitstellen und Deaktivieren digitaler Identitäten. Außerdem verfügt es über Verwaltungsagenten, mit denen Verbindungen zu den unterschiedlichen Identitätsspeichern der Contoso-Umgebung hergestellt werden können.

Bei der Contoso-Implementierung werden Microsoft Zertifikatdienste und die Richtlinienkonfiguration zum Aktivieren der automatischen Registrierung von Benutzerkonten verwendet. Durch die Funktion zum automatischen Registrieren wird die Verwaltung von Benutzerzertifikaten nicht nur ermöglicht, sondern auch kostengünstig gestaltet. Im Microsoft Identity and Access Management-Framework eignet sich die Benutzerauthentifizierung mit Clientzertifikaten am ehesten für Szenarios, in denen sie in Bezug auf Sicherheit einen offensichtlichen Vorteil darstellt.

Beispielsweise wird durch die Clientzertifikatsauthentifizierung das Sicherheitsrisiko verringert, das mit dem Verwenden von Kennwörtern zum Authentifizieren bei Servern einhergeht, auf denen die Anwendung Sales and Contacts im Umkreisnetzwerk gehostet wird. Bei Contoso werden nur Zertifikatdienste eingesetzt und das automatische Registrieren auf dem internen Netzwerk konfiguriert, da in keinem Anwendungsszenario die zertifikatbasierte Authentifizierung für externe Kunden und Partner erforderlich ist.

Identitätsbewusste Anwendungen

Damit das Entwickeln identitätsbewusster Anwendungen unterstützt wird, hat Contoso eine Richtlinie implementiert, der zufolge - wenn möglich - das Kerberos 5-Authentifizierungsprotokoll mit Active Directory-Domänencontrollern verwendet wird. Anwendungen, von denen das Kerberos-Protokoll nicht für die Authentifizierung verwendet werden kann (z. B. Extranetanwendungen), verwenden stattdessen die Windows Forms-basierte Authentifizierung für B2B-Fälle (Business to Business), Microsoft Passport für B2C-Fälle (Business to Consumer) und Zertifikate oder (künftig) Smartcards für B2E-Fälle (Business to Employee).

Die Autorisierung erfolgt für beständige Objekte wie Dateien und Elemente des Verzeichnisses über Zugriffssteuerungslisten (Access Control List, ACL). Für webbasierte Anwendungen wird der rollenbasierte Zugriff mit dem Authorisierungs-Manager verwendet.

Contoso-Netzwerk

In Abbildung 4.4 wird die vollständige Implementierung der Contoso-Architektur zur Identitäts- und Zugriffsverwaltung dargestellt.

Abbildung 4.4 Netzwerklayout der Contoso-Infrastruktur zur Identitäts- und Zugriffsverwaltung

Abbildung vergrößern

Die Implementierung der Contoso-Technologiearchitektur zur Identitäts- und Zugriffsverwaltung weist folgende Merkmale auf:

• Firewall, durch die das externe Active Directory vom internen Netzwerk getrennt wird

• Keine Direktverbindung zwischen dem Internet und dem internen Netzwerk

• Keine Direktverbindung zwischen dem Internet und dem externen Active Directory

• Separate Gesamtstruktur für das Extranet

• Zwei Webserver mit IIS 6.0 im Extranet, auf denen die Anwendungen des Unternehmens für Mitarbeiter der Verkaufsabteilung und Kunden gehostet werden

• Umkreisnetzwerk-Webserver, auf dem auch der Verteilungspunkt für Zertifikatssperrlisten (Certificate Revocation List, CRL) gehostet wird, über den von Mitarbeitern zum Authentifizieren bei den externen Anwendungen verwendete Zertifikate überprüft werden

• Lotus Notes Release 6.5.4-Anwendung und Sun ONE Directory Server 5.1, die Dienste im Rahmen des internen Netzwerks bereitstellen

• Zertifikatdienste, die sich auf dem internen Netzwerk befinden

Die Contoso-Plattform zur Identitäts- und Zugriffsverwaltung basiert auf der WSSRA (Windows Server System Reference Architecture), die von Microsoft und einigen anderen führenden Hardware- und Softwareanbietern entwickelt wurde. Die WSSRA (früher als Microsoft Systems Architecture 2.0 bzw. MSA bekannt) verfügt über bewährte schrittweise Anleitungen zum Implementieren umfangreicher IT-Infrastrukturen, die auf Microsoft-Technologien basieren.

Weitere Informationen über WSSRA finden Sie auf der Seite Windows Server System Reference Architecture (in englischer Sprache).

Im Anhang A dieses Dokuments finden Sie die Einstellungen zum Konfigurieren der Contoso-Umgebung in einer VPC 2004-Testumgebung (Virtual PC).

Szenarios aktivierter Lösungen

Von einer Microsoft-Plattforminfrastruktur werden folgende Lösungen aktiviert:

• Identitätszusammenfassung und -synchronisierung für mehrere Verzeichnisse

• Kennwortverwaltung einschließlich Kennwortübertragung auf mehrere Verzeichnisse

• Intranet-Zugriffsverwaltung einschließlich UNIX- und SAP-Integration mit Active Directory

• Extranet-Zugriffsverwaltung einschließlich Unterstützung für B2B-, B2C- und B2E-Umgebungen

• Entwickeln identitätsbewusster ASP.NET-Anwendungen einschließlich Unterstützung für Intranet- und Extranetanwendungsentwicklung

Die zugrunde liegende Strategie des Unternehmens besteht darin, manuelle ineffiziente Verwaltungsabläufe für die Verwaltung digitaler Identitäten durch automatisierte effiziente Verwaltungsabläufe zu ersetzen. In Artikeln, die im Rahmen dieser Serie an anderer Stelle folgen, werden die in den folgenden Abschnitten beschriebenen Zielbereiche wesentlich detaillierter besprochen.

Identitätszusammenfassung und -synchronisierung

Für die Identitätszusammenfassung und -synchronisierung innerhalb der Organisation hat sich Contoso für den Einsatz von MIIS 2003 mit SP1 als Identitätsintegrationsprodukt entschieden. Dieses Produkt lässt sich zusammen mit den anderen Verzeichnisdiensten und Identitätsspeichern des Unternehmens verwenden. Beispiele:

• Active Directory-Intranetgesamtstruktur

• Active Directory-Extranetgesamtstruktur (mit Schattenkunden für Kunden, Partner und Mitarbeiter)

• SunOne Directory Server 5.1 (früher als iPlanet Directory Server bekannt)

• Lotus Notes Release 6.5.4

Weitere Informationen über dieses Thema finden Sie im Rahmen dieser Serie im Artikel „Identitätszusammenfassung und -synchronisierung“.

Kennwortverwaltung

Zum Implementieren einer effektiven Kennwortverwaltung hat sich Contoso für folgende Komponenten entschieden:

• Gruppenrichtlinie in Active Directory zum Durchsetzen von Kennwortstärke, -komplexität und -ablauf.

• Benutzerdefinierte DLL (Dynamic Link Library) für Kennwortfilter und Benachrichtigungen, mit der Benutzer in Active Directory ihre Kennwörter ändern und die geänderten Kennwörter dann auf andere Verzeichnisse und Identitätsspeicher übertragen können.

• MIIS 2003 mit Verwaltungsagenten (Management Agent, MA), von denen Kennwortänderungen mit allen verbundenen Verzeichnissen verwaltet werden.

• Benutzerdefinierter Windows-Dienst, von dem WMI (Windows Management Instrumentation) als Brücke zwischen den Active Directory-Domänencontrollern und den MIIS 2003-MA verwendet wird. Durch diese Kombination werden Kennwortänderungen an Lotus Notes Release 6.5.4 und Sun One Directory Server 5.1 übertragen.

• Benutzerdefinierte Webanwendung mit MIIS 2003, damit Benutzerkennwörter vom Helpdeskpersonal von einem Ort aus zurückgesetzt werden können. Die Kennwortänderungen werden dann von MIIS 2003 auf die verbundenen Verzeichnisse übertragen.

Weitere Informationen finden Sie im Rahmen dieser Serie im Artikel „Kennwortverwaltung“.

Intranet-Zugriffsverwaltung

Für die Intranet-Zugriffsverwaltung hat Contoso standardmäßig folgende Konfigurationen eingeführt:

• Verwenden des Kerberos 5-Authentifizierungsprotokolls sowohl für die Authentifizierung als auch für den Datenschutz

• Verwenden von Active Directory-Domänencontrollern als KDC (Key Distribution Center) für die Authentifizierung mit dem Kerberos 5-Protokoll

• Aktivieren der Anwendungsunterstützung in SAP R/3 und den UNIX-Arbeitsstationen für die Authentifizierung mit dem Kerberos 5-Protokoll

Weitere Informationen finden Sie im Rahmen dieser Serie im Artikel „Intranet-Zugriffsverwaltung“.

Extranet-Zugriffsverwaltung

Im Rahmen der Extranet-Zugriffsverwaltung hat sich Contoso zum Gewähren von Zugriffsrechten auf Webanwendungen für Partner, Kunden und Mitarbeiter für folgende Architektur entschieden:

• Externe Active Directory-Gesamtstruktur zum Verwalten der Konten für sämtliche externe Benutzer

• Selbstregistrierung für bereits eingerichtete Kundenkonten in Active Directory

• Microsoft Passport-Dienste für Kundenauthentifizierung und SSO

• Formularbasierte Authentifizierung mit SSL-Verschlüsselung zum Schutz der Partnerauthentifizierungsreihenfolge

• MIIS 2003 zum Bereitstellen von Mitarbeiterschattenkonten in der externen Active Directory-Gesamtstruktur

• Microsoft Windows-Autorisierungs-Manager für die rollenbasierte Autorisierung

• Microsoft Zertifikatdienste für PKI

• IIS 6.0 zum Hosten der Webanwendungen

• Microsoft Internet Security & Acceleration Server (ISA) zum Bereitstellen eines Umkreisnetzwerks und von Zugriffssteuerung zwischen den internen und externen Netzwerken

Weitere Informationen finden Sie im Rahmen dieser Serie im Artikel „Extranet-Zugriffsverwaltung“.

Entwickeln identitätsbewusster ASP.NET-Anwendungen

Zum Gewährleisten von Konsistenz beim Entwickeln von identitätsbewussten Anwendungen hat Contoso folgende Verfahrensweisen als Standard eingeführt:

• Verwenden des Kerberos 5-Protokolls für Intranetanwendungen

• Verwenden der Kerberos-Authentifizierung zwischen Anwendungswebservern und Back-End-Ressourcen

• Durchführen der Authentifizierungs- und Autorisierungsintegration mit Active Directory als einziger Verzeichnisdienst für Anwendungen

• Verwenden der rollenbasierten Zugriffssteuerung in Webanwendungen und ACLs auf Back-End-Serverressourcen

Weitere Informationen finden Sie im Rahmen dieser Serie im Artikel „Entwickeln identitätsbewusster ASP.NET-Anwendungen“.

In diesem Beitrag

• Kapitel 1: Einführung
• Kapitel 2: Vorgehensweisen beim Auswählen einer Plattform
• Kapitel 3: Probleme und Anforderungen
• Kapitel 4: Entwerfen der Infrastruktur
• Kapitel 5: Implementieren der Infrastruktur
• Kapitel 6: Betreiben der Infrastruktur
• Anhang A: Konfigurationseinstellungen
• 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).

4 von 9