Einmalanmeldung

Die Einmalanmeldung für Ntlm und Kerberos ist ein kostenpflichtiges Xima® Formcycle Zusatzmodul.

Inhalt [ Verbergen ]

Wir möchten Sie darauf hinweisen, dass wir uns zukünftig von Ntlm als Option für die Einmalanmeldung verabschieden. Wir folgen dabei einer allgemeinen Empfehlung von Microsoft, wonach Ntlm aufgrund unzureichender Sicherheitsmechanismen, zukünftig nicht mehr von Anwendungen verwendet werden sollte (Stellungnahme von Microsoft oder Stellungnahme im Forum unter Chapter 3). Daraufhin wurden durch Microsoft Patches zur Verbesserung der Sicherheit veröffentlich, welche mit der aktuellen Ntlm-Implementierung in FORMCYCLE aber nicht mehr funktionieren wird. Da von einer weiteren Verwendung abgeraten wird, werden wir die Weiterentwicklung des Moduls ab FORMCYCLE Version 7 einstellen.

Für bestehende Kunden bieten wir Ihnen an, kostenfrei auf Kerberos umzustellen. Die Freischaltung für Kerberos erfolgt in Lizenz der V7 automatisch, wenn Ntlm bereits lizensiert wurde.

Nutzeroberfläche für die Einstellungen zu Ntlm. Sie ist nur verfügbar, wenn die Lizenz dies erlaubt.

Ntlm wird für die Authentifizierung von Formularbenutzern verwendet. Ein typisches Einsatzszenario sind Formulare, die intern von Mitarbeitern eines Unternehmens aufgerufen werden. Über Ntlm kann das Formular auf die Benutzerdaten des angemeldeten ActiveDirectory zugreifen.

Ntlm bzw. Kerberos ist nur verfügbar, wenn die Lizenz dies erlaubt.

NTLM nutzen

Mit diesem Schalter lässt sich die Ntlm-Benutzerauthentifizierung für Formulare aktivieren bzw. deaktivieren

Mit Frontend-Server synchronisieren

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

Domain-Controller Host

Host (FQN) des ActiveDirectory Controller für die Ntlm-Authentifizierung eines Benutzers und die anschließende Ermittlung dessen Daten über Ldap.

Beispiel: domain.example.de

NTLM-Authentifizierung

Die folgenden Einstellungen sind für die Authentifizierung eines Benutzers mittels Ntlm notwendig:

Hostname des Domain-Controller Hosts

Hostname des Active-Directory-Controller.

Beispiel: domain

Windows-Domainname

Hier können je nach AD verschiedene Schreibweisen des Domainnamen verwendet werden.

Beispiel: example.de oder example0

Hier muss der Domain-Name angegeben werden, zu denen die zu authentifizierenden Benutzerkonten gehören.
Dieser Domain-Name kann sich von der Domäne des Computer-Kontos unterscheiden (Dabei handelt es sich um den NetBIOS-Name des Computers und nicht den DNS-/FQDN-Name).

Der zu benutzende Windows-Domainname lässt sich beispielhaft ermitteln, indem man auf einen in der Domäne angemeldeten Client eine Windows Konsole öffnet (Start / Ausführen / cmd) und dort folgenden Befehl eingibt:
echo %userdomain%

Computerkonto

Dieses Computerkonto muss die Berechtigung zu Nutzerverifizierung haben. Hierbei darf es sich nicht um ein Active-Directory Nutzerkonto handeln!

Ein Computer-Account ist am '$'-Zeichen im Domain-Namen erkennbar. z.B. example$@domain.de

Beschreibung für die Vorgehensweise zur Erzeugung eines Computer-Accounts im Active Directory Server können wir aktuell nicht liefern und muss in der entsprechenden Dokumentation von externen Quellen bezogen werden.

Computerkontopasswort

Passwort des Computerkontos

LDAP-Benutzersuche

Die folgenden Einstellungen sind für eine Nutzersuche nach erfolgter Ntlm-Authentifizierung notwendig:

Port

Der zu verwende Port für die Verbindung mit dem Ldap-Server zur Nutzersuche

SSL-Verbindung

Ermöglich das Aktivierung der SSL-verschlüsselten Kommunikation mit dem Ldap-Server.

Verweis-Sprünge

Gibt die Anzahl der zu folgenden Verweis-Sprünge (Referrals) an. ein Wert von 0 deaktiviert das Folgen von Verweisen.

Nutzerkonto (mit Domainangabe)

Konto für die Benutzersuche innerhalb des Ldap-Servers. Dieses Konto muss entsprechende Rechte für eine Nutzersuche besitzen.

Beispiel: ldap@example.de

Nutzerkontopasswort

Passwort des Nutzerkontos

BaseDN für Suche

Ldap BaseDN unter der die zu authentifizierten Benutzer gesucht werden sollen.

Beispiel: ou="users", dc="example", dc="de"

Einstellungen für Kerberos Authentifizierung

Nutzeroberfläche für die Einstellungen zu Kerberos. Nur verfügbar, wenn die Lizens dies erlaubt.

Kerberos wird für die Authentifizierung von Formularbenutzern verwendet. Ein typischen Einsatzszenario sind Formulare, die "intern" von Mitarbeitern eines Unternehmens aufgerufen werden. In einem nachgeordneten Schritt kann das Formular dann Benutzerdaten des angemeldeten Nutzers aus dem ActiveDirectory bereitstellen.

Kerberos muss als Lizenz-Option freigeschaltet sein!
Ist dies der Fall, können folgende Einstellungen bearbeitet werden:

Kerberos nutzen

Mit diesem Schalter lässt sich die Kerberos-Benutzerauthentifizierung für Formulare 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 

Diesem Benutzer müssen z.B. im Active Directory die zu verwendeten Hosts der aufrufbaren URLs als auch der Computer-Name (Rechnername und FQDN innerhalb der Domäne) 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

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. 

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

oder

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.

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.

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;
};

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.

Sollte es bei aktiviertem Kerberos vereinzelt oder dauerhaft zu Fehlern beim Formular-Aufruf kommen (HTTP-Status 400), so überschreitet das Kerberos-Ticket die standardmäßige Größenlimitierung des HTTP-Headers durch den Anwendungsserver (z.B. Tomcat). Eine Lösung bringt die Erhöhung dieser Limitierung welche hier beschrieben wird.

LDAP Benutzersuche

Die nachfolgenden Einstellungen sind notwendig, um Benutzerinformationen vom authentifizierten Nutzer über LDAP (MS Active Directory) zu beziehen.
Die ermittelten Benutzer-Stammdaten stehen anschließend im Formular zur Verfügung.

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"

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 Troubleshooting Kerberos)

Ausgelesene LDAP-Nutzerdaten im Designer verarbeiten

Die zum authentifizierten Nutzer ermittelten Eigenschaften aus dem LDAP werden im XFC_METADATA-Objekt abgelegt und stehen dadurch im Formular zur Verfügung. Am JSON-Objekt user befindet sich die Eigenschaft rawData, welche die ermittelten Daten als JSON-Struktur beinhaltet.

Welche Daten die JSON-Struktur unter der rawData Eigenschaft beinhaltet, hängt maßgeblich von den Leserechten des LDAP-Accounts ab,
welcher die Nutzersuche im LDAP-System durchführt.

Das nachfolgende JS-Codeschnipsel zeigt einen Zugriff auf die LDAP-Eigenschaft userPrincipalName mittels JS im Designer:

try {
   // Auslesen der Property und Anzeige in einem Label
    var elem = $('[name=txt1]');
   var ldap = XFC_METADATA.user.rawData;
   if(ldap.hasOwnProperty('userPrincipalName')) {
        elem.html(ldap.userPrincipalName);
    }
} catch (err)  {}