Intranetzugriffsverwaltung und Single Sign-On

Artikel
03/19/2009

Kapitel 4: Entwickeln einer Lösung

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

Im vorherigen Kapitel wurden die geschäftlichen, technologischen und sicherheitsrelevanten Aspekte zweier Szenarios für die Intranetzugriffsverwaltung behandelt und die Lösungsanforderungen für beide Fälle angegeben. Der nächste Schritt im Gesamtprozess ist die Entwicklung einer passenden Lösung.

In den folgenden Abschnitten in diesem Kapitel werden ein Lösungskonzept und die Lösungsanforderungen für die einzelnen Szenarios zur Intranetzugriffsverwaltung vorgestellt. Nach der abschließenden Behandlung des Entwurfs wird in den nachfolgenden Kapiteln beschrieben, wie die jeweiligen Lösungen funktionieren.

Auf dieser Seite

Integrieren von UNIX-Arbeitsstationen in Active Directory
Integrieren der SAP R/3 Application Server-Authentifizierung über das Kerberos-Protokoll

Integrieren von UNIX-Arbeitsstationen in Active Directory

Die Integration von UNIX-Arbeitsstationen in die Microsoft Identitäts- und Zugriffsverwaltungsplattform über das Kerberos 5-Authentifizierungsprotokoll beinhaltet den Transfer von einer Umgebung mit Netzwerkinformationsdienst (Network Information Service, NIS) zu einer Umgebung, die auf dem Microsoft® Active Directory®-Verzeichnisdienst basiert. Eine Active Directory-Umgebung kann sowohl Authentifizierungs- als auch Autorisierungsdienste für UNIX-Arbeitsstationen bieten, wodurch die Anforderung von Contoso nach einer zentralisierten Verwaltung von Benutzerkonten im Intranetverzeichnis erfüllt wird.

Lösungskonzept

Eine Analyse der gemeinsamen Sicherheitsfunktionen von Active Directory und den Solaris 9-Arbeitsstationen bei Contoso ergab, dass das Kerberos 5-Protokoll die ideale Technologie zur Integration der UNIX-Arbeitsstationen des Unternehmens in die Microsoft-Identitäts- und Zugriffsverwaltungsplattform ist.

Die Lösung wird in folgenden Einzelschritten implementiert:

Änderung der Datei pam.conf auf der UNIX-Arbeitsstation, sodass Kerberos bei der Anmeldung und Authentifizierung bei Standard-UNIX-Anwendungen wie Telnet und File Transfer Protocol (FTP) verwendet wird.
Konfiguration der Datei krb5.conf, sodass das Windows®-basierte Schlüsselverteilungscenter der Contoso-Domäne von den UNIX-Arbeitsstationen eingesetzt wird.

In Abbildung 4.1 wird ein Diagramm des Lösungskonzepts dargestellt.

Abbildung 4.1 Das Lösungskonzept für eine Integration der UNIX-Arbeitsstationen in Active Directory mithilfe des Kerberos 5-Protokolls

Abbildung 4.1 Das Lösungskonzept für eine Integration der UNIX-Arbeitsstationen in Active Directory mithilfe des Kerberos 5-Protokolls

Die Lösung wird durch Konfigurieren der Solaris-Arbeitsstationen und Active Directory implementiert.

Lösungsvoraussetzungen

Contoso setzt, wie im Artikel „Plattform und Infrastruktur“ dieser Serie beschrieben, Active Directory für das Intranet ein.

Diese Lösung wird durch die Änderung von UNIX-Konfigurationseinstellungen möglich. Die bestehende Contoso-Netzwerkarchitektur wird nicht verändert, und es wird nichts hinzugefügt. Daher wird hier kein Diagramm der Lösungsarchitektur für dieses Szenario gezeigt.

Wie die Lösung funktioniert

Nachdem die Lösung, wie in den Kapiteln 5 und 6 „Implementieren der Lösung“ und „Testen der Lösung“ beschrieben, implementiert und getestet wurde, können sich Benutzer von UNIX-Arbeitsstationen bei der Shell der UNIX-Arbeitsstation mit ihrem Active Directory-Benutzernamen und ihren Active Directory-Anmeldeinformationen anmelden. Die Anmeldungsanfrage wird von der Shell an das Pluggable Authentication Module (PAM) und schließlich an die Kerberos-Bibliothek weitergegeben, die einen Austausch von Meldungen zwischen der Arbeitsstation und dem Windows-Schlüsselverteilungscenter beginnt (Schritte 1 bis 4 in Abbildung 4.2). Das Endergebnis dieses Austauschs ist ein Kerberos-Serviceticket, das die Kerberos-Bibliothek auf der UNIX-Arbeitsstation mit ihren eigenen Schlüsseln entschlüsseln kann. Dieser Prozess wird in Abbildung 4.2 dargestellt.

Dd443709.intr4-2(de-de,TechNet.10).gif

Abbildung 4.2 Eine UNIX-Arbeitsstation, die das Kerberos-Protokoll zur Authentifizierung bei Active Directory nutzt

Abbildung vergrößern

Die Kerberos-Bibliothek auf dem UNIX-System entschlüsselt dieses Ticket und erkennt den Benutzerprinzipalnamen (User Principal Name, UPN) des authentifizierten Benutzers. Nach der Authentifizierung werden vom Anmeldeprozess die Standard-UNIX-APIs (Application Programming Interfaces) dazu verwendet, die Autorisierungsinformationen abzurufen. Diese APIs werden durch den Namenserviceschalter (Name Service Switch, NSS) geleitet, der dann über das Modul nss_ldap eine Verbindung mit Active Directory herstellt und die angeforderten Informationen, wie die Benutzeridentifikation (UID) und die Gruppenidentifikation (GID), abruft. Schließlich verwendet der Anmeldeprozess diese Informationen, um den Sicherheitskontext des Benutzers zu erstellen. In diesem Sicherheitskontext wird die Anmeldeshell gestartet.

Die Kerberos-Bibliothek verarbeitet auch Fehler- und Statusmeldungen vom Schlüsselverteilungscenter, die Anforderungen der Kontenrichtlinien vermitteln, wie z. B. die Benutzeraufforderung zur Änderung des Kennworts. Der Anmeldeprozess initiiert dann über das PAM die erforderlichen Aktionen zur Einhaltung der Richtlinien.

Als Ergebnis der in Active Directory integrierten Authentifizierung beim Schlüsselverteilungscenter werden die Kerberos-Tickets für den Benutzer (durch PAM und die Kerberos-Bibliothek) auf der Arbeitsstation zwischengespeichert. Durch den Ticket-Cache ist es dem Benutzer möglich, nach nur einmaliger Anmeldung sicher auf mehrere Kerberos-aktivierte Anwendungen im Netzwerk zuzugreifen.

Wenn der Active Directory-Benutzer vorher ein UNIX-Konto auf einer UNIX-Arbeitsstation mit demselben Namen wie das Active Directory-Konto verwendet hat, sind die UNIX-Konteninformationen dieses Benutzers, einschließlich des Kennworts, möglicherweise noch in der Datei /etc/shadow vorhanden. Die Datei /etc/shadow kann bearbeitet werden, um die Kennwortinformationen des Benutzers zu entfernen, da diese für die Anmeldung bei der UNIX-Arbeitsstation nicht mehr nötig sind.

Weitere Details über den Kerberos-Ticketaustausch, der während der Anmeldung durchgeführt wird, finden Sie im Microsoft Systems Journal-Artikel Exploring Kerberos, the Protocol for Distributed Security in Windows 2000 (in englischer Sprache) auf MSDN.

Erweitern der Lösung

Um die funktionellen Anforderungen aus Kapitel 3, „Probleme und Anforderungen“, zu erfüllen, sollten die Attribute des UNIX-Benutzerkontos wie „uid“ und „gid“ in Active Directory anstatt auf der UNIX-Arbeitsstation gepflegt werden. Deshalb wrd bei Contoso die Active Directory-Schemaerweiterung installiert, die mit den UNIX-Services geliefert wird.

Damit die UNIX-Arbeitsstation diese Autorisierungsattribute abrufen kann, wird der NSS auf der UNIX-Arbeitsstation für die Nutzung von LDAP und Active Directory konfiguriert.

Weitere Informationen zur Installation der Microsoft Services für UNIX (SFU)-Schemaerweiterung für Active Directory und der Konfiguration von NSS zur Nutzung von LDAP können Sie im Microsoft Lösungshandbuch für Windows-Sicherheit und Verzeichnisdienste für UNIX (in englischer Sprache) finden.

Integrieren der SAP R/3 Application Server-Authentifizierung über das Kerberos-Protokoll

Die Contoso-Lösung für die Integration von SAP in die Microsoft Identitäts- und Zugriffsverwaltungsplattform beinhaltet die Neukonfiguration des SAP-Anwendungsservers und der grafischen Benutzeroberfläche des SAP-Clients (GUI), sodass SNC (Secure Network Communication) und das Kerberos-Protokoll verwendet werden. Dieser Ansatz bietet eine leistungsfähige Authentifizierung und eine sichere Übermittlung von Anwendungsdaten über das Netzwerk.

Weitere Informationen über die SNC-Funktionalitäten von SAP R/3 finden Sie auf der Seite SAP Partners Integration & Certification: Integration scenarios (in englischer Sprache).

Lösungskonzept

Eine Analyse der gemeinsamen Sicherheitsfunktionen von Active Directory und des SAP-Anwendungsservers ergab, dass das Kerberos 5-Protokoll aus folgenden Gründen die ideale Technologie für den Integrationsprozess und die Erhöhung der Sicherheit ist.

Das Kerberos-Protokoll ist ein standardbasiertes Protokoll, das in Windows-Client- und -Serverprodukten, Active Directory und im SAP R/3-Anwendungsserver enthalten ist.
Dieses Protokoll gibt an, dass die ticketgewährenden Tickets (Ticket granting tickets, TGT), die während der Anmeldung entstehen, an das Windows-Schlüsselverteilungscenter weitergegeben werden, um ein Service-Ticket zu erstellen. Das Service-Ticket führt dann die Authentifizierung bei Netzwerkressourcen und -anwendungen wie dem SAP R/3-Anwendungsserver durch. Dieser Prozess ist für den Benutzer transparent und ermöglicht Einfaches Anmelden (SSO).
Das Kerberos-Protokoll beinhaltet die Erstellung und gemeinsame Nutzung von Client-/Server-Sitzungsschlüsseln, die eine leistungsfähige Verschlüsselung von nachfolgend zwischen Client und Server übertragenen Anwendungsdaten garantieren.

Die Konfiguration des SAP R/3-Anwendungsservers und der grafischen Benutzeroberfläche des SAP-Clients zur Nutzung von SNC und des Kerberos-Authentifizierungsprotokolls bietet eine sichere Benutzerauthentifizierung bei gleichzeitigem Schutz der SAP-Anwendungsdaten im Netzwerk.

Zusätzlich müssen sich SAP-Benutzer aufgrund der Kerberos-Authentifizierung durch SAP nur noch einmal mit ihren Active Directory-Netzwerkanmeldeinformationen beim SAP-System anmelden. Da durch diese Lösung ein separates SAP-Kennwort unnötig wird, wird die Kennwortverwaltung einschließlich der Helpdeskkosten bedeutend verringert. In Abbildung 4.3 wird das Lösungskonzept für dieses Szenario dargestellt.

Abbildung 4.3 Integrieren der SAP R/3 Application Server-Authentifizierung über das Kerberos 5-Protokoll

Abbildung 4.3 Integrieren der SAP R/3 Application Server-Authentifizierung über das Kerberos 5-Protokoll

Lösungsvoraussetzungen

Contoso setzt Active Directory für das Intranet ein, wie es im Artikel „Plattform und Infrastruktur“ dieser Serie beschrieben wird.

Wie die Lösung funktioniert

Nachdem die Lösung, wie in den Kapiteln 5 und 6 „Implementieren der Lösung“ und „Testen der Lösung“ beschrieben, implementiert und getestet wurde, können sich Benutzer des SAP R/3-Anwendungsservers bei ihrer Windows-Arbeitsstation mit ihren Active Directory-Anmeldeinformationen anmelden. Der Benutzer startet dann vom Desktop die grafische SAP-Benutzeroberfläche und wählt die Option zur Anmeldung über das Kerberos-Protokoll. Die grafische SAP-Benutzeroberfläche fordert mit den im SAP-Profil gespeicherten Konfigurationsinformationen über den GSS-API-Wrapper (Generic Security Service-API-Wrapper) für das Kerberos-Authentifizierungspaket ein Kerberos-Service-Ticket für den SAP R/3-Anwendungsserver an (Schritt 1). Das Kerberos-Authentifizierungspaket fordert nötigenfalls ein neues Ticket vom Domänencontroller an oder ruft ein vorhandenes Ticket aus dem Ticket-Cache ab (Schritt 2). Die grafische SAP-Benutzeroberfläche stellt dann eine Verbindung mit dem SAP R/3-Anwendungsserver her und meldet auf Anfrage das Ticket (Schritt 3). In Abbildung 4.4 wird der Ablauf dieser Schritte im Betrieb dargestellt.

Dd443709.intr4-4(de-de,TechNet.10).gif

Abbildung 4.4 Authentifizierung eines Windows-Clients beim SAP-Anwendungsserver

Abbildung vergrößern

Der SAP R/3-Anwendungsserver nimmt das Service-Ticket in Empfang und prüft es, indem er mit dem GSS-API-Wrapper das Kerberos-Authentifizierungspaket auf dem Server aufruft (Schritt 4). Ist das Ticket gültig, wird der Benutzerprinzipalname vom Server extrahiert, und diese Information werden einem Konto zugewiesen, das vom SAP R/3-Anwendungsserver verwaltet wird (Schritt 5). Der Benutzer ist dann durch die Nutzung des SAP-verwalteten Kontos beim SAP-Anwendungsserver angemeldet, und eine verschlüsselte Sitzung für Anwendungsdaten wird zwischen dem Client und dem Server hergestellt (Schritt 6).

Da der Benutzer sich mit seinen Standard-Kerberos-Anmeldeinformationen beim SAP R/3-Anwendungsserver authentifiziert hat, ist SSO abgeschlossen, und es ist kein weiteres Anmelden nötig.

Erweitern der Lösung

Diese Lösung beschreibt, wie jedes SAP-Konto manuell dafür konfiguriert wird, mit dem Kerberos-Protokoll ein Active Directory-Konto zur Authentifizierung zu nutzen. Diese Lösung ist für Unternehmen sinnvoll, in denen nur eine begrenzte Anzahl Benutzer direkt auf SAP zugreift, zum Beispiel eine Personalabteilung durchschnittlicher Größe.

In Umgebungen mit vielen SAP-Nutzern ist ein höher automatisierter Bereitstellungs- und Synchronisierungsprozess zur Verwaltung der SAP-Konten (einschließlich der Zuweisung der Active Directory-Konten) vorzuziehen. Solch eine Lösung könnte durch den Einsatz von Microsoft Identity Integration Server 2003 Enterprise Edition mit Service Pack 1 (MIIS 2003 mit SP1) realisiert werden.

Hinweis Das Design könnte auch erweitert werden, um UNIX-Arbeitsstationen, die das Kerberos 5-Protokoll zur Authentifizierung beim SAP R/3-Anwendungsserver nutzen, einzuschließen. Bei Contoso verhindern einige Punkte jedoch den sofortigen Einsatz einer solchen Lösung. Der Hauptgrund, warum Contoso diese Lösung zurzeit nicht implementiert, besteht darin, dass SAP nur wenige Implementierungen der GSS-API-Bibliothek für die UNIX-Plattform unterstützt. Wenn die Liste der mit SAP kompatiblen GSS-API-Bibliotheken um eine bei Contoso eingesetzte Version erweitert wird oder das Unternehmen sich für eine andere Version entscheidet, die von SAP unterstützt wird, wird diese Projektphase gestartet.