Kerberos ist ein Netzwerkprotokoll, das zur Authentifizierung eines Benutzers oder eines Systems verwendet wird, um zu überprüfen, ob der Benutzer bzw. das System die Identität hat, die es vorgibt zu haben. Der Authentifizierungsmechanismus basiert auf sogenannten Tickets. Wenn ein Benutzer oder System von einem Kerberos-System authentifiziert wurde, können andere Systeme, z. B. der ConSol CM-Server, dieser Authentifizierung vertrauen und dem Benutzer bzw. System Zugriff auf die eigenen Ressourcen gewähren. Einer der Vorteile der Verwendung von Kerberos ist, dass keine Passwörter (verschlüsselt oder im Klartext) über das Netzwerk gesendet werden. Es werden nur Informationen, die mit dem Passwort verschlüsselt wurden, gesendet. Sobald er authentifiziert ist, hat ein Client Zugriff auf alle Ressourcen innerhalb der Kerberos-Domäne (Realm), ohne sich erneut anmelden zu müssen (Single Single Sign-On, SSO).
Die aktuelle Version von Kerberos ist V5, sie wurde zuerst 1993 entwickelt. Wenn Sie sich genauer in das Thema einarbeiten möchten, können Sie RFC 1510 (initialer RFC) oder RFC 4120 (V5) lesen.
Folgende Komponenten sind in einer Kerberos-Infrastruktur wichtig:
Das Key Distribution Center, das zwei aktive Komponenten enthält:
Die Single Sign-On-Funktion ermöglicht es, die Benutzer automatisch in ConSol CM zu authentifizieren, z. B. mit ihren Windows-Anmeldeinformationen.
Diese Authentifizierungsmethode ...
Die Single-Sign-On-Funktion basiert auf dem Protokoll Kerberos V5, das in Windows Active Directory integriert ist.
Der ConSol CM-Server fungiert als Nicht-Windows-Kerberos-Dienst und kann auf einem beliebigen Betriebssystem / Application Server installiert werden.
Der ConSol CM-Server ist Teil einer Windows-Domäne, in der das Key Distribution Center der Domänen-Controller ist, und in der Active Directory ausgeführt wird, um die Informationen zur Benutzerauthentifizierung zu speichern.
Die folgende Abbildung zeigt eine (vereinfachte) Übersicht über die Schritte, die erforderlich sind, um eine gültige Client/Server-Session für einen ConSol CM-Client und den entsprechenden ConSol CM-Server bereitzustellen. Die Erklärungen in diesen Abschnitten führen Sie durch den gesamten Konfigurationsprozess, der notwendig ist, um ConSol CM mit Kerberos-Authentifizierung zu betreiben.
Abbildung 442: Kerberos-Authentifizierung in einer Windows-Domäne für den Zugang von ConSol CM
Der Benutzer meldet sich an seinem PC/Laptop mit dem Benutzernamen und Passwort an. Der PC/Laptop sendet eine Nachricht an den Authentifizierungsserver und fordert ein Ticket Granting Ticket (TGT) an.
Sofern die Präauthentifizierung aktiviert wurde, wird ein Zeitstempel mit dem Hash des Benutzerpassworts als Verschlüsselungsschlüssel verschlüsselt. Wenn der Authentifizierungsserver eine gültige Zeit erkennt, wenn er den Zeitstempel mit dem (in Active Directory gespeicherten) Hash des Benutzerpassworts entschlüsselt, weiß er, dass die Anforderung keine Erneuerung einer vorherigen Anforderung ist.
In diesem Beispiel ist die Präauthentifizierung deaktiviert.
Der Autorisierungsserver überprüft die Zugriffsrechte des Benutzers in Active Directory und AD stellt das Passwort des Benutzers für Schritt 3 zur Verfügung.
Der Authentication Service erstellt ein Ticket Granting Ticket (TGT) und einen Sitzungsschlüssel. Diese werden in einer Nachricht an den Client gesendet und sind mit einem aus dem Benutzerpasswort abgeleiteten Schlüssel verschlüsselt.
Der PC/Laptop fragt den Benutzer nach einem Passwort und verwendet dieses Passwort, um die eingehende Nachricht zu entschlüsseln. Wenn die Entschlüsselung erfolgreich ist, kann der Benutzer mit dem TGT ein Service Ticket anfordern.
Schritt 3a. Das TGT wird während seiner Gültigkeitsdauer für den Benutzer gespeichert und kann während dieses Zeitraums für alle Anforderungen von Service Tickets verwendet werden.
Wenn ein Benutzer Zugang zu einem Dienst haben möchte, d. h. wenn sich ein Bearbeiter in ConSol CM anmelden möchte, sendet die Client-Applikation seiner Workstation (ConSol CM Web Client) eine Anforderung an den Ticket Granting Service, die den SPN (Service Principal Name, Dienstprinzipalname) des angefragten Dienstes, den Client-Namen, den Realm-/Domänennamen und einen Zeitstempel (mit dem Sitzungsschlüssel verschlüsselter Name und Zeitstempel) enthält. Der Benutzer weist sich durch Senden des in Schritt 3 erhaltenen Authentikators (TGT) aus.
Der Ticket Granting Service entschlüsselt das Ticket und den Authentifikator, überprüft die Anforderung und erstellt ein Service Ticket für den angefragten Dienst (SPN = ConSol CM). Das Service Ticket enthält den Namen des Benutzers (Bearbeiters). Es enthält auch den Realm-/Domänennamen und die Gültigkeitsdauer des Service Tickets. Das Service Ticket wird mit dem geheimen Schlüssel des Dienstes (CM) verschlüsselt. Der Ticket Granting Service sendet das Service Ticket an den Benutzer.
Schritt 5a. Das Service Ticket wird während seiner Gültigkeitsdauer für den Benutzer gespeichert und kann während dieses Zeitraums für alle Anforderungen an den SPN verwendet werden.
Die Client-Applikation (CM Web Client) sendet jetzt eine Dienstanforderung, die das in Schritt 5 erhaltenen Ticket und einen Authentifikator enthält, an den CM-Server. Der Dienst (CM-Server) authentifiziert die Anforderung durch Entschlüsseln des Sitzungsschlüssels. Der CM-Server überprüft, dass das Service Ticket und der Authentifikator übereinstimmen und gewährt dann Zugang zum Dienst (ConSol CM-Applikation).
Die Client/Server-Session läuft.
Normalerweise wird Kerberos mit symmetrischer Verschlüsselung ausgeführt (d. h. derselbe Schlüssel wird zum Verschlüsseln und zum Entschlüsseln der Nachricht verwendet). In Kerberos basiert die Verschlüsselung auf dem Passwort des Benutzers. Optional kann in einer Kerberos-Umgebung Kryptographie mit öffentlichen Schlüsseln eingesetzt werden.
Microsoft Windows verwendet Kerberos als Standardauthentifizierungsmethode mit RC4 für die Verschlüsselung und HMAC (Hash-based Message Authentication Code).
Ein Kerberos-Prinzipal ist eine eindeutige Identität, der Kerberos Tickets zuweisen kann. Dies kann ein Benutzerkonto einer Person oder eines Systems sein. Kerberos-Prinzipale bestehen aus mehreren Komponenten. Die Komponenten sind durch ein Trennzeichen voneinander getrennt, normalerweise "/". Die letzte Komponente ist der Realm/Domäne, der vom Rest des Prinzipals durch das Realm-/Domänen-Trennzeichen, normalerweise "@", getrennt ist. Wenn der Kerberos-Prinzipal keinen Realm/Domäne enthält, wird angenommen, dass der Prinzipal zum Standard-Realm/-Domäne für die aktuelle Umgebung gehört.
Normalerweise besteht ein Kerberos-Prinzipal aus drei Teilen: Primary, Instanz und Realm/Domäne. Das Format eines typischen Kerberos V5-Prinzipals ist primary/instanz@REALM.
Eine keytab-Datei ist eine Datei, die Paare von Kerberos-Prinzipalen und die entsprechenden verschlüsselten Schlüssel (die aus dem Kerberos-Passwort abgeleitet sind) enthält. Wenn ein Passwort geändert wird, müssen Sie die keytab-Datei neu bauen. Im Kontext von ConSol CM tritt dies ein, wenn das Passwort des Systembenutzers (in unserem Beispiel tomcat) geändert wurde, nicht wenn ein CM-Bearbeiter sein Passwort geändert hat.
Für auf Kerberos basierendes Single Single Sign-On in ConSol CM benötigen Sie:
Da in einer Kerberos-Umgebung Zeitstempel verwendet werden, um die Gültigkeitsdauer der Tickets zu berechnen und zu überprüfen, ist es unbedingt notwendig, dass alle Komponenten mit der gleichen Systemzeit arbeiten! Es kann zum Beispiel ein auf NTP basierender Zeitserver/-dienst verwendet werden. (Einige Win DCs lassen maximal eine Differenz von fünf Minuten zu.)
Um als CM-Bearbeiter mit SSO arbeiten zu können, muss der entsprechende CM-Server zu einer Windows-Domäne gehören. Der Domänen-Controller fungiert als Kerberos Key Distribution Center (KDC) und die Benutzer-/Kontonamen werden in Active Directory verwaltet. Deshalb müssen Sie
ConSol CM muss als Kerberos-Dienst registriert sein, sodass Kerberos Service Tickets für Benutzer, die mit CM arbeiten möchten, erstellt werden können. Deshalb muss CM bei Kerberos registriert sein. Da CM unter einem bestimmten Systembenutzer ausgeführt wird (in unserem Beispiel tomcat), muss dieser Systembenutzer für den entsprechenden Rechner registriert sein. Deshalb müssen Sie
Da nicht der Systembenutzer (tomcat), sondern die CM-Bearbeiter mit dem CM arbeiten werden,
Auf dem CM-Rechner muss der Application Server so konfiguriert werden, dass Kerberos verwendet werden kann, und CM weiß, wo die keytab-Datei mit dem Systembenutzer und Prinzipalnamen zu finden ist, um Kerberos-Verschlüsselung und -Kommunikation einzusetzen. Deshalb müssen Sie
Für die Benutzer, die SSO mit Kerberos und CM verwenden möchten, muss ein CM-Bearbeitername dem Kerberos-Prinzipalnamen zugewiesen werden. Deshalb müssen Sie
Der erste Schritt ist die Konfiguration des Domänen-Controllers, damit dieser den ConSol CM-Server kennt, d. h. die Integration des CM-Servers in der Windows-Domäne. In unserem Beispiel heißt der Domänen-Controller mywin2003srv und die Domäne ist MYSSODOMAIN.COM.
Zuerst muss der ConSol CM-Serverrechner im Active Directory des Domänen-Controllers registriert werden. In unserem Beispiel ist der Domänen-Controller der Computer MyComputer.
Der Radio-Button Computer bei Delegierungen aller Dienste vertrauen (nur Kerberos) muss aktiviert sein!
führen Sie folgenden Befehl aus: dsamsc, machines
Abbildung 443: Registrieren des ConSol CM-Serverrechners
Als Zweites muss der Benutzer, unter dem der ConSol CM-Serverprozess ausgeführt wird, in Active Directory (als Key Distribution Center fungierend) erstellt und registriert werden, in unserem Beispiel der Benutzer tomcat.
Folgende Kontooptionen müssen aktiviert sein:
Führen Sie folgenden Befehl aus: dsamsc, users
Abbildung 444: Registrieren des ConSol CM-Serverbenutzers
Stellen Sie sicher, dass der Prozess des CM-Application-Servers (z. B. JBoss) unter dem angegebenen Benutzer auf dem CM-Rechner läuft.
Auf dem Domänen-Controller wird der ConSol CM-Server als neuer (nicht-Windows) Kerberos-Dienst erstellt und eine Kerberos-keytab-Datei erzeugt. Diese Datei wird später auf dem ConSol CM-Serverrechner benötigt. Die keytab-Datei enthält den gemeinsamen geheimen Schlüssel des Dienstes (SPN, Service Principal Name).
Verwenden Sie folgenden ktpass-Befehl:
C:\Program Files\Support Tools>ktpass /out tomcat.keytab /ptype KRB5_NT_PRINCIPAL /princ HTTP/MyComputer.MySSODomain.com@MYSSODOMAIN.COM /pass consol.123 /mapuser tomcat /crypto rc4-hmac-nt
Wenn ktpass nicht verfügbar ist, müssen die Windows Server 2003 Support Tools installiert werden. Diese sind hier verfügbar.
/out tomcat.keytab
=> Verwendet tomcat.keytab als Ausgabedatei.
/ptype KRB5_NT_PRINCIPAL
=> Gibt den Prinzipaltyp an.
/princ HTTP/MyComputer.MySSODomain.com@MYSSODOMAIN.COM
=> Gibt den Kerberos-Prinzipalnamen in der Form host/computer.<domäne>@<realm> an. Siehe Benutzeranmeldename in der Konfiguration (obige Abbildungen).
/pass consol.123
=> Setzt das Passwort für den Benutzer princ, der mit /princ angegeben wird
/mapuser tomcat
=> Ordnet den Namen des Kerberos-Prinzipals (Parameter /princ) dem angegebenen Domänenkonto zu.
/crypto rc4-hmac-nt
=> Gibt die Schlüssel an, die in der keytab-Datei erzeugt wurden:
Führen Sie den Application Server (z. B. JBoss) unter dem Systembenutzer aus, der in der Windows-Domäne registriert ist (in unserem Beispiel tomcat).
Installieren Sie ConSol CM wie gewohnt und aktivieren und konfigurieren Sie Kerberos wie in den nächsten Schritten beschrieben.
Wenn Sie eine Ersteinrichtung vornehmen, können Sie entscheiden, ob Kerberos aktiviert sein soll. Beachten Sie, dass dies nur ein Hinweis ist und zusätzliche Konfigurationen erforderlich sind (siehe nächste Schritte).
Wenn Ihr ConSol CM schon ohne Kerberos konfiguriert ist, können Sie Kerberos im Admin Tool aktivieren, indem Sie die System-Property cmas-core-security, kerberos.v5.enabled auf true setzen. Ein Neustart des Servers ist erforderlich, damit die neue Einstellung wirksam wird.
Ein ConSol CM-Server liest die Konfigurationsparameter aus der Datei cm6-kerberos.properties aus folgendem Klassenpfad: (Die einzelnen Cluster-Nodes brauchen möglicherweise eigene Konfigurationen, weshalb jeder Node seine Datei cm6-kerberos.properties aus dem Klassenpfad liest.)
../jboss/server/{domain}/conf/cm6-kerberos.properties../{domain}/cm6-kerberos.properties<module xmlns="urn:jboss:module:1.1" name="com.consol.cmas">
<resources>
<resource-root path="."/>
</resources>
</module>
<subsystem xmlns="urn:jboss:domain:ee:1.1">
...
<global-modules>
<module name="com.consol.cmas" slot="main" />
</global-modules>
</subsystem>
<subsystem xmlns="urn:jboss:domain:ee:2.0">
...
<global-modules>
<module name="com.consol.cmas" slot="main" />
</global-modules>
</subsystem>
Falls Sie ein Cluster aus mehr als einem ConSol CM-Server in Betrieb haben, muss jeder Server eine eigene Properties-Datei haben.
Die .properties-Datei sollte Folgendes enthalten:
# path to kerberos configuration
kerberos.config.location=C:\\conf\\krb5.ini
# one or more service principals (principal = path to keytab file)
HTTP/MyComputer.MySSODomain.com@MYSSODOMAIN.COM=C:\\conf\\tomcat.keytab
Code-Beispiel 75: cm6-kerberos.properties
[libdefaults]
default_realm = MYSSODOMAIN.COM
default_tkt_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc des3-cbc-sha1
default_tgs_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc des3-cbc-sha1
[realms]
MYSSODOMAIN.COM = {
kdc = mywin2003srv
admin_server = mywin2003srv:8888
}
[domain_realm]
.mywin2003srv = MYSSODOMAIN.COM
mywin2003srv = MYSSODOMAIN.COM
Kopieren Sie die keytab-Datei, die Sie auf dem Domänen-Controller erzeugt haben, an den in der Konfigurationsdatei cm6-kerberos.properties angegebenen Speicherort.
Sie müssen den ConSol CM-Serverprozess neu starten, damit diese Änderung wirksam wird.
Wenn die System-Property cmas-core-security, kerberos.v5.enabled auf true gesetzt wurde, ist das Feld Kerberos Principal Name in den Bearbeiterdaten verfügbar.
Abbildung 445: ConSol CM Admin Tool - Kerberos Principal Name in den Bearbeiterdaten
Der Kerberos Principal Name ist ein Benutzername zusammen mit dem entsprechenden Realm-/Domänennamen, zum Beispiel SusanServiceDesk@consol.de. Damit können sich Benutzer mit dem Anmeldenamen SusanServiceDesk authentifizieren, die zu unterschiedlichen Kerberos-Realms gehören (SusanServiceDesk@consol.de und SusanServiceDesk@consol.pl sind zwei unterschiedliche Benutzer). Wenn das Feld Kerberos Principal Name für einen Bearbeiter leer ist, wird stattdessen der Benutzername (Login) verwendet. Wenn die Kerberos-Authentifizierung fehlschlägt, wird der reguläre Authentifizierungsmechanismus (DATABASE, LDAP) verwendet. In diesem Fall ist Single Sign-On nicht möglich und dem Bearbeiter wird die Anmeldeseite angezeigt.
Internet Explorer muss so konfiguriert werden, dass die automatische Anmeldung aktiviert ist. Standardmäßig ist dies bei der Sicherheitseinstellung mittel bis niedrig, der Standardeinstellung für die Zone Lokales Intranet, erlaubt.
Es sind folgende Einstellungen für das Anmeldeverhalten verfügbar.
Abbildung 446: Anmeldekonfiguration von Internet Explorer
Einstellungen und resultierendes Verhalten:
Bei Verwendung der Standardeinstellungen unterstützt Firefox Single Sign-On mit Kerberos nicht. Um Single Sign-On zu aktivieren, müssen Sie die URI des ConSol CM Web Clients in der Firefox-Konfiguration eintragen.
Führen Sie dazu folgende Schritte aus:
Sie können diese Property auch im Dateisystem setzen. Öffnen Sie dazu die Datei
C:\Benutzer\[BENUTZER]\AppData\Roaming\Mozilla\Firefox\Profiles\[XYZ].default\prefs.js
und fügen Sie folgende Zeile hinzu bzw. ersetzen Sie sie:
user_pref("network.automatic-ntlm-auth.trusted-uris", "http://mycm6server");
oder
user_pref("network.negotiate-auth.trusted-uris", "http://mycm6server");
Sie müssen Firefox nach dieser Änderung neu starten.
Ein Bearbeiter, der sich mit Single Sign-On in ConSol CM anmeldet, wird Folgendes bemerken:
Es ist trotzdem möglich, sich als anderer ConSol CM-Benutzer anzumelden. Klicken Sie dazu auf den Button zum Abmelden, wodurch Sie auf die Anmeldeseite weitergeleitet werden, oder rufen Sie explizit die URL ...../cm-client/login auf.
Erstellen Sie für jede Domäne, in der Sie Single Sign-On aktivieren, eine neue Domäne/Benutzer und einen neuen Kerberos-Prinzipal und tragen Sie diese in die Datei cm6-kerberos.properties ein:
# path to kerberos configuration (think krb5.conf or krb5.ini)
kerberos.config.location=/etc/krb5.conf
# one or more service principals (principal = path to keytab file)
HTTP/MyServerMyDomain.com@MYDOMAIN.COM=/etc/krb5_mycompanycom.keytab
HTTP/MyServer.MyDEDomain@MYDOMAIN.DE=/etc/krb5_mycompanyde.keytab
Um auf Kerberos basierendes Single Sign-On verwenden zu können, muss der Kerberos-Prinzipal (d. h. der Anmeldename des Benutzers im Betriebssystem) mit dem Namen eines ConSol CM-Bearbeiters verknüpft werden.
Standardmäßig findet die Zuordnung auf einem der beiden folgenden Wege statt:
Wenn weitere Anpassungen erforderlich sind, lesen Sie bitte UsernameAdapter interface javadoc.
Die Kerberos-Authentifizierung kann im Admin Tool in der Navigationsgruppe Dienste -> Navigationselement CM-Services -> Kerberos v5 authentication provider, siehe Abschnitt CM-Services, gestartet bzw. gestoppt werden.