Server

Für die Authentifizierung mit Kerberos muss die server.xml des oxaion-Servers angepasst werden.

Konfiguration server.xml (oxaion open)

Der folgende Abschnitt stellt die Konfiguration in oxaion open dar. Die Authentifizierung erfolgt durch den oxaion-Server. In der server.xml konfiguriert man dazu den Port-listener:

<option name="sasl-krb5-realm" value="<REALM>"/>
<option name="sasl-krb5-kdc" value="<DC>"/>

<REALM>: Der Name des Kerberos Realms, bspw. OXAION.LOCAL 
<DC>: Der DNS-Name des Domain Controllers, bspw. oxdc01.oxaion.local

Hinterlegung oxaion-Server-Kennwort bzw. der Keytab-Datei für das Service-Prinzipal-Konto

Damit der Applikation Server einen Kerberos-Benutzer authentifizieren kann, benötigt er Zugriff auf ein Servicekonto das spezifisch für den Rechner und den Servicenamen "jet" angelegt wurde. Diesen Zugriff bekommt er über eine Keytab-Datei krb5.keytab, die in dem Benutzerverzeichnis des Benutzer abgelegt wird, mit dessen Konto der Applikationsserver gestartet wird. Dieser Benutzer hat selbst nichts mit dem Service-Prinzipal-Konto zu tun dessen Keytab Datei verwendet wird.

Die Einrichtung von dem Servicekonto und die Erzeugung von der zugehörigen Keytab-Datei wird auf der Seite Konfiguration Active Directory beschrieben.

In diesem Kapitel wird nur eine alternative Möglichkeit beschrieben, mit der eine keytab Datei über java bezogene Kommandos erzeugt werden kann. Grundsätzlich sollte aber, wenn möglich, die von ktpass erzeugte Keytab-Datei verwendet werden.
Der unten beschriebene Befehl zur Anzeige des Inhalts der Keytab-Datei sollte auch mit der über ktpass erzeugten Keytab-Datei funktionieren.

Die Verwendung des Kommandos ktab aus der Java-Installation hat den Nachteil, dass das Passwort des Service-Prinzipal-Konto bekannt sein muss.  In dem ktpass Aufruf auf der Seite Konfiguration Active Directory muss dann das Argument "+rndpass" mit den Argumenten "-pass *" ersetzt werden. Bei der Ausführung mit dem Stern wird dann nach dem Passwort gefragt.

Zur Erzeugung der Keytab verwenden Sie bspw. unter Windows in der Kommandozeile (cmd.exe) das Java-Programm ktab.

Vorraussetzung ist:

1. Die vorhandene Zuordnung des Service Prinzipal "jet/<hostname-name-fully-qualified>" zu einem Active Directory Benutzer-Konto.
   Beispiel für das Prüfen des vorhandensein eines Service Prinzipal jet/servername.sampledomain.lan mit dem Window Kommando setspn:
   
In diesem Fall gibt es das Active Directory Benutzer-Konto "jet_servername" dem das Service Prinzipal "jet/servername.sampledomain.lan" zugeordnet wurde. Es darf nur ein einziges Active Directory Benutzer-Konto geben, dem ein bestimmtes Service Prinzipal zugeordnet wurde. Die Zuordnung wird üblicherweise mit durch den ktpass Aufruf erstellt.
   
2. Der Wechsel in das bin Verzeichnis der verwendeten Java Installationsverzeichnis

.\ktab -a jet/<hostname-fully-qualified>@<REALM> -n 0

<hostname-fully-qualified> ist dabei der klein geschriebene vollqualifizierter DNS-Name des Rechners auf dem der java Prozess startet, der die oben angegeben server.xml einliest.

Für einen Jet bzw. Applikations-Server (=>java Prozess) der in einer eclipse Entwicklungsumgebung gestartet wird, ist das genau der Rechner auf dem die Entwicklungsumgebung gestartet wird.

Die oxaion open IDE (=eclipse Entwicklungsumgebung) bringt eine eigene Java Installation im Unterverzeichnis jdk mit.

Den Namen<hostname-fully-qualified> kann man in einer powershell die auf diesen Server geöffnet wurde mit dem Kommando:

[system.net.dns]::GetHostByName("localhost").hostname.ToLower() 

ermittelt werden.

<REALM> ist der groß geschrieben vollqualifizierter  Active Directory Domain-Name.

Diesen Namen kann man in einer powershell die auf diesen Server geöffnet wurde mit dem Kommando:

[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().Name.ToUpper()

ermittelt werden.

Beispiel:

ktab.exe -a jet/servername.sample.lan@SAMPLEDOMAIN.LAN -n 0

Dadurch wird eine Datei krb5.keytab im Benutzerverzeichnis des angemeldeten Benutzers erzeugt. Ggf. müssen Sie diese in das Benutzerverzeichnis desjenigen Benutzers verschieben, unter dem der oxaion-Server-Dienst läuft.

Die darin gespeicherten Daten können mit ktab –l eingesehen werden. Es sollten 3-6 Einträge erstellt worden sein:

Die unterschiedlichen Einträge entstehen durch unterschiedliche Verschlüsselungstypen:

ktab -l -e

JET-Client

In den client.properties konfiguriert man zuerst den zu verwendenden Mechanismus:
Standard-1.0-SASL-Mechanisms=GSSAPI
Und dann die Informationen für Kerberos:
Standard-1.0-SASL-krb5-realm=<REALM>
Standard-1.0-SASL-krb5-kdc=<DC>

<REALM>: Der Name des Kerberos Realms, bspw. SAMPLEDOMAIN.LAN
<DC>: Der DNS-Name des Domain Controllers, bspw. oxdc01.oxaion.local

Diese Angaben müssen denen des Servers entsprechen. Diese Information muss doppelt gepflegt werden, da der Client diese Informationen benötigt, bevor er den Server das erste Mal kontaktiert und der Server sie nicht vom Client übernehmen kann, da dieser sonst bspw. einen eigenen, unsicheren KDC angeben könnte. Sollten diese Parameter nicht angegeben sein, versucht JET diese automatisch aus den Systemvariablen zu ermitteln.

Besonderheiten der Benutzer-Verwaltung

Mit dem SASL-Mechanismus GSSAPI wird beim Login im JET-Client der Benutzername des Betriebssystems ermittelt. In der Standard-Einstellung wird dabei der eventuell vorhandene Domänenname entfernt.
Statt OXAION@OXAION.LOCAL wird dadurch nur OXAION als Benutzername zum Login vorbelegt und genutzt.

Ist es aufgrund der Benutzerverwaltung im oxaion open erforderlich, auch die Domäne für den Login zu erhalten, ist zusätzlich in den client.properties zu hinterlegen:
Standard-1.0-SASL-krb5-full-principal=true

Anmelden mit Kerberos

Die Hinweise zu LDAP_NEWKENW und LDAP_NEWUSER in Anmelden mit LDAP können eins zu eins übernommen werden, inklusive dem Beginn "LDAP_".  Speziell auch die Hinweise zur automatischen Nutzeranlage.