Single Sign On - Keytab File - Kix 18.25

[SebastianPohl]

Moin,


ich habe Probleme mit einem relativ bekannten Thema, wozu ich aber bisher noch keine Lösung gefunden habe.
Ich versuche derzeit SSO in Kix 18.25 in einer Windows Domäne zum Laufen zu bringen.


Der Anleitung entsprechend habe ich dafür ein Keytab-File erzeugt und in der Sysconfig konfiguriert:
[{"Config":{"Keytab":"Base64-Keytab-hier-eingefügt"},"Enabled":1,"Module":"KIXPro::Kernel::System::Auth::Kerberos","Name":"Kerberos Test"}]


Die Änderungen habe ich gespeichert und das Frontend neugestartet.


Anschließend besagt die Anleitung, dass man SSO im Frontend aktivieren soll und zwar in der Environment-Datei.


Die einzige Environment-Datei, die ich gefunden habe, befindet sich im Docker-Host unter:
/opt/kix-on-premise/deploy/linux#
In diese habe ich also folgenden Eintrag im "frontend service configuration"-Segment gesetzt:


#custom configuration
SSO_ENABLED=true




Anschließend habe ich den "Stack" über die restart.sh neu gestartet.


Es passiert aber leider sehr wenig. Alle URL's, über die ich das Kix-Frontend aufrufen kann, funktionieren zwar, aber jeweils ohne SSO (die URL's sind als SPN auf dem User hinterlegt, für den ich das Keytab-File ausgestellt habe). Ich bekomme nicht einmal einen Fehler oder Ähnliches. In den Logs im Portal unter "Admin -> Kix -> System -> Logs" finde ich auch keine Hinweise, obwohl ich in der selben Environment-Datei das Loglevel auf "3" gesetzt habe.
Zum Testen benutze ich einen Firefox, in welchem ich in die "network.negotiate-auth.trusteduris" meine URLs eingetragen habe. Die Verbindung erfolgt über einen nginx reverse-Proxy, der aber nur einen "proxy_pass" durchführt - es funktioniert aber auch ohne diesen reverse Proxy nicht.


Weiß jemand Rat?

[SebastianPohl]

Auch in der Version 27 besteht der Fehler weiterhin.

[Torsten Thau]

Hallo Sebastian,


Kerberos-SSO ist eine relativ volatile "Sache". Häufige Knackpunkte sind

   
• falsch erstellte Keytab
• der FQDN aus der URL für KIX muss auch per Reverse DNS korrekt aufgelöst werden
• differierende Systemzeiten

Daher schlage ich vor zunächst zu prüfen ob überhaupt ein Token am KIX ankommt. Bei Aufruf des SSP hilft die Fehlerkonsole des Browsers - siehe Anhang. Auch auf dem aufrufenden Client sollte geschaut werden ob der ein passendes Kerberosticket hält.


CU, Torsten

[SebastianPohl]

Hallo Torsten,

vielen Dank für die schnelle Antwort.

- Falsch erzeugter Keytab -> kann ich nicht ausschließen, jedoch wurde er anhand des Beispiels aus der Doku konfiguriert:
ktpass -princ HTTP/hostname@DOMAIN.GROßGESCHRIEBEN -mapuser user@domain -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass AlphanumerischerCode -out c:\temp\kix.keytab
(Domain und mapuser wurden verallgemeinert, sind aber schon die richtigen)

- IP zeigt im Reverse DNS nicht auf den Dockerhost, da ich wie gesagt, einen nginX-Reverseproxy einsetze. Dieser erleichtert uns das aufrufen des Agentenportal und SSP's, da diese unterschiedliche Namen bei uns haben


- Systemzeit Dockerhost -> Active Directory passt.

Die Optionen im Browser sind unterschiedlich, ob ich das SSP mit oder ohne den reverse proxy aufrufe. In beiden Fällen funktioniert SSO jedoch nicht.

[SebastianPohl]

Hallo Torsten,

noch ein Nachtrag bzgl. der Systemzeit.

Im Agentenportal zeigen die Logs für den Frontend-Dienst "invalid Date" an -> kann hier ein Fehler mit der Systemzeit vorliegen?
Wenn ja, wo stelle ich die ein?

Danke im Voraus.

[Torsten Thau]

Hi Sebastian,
zum letzten schnell eine Antwort. Die "invalid date"-Amzeige ist nur ein Frontend-/Anzeige-Thema. Es besteht kein Zusammenhang zum SSO.
CU, Torsten

[Ulf Wagner]

Servus,

ich habe auch eine weile gebastelt, aber jetzt läuft es. 
HTTP/hostname@DOMAIN.GROßGESCHRIEBEN muss auf den HOST Eintrag gemäß DNS verweisen, nicht auf den/die Aliase des Frontend oder SSP. Das geht zwar wenn man es genau liest aus "hostname" hervor, explizit ist die Aussage aber nur schwer zu finden. 

Viele Grüße
Ulf