Dieses Handbuch kann nicht die Konfiguration der verschiedenen Kerberos-Server (Active Directory, OpenDirectory, MIT, etc.) beschreiben. Bitte greifen Sie dazu auf die Dokumentation Ihres jeweiligen Anbieters zurück.


Wichtig

Namen im Servicekonto, die mit "jet" beginnen, müssen zwingend in Kleinbuchstaben eingegeben werden!


Der Service-Prinzipal-Name "jet/vollqualifizierter_rechername" muss einem normalen extra dafür angelegtem Benutzerkonto im Active Directory zugeordenet werden.

Der Service-Prinzipal-Name des JET Services in Kerberos besteht – wie oben gezeigt – aus einem Servicenamen (für einen oxaion-Server muss dieser zwingend jet sein!) und, abgetrennt mit einen Schrägstrich, dem DNS-Namen des Servers.



Daher müssen Sie zuerst ein Pseudo-Benutzerkonto ohne Anmeldeberechtigung anlegen; der Name ist zwar beliebig, es bietet sich aber eine Namenskonvention wie bspw. jet_<rechnername> an.
Wichtig dabei ist, dass in den folgenden Feldern der tatsächliche Benutzername im vorgegebenen Schema angegeben ist:

  • Vorname: jet_rechnername
  • Benutzeranmeldename (=Prinzipalname): jet/<jet-Server>
    <jet-server> ist dabei der DNS-Name des JET Servers, bspw. jet/rechnername.sampledomain.lan
  • Benutzeranmeldename (Prä-Windows 2000): jet_rechnername

Legen Sie das Kennwort für dieses Konto fest und aktivieren Sie folgende Optionen:

  • Benutzer kann Kennwort nicht ändern
  • Kennwort läuft nie ab

Deaktiviert werden muss:

  • Benutzer muss Kennwort bei der nächsten Anmeldung ändern


Einrichtung und Keytab Erzeugung mit dem älteren Verschlüsselungstyp RC4_HMAC_MD5 

Wenn für den Jet-Client eine Java Version verwendet wird, die kleiner als 11.0.13 ist, wird für diesen Service-Benutzer nur der Verschlüsselungstyp RC4_HMAC_MD5 unterstützt.

Aufgrund von neuen Betriebsystemdefaulteinstellungen reicht es in diesem Fall nicht die im Konto die Unterstützung Kerberos-AES*  Verschlüsselungen zu deaktivieren. Sondern es muss explizit das Account-Attribut "msDS-SupportedEncryptionTypes" auf 4 gestellt werden. 

Beispiel msDS-SupportedEncryptionTypes für ein jet Service Konto


msDS-SupportedEncryptionTypes

Falls das Attribut nicht existiert, kann man es beispielsweise durch Anhaken der Konto-Option "Kerberos-DES-Verschlüsselungstypen für dieses Konto" erzeugen und dann abändern.

Alternative Möglichkeiten per Powershell:

msDS-SupportedEncryptionTypes per Powershell
# Attribut anzeigen
get-ADUser jet_<RECHNERNAME> -Properties msDS-SupportedEncryptionTypes


# Attribut ändern
set-ADUser jet_<RECHNERNAME> -Replace @{"msDS-SupportedEncryptionTypes"=4}


# alternativ wenn nicht vorhanden in einem Zug passend anlegen
set-ADUser jet_<RECHNERNAME> -Add @{"msDS-SupportedEncryptionTypes"=4}

# wenn nicht mehr benötigt entfernen
get-ADUser jet_<RECHNERNAME> -Clear msDS-SupportedEncryptionTypes


Erzeugen Sie anschließend über die Eingabeaufforderung (auf einem Domaincontroller) für dieses Benutzerkonto das eigentliche Namensmapping in der Active Directory-Datenbank und die Keytab.

Bei diesem Befehl wird auch das Passwort von dem per -mapUser Option angegebenen Konto auf ein zufällig generiertes Passwort umgestellt (+rndPass).

Es ist eine gute Praxis, wenn man den ausgeführten Befehl und die Ausgabe dazu textuell aus dem Fenster der Eingabeaufforderung kopiert und zusätzlich in einer Textdatei z.B. krb5_keytab_ktpass_rechnername.txt speichert.

ktpass -princ  "jet/<jet-server>@<REALM>" -mapUser "jet_<rechnername>@<REALM>" +rndPass -mapOp set +DumpSalt -crypto RC4-HMAC-NT -out krb5.keytab  -ptype KRB5_NT_PRINCIPAL -kvno 0


<jet-server> ist dabei der DNS-Name des JET Servers, bspw.:

ktpass -princ "jet/rechnername.sampledomain.lan@SAMPLEDOMAIN.LAN" -mapuser "jet_rechnername@SAMPLEDOMAIN.LAN"  +rndPass -mapOp set +DumpSalt -crypto RC4-HMAC-NT -out krb5.keytab -ptype KRB5_NT_PRINCIPAL -kvno 0


Einrichtung und Keytab Erzeugung mit dem Verschlüsselungstyp AES256-CTS-HMAC-SHA1-96 

Mindest Vorraussetzung

Der Jet-Client muss mit einer Java Version >= 11.0.13 betrieben wird. Damit ist die im Clientverzeichnis mit ausgelieferte Java VM gemeint (Unterordner jre). Im laufenden Client kann man die Javaversion auch feststellen in dem per Rechtsklick auf dem Logo oben links der Menüeintrag Hilfe → Info auswählt wird (siehe das folgende Bild):

Für Release Versionen vor 2021.5301.1 (In dem Bild oben die Zeile unter der Java Version) müssen zusätzliche Konfigurationsschritte erfolgen 

  •  Die Java system property  sun.security.jgss.native auf dem Client auf true gesetzt werden:

Am besten die Client.txt anpassen in dem vor dem -cp Parameter die Zeichenkette  -Dsun.security.jgss.native=true eingefügt wird.

Beispiel:

von

..\jre\bin\javaw -Xmx512m -XX:-OmitStackTraceInFastThrow -Djet.classloader.exclude=weblauncher.jar -Djava.system.class.loader=com.oxaion.util.launcher.OxaionClassLoader -cp ./../lib/oxaion-classloader.jar com.oxaion.jet.client.swing.Main properties=./../conf/client.properties pathType=WIN

nach:

..\jre\bin\javaw -Xmx512m -XX:-OmitStackTraceInFastThrow -Djet.classloader.exclude=weblauncher.jar -Djava.system.class.loader=com.oxaion.util.launcher.OxaionClassLoader -Dsun.security.jgss.native=true -cp ./../lib/oxaion-classloader.jar com.oxaion.jet.client.swing.Main properties=./../conf/client.properties pathType=WIN

  • In der server.xml bzw. in dem template aus dem diese generiert wird, muss auf dem Server im entsprechenden host Tag (NICHT für den type="Database") die folgende Definition eingefügt werden:

    <define name= "force-java-kerberos" value="true" />

    Beispiel für eine server.xml in der IDE (Entwicklungsumgebung):

    <host name="IDE lokal" type="local" address="localhost" >
	<define name= "force-java-kerberos" value="true" />
</host>

Konfigurationen und Erzeugung der Keytab mit dem AES Schlüssel 

Damit die Kerberos Kommunikation sicher und stabil (Windowsupdates) funktioniert, sollte bei dem Konto jet_<Rechnername> die Eigenschaft msDS-SupportedEncryptionTypes auf nur AES256_CTS_HMAC_SHA1_96 umgestellt werden:

Dazu muss die Konto-Eigenschaft msDS-SupportedEncryptionTypes auf den decimalen Wert 16 (Hexadecimal: 0x10) festgelegt werden:

msDS-SupportedEncryptionTypes

Falls das Attribut nicht existiert, kann man es beispielsweise durch Anhaken der Konto-Option "Kerberos-DES-Verschlüsselungstypen für dieses Konto" erzeugen und dann abändern.

Alternative Möglichkeiten per Powershell:

msDS-SupportedEncryptionTypes per Powershell
# Attribut anzeigen
get-ADUser jet_<RECHNERNAME> -Properties msDS-SupportedEncryptionTypes

# Attribut ändern
set-ADUser jet_<RECHNERNAME> -Replace @{"msDS-SupportedEncryptionTypes"=16}

# alternativ wenn nicht vorhanden in einem Zug passend anlegen
set-ADUser jet_<RECHNERNAME> -Add @{"msDS-SupportedEncryptionTypes"=16}

# wenn nicht mehr benötigt entfernen
get-ADUser jet_<RECHNERNAME> -Clear msDS-SupportedEncryptionTypes


Erzeugen Sie anschließend über die Eingabeaufforderung (auf einem Domaincontroller) für dieses Benutzerkonto das eigentliche Namensmapping in der Active Directory-Datenbank und die Keytab Datei.

Bei dem beschrieben Aufruf wird auch das Passwort von dem per -mapUser Option angegebenen Konto auf ein zufällig generiertes Passwort umgestellt (+rndPass).

Es ist eine gute Praxis, wenn man den ausgeführten Befehl und die Ausgabe dazu textuell aus dem Fenster der Eingabeaufforderung kopiert und in einer Textdatei z.B. krb5_keytab_ktpass_rechnername.txt speichert, weil bei einer Fehlersuche genau diese Daten benötigt werden.

ktpass -princ  "jet/<jet-server>@<REALM>" -mapUser "jet_<rechnername>@<REALM>" +rndPass -mapOp set +DumpSalt -crypto AES256-SHA1 -out krb5.keytab  -ptype KRB5_NT_PRINCIPAL -kvno 0

<jet-server> ist dabei der DNS-Name des JET Servers, bspw.:

ktpass -princ "jet/rechnername.sampledomain.lan@SAMPLEDOMAIN.LAN" -mapuser "jet_rechnername@SAMPLEDOMAIN.LAN"  +rndPass -mapOp set +DumpSalt -crypto AES256-SHA1 -out krb5.keytab -ptype KRB5_NT_PRINCIPAL -kvno 0

Wichtig weiter Einrichtungsinformationen

Die dabei generierte Datei krb5.keytab muss anschließend manuell in das User-Verzeichnis des ausführenden Benutzers auf dem JET-Server kopiert werden. Wenn beispielsweise der Benutzer „jetdienst" den JET-Server ausführt, ist die Datei in das Verzeichnis „c:\Users\jetdienst" auf dem JET-Server zu kopieren.

Mit adsiedit.msc (Windows Support Tools) kann geprüft werden, ob die Eigenschaft "Serviceprincipalname" für den Benutzer jet_<rechnername> auf den richtigen Wert gesetzt ist.

Wichtig

Stellen Sie sicher, dass kein anderes Objekt im AD über diesen Wert der Eigenschaft "Serviceprincipalname" verfügt. Sonst schlägt die Kerberos-Authentifizierung auf dem Client mit der Fehlermeldung "Server not found in Kerberos database" fehl und im Systemprotokoll des authentifizierenden Domänen-Controller wird ein entsprechender Event geschrieben. Die tatsächlich registrierten Namen für einen Rechner können Sie sich in der Kommandozeile mit setspn -l <rechnername> anzeigen lassen.

Fehlersuche

Ein häufiges Problem ist das Änderungen am Servicekonto jet_rechnername noch nicht übernommen worden sind, bzw der alte Zustand noch in irgendeiner Form "gecacht" ist.
Der Neustart des Rechners auf dem der jet-Server oder Applikationserver betrieben wird, sollte ein solches Problem beheben.

Wenn das Passwort von dem Servicekonto geändert wird, ist eine vorher erzeugte Keytab Datei nicht mehr verwendbar.

Ein wichtiges Thema bei der Kompatibilität ist der verwendete "Salt/Salz".
Die Verschlüsselungsoperationen verwenden einen Schlüssel, der sich zusätzlich zum Passwort-Hash aus bestimmte Daten vom Prinzipalnamen zusammen setzt, damit das Ergebnis sich zwischen unterschiedlichen Konten auch dann unterscheidet, wenn das gleiche Passwort verwendet werden würde. Der Parameter +DumpSalt vom ktpass Befehlt gibt diesen zusätzlich aus, so dass ein Vergleich mit der Verwendung an anderer Stelle möglich ist.

ktpass Beispielausführung (auf dem Domaincontroller):

E:\Oxaion Kerberos Service Accounts\jdk-11.0.4_11-WinX64\jdk-11.0.4+11\bin>ktpass -out aes.keytab -mapUser jet_hostname@SAMPLEDOMAIN.LAN +rndPass -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -princ jet/hostname.sampledomain.lan@SAMPLEDOMAIN.LAN
Targeting domain controller: XXXXXXXXX.SAMPLEDOMAIN.lan
Successfully mapped jet/hostname.sampledomain.lan to jet_hostname.
Passwort successfully set!
Building salt with principalname jet/hostname.sampledomain.lan and domain SAMPLEDOMAIN.LAN (encryption type 18)...
Hashing password with salt "SAMPLEDOMAIN.LANjethostname.sampledomain.lan".
Key created.
Output keytab to aes.keytab:
Keytab version: 0x502
keysize 95 jet/hostname.sampledomain.lan@SAMPLEDOMAIN.LAN ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (...)

Um die Keytab im  zusammenspiel mit Java zu testen kann man nun auf dem entsprechenden Rechner, für den die Keytab erzeugt wurde, den folgenden Befehl, im bin Verzeichnis der passenden Java Version ausführen:

.\java.exe -D"sun.security.krb5.debug=true" -D"java.security.krb5.kdc=domaincontroller_vollquallifiziert" -D"java.security.krb5.realm=REALM" sun.security.krb5.internal.tools.Kinit  -k  prinzipalname

Bezogen auf die ktpass Bespielausführung oben, sieht der Aufruf so aus:

.\java.exe -D"sun.security.krb5.debug=true" -D"java.security.krb5.kdc=XXXXXXXXX.sampledomain.lan" -D"java.security.krb5.realm=SAMPLEDOMAIN.LAN"  sun.security.krb5.internal.tools.Kinit  -k  jet/hostname.sampledomain.lan


Durch das Argument -D"sun.security.krb5.debug=true" werden zusätzlich Komunikationdaten und auch der verwendet "Salt" ausgegeben:

....

>>> KDCRep: init() encoding tag is 126 req type is 11
>>>KRBError:
         sTime is Tue Feb 14 12:34:31 CET 2023 1676374471000
         suSec is 584769
         error code is 25
         error Message is Additional pre-authentication required
         sname is krbtgt/SAMPLEDOMAIN.LAN@SAMPLEDOMAIN.LAN
         eData provided.
         msgType is 30
>>>Pre-Authentication Data:
         PA-DATA type = 19
         PA-ETYPE-INFO2 etype = 18, salt = SAMPLEDOMAIN.LANjethostname.sampledomain.lan, s2kparams = null
....

Looking for keys for: jet/hostname.sampledomain.lan@SAMPLEDOMAIN.LAN
Added key: 18version: 0
>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply jet/hostname.sampledomain.lan
New ticket is stored in cache file C:\Users\benutzername\krb5cc_benutzername


Zur Info: der ausgegebene "KRBError" gehört zum Protokollablauf dazu. Das Salz (salt) muss mit der Ausgabe von ktpass übereinstimmen (auch in der Groß/Kleinschreibung), damit die Ausführung funktionieren kann.

Das erzeugt Ticket in C:\Users\benutzername\krb5cc_benutzername sollte dann wieder gelöscht werden.

Falls über diese Informationen keine Lösungsstrategie entwickelt werden kann, gibt es noch die zusätzliche Möglichkeit die Keytab-Datei über ein Java Kommando zu erzeugen siehe Konfiguration oxaion.





  • Keine Stichwörter