Intranetzugriffsverwaltung und Single Sign-On

Kapitel 2: Methoden der Intranetzugriffsverwaltung

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

Es gibt verschiedene Möglichkeiten, die Intranetzugriffsverwaltung in einer Organisation zu verbessern, die Microsoft-Technologien einsetzt. Eine Methode, bei der Plattformen und Anwendungen migriert werden, damit allgemeine Sicherheitsdienste für die Authentifizierung und Autorisierung verwendet werden, kann Einmaliges Anmelden (Single Sign-On, SSO) für Benutzer ermöglichen, die Sicherheitsüberwachung verbessern, bestehende Vertrauensstellungen nutzen, die Infrastruktur konsolidieren, den Verwaltungsaufwand reduzieren und die Netzwerksicherheit verbessern.

Jedoch sind nicht alle Methoden in Bezug auf ihre Effizienz, Implementierung oder Sicherheit gleich gestellt. Im Folgenden sind diese Methoden in der Reihenfolge ihrer Priorität aufgeführt:

• Anwendungsintegration in Windows-Sicherheitsdienste. Bei dieser Methode werden Anwendungen entwickelt und migriert, sodass sie die Sicherheitsdienste der Microsoft® Windows®-Plattform, einschließlich der Authentifizierung und Autorisierung, verwenden. Durch die Integration in Windows-Sicherheitsdienste werden Kosten bei der Anwendungsentwicklung gesenkt. Außerdem können Anwendungen problemlos die Funktionen des Betriebssystems Windows für Einmaliges Anmelden, Vertrauensstellungen und Sicherheitsüberwachung verwenden.

• Plattformintegration in Windows-Verzeichnis- und Sicherheitsdienste. Bei dieser Methode werden andere Plattformen so konfiguriert, dass sie die vom Verzeichnisdienst Microsoft Active Directory® unterstützten Verzeichnis- und Sicherheitsdienste verwenden. Darüber hinaus wird eine plattformübergreifende Interoperabilität ermöglicht und der Verwaltungsaufwand reduziert.

• Anwendungsintegration in Windows-Verzeichnisdienste. Durch die Entwicklung und Migration von Anwendungen, sodass diese von Active Directory unterstützte Standardverzeichnisprotokolle für die Authentifizierung und Autorisierung verwenden, ist eine Konsolidierung der Identitätsspeicher möglich.

• Indirekte Integration durch Zuordnung von Anmeldeinformationen. Wenn die direkte Integration einer Anwendung oder Plattform nicht möglich ist, können SSO-Funktionen für Benutzer durch Zuordnung von Anmeldeinformationen (auch als SSO für Unternehmen bezeichnet) bereitgestellt werden.

• Synchronisierte Konten und Kennwörter. Wenn keine der anderen Optionen verfügbar sind und die Sicherheitsrisiken abgewägt wurden, trägt die Verwendung allgemeiner Anmeldeinformationen zwischen unterschiedlichen Anwendungen und Plattformen zu erhöhter Benutzerfreundlichkeit bei.

Aufgrund der Funktionen eines Hostsystems, der Möglichkeit, eine Anwendung zu ändern, oder der erwarteten Investitionsrendite bei der Implementierung der Lösung entscheidet sich eine Organisation möglicherweise für eine der weniger empfehlenswerten Methoden.

Auf dieser Seite

Anwendungsintegration in Windows-Sicherheitsdienste
Plattformintegration in Windows-Verzeichnis- und Sicherheitsdienste
Anwendungsintegration in Windows-Verzeichnisdienste.
Indirekte Integration durch Anmeldeinformationszuordnung
Synchronisierte Konten und Kennwörter

Anwendungsintegration in Windows-Sicherheitsdienste

Das Integrieren von Anwendungen in Windows-Sicherheitsdienste (auch als in Windows integrierte Anwendungen bezeichnet) bietet die folgenden Vorteile:

• SSO für Windows-basierte Clients

• Größere Sicherheit für über das Netzwerk übertragene Anwendungsdaten

• Effizientere Verwaltung digitaler Identitäten in Active Directory

• Die Möglichkeit, anwendungsübergreifend Sicherheitsgruppen auf Unternehmensebene und eine rollenbasierte Zugriffssteuerung einzurichten

• Eine erweiterte Palette von Authentifizierungs- und Autorisierungsdiensten durch Vertrauensstellungen mit eingeschränktem Verwaltungsaufwand

• Integrierte Sicherheitsereignisprotokollierung

In diesem Abschnitt werden anhand der folgenden Themen zahlreiche Vorteile von in Windows integrierten Anwendungen beschrieben:

• Windows-SSO und Zugriffsverwaltung

• Beispiele für in Windows integrierte Anwendungen

Hinweis   Weitere Informationen zum Entwickeln von Microsoft ASP.NET-Anwendungen, die in Windows-Sicherheitsdiensten integriert werden können, finden Sie im Artikel „Entwickeln identitätsbewusster ASP.NET-Anwendungen“ in dieser Serie.

Einmaliges Anmelden für Windows und Zugriffsverwaltung

Clientcomputer, auf denen auf Microsoft Windows basierende Betriebssysteme wie Microsoft® Windows® XP Professional und Windows® 2000 Professional (sowie als Client fungierende Serverprodukte wie z. B. Windows Server™ 2003) ausgeführt werden, enthalten integrierte Features, die SSO zulassen, wenn der Client und der Server mit einer Windows-Domäne oder -Gesamtstruktur verbunden sind. Ein domänenübergreifendes SSO wird durch Einrichten von Vertrauensstellungen zwischen Domänen oder Gesamtstrukturen ermöglicht, wie im Artikel „Grundlegende Konzepte“ in dieser Serie beschrieben.

Die folgenden in Windows-Sicherheitsdienste implementierten Features bieten SSO-Funktionen:

• Eine von der lokalen Sicherheitsinstanz (Local Security Authority, LSA) verwaltete Zwischenspeicherung der Anmeldeinformationen

• Eine Gruppe von Authentifizierungspaketen, die in LSA integriert sind

Ein Verständnis des Windows-Anmeldeprozesses ist Voraussetzung, um zu verstehen, wie SSO von den Windows-Sicherheitsdiensten bereitgestellt wird. In den folgenden Abschnitten finden Sie eine Übersicht über die Ausführung dieses Prozesses, um SSO bereitzustellen.

Der Anmeldeprozess

Im Betriebssystem Windows ist der Mechanismus für die Benutzeranmeldung ein integraler Bestandteil des Clientcomputers und des Netzwerks. Der Benutzer muss sich nur einmal mit seinen Anmeldeinformationen für die Domäne im Netzwerk authentifizieren. Durch diese einmalige Anmeldung kann sich der Benutzer an der Arbeitsstation anmelden und auf beliebige lokale oder Remoteressourcen zugreifen, für die er eine Zugriffsberechtigung erhalten hat. Der Anmeldeprozess wird in Abbildung 2.1 beschrieben.

Abbildung 2.1: Der integrierte Windows-Authentifizierungsprozess für die Desktopanmeldung

Abbildung vergrößern

Im Rahmen des Anmeldeprozesses ruft der Benutzer mit der Tastenkombination STRG+ALT+ENTF die GINA-DLL (Graphical Identification and Authentication) auf. Hierbei handelt es sich um eine sichere Authentifizierungsfolge (Secure Authentication Sequence, SAS), die das Windows-Anmeldedialogfeld (Schritt 1) für den Benutzer anzeigt. Der Benutzer gibt seine Anmeldeinformationen dann in das Anmeldedialogfeld ein.

Die lokale Sicherheitsinstanz (LSA) stellt dann bei einem Domänencontroller, auf dem Active Directory ausgeführt wird, eine TGT-Anforderung (Ticket Granting Ticket; auch als TGT-REQ bezeichnet) (Schritt 2). Das im LSA-Dienst auf dem Domänencontroller ausgeführte Schlüsselverteilungscenter (Key Distribution Center, KDC) für Kerberos, Version 5 authentifiziert den Benutzernamen und das Kennwort durch Aufrufen der Sicherheitskontenverwaltung (Security Accounts Manager, SAM) (Schritt 3) auf dem Domänencontroller. Wenn die Anmeldeinformationen korrekt sind und keine weiteren Richtlinienelemente (wie z. B. Einschränkungen der Zeit oder Arbeitsstation) eine Benutzeranmeldung verhindern, gibt die LSA auf dem Domänencontroller entweder Tickets des Authentifizierungsprotokolls Kerberos, Version 5 (Schritt 4) oder NTLM-Autorisierungsdaten (NT LAN Manager) (nicht angezeigt) an die LSA auf dem Client zurück.

Hinweis   Andere Authentifizierungsprotokolle sind in Authentifizierungspaketen (auch als Authentifizierungsanbieter bezeichnet) in Windows-Clients und -Servern implementiert. Der Schwerpunkt dieses Artikels liegt jedoch auf dem Authentifizierungsprotokoll Kerberos, Version 5. NTLM wird nur an den relevanten Stellen erwähnt.

Erstellen des Autorisierungskontexts

Das Kerberos-Ticket enthält unter anderem das Zertifikat mit Rechteattributen (Privilege Attribute Certificate, PAC), das wiederum Sicherheits-ID-Informationen (SID) für den Benutzer und die Gruppen enthält, bei denen dieser Benutzer Mitglied ist. Diese Struktur ist in Abbildung 2.2 veranschaulicht.

Die Arbeitsstation erstellt aus dem Kerberos-Ticket (Schritt 5 in Abbildung 2.1) oder den NTLM-Autorisierungsdaten ein Zugriffstoken. (Dies wird manchmal auch als Sicherheitskontext bezeichnet. Bei einer Diskussion über die lokale Autorisierung im Gegensatz zur Netzwerkautorisierung ist Zugriffstoken jedoch der korrekte Begriff.)

Ein Windows-Zugriffstoken enthält Folgendes:

• Die primäre SID des Benutzers

• SIDs für globale und universelle Gruppen aus dem Konto, der Domäne oder der Gesamtstruktur des Benutzers

• SIDs der lokalen Domäne aus der Domäne der Arbeitsstation (falls sich diese von der Domäne des Benutzers unterscheidet)

• Berechtigungen, die dem Benutzer ausdrücklich zugewiesen oder aus der Gruppenmitgliedschaft abgeleitet wurden

Die Authentifizierungsfolge auf dem Clientcomputer startet eine Instanz der Shell (normalerweise die Datei Explorer.exe) und hängt das Zugriffstoken des Benutzers an die Shell an (Schritt 6 in Abbildung 2.1).

Abbildung 2.2: Das Kerberos-Ticket enthält das PAC , das wiederum Benutzer- und Gruppen-SIDs enthält

Zugreifen auf lokale Ressourcen

Alle Anwendungen, die von der Shell auf der Arbeitsstation gestartet werden, erben das Zugriffstoken aus dem Shellprozess. Nachdem sich der Benutzer angemeldet hat, vergleicht die Arbeitsstation daher bei jedem Versuch, auf eine lokale Ressource zuzugreifen (z. B. beim Öffnen einer Datei oder Drucken eines Dokuments aus der Shell oder einem beliebigen von der Shell gestarteten Prozess) das Zugriffstoken des Benutzers mit der Sicherheits-Zugriffssteuerungsliste (Access Control List, ACL) des Objekts, auf das zugegriffen wird.

Zugreifen auf Remoteressourcen

Bei jedem Versuch des Benutzers, eine Aktion an einer Remoteressource durchzuführen (z. B. Öffnen einer Datei auf einer Netzwerkdateifreigabe oder Drucken eines Dokuments auf einem Netzwerkdrucker) führen der Client und der Server eine Authentifizierungsfolge aus. Die Authentifizierungsfolge wird standardmäßig mit den gleichen Anmeldeinformationen ausgeführt, mit denen die Anmeldung an der Arbeitsstation erfolgte. Die SSO-Funktionen für den Windows-basierten Benutzer sind das Resultat der Integration der Authentifizierungsprotokollanbieter Kerberos und NTLM in der LSA auf der Arbeitsstation. Dieser Vorgang wird in Abbildung 2.3 beschrieben.

Abbildung 2.3: Der Authentifizierungsprozess für die Anmeldung an Remoteressourcen

In diesem Beispiel wird davon ausgegangen, dass die Anmeldung an der Arbeitsstation mit dem Kerberos-Protokoll erfolgt. Dies ist der Standardauthentifizierungsmechanismus in Microsoft Windows® 2000 und Windows Server 2003. Erfolgte die ursprüngliche Anmeldung mit dem NTLM-Protokoll, ergibt sich eine etwas andere Reihenfolge.

Der Benutzer versucht, auf eine Datei auf einem Remotecomputer mit Windows Server 2003 zuzugreifen (Schritt 1). Der Server erfordert eine Authentifizierung und gibt eine „Herausforderung“ für den Benutzer heraus (Schritt 2). Die LSA auf dem Client ruft dann das Kerberos-Authentifizierungspaket auf, um die nötigen Anmeldeinformationen für die Authentifizierung anzufordern (Schritt 3). Das Kerberos-Authentifizierungspaket erfüllt die Anforderung durch Abrufen eines zuvor ausgegebenen gültigen Tickets aus dem Ticketcache auf dem Client (Schritt 4) oder durch Anfordern eines neuen Tickets (TKT) für den Server (nicht angezeigt) vom KDC. Zum Schluss reagiert der Client auf die Serverherausforderung, indem er das Ticket an den Server sendet (Schritt 5).

Nachdem das Ticket geprüft wurde (Schritt 6), erstellt der Kerberos-Authentifizierungsanbieter ein Zugriffstoken wie bereits weiter oben beschrieben (Schritt 7). Über dieses Token kann der Server die Identität des Clientbenutzers annehmen (Schritt 8). Durch den Identitätswechsel kann der Server zum Durchsetzen der korrekten Autorisierungsdaten durch Vergleichen der Berechtigungen des Benutzers (die im Zugriffstoken erfasst wurden) mit der Zugriffssteuerungsliste in der Ressource das Betriebssystem verwenden (Schritt 9). Das Betriebssystem lässt den Vorgang dann je nach Situation zu (siehe Abbildung 2.3) oder lehnt sie ab.

Sicherheitsüberwachung

Die Sicherheitsüberwachung kann sowohl für die Authentifizierung (einschließlich der Anmeldung an der Arbeitsstation) als auch die Autorisierung konfiguriert werden. Diese Funktion muss entsprechend der schriftlichen Sicherheitsrichtlinien der Organisation optimiert werden. Sie können die Sicherheitsüberwachung so konfigurieren, dass sie erfolgreiche und/oder fehlgeschlagene Anmeldungsvorgänge überwacht.

Die Autorisierungsüberwachung kann auf einer Objektebene konfiguriert werden und wird detailliert bis auf die Ebene angegeben, auf der Objektvorgänge definiert sind. Beispielsweise können fehlgeschlagene oder erfolgreiche Lese-, Schreib- oder Bearbeitungsvorgänge an einer Datei überwacht werden.

Erweitern des Zugriffs mit Vertrauensstellungen

Sie können die Auswirkungen der integrierten Windows-Authentifizierung mithilfe von Windows-Vertrauensstellungen erweitern. Durch eine Vertrauensstellung zwischen zwei Windows-Domänen (oder zwischen Gesamtstrukturen in Windows Server 2003) ist es möglich, Benutzerkonten in einer vertrauenswürdigen Domäne Rechte und Berechtigungen für die andere vertrauenswürdige Domäne zu gewähren.

Vertrauensstellungen erweitern die Funktionen von SSO, da der Benutzer sich zum Zugreifen auf Ressourcen in der vertrauenswürdigen Domäne nicht erneut anmelden muss. Wenn ein Benutzer versucht, sich bei einer Ressource in der vertrauenswürdigen Domäne anzumelden, stellt die vertrauende Domäne über Vertrauensstellungen eine Verbindung zu der vertrauenswürdigen Domäne her und überprüft die Anmeldeinformationen des Benutzers. Die Ressource in der vertrauenden Domäne gewährt dann je nach den Berechtigungen des Benutzers Zugriff.

In Windows 2000-Domänen werden domänenübergreifende Vertrauensstellungen standardmäßig in der gleichen Gesamtstruktur eingerichtet. In Windows Server 2003-Domänen ermöglichen gesamtstrukturübergreifende Vertrauensstellungen, dass alle Domänen in einer Gesamtstruktur den Domänen in der anderen Gesamtstruktur vertrauen.

Wenn keine Vertrauensstellungen aufgebaut werden können, können Sie mithilfe der Windows-Anmeldeinformationsverwaltung über eine Anwendung, die die integrierte Windows-Authentifizierung verwendet, SSO-Funktionen für den Benutzer bereitstellen. Auf die Windows-Anmeldeinformationsverwaltung wird weiter hinten in diesem Kapitel näher eingegangen.

Weitere Informationen zu Windows-Vertrauensmechanismen finden Sie auf der Seite Domänen und Gesamtstrukturen (in englischer Sprache).

Weitere Informationen zum Planen und Implementieren von gesamtstrukturübergreifenden Vertrauensstellungen in Windows Server 2003 finden Sie auf der Seite Planen und Implementieren zusammengeschlossener Gesamtstrukturen in Windows Server 2003 (in englischer Sprache).

Verbessern des Zugriffs mit der Windows-Anmeldeinformationsverwaltung

Wie bereits erwähnt, bieten die in die Windows-Sicherheitsdienste integrierten Anwendungs- und Plattformdienste SSO-Funktionen für Benutzer, indem sie den Benutzer anhand seiner Anmeldeinformationen bei den Netzwerkressourcen authentifizieren. Diese Methode ist jedoch möglicherweise nicht in allen Situationen ausreichend oder wünschenswert. Im Folgenden finden Sie Beispiele für Fälle, in denen die Windows-Sicherheitsdienste keine SSO-Funktionen bereitstellen:

• Wenn die Authentifizierung an einer Ressource in einer nicht vertrauenswürdigen Domäne erfolgen muss.

• Wenn die Authentifizierung an einer Ressource auf einem eigenständigen Server erfolgen muss.

• Wenn zum Zugreifen auf eine Netzwerkressource alternative Anmeldeinformationen erforderlich sind.

In Microsoft Windows® XP und Windows Server 2003 werden diese Szenarios über die in LSA integrierte Komponente Gespeicherte Benutzernamen und Kennwörter angegangen, die in der Regel als Windows-Anmeldeinformationsverwaltung bezeichnet wird und clientseitige Funktionen zur Anmeldeinformationsverwaltung bietet.

Sie können diese Komponente auf eine von zwei Arten konfigurieren: Sie können festlegen, dass ein Benutzer Anmeldeinformationen vor dem Zugriff auf die Ressource einmal manuell eingeben muss oder dass die Anmeldeinformationen des Benutzers automatisch gespeichert und für künftige Zugriffe verwendet werden.

Die Windows-Anmeldeinformationsverwaltung bietet dem Benutzer ein sicheres Speichern der Anmeldeinformationen auf einem Server. Sie implementieren diesen im servergespeicherten Profil des Domänenbenutzers, das Benutzern immer dann den Zugriff auf ihren Anmeldeinformationsspeicher ermöglicht, wenn sie sich anmelden und auf ihr Profil zugreifen.

Einige Anwendungen und Entwicklerschnittstellen sehen die Verwendung der Windows-Anmeldeinformationsverwaltung bei Bedarf vor. Für den Benutzer bedeutet dies, dass die Anwendung ihn bei seinem ersten Versuch, auf eine Ressource zuzugreifen, die eine Authentifizierung erfordert, zur Angabe von Anmeldeinformationen auffordert. Der Benutzer kann die Anmeldeinformationen speichern, wenn die Anwendung diese Möglichkeit zulässt. Die Anmeldeinformationen werden dann mit der anfordernden Ressource verknüpft. Wenn der Benutzer in Zukunft auf die Ressource zugreift, verwendet das Authentifizierungspaket die gespeicherten Anmeldeinformationen erneut, ohne den Benutzer zur Eingabe dieser aufzufordern. Lässt die Anwendung das Speichern der Anmeldeinformationen durch den Benutzer jedoch nicht zu, müssen die Anmeldeinformationen für diese Ressource manuell über die Komponente Gespeicherte Benutzernamen und Kennwörter der Windows-Anmeldeinformationsverwaltung eingerichtet werden. Sie können die Windows-Anmeldeinformationsverwaltung so konfigurieren, dass Anmeldeinformationen für die Protokolle Kerberos und NTLM, SSL (Secure Sockets Layer), TLS, Microsoft Passport und die Standardauthentifizierung bereitgestellt werden.

Weitere Informationen darüber, wie Anwendungen die Komponente Gespeicherte Benutzernamen und Kennwörter verwenden können, finden Sie unter Verwenden der Anmeldeinformationsverwaltung unter Windows XP und Windows Server 2003 (in englischer Sprache) auf Microsoft MSDN®.

Beispiele für in Windows integrierte Anwendungen

Client/Server-Anwendungen können mithilfe der beschriebenen Mechanismen SSO-Funktionen für Benutzer und integrierte Sicherheitsüberwachung bereitstellen und die Vorteile von Vertrauensstellungen nutzen. Viele (Server-und Client-)Anwendungen von Microsoft und Drittanbietern stellen SSO-Funktionen mithilfe der in Windows integrierten Sicherheitsfeatures bereit. Dabei sind die folgenden Client/Server-Anwendungen von besonderem Interesse:

• Microsoft Internet Explorer und Internetinformationsdienste (Internet Information Services, IIS)

• Microsoft Office Outlook® und Exchange Server 5.5 oder höher

• Microsoft SQL Server™ 7.0 oder höher und SQL Server für Clients

In den folgenden Abschnitten finden Sie Beispiele für die Funktionsweise der integrierten Windows-Authentifizierung in diesen Anwendungen.

Internet Explorer und IIS

Die Bereitstellung von Web-SSO für Intranetbrowser trägt erheblich zur Benutzerfreundlichkeit von Webanwendungen bei. Internet Explorer ist eine in Windows integrierte Anwendung, die Intranet-Web-SSO für IIS 5.0 (im Lieferumfang von Windows 2000 Server enthalten) und IIS 6.0 (im Lieferumfang von Windows Server 2003 enthalten) bereitstellt. In Abbildung 2.4 wird dargestellt, wie sich die integrierte Windows-Authentifizierung zwischen Internet Explorer und IIS gestaltet.

Abbildung 2.4: IIS-Authentifizierung mit dem Kerberos-Protokoll

Ein IIS-Administrator, der den Zugriff auf eine Intranet-Webanwendung auf authentifizierte Benutzer beschränken möchte, konfiguriert in der Regel ein Site- oder virtuelles Verzeichnis, das die integrierte Windows-Authentifizierung verwendet. Wenn diese Sicherheitseinstellung aktiviert wurde, muss die auf Internet Explorer basierende Clientanwendung den Benutzer zuerst mit dem Kerberos- oder NTLM-Authentifizierungsprotokoll auf dem Webserver mit IIS 6.0 authentifizieren. In den meisten Fällen sollte der Version 5 des Kerberos-Protokolls der Vorzug gegeben werden. Es sind jedoch Netzwerk- und Sicherheitskonfigurationen auf der Ebene des Domänencontrollers, des Servers mit IIS 6.0 und des auf Internet Explorer basierenden Clients vorhanden, mit denen ein Administrator die Verwendung der NTLM-Authentifizierung erzwingen kann.

Im Folgenden finden Sie ein Beispiel für die Funktionsweise der Kerberos-Authentifizierung zwischen Internet Explorer und IIS. Zuerst stellt der Client, auf dem Internet Explorer ausgeführt wird, eine Seitenanforderung (Schritt 1). Dann erzwingt der Server, auf dem IIS 6.0 ausgeführt wird, die Authentifizierung über HTTP (Hypertext Transfer Protocol), indem er eine Herausforderung vom Typ 401 an den Browser zurücksendet (Schritt 2). Die Herausforderung enthält eine Liste von WWW-Authenticate-HTTP-Headern, die die Authentifizierungsprotokolle angeben, die der Server mit IIS 6.0 entsprechend seiner Konfiguration für diese URL akzeptiert.

Wenn bei Internet Explorer eine Herausforderung vom Typ 401 eingeht, untersucht die Anwendung die Headerliste und wählt das zutreffende Authentifizierungsprotokoll entsprechend der Browserkonfiguration aus. Internet Explorer ruft das Authentifizierungspaket über die LSA auf (Schritt 3). Das Ticket wird dann aufgrund der Benutzeranmeldeinformationen im LSA-Anmeldeinformationscache der Arbeitsstation und der Möglichkeit, ein Kerberos-Ticket für die IIS-Ressource zu erhalten (Schritt 4), von der LSA an Internet Explorer zurückgegeben (Schritt 5). Nachdem Internet Explorer das Ticket erhalten hat, wird dieses in einer Antwort vom Typ 401 (einschließlich WWW-Authenticate-HTTP-Header) an den Server mit IIS 6.0 zurückgesendet (Schritt 6).

Wenn der Client die Anforderung zurücksendet, extrahiert der Server, auf dem IIS 6.0 ausgeführt wird, die Authentifizierungsinformationen aus dem HTTP-Header, und präsentiert die Daten dem vom Client angegebenen Authentifizierungsanbieter (Schritt 7). Ist die Authentifizierung erfolgreich, erstellt der Authentifizierungsanbieter ein Zugriffstoken, das den Benutzer repräsentiert, und IIS 6.0 verknüpft dieses Token durch Identitätswechsel mit der Clientanforderung (Schritt 8). In Abbildung 2.4 wird der Ablauf dieses Vorgangs dargestellt.

Dabei ist folgendes Verständnis nützlich: IIS 6.0 authentifiziert während dieses Vorgangs nicht den Benutzer. Die Serveranwendung vertraut diese Aufgabe über die Authentifizierungsanbieterschnittstelle dem Betriebssystem an. Für die Serveranwendung hat dies den Vorteil, dass sie den Authentifizierungscode nicht selbst implementieren muss.

Wenn die folgenden Bedingungen erfüllt sind, können Authentifizierung und Autorisierung erfolgreich durchgeführt werden, ohne dass der Benutzer weitere Anmeldeinformationen eingeben muss:

• Der Server, auf dem IIS ausgeführt wird, ist Mitglied einer auf Windows basierenden Domäne.

• Die auf Windows basierende Clientarbeitsstation ist Mitglied einer Domäne mit einer Vertrauensstellung in der Domäne, in der sich der IIS-Server befindet.

• Der Benutzer hat sich mit seinen Anmeldeinformationen für die Domäne an der Arbeitsstation angemeldet.

• Ihm wird Zugriff auf die angeforderte Ressource gewährt, da eine der folgenden Bedingungen erfüllt ist.

  • Der IIS 6.0-Administrator hat Zugriffssteuerlisten für statische Inhalte (Dateien mit den Erweiterungen HTM und ASP) konfiguriert, um dem Benutzer den Zugriff zu ermöglichen.

  • Eine Microsoft ASP.NET-Anwendung definiert Microsoft .NET-Rollen oder den Autorisierungs-Manager, die den Benutzerzugriff zulassen.

Weitere Informationen zu diesem Authentifizierungs- und Autorisierungsprozess finden Sie in den folgenden Dokumenten:

• Kerberos-Authentifizierung in Windows Server 2003 (in englischer Sprache)

• Microsoft Knowledge Base-Artikel zum Authentifizieren von Browserclients durch IIS (in englischer Sprache)

• Im Artikel zur Kerberos-Authentifizierung für Websites mit Lastenausgleich (in englischer Sprache)

• Im MSDN-Artikel zur Erstellung sicherer ASP.NET-Anwendungen für Authentifizierung, Autorisierung und sichere Kommunikation (in englischer Sprache)

Microsoft Office Outlook und Exchange Server

In diesem Beispiel meldet sich ein Benutzer mit seinem Benutzerkonto an einer auf Windows basierenden Arbeitsstation an. Anschließend startet er den E-Mail-Client Outlook, der versucht, über RPC-Schnittstellen (Remote Procedure Call) eine Verbindung zu der unter Windows Server 2003 ausgeführten Anwendung Exchange Server herzustellen. In Exchange Server ist eine Authentifizierung von Clients erforderlich, bevor eine Verbindung hergestellt wird. Daher werden sowohl vom Client als auch Server beim Aufbau der RPC-Sitzung Authentifizierungsmeldungen ausgehandelt.

Im Fall von Outlook und Exchange wird zunächst die Kerberos-Authentifizierung versucht (dem Authentifizierungsprotokoll Kerberos wird der Vorzug vor NTLM gegeben). Ist der Versuch erfolgreich, wird ein Zugriffstoken generiert, damit Exchange Server die Identität des Betriebssystems annehmen und die richtige Autorisierung durchsetzen kann. Die Clientanwendung Outlook versucht, das Postfach des Benutzers zu öffnen. Dieser Vorgang ist jedoch nur erfolgreich, wenn die Konfiguration der Zugriffsteuerungslisten des Postfachs vorsieht, dass dem Benutzer, der im Begriff ist, eine Verbindung herzustellen, Zugriff gewährt wird. Wenn die Authentifizierung erfolgreich ist und die von der Zugriffssteuerungsliste für das Postfach beschriebenen Autorisierungsregeln erfüllt werden, erhält der Benutzer Zugriff auf das Postfach in Outlook, ohne dass er sich erneut anmelden muss.

SQL Server und SQL-Clients

Bei von SQL Server gehosteten Datenbanken, die entweder den Windows-Authentifizierungsmodus oder den gemischten Modus verwenden, wird ähnlich verfahren. Der Windows-Authentifizierungsmodus in SQL Server ist mit der weiter oben für IIS 6.0 beschriebenen integrierten Windows-Authentifizierung identisch, wohingegen der gemischte Modus eine Kombination aus der Windows-basierten und der SQL Server-Authentifizierung ermöglicht.

Der SQL Server-Datenbankadministrator kann den Zugriff für Active Directory-Benutzer oder -Gruppen auf der Datenbank- oder Tabellenebene definieren. Wenn eine Clientanwendung wie z . B. SQL Query Analyzer oder eine benutzerdefinierte Anwendung, die ODBC (Open Database Connectivity) oder Microsoft ADO.NET verwendet, eine Verbindung zur Datenbank herstellt, authentifiziert SQL Server den Benutzer und ermittelt, ob die angeforderten Daten an den Client zurückgegeben werden sollen. Die Zugriffsprüfung vergleicht die Benutzerberechtigungen für die gesamte Datenbank (genauer gesagt: auf Tabellenebene) anhand der vom SQL Server-Betriebssystem gespeicherten Zugriffssteuerungstabellen und des Benutzerzugriffstokens. Nach einer erfolgreichen Authentifizierungs- und Zugriffsprüfung ist ein sicherer Zugriff auf die SQL Server-Daten möglich, ohne dass sich der Benutzer separat an der Anwendung SQL Server anmelden muss.

Weitere Informationen zum Konfigurieren und Verwenden der integrierten Windows-Authentifizierung bei SQL Server finden Sie im Artikel zum Verwalten von SQL Server und Authentifizierungsmodi (in englischer Sprache).

Plattformintegration in Windows-Verzeichnis- und Sicherheitsdienste

Für die Integration von Windows in andere Plattformen stehen eine Reihe von Diensten zur Verfügung. Diese Dienste bieten Organisationen Optionen für die Integration (auf einer bestimmten Ebene) in Windows-Sicherheits- und -Verzeichnisdienste. Bei der Integration über diese Dienste ist eine Änderung von Anwendungen oder Neukonfiguration von Arbeitsstationen und Servern in der Regel nicht nötig. Sie fügen dem Netzwerk jedoch weitere „bewegliche Teile“ hinzu und stellen andere Anforderungen an die Verwaltbarkeit. In der Regel bieten diese Dienste nicht alle Merkmale und Funktionen, die durch die direkte Integration in Windows-Sicherheitsdienste verfügbar sind.

Integration von UNIX und Linux

Für die Plattformintegration in Windows-Sicherheitsdienste wird das Kerberos-Protokoll Version 5 verwendet. Das Kerberos-Protokoll ist eine hervorragende Wahl für die Integration von UNIX und Linux in das Betriebssystem Windows, da es von all diesen Betriebssystemen (gegebenenfalls mithilfe von Drittanbieterprodukten) unterstützt wird.

Die Verwendung des Kerberos 5-Protokolls für die Integration hat folgende Vorteile:

• Kerberos ist ein standardbasiertes Protokoll (Internet Engineering Task Force (IETF) RFC 1510), das in Microsoft Windows-basierten Client- und Serverprodukten, Active Directory und fast allen Versionen von UNIX und Linux integriert ist.

• Kerberos unterstützt die sichere Anmeldung.

• Bei der Anmeldung mit dem Kerberos-Protokoll können mithilfe der folgenden Mechanismen ein Autorisierungskontext (der Gruppen enthält) und Profilinformationen bereitgestellt werden.

  • Verarbeiten der Windows-PAC-Informationen in Kerberos-Tickets, die von Windows-Domänencontrollern ausgegeben werden: Nicht alle Hersteller haben ihre Implementierungen des Kerberos 5-Protokolls so geändert, dass das Windows-PAC bei Ticketanforderungen angefordert wird. Diese Einschränkung gilt auch für die aktuelle Version der Kerberos-Protokollbibliotheken, die zum Lieferumfang des Betriebssystems SUN Solaris 9 gehören.

    Weitere Informationen zum Windows-PAC finden Sie im Whitepaper Verwenden der Windows 2000-Autorisierungsdaten in Kerberos-Tickets für die Steuerung des Zugriffs auf Ressourcen auf MSDN (in englischer Sprache).

  • Konfigurieren des NSS (Name Service Switch) für UNIX-Arbeitsstationen, sodass LDAP mit dem Modul „nss_ldap“ verwendet wird: Das Modul „nss_ldap“ bietet UNIX-Arbeitsstationen die Möglichkeit, Autorisierungsinformationen aus einem LDAP-Verzeichnis abzurufen, das auf dem Prinzipalnamen in den vom Windows-Schlüsselverteilungscenter (Key Distribution Center, KDC) ausgegebenen Kerberos-Tickets basiert. Für diese Methode der Autorisierung ist normalerweise eine Schemaerweiterung auf Active Directory erforderlich, die UNIX-ähnliche Gruppen- und Autorisierungsdaten hinzufügt. Microsoft Services for UNIX (SFU) bieten eine Schemaerweiterung, die diese Anforderung erfüllt.

  • Konfigurieren des NSS für UNIX-Arbeitsstationen, damit NIS mit dem Modul „nss_nis“ verwendet werden kann: Sie können SFU installieren, um einen NIS-Header für Active Directory bereitzustellen. Mit SFU wird Active Directory als NIS-Server angezeigt. Darüber hinaus wird eine Schemaerweiterung in Active Directory implementiert, um allgemeine UNIX-Profil- und Autorisierungsinformationen, Benutzeridentifizierung (UID), Gruppenidentifizierung (GID) und Shell-Informationen bereitzustellen.

• Das Kerberos-Protokoll in Active Directory ist vollständig in eine strikte Sicherheitsrichtlinie integriert, die von Domänencontrollern mit Windows Server 2003 durchgesetzt werden. Bevor eine Kerberos-Anmeldeanforderung verarbeitet wird, vergleicht der Domänencontroller alle relevanten Richtlinieneinstellungen mit dem aktuellen Kontostatus. Wird eine Richtlinienanforderung nicht erfüllt, weist der Domänencontroller die Anforderung zurück.

• Das Kerberos-Protokoll gibt an, dass das bei der Anmeldung erworbene TGT (Ticket Granting Ticket) dem KDC zur Generierung eines Diensttickets präsentiert werden kann. Mit diesem Dienstticket erfolgt die Authentifizierung dann an Netzwerkressourcen und -anwendungen wie SAP R/3 Application Server. Dieser Vorgang ist für Benutzer durchschaubar und ermöglicht einmaliges Anmelden.

• Das Kerberos-Authentifizierungsprotokoll umfasst die Erstellung und Freigabe von Client/Server-Sitzungsschlüsseln, die eine starke Verschlüsselung von Anwendungsdaten ermöglichen, die anschließend zwischen Client und Server übertragen werden.

Konventionelle UNIX- und Linux-Benutzer melden sich durch die Angabe eines eindeutigen Benutzernamens und Kennworts an ihrem Computer an. Der Benutzername und das Kennwort werden mit den entsprechenden, in den Dateien /etc/password und /etc/shadow gespeicherten Daten verglichen. Der PAM-Dienst (Pluggable Authentication Module) erweitert die Authentifizierungs- und Autorisierungsfunktionen von UNIX und Linux, denn er ermöglicht das Speichern von Anmeldeinformationen an verschiedenen Speicherorten. Dieser Dienst ermöglicht ferner die Verwendung unterschiedlicher Mechanismen zum Überprüfen von Benutzeranmeldeinformationen.

Auf Systemen, die den PAM-Dienst verwenden, müssen der Anmeldevorgang und alle Dienstprogramme, für die eine Benutzerauthentifizierung erforderlich ist, so kompiliert werden, dass PAM zur Authentifizierung und Autorisierung verwendet werden kann.

Die meisten Versionen von UNIX und viele Versionen von Linux unterstützen das Kerberos 5-Protokoll über die PAM-Konfigurationsdatei pam.conf. Viele dieser Betriebssystemversionen bieten darüber hinaus Bibliotheken, die die Client/Server-Abschnitte des Kerberos-Protokolls implementieren. Die Unterstützung des Kerberos-Protokolls in UNIX und Linux bietet die Möglichkeit einer nahtlosen Integration von Anwendungen mit Windows-Sicherheitsdiensten auf Computer mit UNIX und Linux.

In den Kapiteln 3 bis 7 dieses Artikels finden Sie ein ausführliches Szenario, in dem die Kerberos-Authentifizierung auf einer UNIX-Arbeitsstation mit Sun Solaris konfiguriert und so die Integration in Active Directory für Authentifizierungs- und Autorisierungszwecke ermöglicht wird.

Dienste für UNIX 3.5

Microsoft Windows Services for UNIX (SFU) ermöglichen Windows- und UNIX-Clients und -Servern die gemeinsame Nutzung von Netzwerkressourcen, integrieren die Kontoverwaltung, vereinfachen die plattformübergreifende Verwaltung und stellen eine voll funktionstüchtige UNIX-Umgebung zur Skripterstellung und Anwendungsausführung bereit, die im systemeigenen Format unter dem Betriebssystem Windows ausgeführt wird. Weitere Informationen zu SFU finden Sie auf der Website zu Windows Services for UNIX (in englischer Sprache).

Interoperabilität zwischen Windows Server 2003 R2 und UNIX

Das Betriebssystem Windows Server 2003 R2 enthält Komponenten für die Interoperabilität mit UNIX. Dazu gehören folgende Komponenten:

• Subsystem for UNIX-based Applications, mit dem UNIX-basierte Anwendungen für die Ausführung unter Windows Server 2003 R2 kompiliert werden können.

• Identity Management for UNIX (IDMU), das die Möglichkeit zur Integration von UNIX-Sicherheits- und Verzeichnisdiensten bietet. IDMU umfasst eine optionale Active Directory-Schemaaktualisierung, die die Schemaerweiterungen von NIS und Kerberos importiert.

• Microsoft Services for Network File System, die eine Reihe von Komponenten zum Freigeben von Dateien, zum Durchsetzen der Dateisicherheit sowie zum Verwalten der Datei- und Druckfreigabe zwischen UNIX- und Windows-Systemen umfassen.

Weitere Informationen finden Sie im Whitepater zur UNIX-Interoperabilität in Microsoft Windows Server 2003 R2 (in englischer Sprache).

Vintela Authentication Services

Vintela Inc. (nun im Besitz von Quest Software) ist ein Microsoft-Partner und unabhängiger Softwarehersteller, der seinen Schwerpunkt auf die UNIX-Integration in die Microsoft-Plattform gelegt hat. Vintela Authentication Services (VAS) integrieren Versionen der Betriebssysteme UNIX und Linux sowie die systemeigenen UNIX-Schnittstellen mithilfe des Kerberos-Protokolls und LDAP in Active Directory.

Weitere Informationen zu VAS finden Sie auf der Website von Vintela.

Integration von Novell NetWare

Microsoft Windows Services for NetWare (SFN) 5.02 bieten eine Gruppe von Dienstprogrammen für die Interoperabilität, die die Einführung von Windows Server 2003 und Active Directory in einer Novell NetWare-Netzwerkumgebung mit Novell Directory Service (NDS) erleichtern.

Weitere Informationen zu SFN finden Sie im Artikel zu Microsoft Windows Services for Netware 5.03 (in englischer Sprache).

Integration von Apple Macintosh

Microsoft Windows Server 2003 Services for Macintosh (SFM) ist eine vollständig integrierte Komponente von Windows Server 2003, die Computern, auf denen die Betriebssysteme Windows und Macintosh ausgeführt werden, die Freigabe von Dateien und Druckern ermöglicht. Nachdem SFM eingerichtet wurde, können diese Computer die Funktion eines Dateiservers, Remotezugriffsservers und Druckservers für Computer übernehmen, auf denen das Macintosh-Betriebssystem ausgeführt wird. Darüber hinaus kann Windows Server 2003 mit SFM die Funktionen eines AppleTalk-Routers übernehmen.

Weitere Informationen zu SFM finden Sie auf der Mactopia-Website von Microsoft auf der Seite Windows SFM 2000 (in englischer Sprache).

Integration von Mainframe-Betriebssystemen

Die Integration von Mainframe-Betriebssystemen wie OS/390 und z/OS von IBM in Windows-Verzeichnis- und Sicherheitsdienste ist auf verschiedene Weise möglich, z. B. wie folgt:

• Zuordnung von Anmeldeinformationen über Microsoft Host Integration Server

• Plattformintegration über das Kerberos-Protokoll

• Methoden zur Anwendungsintegration unter Verwendung von LDAP und GSS-API

HIS bietet eine Methode zur Zuordnung von Anmeldeinformationen (oder SSO für Unternehmen), bei der Active Directory indirekt in die Mainframeverzeichnisspeicher integriert wird. Weitere Informationen zu diesem Thema finden Sie im Abschnitt „Indirekte Integration durch Anmeldeinformationszuordnung“ weiter hinten in diesem Dokument.

IBM-Mainframecomputer mit aktualisierten Versionen von IBM SecureWay Security Server (der Resource Access Control Facility (RACF) umfasst) unterstützen das Kerberos-Protokoll, LDAP, SSL, GSS-API und andere Standards für die Zugriffsverwaltung, die im Artikel „Grundlegende Konzepte“ in dieser Serie beschrieben werden. Durch die Verwendung von Standards wie Kerberos ist es theoretisch möglich, RACF so auf einem Mainframecomputer zu konfigurieren, dass eine Zusammenarbeit mit der Microsoft-Implementierung eines Kerberos-KDC möglich ist.

Alternativ können Sie Anwendungen auf Mainframecomputern, die Standards wie LDAP und GSS-API verwenden, so konfigurieren oder migrieren, dass sie Windows-Verzeichnis- und Sicherheitsdienste verwenden.

Weitere Informationen zur Verwendung von RACF-Standards, die die Integration in Windows-Verzeichnis- und Sicherheitsdienste unterstützen, finden Sie in den folgenden Ressourcen.

• Im Artikel mit umfassenden aktuellen und flexiblen Informationen zur Sicherheit in z/OS: auf IBM.com

• Im Artikel zu SecureWay Security Server für z/OS und OS/390 auf IBM.com

• Im PDF-Dokument zu Fallstudien zur Interoperabilität von OS/390 Security Server (RACF) mit Windows 2000, das Sie von IBM.com herunterladen können

Integration von J2EE

J2EE ist eine Plattform für die Entwicklung von Anwendungen, die viele Kunden anstelle von oder zusätzlich zu Microsoft .NET Framework zum Entwickeln von Anwendungen verwenden. Mithilfe der folgenden Technologien können J2EE-Anwendungen in Windows-Verzeichnis- und Sicherheitsdienste integriert werden:

• Browser zu Webserver J2EE-Anwendungsserver wie z. B. Apache und BEA WebLogic unterstützen das Kerberos-Protokoll durch dynamisch austauschbare Authentifizierungsmodule, die als Open Source vom Hersteller oder von unabhängigen Softwareherstellern erhältlich sind.

• LDAP Eine beliebige J2EE-Anwendung, die eine Standard- oder formularbasierte Authentifizierung durchführt, kann Benutzeranmeldeinformationen mit einer LDAP-Bindung mit Active Directory vergleichen.

• Sicherheit bei Web Services WS-Security definiert mehrere Tokentypen, einschließlich der Token für das Kerberos-Protokoll und X.509, die eine Integration zwischen J2EE-Anwendungen und Windows-Sicherheitsdiensten ermöglichen.

Vintela

Vintela (nun im Besitz von Quest Software) hat JCSI Kerberos von Wedgetail in Vintela Single Sign-on for Java (VSJ) integriert. VSJ ist eine serverseitige Lösung, die die integrierte Windows-Authentifizierung auf Java-Anwendungsservern zulässt. Weitere Informationen zu Produkten von Vintela finden Sie auf der Vintela-Website.

Anwendungsintegration in Windows-Verzeichnisdienste.

Wenn eine systemeigene Integration zwischen Anwendungen und Windows-Sicherheitsdiensten nicht möglich ist, können Sie Anwendungen möglicherweise über Windows-Verzeichnisdienste oder mit einem Produkt, das den Funktionsumfang von Active Directory erweitert, in der Windows-Umgebung integrieren. Diese Lösung ist zwar vielleicht nicht ganz so elegant wie die weiter oben beschriebene vollständig integrierte Lösung, ist aber unter Umständen die einzige Möglichkeit für Plattformen und Anwendungen, die eine direkte Integration in Windows nicht unterstützen.

Für die Integration in Verzeichnisdienste reicht es möglicherweise aus, Anwendungen, Server oder Arbeitsstationen so zu konfigurieren, dass ein Active Directory-Dienst wie LDAP verwendet werden kann. In einigen Fällen müssen Anwendungen gegebenenfalls geändert werden, um eine vollständige Integration in Windows-Verzeichnisdienste zu ermöglichen. In anderen Fällen ist dagegen ein Anwendungsverzeichnis wie Active Directory-Anwendungsmodus (ADAM) erforderlich.

In den folgenden Abschnitten finden Sie Beispiele dafür, wie Anwendungen unter Verwendung von LDAP und ADAM in Windows-Verzeichnisdienste integriert werden.

Integration in LDAP

Active Directory ist mit LDAP 3.0 kompatibel, das durch RFC 3377 und andere RFCs definiert wird. Da viele andere, kommerziell erhältliche Verzeichnisdienste LDAP unterstützen (viele Anwendungen verwenden LDAP außerdem für den Zugriff auf diese Verzeichnisdienste), kann ein standardisiertes Protokoll wie LDAP eine Interoperabilität bei der Zugriffsverwaltung zwischen bestehenden Anwendungen von Drittanbietern oder intern entwickelten Anwendungen und Active Directory bieten.

Weitere Informationen zur Active Directory-Unterstützung für LDAP finden Sie im Artikel zur Kompatibilität von Active Directory und LDAP (in englischer Sprache)

LDAP kann die Integration der Authentifizierung und Autorisierung zwischen Active Directory und Anwendungen ermöglichen, die auf einem beliebigen Client- oder Serverbetriebssystem gehostet werden, das LDAP unterstützt. In dieser Rolle wird Active Directory zum Identitätsspeicher der Anwendung. In Allgemeinen können Anwendungen LDAP direkt über RFC 1823-kompatible APIs (Application Programming Interface) verwenden, die vom Betriebssystem, das als Host der Anwendung fungiert, bereitgestellt werden. Alternativ kann LDAP über Add-Ons wie Open LDAP, eine Open Source-LDAP-Bibliothek für die Betriebssysteme UNIX und Linux verwendet werden.

Entwickeln für LDAP

Der Schwerpunkt dieses Artikels liegt nicht auf der Anwendungsentwicklung, es muss jedoch darauf hingewiesen werden, dass bei der Integration in Active Directory über LDAP Änderungen an bestehenden Anwendungen nötig werden können. Einige dieser Änderungen haben beispielsweise folgende Gründe:

• Geringfügige Unterschiede bei LDAP-Implementierungen

• Eine komplexere Verzeichnisstruktur auf der Grundlage von Active Directory-Domänen und -Gesamtstrukturen

• Die Anforderung, die LDAP-Sicherheitsfeatures in der Windows-Plattform zu nutzen

Für Anwendungen auf Windows-basierten Clients und Servern, die nicht mit Windows-Sicherheitsdiensten abgestimmt werden können, stehen eine Reihe von APIs zur Verfügung, mit denen die Integration in Windows-Verzeichnisdienste erzielt werden kann. Active Directory unterstützt die folgenden Schnittstellen:

• Den mit RFC 1823 kompatiblen LDAP-Win32-API-Satz für C- und C++-Anwendungen

• Active Directory-Dienstschnittstellen (Active Directory Service Interfaces, ADSI) für Microsoft Visual Basic®-Anwendungen und VB-Skripts

• System.DirectoryServices für Anwendungen mit verwaltetem Code, die mit Microsoft Visual Studio .NET geschrieben wurden  

Weitere Informationen zum Verwenden dieser Programmierungsschnittstellen mit Active Directory finden Sie auf der Seite zur Verwendung von Active Directory im Abschnitt zu Plattform-SDK: Active Directory auf MSDN (in englischer Sprache).

Authentifizierung über LDAP

LDAP-Sitzungen beginnen in der Regel mit einem Bindungsvorgang. Dieser Bindungsvorgang kann entweder anonym erfolgen oder optional die Anmeldeinformationen des Benutzers enthalten, der eine Verbindung zum Verzeichnisdienst herstellen möchte. Da der Schwerpunkt dieses Abschnitts auf der Authentifizierung von Benutzern liegt, richtet sich der Fokus hier auf die authentifizierte Bindung.

Es gibt zwei Arten von authentifizierten Bindungsvorgängen: einfache Bindungen und komplexe Bindungen. Letztere verwenden ein vom Verzeichnisdienst unterstütztes Authentifizierungsprotokoll. Einfache Bindungen verwenden Nur-Text-Anmeldeinformationen zum Authentifizieren der Bindung und sollten aus diesem Grund mit Sorgfalt verwendet werden. LDAP unterstützt SSL, ein Protokoll, das für Anwendungen, die einfache Bindungen verwenden, als zwingend anzusehen ist. Die LDAP-Funktion, die SSL aktiviert, ist ldap_set_option() mit dem LDAP_OPT_SSL-Flag.

Weitere Informationen zur Verwendung von SSL zum Schützen von LDAP-Sitzungen finden Sie auf der Seite mit Beispielcode zum Einrichten einer Sitzung über SSL im Abschnitt zu Plattform-SDK: Lightweight Directory Access Protocol auf MSDN (in englischer Sprache).

In bestimmten Fällen sind einfache LDAP-Bindungen die beste Lösung. Beispiele hierfür sind Serveranwendungen, die zur Authentifizierung die Eingabe des Benutzernamens und Kennworts anfordern, darunter z. B. Webanwendungen, die eine formularbasierte Authentifizierung verwenden und das Nur-Text-Kennwort des Benutzers überprüfen müssen. Wenn die Anwendung so plattform- und verzeichnisneutral wie möglich sein soll, stellen einfache LDAP-Bindungen die richtige Methode dar.

Für Serveranwendungen, die unter Verwendung der eigenen Anmeldeinformationen eine Bindung zu Active Directory herstellen, um Informationen vom Verzeichnisdienst abzurufen, empfiehlt Microsoft, bei der Konfiguration des Servers einen der in der Dokumentation zur ldap_bind_s()-API aufgeführten Authentifizierungsmechanismen zu verwenden.

Hinweis   Bei LDAP-APIs, die mit einem „s“ enden (z. B. ldap_bind_s) handelt es sich um synchrone APIs. Das „s“ bedeutet nicht, dass für die Sitzung ein bestimmter Sicherheitstyp gilt. Dies kann zu Verwirrung führen, da nur synchrone Bindungen (d. h. ldap_bind_s) neben der einfachen Bindung weitere Authentifizierungsmechanismen unterstützen.

Komplexe LDAP-Bindungen werden über einen als SASL (Simple Authentication and Security Layer) bezeichneten Mechanismus erzielt. Die von Active Directory unterstützten SASL-Mechanismen umfassen die gleichen Authentifizierungsprotokolle, die bereits an anderen Stellen in dieser Serie dokumentiert wurden: das Kerberos 5- und NTLM-Protokoll (über das Sicherheitspaket Negotiate) sowie die Digestauthentifizierung. LDAP-Bindungen, die diese Mechanismen nutzen, verwenden die Standardanmeldeinformationen von Serveranwendungen. Die Speicherung einer Nur-Text-Version des Anwendungskennworts im Arbeitsspeicher ist somit überflüssig. Um diese Mechanismen zu verwenden, muss die Anwendung ldap_bind_s() mit dem LDAP_AUTH_NEGOTIATE- oder LDAP_AUTH_DIGEST-Flag aufrufen.

Wenn eine Anwendung mit einem beliebigen SASL-Mechanismus eine Sitzung mit Active Directory herstellt, kann sie außerdem angeben, dass alle zwischen dem LDAP-Client und -Server ausgetauschten Daten digital signiert oder verschlüsselt werden. Die Anwendung verwendet die ldap_set_option()-API entweder mit der Option LDAP_OPT_SIGN oder LDAP_OPT_ENCRYPT. Microsoft empfiehlt, alle Sitzungen, über die vertrauliche Daten oder sonstige zur Autorisierung verwendete Daten ausgetauscht werden, durch Sitzungsverschlüsselung zu schützen.

Autorisierung über LDAP

Neben der Authentifizierung fragen Anwendungen auch häufig Verzeichnisdienste ab, um Daten über Benutzer abzurufen, die zur Autorisierung verwendet werden. Folgende Attribute und Verzeichnisinformationen werden in vielen Fällen zur Autorisierung herangezogen:

• Sicherheitsgruppen

• Benutzerattribute wie Ort, Titel oder Vorgesetzter

• Hierarchische Informationen wie die Organisationseinheit oder die Abteilung

• Im Verzeichnis gespeicherte, unter Umständen anwendungsspezifische Kundenattribute wie z. B. „Platinkunde“

Anwendungen, die Verzeichnisdienste zur Autorisierung verwenden, bieten zahlreiche Möglichkeiten für den Zugriff auf Verzeichnisinformationen, und Entwickler treffen für die Implementierung manchmal eine ungünstige Wahl. Ein gängiges Problem besteht darin, dass die Anwendung Abfrageergebnisse nicht zwischenspeichert. Dies hat zur Folge, dass eine einzelne Anwendung einen erheblichen Teil der Last eines Verzeichnisses generieren kann. Entwickler müssen daher darauf achten, dass die Ergebnisse von Verzeichnisabfragen zwischengespeichert werden, wenn die Möglichkeit besteht, dass diese Informationen zu einem späteren Zeitpunkt erneut benötigt werden.

Hinweis   Einer der größten Vorteile der Anwendungsintegration in Windows-Sicherheitsdienste besteht darin, dass Windows-Authentifizierungsmechanismen Autorisierungsinformationen wie Sicherheitsgruppen während der Authentifizierungsfolge abrufen und zwischenspeichern. Der Windows-Autorisierungs-Manager nimmt bei der ursprünglichen Erstellung des Autorisierungskontexts ferner eine Zwischenspeicherung anderer rollenbasierter Autorisierungsinformationen vor. Nach der Zwischenspeicherung stehen Autorisierungsinformationen für die Dauer der authentifizierten Sitzung lokal zur Verfügung. Durch integrierte Cachemechanismen wird die Entwicklung effizienter Anwendungen erheblich erleichtert.

Ein weiteres bekanntes Problem besteht darin, dass Entwickler oft nicht wissen, wie effektive Suchvorgänge zu implementieren sind. Unzulängliche Suchvorgänge, die häufig wiederholt werden, wirken sich unnötig auf die Verzeichnisleistung und -verfügbarkeit aus. Weitere Informationen finden Sie auf der Seite zum Erstellen effizienterer Microsoft Active Directory-fähigen Anwendungen (in englischer Sprache) auf MSDN.

Integration in Windows-Verzeichnisdienste unter Verwendung von ADAM

Der Active Directory-Anwendungsmodus (ADAM) bietet eine zusätzliche Möglichkeit für die Integration in Windows-Verzeichnisdienste. ADAM ist eine eigenständige Version von Active Directory, die auf Computern mit Windows XP oder Windows Server 2003 als Benutzerdienst ausgeführt wird.

Microsoft empfiehlt jedoch, nach Möglichkeit Active Directory zu verwenden, um der Anforderung nach einer geringeren Anzahl von Identitätsspeichern in einer Umgebung nachzukommen. Active Directory hat gegenüber ADAM unter anderem folgende Vorteile:

• Reichhaltigere Authentifizierungsfeatures, einschließlich der Integration mithilfe des Kerberos 5-Protokolls (und die eingeschränkte Kerberos-Delegierung für Server mit n Ebenen), PKI (Public Key Infrastructure) und Microsoft Passport

• Ein Speicherort für alle Konten, um die Identitätsverwaltung zu erleichtern

• Konnektivität mit vielen Microsoft-Anwendungen (z. B. Microsoft SharePoint™ Portal Server und Microsoft Exchange Server), für die Benutzer ein Active Directory-Konto benötigen.

Es gibt jedoch mehrere gute Gründe, sich für ADAM zu entscheiden. Dazu zählen die im Folgenden erläuterten Punkte:

• Anwendungsmigration. Migrieren bestehender Anwendungen mit X.500-Benennung.

• Setup und Verwaltung. Entwickler können ADAM problemlos einrichten und verwalten.

• Isolierung von Sicherheit und Identität. ADAM-Prinzipale können sich nur unter Verwendung einer bestimmten Anwendung, die eine ADAM-Instanz verwendet, an einer Arbeitsstation oder einem Server anmelden oder auf eine bestimmte Netzwerkressource zugreifen.

• Personalisierungsdaten und Leistung. ADAM eignet sich gut für Personalisierungsdaten mit geringem Wert, die nicht von globalem Interesse sind. Daten und Attribute, die sich häufig ändern, können sich negativ auf die Leistung von Active Directory auswirken.

Weitere Informationen zu ADAM finden Sie auf der Seite zum Active Directory-Anwendungsmodus von Windows Server 2003 (in englischer Sprache).

Anwendungsmigration

Die LDAP-Authentifizierung in Active Directory erweist sich als besonders nützlich bei der Migration von Anwendungen aus einem anderen Verzeichnisdienst, der die Formatbenennungskontexte von X.500 unterstützt. Da Active Directory die Formatbenennung von X.500 nicht unterstützt, ist ADAM möglicherweise eine gute Wahl bei der Migration von codelosen Anwendungen in Microsoft-Verzeichnisdienste.

ADAM bietet ein als Umleitung von LDAP-Bindungen (manchmal auch als Bindungsproxy) bezeichnetes Feature, dass sich in dieser Art von Szenario anbietet. Die Bindungsumleitung lässt zu, dass das ADAM-„Schattenkonto“ eines Active Directory-Benutzers alle von der Anwendung benötigten Benutzerattribute, nicht jedoch das Benutzerkennwort enthält. Die Anwendung versucht, mithilfe der LDAP-Bindung eine Authentifizierung mit ADAM durchzuführen, doch ADAM leitet die Authentifizierungsanforderung an Active Directory weiter. Active Directory authentifiziert den Benutzer und gibt das Ergebnis an ADAM zurück. Dieses Feature ermöglicht die Migration eines wichtigen Benutzeraspekts (die Anmeldeinformationen für das Konto) in eine zentralisierte Active Directory-Identität, während anwendungsspezifische Verzeichnisinformationen in ADAM verbleiben.

Setup und Verwaltung

Bei der Entwicklung von verzeichnisfähigen Anwendungen müssen Programmierer möglicherweise Änderungen am Verzeichnisschema vornehmen. Entwickler sind jedoch aller Wahrscheinlichkeit nach keine Mitglieder der Gruppe der Active Directory-Schemaadministratoren und daher nicht zum Ändern von Schemas berechtigt. ADAM kann allerdings bei der Entwicklung eines Prototyps der vorgeschlagenen Schemaänderungen eingesetzt werden, bei der die Active Directory-Umgebung der Organisation nicht geändert werden muss.

Isolierung von Sicherheit und Identität

ADAM kann aus Sicherheitsgründen ferner als Identitätsspeicher für bestimmte Benutzertypen verwendet werden. Für Extranetanwendungen, die Dienste sowie Mitarbeiter und Partner für Kunden offen legen, stipuliert die Organisation möglicherweise, dass mit den für Kunden eingerichteten Konten nicht auf andere Anwendungen oder Ressourcen im Extranet zugegriffen werden kann. Wenn die Konten in Active Directory erstellt wurden, lässt sich diese Voraussetzung unter Umständen nur schwer erfüllen, da Active Directory-Konten normalerweise zum Herstellen von Verbindungen zu Diensten und Ressourcen in der externen Domäne verwendet werden. Kundenkonten könnten sehr strikt durch ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) und sonstige Richtlinieneinstellungen kontrolliert werden. Einige Organisationen bevorzugen allerdings eine ausdrückliche Trennung der Konten. Organisationen, bei denen diese Anforderung gilt, wählen daher eventuell ADAM als Identitätsspeicher für den Kunden.

Personalisierungsdaten und Leistung

In bestimmten Szenarios befürchtet eine Organisation vielleicht, dass die Migration einer Anwendung in Active Directory negative Auswirkungen auf ihren zentralen Verzeichnisdienst hat. Ursache hierfür ist möglicherweise die Notwendigkeit, große Mengen an anwendungsspezifischen, für andere Anwendungen nicht relevante „Personalisierungsdaten“ speichern zu müssen, weil sich die anwendungsspezifischen Daten häufig ändern oder die Anwendung die Verzeichnisdienste ineffizient nutzt. In diesen Fällen bietet sich die Verwendung von ADAM für die anwendungsspezifischen Daten an.

Indirekte Integration durch Anmeldeinformationszuordnung

Wenn die direkte Integration von Plattformen und Anwendungen mit Windows-Verzeichnis- und Sicherheitsdiensten nicht möglich ist, kann mit SSO für Unternehmen eine direkte Integration in Active Directory und andere Identitätsspeicher erzielt und Authentifizierung und Einmaliges Anmelden mithilfe von Diensten zur Zuordnung von Anmeldeinformationen bereitgestellt werden.

Viele Portal- und Middleware-Branchenanwendungen rufen Daten im Namen der Anwendungsbenutzer von Back-End-Systemen ab. Die Back-End-Systeme implementieren in der Regel ihre eigene Sicherheit und verfügen über eigene Identitätsspeicher. Normalerweise wurden die Sicherheitsmechanismen in den Back-End-Systemen nicht vollständig in Windows-Sicherheitsdienste integriert, sodass die Authentifizierung nicht von der Portal- oder Middlewareanwendung an das Back-End-System delegiert werden kann.

In einem typischen Szenario fordert das Portal den Benutzer auf, Anmeldeinformationen einzugeben, die zur Authentifizierung auf dem Back-End-System verwendet werden können. Weitere Aufforderungen zur Eingabe von Benutzeranmeldeinformationen beim Zugriff auf das Portal reduzieren in der Regel die Benutzerfreundlichkeit. Daher entscheiden sich viele Organisationen für die Einführung einer Technologie, mit der SSO möglich ist. Die gängigste Technologie zur Bereitstellung von SSO ist eine Form der Zuordnung von Anmeldeinformationen.

Wie die Zuordnung von Anmeldeinformationen funktioniert, wird am folgenden Beispiel veranschaulicht: Angenommen, Sie haben eine typische Anwendung der mittleren Ebene, die Daten von einem Back-End-System abruft. Das Back-End-System ist nicht in die Windows-Sicherheitsdienste integriert oder verfügt weiterhin über einen eigenen Identitätsspeicher. Damit Benutzer auf dieses Back-End-System zugreifen können, ohne zur Eingabe von Anmeldeinformationen aufgefordert zu werden, fordert die Anwendung der mittleren Ebene die notwendigen Anmeldeinformationen für das Back-End-System vom SSO-Dienst für Unternehmen ab. In diesem Beispiel wurden die Anmeldeinformationen der lokalen Benutzerin Mary einem Benutzer namens M2231 auf dem Back-End-System zugeordnet. Mary wird daraufhin der Zugriff auf eine bestimmte Ressource gewährt (siehe Abbildung 2.5).

Zu einer Variation der direkten Zuordnung kommt es, wenn Anmeldeinformationen zur Bildung einer Viele-zu-Eins-Zuordnung verwendet werden. In diesem Fall werden mehrere Benutzer einem einzelnen Satz an Anmeldeinformationen zugeordnet, die vom Back-End-System erkannt werden. In Abbildung 2.5 wurde Bob auf dem Back-End-System einem allgemeinen Anwendungsbenutzer zugeordnet.

Abbildung 2.5: Ein Beispiel für die Zuordnung von Anmeldeinformationen

Vor- und Nachteile der Zuordnung von Anmeldeinformationen

Das Modell zur Zuordnung von Anmeldeinformationen erweist sich als besonders gut geeignet, wenn in einer Organisation folgende Situationen auftreten:

• Heterogene Sicherheitsmodelle. Ihre Anwendung wird unter dem Betriebssystem Windows und mit IIS 6.0 als Anwendung der mittleren Ebene ausgeführt. Die aktuellen Back-End-Systeme verwenden sowohl SQL Server 2000 oder höher als auch Exchange 5.5 oder höher. Das Kerberos 5-Protokoll ist ausreichend, bis Sie ein drittes Back-End-System (z. B. DB2 auf OS/390) einführen. In diesem Fall müssen Sie die Windows-Anmeldeinformationen den RAFC-Anmeldeinformationen (Resource Access Control Facility) zuordnen, um auf die Back-End-Ressource zugreifen zu können.

• Verzögerte Verwendung von Anmeldeinformationen. Die Verwendung von Anmeldeinformationen zur Authentifizierung muss verzögert werden, nachdem Daten asynchron über Nachrichtenwarteschlangen, Service Broker oder Integrationsmodule weitergeleitet wurden.

Sie müssen die dadurch erzielten Vorteile allerdings an den folgenden Nachteilen messen.

• Risiko der Speicherung von Benutzernamen und Kennwörtern. Damit solche Systeme zur Zuordnung von Anmeldeinformationen funktionieren, benötigen Sie eine Datenbank mit Benutzernamen und Kennwörtern, die vor ihrer Verwendung verschlüsselt werden können. Sie können solche Datenbanken auf unterschiedliche Weise sichern, doch das Speichern von Kennwörtern, selbst wenn diese verschlüsselt sind, stellt ein Risiko dar. Wenn in Active Directory die Standardeinstellungen gelten, wird beispielsweise nie ein tatsächliches Kennwort gespeichert. Sie müssen die Risiken daher sorgfältig abwägen.

• Kennwortsynchronisierung. Eine Datenbank zur Zuordnung von Anmeldeinformationen bedeutet, dass einige Benutzeranmeldeinformationen entweder an zwei Orten verwaltet oder mit einem automatisierten Prozess synchronisiert werden. Dieser Faktor kann zu einer komplexeren Systemarchitektur oder erhöhtem Verwaltungsaufwand führen. Weitere Informationen finden Sie im Artikel „Kennwortverwaltung“ in dieser Serie.

Das Modell zur Zuordnung von Anmeldeinformationen in Microsoft-Produkten

Microsoft-Produkte zur Geschäftsintegration umfassen einen SSO-Dienst für Unternehmen, der die Speicherung und Zuordnung von Anmeldeinformationen bereitstellt, damit die Anwendungen Informationen aus Systemen für Unternehmensressourcenplanung (Enterprise Resource Planning, ERP), Systemen für Kundenbeziehungsmanagement (Customer Relationship Management, CRM) und Mainframe-basierten Anwendungen abrufen können.

Alle Anwendungen verwenden eine sichere Datenbank zum Speichern der Benutzeranmeldeinformationen und der Kontozuordnungsinformationen, die Active Directory-Konten mit Konten für Back-End-Anwendungen verknüpfen. Der SSO-Dienst für Unternehmen implementiert ferner einen sicheren Dienst zum Ausgeben und Austauschen von Tickets, den die Geschäftsintegrationsanwendung zum Abrufen von Daten aus der Back-End-Anwendung verwendet. Da der Benutzer beim Zugreifen auf die verschiedenen Anwendungen nur seine Active Directory-Anmeldeinformationen verwendet, profitiert er von der einmaligen Anmeldung.

Folgende Anwendungen nutzen den SSO-Dienst für Unternehmen von Microsoft:

• SharePoint Portal Server (SPS 2003)

• Microsoft BizTalk® Server 2004

• Host Integration Server 2004

Verwenden der SSO-Funktion für Unternehmen von SharePoint Portal Server

SharePoint Portal Server (SPS 2003) ermöglicht es Organisationen, ein intelligentes Portal zu entwickeln, mit dem Benutzer, Teams und Wissen verbunden werden, sodass Mitarbeiter geschäftsprozessübergreifende, relevante Informationen nutzen und effizienter arbeiten können.

SPS 2003 bietet eine Unternehmenslösung, von der Informationen aus unterschiedlichen Systemen in eine einzelne Webportallösung integriert wurden. Hierbei kommen SSO-Funktionen und Funktionen zur Integration von Unternehmensanwendungen sowie flexible Bereitstellungsoptionen und Verwaltungstools zum Einsatz. SPS 2003 trägt außerdem durch Speichern und Zuordnen von zugewiesenen Anmeldeinformationen zum Sichern von Unternehmensanwendungen bei, mit denen Kunden direkt über das Portal mit Unternehmensanwendungen interagieren können und dazu lediglich ihre Active Directory-Anmeldeinformationen benötigen.

Verwenden der SSO-Funktion für Unternehmen von BizTalk Server

BizTalk Server 2004 verbindet Systeme, Personen und Handelspartner mithilfe verwaltbarer Geschäftsprozesse. Diese Anwendung dient zur Integration verschiedener ERP-Produkte und ermöglicht Organisationen dadurch die Integration ihrer Geschäftsvorgänge und das Zusammenbringen von Lieferanten und Konsumenten. Sie bietet außerdem eine Reihe von Interoperabilitätsmechanismen, darunter insbesondere XML-Webdienste (Extensible Markup Language).

BizTalk Server verwendet eine ähnliche SSO-Datenbank zur Anmeldeinformationszuordnung für Unternehmen wie SPS 2003. In diesem Fall kann BizTalk 2004 für beliebige vom BizTalk Server-Orchestrierungsmodul definierte Verbindungen Authentifizierungsdetails bereitstellen.

Ein SSO-Szenario in BizTalk Server 2004 ähnelt einem SSO-Szenario in SPS, basiert allerdings möglicherweise nicht auf einem Portal. Der Benutzer wird im Betriebssystem Windows authentifiziert, und BizTalk Server 2004 verknüpft diese Authentifizierung dann mit seiner internen Anmeldeinformationsdatenbank. Wenn der Benutzer auf Informationen zugreifen muss, die bei einem Geschäftspartner gespeichert sind (z. B. Lagerbestände), ruft BizTalk Server 2004 die gespeicherten Anmeldeinformationen ab und präsentiert sie dem Fremdsystem.

In Bezug auf die Integration von SPS 2003 in BizTalk Server und SSO empfiehlt es sich, der SSO-Version von BizTalk Server den Vorzug vor der SSO-Version von SPS zu geben. Dies bedeutet, dass die Webteile von SPS den Adapter für Webdienste in BizTalk Server aufrufen und sicherstellen müssen, dass der BizTalk-Adapter für Webdienste beim Empfangen der Anforderung im Kontext des Endbenutzers ausgeführt wird, der ihn gestartet hat. Aus diesem Grund muss sich der Adapter für Webdienste auf dem gleichen Computer befinden wie der Webteil. Sie können stattdessen auch eine eingeschränkte Delegierung für Remotecomputerszenarios einrichten. Der Adapter für Webdienste verwendet den IssueTicket-Aufruf mit SSO für Unternehmen, der Back-End-Adapter den ValidateAndRedeemTicket-Aufruf.

Verwenden von Host Integration Server für SSO für Unternehmen

In Kundenumgebungen werden Mainframe- und andere hostbasierte Systeme fast nie zusammen mit den Active Directory-Anmeldeinformationen des Benutzers eingesetzt. Zwar planen viele Organisation auf lange Sicht hostbasierte Systeme mit Standardprotokollen wie Kerberos Version 5 in Active Directory zu integrieren, die Umsetzung dieses Plans ist jedoch sehr zeitaufwändig. Host Integration Server 2004 bietet Funktionen zur Verwaltung von Anmeldeinformationen, die Benutzern SSO-ähnliche Funktionen zur Verfügung stellen.

Diese Anwendung bietet die nächste Version der von BizTalk Server 2004 bereitgestellten SSO-Datenbank zur Anmeldeinformationszuordnung für Unternehmen. Diese Datenbank stellt die SSO-Funktionen in Host Integration Server mithilfe der Emulatoren 3270 und 5250 bereit, sodass sich authentifizierte Windows-Benutzer automatisch an einem Mainframe- oder AS/400-System anmelden können, ohne weitere Anmeldeinformationen einzugeben. Darüber hinaus ermöglichen die Anwendungs- und Datenintegrationsfunktionen den in Host Integration Server authentifizierten Windows-Benutzern den Zugriff auf CICS- (Customer Information Control System) und IMS-Subsysteme (Information Management System) oder DB2 ebenfalls ohne die Angabe weiterer Anmeldeinformationen.

An einem Szenario mit Host Integration Server könnte beispielsweise ein Broker bei einer Handelsbank beteiligt sein. Der Broker meldet sich an, wird im Betriebssystem Windows authentifiziert und startet eine auf Microsoft .NET Framework basierende Handelsanwendung. Damit ein Handel verarbeitet werden kann, benötigt er den aktuellen Handelssaldo des Kunden, den die Bank auf einem Legacy-Mainframecomputer speichert. Host Integration Server 2004 leitet die Anmeldeinformationen mithilfe seiner Datenbank zur Anmeldeinformationszuordnung an den Mainframe weiter, damit der Broker Abfragen zum Kunden ausführen kann.

ISV-Produkte für SSO für Unternehmen

SSO für Unternehmen ist ein weiterer Technologiebereich, der von einer robusten Entwicklung des ISV-Markts profitiert hat. Im Gegensatz zur Microsoft-Technologie für SSO für Unternehmen bieten diese ISV-Produkte in der Regel einen zentralisierten, für Anmeldeinformationen und Zuordnungen auf Active Directory basierenden Speichermechanismus sowie einen API-Satz, mit dem Anwendungen die Funktionen von SSO für Unternehmen realisieren können. Folgende Hersteller entwickeln SSO-Produkte für Unternehmen:

• Passlogix

• Proginet

• ActivIdentity

• Version3

Synchronisierte Konten und Kennwörter

Das direkte Integrieren von Plattformen und Anwendungen in gängige Verzeichnis- und Sicherheitsdienste mit einer Strategie, bei der die Plattforminteroperabilität, Anwendungsmigration und Infrastrukturkonsolidierung berücksichtigt wird, kann erhebliche Vorteile mit sich bringen. Wenn eine direkte oder indirekte Integration wie weiter oben besprochen nicht möglich ist, kann durch Integrieren der zugrunde liegenden Identitätsspeicher doch zumindest ein gewisser Teil der Vorteile realisiert werden.

Die Konto- und Kennwortsynchronisierung ist eine Fallbackmethode, mit der eine reduzierte Anmeldung erzielt werden kann, wenn alle anderen Methoden fehlschlagen, sich als zu schwierig erweisen oder zu kostspielig sind. Mit dieser Methode wird keine echte SSO-Funktionalität geboten, sie reduziert jedoch die Anzahl von Benutzernamen und Kennwörtern, die sich ein Benutzer merken muss.

Bei der Kennwortsynchronisierung wird in der Regel davon ausgegangen, dass mehrere Identitätsspeicher identische Benutzerkonten und Kennwörter enthalten. Jeder Benutzer meldet sich mit der gleichen Kombination aus Benutzername und Kennwort beim Client, bei anderen Plattformen, Anwendungen und Intranetwebsites an.

Hinweis   Die Kennwortsynchronisierung sollte erst umgesetzt werden, nachdem alle Sicherheitsmerkmale und -risiken, die beim Speichern und Verwenden der gleichen Kennwörter in mehreren Systemen abgewägt wurden.

Weitere Informationen zum Synchronisieren digitaler Identitäten über mehrere Identitätsspeicher finden Sie im Artikel „Identitätszusammenfassung und -synchronisierung“ in dieser Serie.

Im Artikel „Kennwortverwaltung“ in dieser Serie wird ausführlicher auf die Methoden und Probleme bei der Verwendung der Kennwortsynchronisierung zur Bereitstellung der Intranetzugriffsverwaltung eingegangen. Dort erfahren Sie außerdem, wie Sie die Kennwortpropagierung von einer Active Directory-Gesamtstruktur in anderen Active Directory-Gesamtstrukturen, Identitätsspeichern von Anwendungen und Verzeichnisdiensten für andere Plattformen implementieren können.

In diesem Beitrag

• Kapitel 1: Einführung
• Kapitel 2: Methoden der Intranetzugriffsverwaltung
• Kapitel 3: Probleme und Anforderungen
• Kapitel 4: Entwickeln einer Lösung
• Kapitel 5: Implementieren der Lösung
• Kapitel 6: Testen der Lösung
• Kapitel 7: Operative Überlegungen
• 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).

2 von 9