Die Einmalanmeldung für Kerberos ist ein kostenpflichtiges formcycle Zusatzmodul.

Kerberos erlaubt eine Einmalanmeldung bzw. Single-Sign-On. In einem nachgeordneten Schritt können Benutzerdaten über einen LDAP-Server bereitgestellt werden. Die Authentifizierung des Kerberos Login-Dienstes kann nur einmal pro System konfiguriert werden, die Bereitstellung der Benutzerdaten über einen LDAP-Server kann innerhalb der Mandanten überschrieben werden. Die Konfiguration von Kerberos unterscheidet sich also ahängig davon ob der Login-Dienst in den Systemeinstellungen oder innerhalb eines Mandanten konfiguriert wird.

Inhalt

Konfiguration in den Systemeinstellungen

In den Systemeinstellungen wird die globale Kerberos-Konfiguration eingestellt.

Authentifizierung

Kerberos nutzen

Mit diesem Schalter lässt sich die globale Kerberos-Benutzerauthentifizierung aktivieren/deaktivieren.

Mit Frontend-Server synchronisieren

Wenn dieser Schalter aktiviert ist, wird beim Speichern der Einstellungen die aktuelle Konfiguration auf alle (erreichbaren) Frontend-Server übertragen.

Nutzername

Windows Domain Account, welcher für den Zugriff auf das Key Distribution Center (KDC) benötigt wird, um den nachfolgenden Authentifizierungsprozess einzuleiten.
In den meisten Fällen ist dies ein User-Account aus dem AD, welcher als Service-Account fungiert und nicht zur Anmeldung an einer Workstation gedacht ist.

Es wird ein Nutzername mit Domainangabe (FQDN) benötigt, wenn in der krb5.conf Datei, unter dem Abschnitt [libdefaults], kein default_realm definiert ist. Beispiel: user@EXCAMPLE.COM

Wird in der weiteren Konfiguration eine AES-Verschlüsselung zur Kommunikation zwischen formcycle und dem KDC verwendet, so muss zwingend auf die Groß- / Kleinschreibung des Nutzernamens geachtet werden. Im Prozess der "Pre-Authentication" wird ein Hashwert gebildet. Ein Teil dieses Hashwertes bildet der Nutzername, welcher der genauen Angabe im Active Directory (AD) entsprechen muss, sonst schlägt eine Nutzeranmeldung in weiteren Verlauf fehl! 

Diesem Benutzer müssen z.B. im Active Directory die zu verwendeten Hosts der aufrufbaren URLs als auch der Computer-Name des Anwendungsservers als ServicePrincipalName (SPN) beginnend mit der Serviceklasse HTTP registriert werden. Mehr dazu finden Sie hier oder hier.

Passwort

Passwort des oben genannten Service-Accounts

Client-Modulname

Der Name, welcher in der login.conf Datei für die Definition der Clients verwendet wird.

Name des Server-Moduls

Der Name, welcher in der login.conf Datei für die Definition des Servers verwendet wird.

Datei krb5.conf

Hier wird der Inhalt der krb5.conf Datei definiert, in welcher die Konfiguration für Kerberos festgelegt werden.
Unter anderem werden hier die vom System unterstützten Verschlüsselungsverfahren aufgeführt, sowie der aktuell zu verwendende Realm (Administrationsbereich) und deren Mapping zu einem KDC. 

Beispielkonfiguration der kbr5.conf.

Dateistruktur

Die zu verwendende Schreibweise innerhalb der Datei orientiert sich an Windows INI-Dateien, das heißt, einzelne Abschnitte werden mit einen Abschnittsnamen (in eckigen Klammern) versehen. Jeder Abschnitt enthält keine oder mehrere Zuordnungen, die in folgender Form definiert werden können:

foo = bar

foobar = {
    foo = bar
    some = input
}

Abschnittsnamen

• [libdefaults]: Enthält die Einstellungen die von der Kerberos V5-Bibliothek verwendet werden
• [realms]: Realm-spezifische Kontaktinformationen und Einstellungen
• [domain_realm] Definiert die Zuordnung von Server Host-Namen zu Kerberos Realms

[libdefaults]

Der Abschnitt [libdefaults] kann folgende Zuordnungen enthalten:

• default_realm: Definiert den standardmäßig zu verwendenden Kerberos Administrationsbereich.
• default_tkt_enctypes: Definiert eine Liste von unterstützten Sitzungsschlüssel-Verschlüsselungstypen, die der Client anfordern sollte, wenn ein AS (Authentication Server)-Request durchgeführt wird. Die Reihenfolge der einzelnen Typen entspricht ihrer Präferenz vom höchsten zum niedrigsten. Die Werte innerhalb der Liste können mit Komma oder Leerzeichen getrennt werden.
• default_tgs_enctypes: Definiert eine Liste von unterstützten Sitzungsschlüssel-Verschlüsselungstypen, die der Client anfordern sollte, wenn ein TGS (Ticket Granting Server)-Request durchgeführt wird. Die Reihenfolge der einzelnen Typen entspricht ihrer Präferenz vom höchsten zum niedrigsten. Die Werte innerhalb der Liste können mit Komma oder Leerzeichen getrennt werden.
• permitted_enctypes: Definiert alle Verschlüsselungstypen, die für den Einsatz in Sitzungsschlüssel-Verschlüsselung erlaubt sind.

Eine beispielhafte Konfiguration für den [libdefaults]-Abschnitt kann folgendermaßen aussehen:

[libdefaults]
 default_realm = EXAMPLE.COM
 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac
 default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac
 permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac

[realms]

Jeder Tag im Abschnitt [realms] ist der Name eines Kerberos-Administrationsbereichs (auch 'Realm' genannt). Der Wert der Variablen ist eine Auflistung von Zuordnungen, die die Eigenschaften eines bestimmten Realms definieren. Für jeden Realm können die folgenden Zuordnungen definiert werden:

• kdc: Definiert den Namen oder die Adresse eines Rechners auf dem ein KDC (Key Distribution Center) für diesen Administrationsbereich läuft (Meist ist dies der Server, unter dem das Active Directory erreichbar ist). Es kann eine optionale Port-Nummer, getrennt mit Doppelpunkt, angegeben werden.
• debug: Ein boolescher Wert, welcher definiert, ob Debugnachrichten im Log erscheinen sollen.

Eine beispielhafte Konfiguration für den [realms]-Abschnitt kann folgendermaßen aussehen:

[realms]
   EXAMPLE.COM = {
 kdc = domain.example.com
   }

[domain_realm]

Der [domain_realm] Abschnitt enthält eine Zuordnung von einem Domain-Namen oder den Hostnamen zu einem Kerberos-Realm-Namen. Der Tag-Name kann ein Host oder Domain-Name sein, wobei Domain-Namen mittels Punkt (.) als Vorzeichen gekennzeichnet sind. Als Wert wird der Name eines Kerberos-Realm für diesen bestimmten Host oder die Domäne erwartet. Host- oder Domain-Namen sollten klein geschrieben werden.

Eine beispielhafte Konfiguration für den [domain_realm]-Abschnitt kann folgendermaßen aussehen:

[domain_realm]
   .example.com = EXAMPLE.COM

Datei login.conf

Hier wird der Inhalt der login.conf Datei definiert und damit welche Authentifizierungstechnologie für Client und Server zu verwenden ist.

Beispielkonfiguration der login.conf.

Eine beispielhafte Konfiguration kann folgendermaßen aussehen:

spnego-client {
   com.sun.security.auth.module.Krb5LoginModule required;
};

spnego-server {
   com.sun.security.auth.module.Krb5LoginModule required
   refreshKrb5Config=true
   storeKey=true
   isInitiator=false;
};

LDAP Benutzersuche

Die nachfolgenden Einstellungen sind notwendig, um Benutzerinformationen vom authentifizierten Nutzer über LDAP (MS Active Directory oder OpenLDAP) zu beziehen. Die ermittelten Benutzer-Stammdaten stehen anschließend für Autorisierungen zur Verfügung. Die Benutzersuche kann innerhalb der Mandanten überschrieben werden. Siehe Abschnitt Konfiguration innerhalb von Mandanten.

Konfiguration des LDAP-Servers für die Benutzersuche.

Domain-Controller Host*

FQN (Full Qualified Name) und Port des Active-Directory Controllers.
Beispiel: domain.example.com Port: 389 

SSL-Verbindung

Mit diesem Schalter lässt sich festlegen, ob SSL für den Kommunikation mit dem LDAP-Server verwendet werden soll.

Verweis-Sprünge*

Gibt die maximale Anzahl von durchzuführenden Verweis-Sprüngen (Referrels-Hops) auf dem LDAP-Server an.
Ein Wert von 0 deaktiviert ein Folgen von Verweisen.

Nutzer-Account (mit Domainangabe)*

Dieser Account muss das Recht haben, Suchanfragen (Benutzerobjekt) an das Active-Directory zu senden.

Es wird ein Nutzername mit Domainangabe (FQDN) benötigt. Beispiel: user@EXCAMPLE.COM

Nutzer-Account Passwort*

Passwort für den oben genannten Nutzer-Account.

BaseDn für Suche*

LDAP BaseDN unter der der authentifizierte Benutzer gesucht wird.
Beispiel: ou="intern", dc="example", dc="com"

Nutzer-ID-Attribute

Es kann eine Reihe von AD-Attributen angegeben werden, welche für die Nutzeridentifizierung verwendet werden soll. Diese Attribute werden in der angegebenen Reihenfolge für die Identifizierung des Nutzers versucht. Werden keine Attribute angegeben, dann werden standardmäßig folgenden Attribute in dieser Reihenfolge für die Nutzeridentifizierung versucht: sAMAccountName, userPrincipalName, uid und DN. Das Standardverhalten kann zudem über den Parameter ldap.override.filter.user.login in den Anwendungseinstellungen konfiguriert werden.

Nutzer-Filter

LDAP-Filter für Suche eines Nutzers nach erfolgreicher Kerberosauthentifizierung. Der durch die Authentifizierung erhaltene Benutzername kann dabei in einzelne Bestandteile aufgeteilt werden, welche für die Suche des Benutzers im LDAP verwendet werden können. Am Beispiel test/admin@EXAMPLE.COM stehene folgende Bestandteil zur Verfügung:

{0}: test/admin@EXAMPLE.COM

{1}: test/admin

{2}: test

{3}: admin

{4}: EXAMPLE.COM

Diese Bestandteile können also verwendet werden, um einen LDAP-Filter zu definieren, um den Benutzer auf dem LDAP-Server zu finden, bspw.:

(sAMAccountName={2})

Dieser Filter würde im gegebenen Beispiel also den LDAP-Filter für die Benuztersuche wie folgt definieren:

(sAMAccountName=test)

Wird kein Wert gesetzt, so wird standardmäßig der folgende LDAP-Filter verwendet:

(|(sAMAccountName={0})(userPrincipalName={0})(uid={0})(DN={0}))

Das Standardverhalten kann zudem über den Parameter ldap.override.filter.kerberos.user in den Anwendungseinstellungen konfiguriert werden.

Konfiguration innerhalb von Mandanten

Innerhalb von Mandanten kann die globale Konfiguration der LDAP-Benutzersuche überschrieben werden. Wird ein Mandant-Kerberos-Login-Dienst in Formularen verwendet, so wird die global Authentifizierungskonfiguration von Kerberos (siehe oben) mit der im Mandant-Kerberos-Login-Dienst konfigurierten LDAP-Benutzersuche verwendet.

Konfiguration des LDAP-Servers für die Benutzersuche innerhalb von Mandanten.

Für die Konfiguration der mandantspezifischen LDAP-Bernutzersuche sind folgende Angaben nötig:

LDAP-Verbindung: Es muss eine exisitierende LDAP-Verbindung gewählt werden.

BaseDN für die Nuztersuche: siehe BaseDn für Suche oben.

Nutzer-Filter: siehe Nutzer-Filter oben.

Theoretische Betrachtung der Anbindung mehrerer KDCs/Domänen

Sollten mehrere KDC-Server bzw. Domänen für eine übergreifende Anmeldemöglichkeit mittels Kerberos gewünscht sein, ist dies über den Standard der von Java mitgelieferten und von FORMCYCLE verwendeten Kerberos-Implementierung des MIT theoretisch möglich. Zu beachten sind hier jedoch folgende Konfigurationen:

• Für jeden KDC-Server/jede Domäne ist ein eigener Realm zu definieren
• Anhand der unter [domain_realm] zu definierenden Liste ist anzugeben welche Aufruf-URL von welchem Realm behandelt werden soll
• Sollte eine Cross Realm Authentifizierung gewünscht sein, so muss ein Cross Realm Trust aufgebaut werden. Dies dient dazu, dass ein Benutze aus Realm A sich auch innerhalb des Realms B anmelden kann. Realisieren lässt sich dies unter anderem mit einem direkten Realm Trust bei dem auf jedem relevanten Server Principals gegen die anderen Realms angelegt werden. Bei den Realms A.REALM.COM und B.REALM.COM wäre dies beispielhaft krbtgt/A.REALM.COM@B.REALM.COM und krbtgt/B.REALM.COM@A.REALM.COM.
• Benutzen Sie in für den Service Principal denselben Namen und ein starkes Passwort oder konfigurieren Sie eine keytab-Datei.
• Um nach erfolgter Kerberos-Anmeldung die korrekten Benutzer-Daten abzufragen, muss entweder ein LDAP-Server mit Zugriff in den kompletten Forest der Realms oder die Funktionalität der Mandant-Spezifischen LDAP-Server konfiguriert werden. Ggf. ist ferner eine Anpassung des hierfür zuständigen LDAP-Filters notwendig (siehe Kerberos Troubleshooting)

Ausgelesene LDAP-Nutzerdaten im Formular verarbeiten

Um LDAP-Nutzerdaten im Formular zu verarbeiten, siehe hier.