SPNEGO/Kerberos-Authentifizierung für Outlook

mho · 2024-09-05T09:07:04+00:00

Gibt es irgendwo eine Anleitung, wie Kerberos-Anmeldung für Outlook Clients (also transparentes SSO für Outlook ohne Eingabe eines Kennwortes) eingerichtet w...

mho

Interessant finde ich folgendes Verhalten:

PC mit funktionierendem Outlook Profil (verbindet sich nachweislich per Kerberos)
Neues Outlook Profil einrichten => Fehler Abfrage nach Kennwort. - hat möglicherweise noch hiermit zu tun: https://learn.microsoft.com/en-us/outlook/troubleshoot/authentication/password-prompt-at-every-start-or-cannot-create-profile - setzt man UseOnlineContent auf 2 (=Allow), dann wird zumindest das Kennwort "angenommen", es kommt keine Abfrage bzgl. autodiscover und das Profil kann erstellt werden. Entgegen dem MS Artikel scheint der Default eher 0 (=deny) zu sein, was zu "etwas ist schief gelaufen" beim Profil einrichten führt.
So oder so kommt aber wenigstens einmal eine Abfrage nach dem Kennwort
Hat man es nun irgendwie geschafft ein Profil anzulegen, funktioniert dieses aber nicht, weil beim öffnen von Outlook ständig nach dem Kennwort gefragt wird!!!
Nun kommt es: Öffnet man nun das vorher bereits funktionierend Profil in Outlook, kommt hier das gleiche Fehlverhalten - ständige Abfragen nach Kennwort.
Startet man nun den gromox http Dienst neu, funktionieren beide (!) Profile einwandfrei
Klingt für mich, als ob sich da auf der Serverseite was verklemmt!? Wie könnte man das genauer testen?

mho

WalterH

da bin ich mir nicht sicher, u.U. muss http_krb_service_principal=gromox/adsdomain.local@ADSDOMAIN.LOCAL sein. das muss man noch testen. Wobei bei mir beides nicht funktioniert.

hätte ich auch gedacht, aber da kamen so merkwürdige Konstrukte im gromox http Log wie gromox\/adsdomain.local@ oder so ähnlich zustande und er hat sich beschwert, dass er dazu keinen Eintrag in der Keytab finden kann. Und Kerberos hat natürlich dann garnicht funktioniert. Logisch, wenn er den Eintrag nicht zuordnen kann.

Nur mit der o.g. Konfiguration sieht es für mich erstmal "sauber" aus, da er den Eintrag in der Keytab findet.

WalterH

Ich werde es am Abend testen, wenn ich die Outlooks abhängen kann.

CombinedNetworks

Hallo zusammen
Ich habe es nach einigen Nächten geschafft, Outlook authentisiert sich mit grommunio über Kerberos. Ich werde eine Anleitung in den nächsten Tagen schreiben und hier posten. Wer dringend Infos benötigt, kann sich melden. Allerdings ist grommunio mit Kerberos unstabil. Ich muss häufig den gromox-http-Dienst neu starten, weil sich aufhängt und dann kann Outlook nicht mehr anmelden und es kommt ein Popup.
Ich habe gerade heute grommunio auf dem neuesten Stand aktualisiert und das Problem ist leider nicht behoben. Ich werde in den nächsten Tagen weitere Tests durchführen.

mho

Stellt sich bei mir auch so dar. Seit ich noch die Namen autodiscover.maildomain.de und remote.maildomain.de zu den Intranet Seiten in den Internetoptionen eingetragen hab, funktioniert Kerberos prinzipiell und ich bekomme auch keine Warnmeldung mehr bzgl. Umleitung auf autodiscover.....

Leider bleiben zwei Probleme: Zum einen wird beim Neueinrichtung eines Outlook Clients immer einmal nach einem Kennwort gefragt - warum er da noch kein Kerberos nimmt ist mir ein Rätsel.
Technisch macht Outlook da zwei Anfragen an den Server:

eine mit einem leere Bearer Token und bekommt als Antwort 401 mit basic oder negioate als mögliche Anmeldungen.
Daraufhin die zweite Anfrage, wieder ohne Kerberos Token, wieder 401 als Antwort mit basic oder negioate. Dann kommt beim Outlook das Anmeldefenster. Warum er da nicht einfach mal ein Kerberos "versucht" erschließt sich mir im Moment nicht ganz. Füllt man das Anmeldefenster einmalig - ohne Kennwort speichern aus, funktioniert ab da alles per Kerberos.
Das wäre aber in der Praxis zu verschmerzen.

Viel gravierender ist die von Dir erwähnte Instabilität - sprich nach 3-4 "Stunden" Laufzeit funktioniert sporadisch das Kerberos nicht mehr - im Log des gromox-http steht dann:

Sep 13 12:44:29 remote gromox-http[25602]: E-9996: Unable to accept security context: Invalid token was supplied
Sep 13 12:44:29 remote gromox-http[25602]: E-9996: Unable to accept security context: Unknown error

Und Outlook quittiert das durch Anmelde-Fenster, die allerdings kein korrektes Kennwort akzeptieren.
Neustart des gromox-httpDienstes behebt das Problem für einige Stunden.

Kerberos Tickets am Client sind noch vorhanden und auch noch gültig.

CombinedNetworks

Autodiscover kann beide Authentifizierungsmethoden (Kerberos und Basic), weil auch für die Anbindung von Smartphones über das Internet verwendet wird. Vermutlich versucht Outlook bei Autodiscover zuerst Basic Auth und erst dann Kerberos. Ein Test mit dem CTRL+Rechtsklick auf das Outlook-Icon in der Taskleiste -> Test Email AutoConfiguration zeigt ebenfalls einige "Basic Auth Packages". Im Exchange Bereich gibt es neben /mapi noch /ews, /oab, usw. und ich weiss nicht, ob die Konfiguration für grommunio alle Services berücksichtigt. Ich habe mich immer gefragt, wie kann ich gezielt die Authentifizierung für jeden Ordner konfigurieren. Die Datei http.cfg ist für alle Unterordner /mapi, /ews, /oab, usw. zuständig?

Ich habe die gleiche Fehlermeldungen im Log gromox-http. Manchmal nach 30-40 Minuten, manchmal nach 3 Stunden oder länger. Wie schon geschrieben, gromox-http neu starten und dann ist wieder gut.

Ich werde heute noch ein Supportfall bei grommunio eröffnen und die Logs senden.

Was bei mir entscheidend für die Kerberos-Konfiguration war: SPN und A- bzw. PTR-Record verwenden und keine CNAME/Alias. Ich habe die Anleitung fast fertig.

Nächster Schritt ist die Konfiguration über den Reverse Proxy. Da erwarte ich noch einige Überraschungen.

CombinedNetworks

Unsere Anleitung ist online auf dem Blog:
https://blog.combined.swiss/index.php/blog-item/combined-expert-kerberos-authentifizierung-fuer-outlook-und-grommunio.html
So haben wir Kerberos zum Laufen bekommen. Allerdings ist der Dienst gromox-http unstabil. Da haben wir ein Supportfall bei grommunio offen.

WalterH

CombinedNetworks Eine Frae dazu, in der /etc/gromox/http.cfg wird diese Zeile eingetragen: http_krb_service_principal=gromox@mail.domain.ch, also gromox@... jedoch werden 4 verschiedene SPN erstellt:

setspn -S gromox/mail.domain.ch gromox
setspn -S gromox/dc01.domain.ch gromox
setspn -S HTTP/mail.domain.ch gromox
setspn -S HTTP/autodiscover.domain.ch gromox

Die beiden SPN mit HTTP/... wo werden diese beiden SPN verwendet?
Die beiden mit gromox/... verstehe ich, die beiden mit HTTP/... nicht. Kann man die mit HTTP/... weglassen?

crpb

Wegen sinnfreien verbindunge nzu autodiscover würde ich empfehlen das mal mit der konfiguration zu testen wie ich sie oben geschreben habe. Also nur SRV DNS Eintrag. Damit ist halt klipp und klar, geh da hin und sonst nirgends.
Vielleicht verbessert das ja die gesamtsituation _kicher`

CombinedNetworks

WalterH
In der Datei /etc/gromox/http.cfg ist der Benutzer (Service Account) eingetragen. Ich kann nur einen Benutzer eintragen, mehrere Einträge funktionieren nicht. Ich habe zuerst nur mit dem SPN gromox/mail.domain.ch getestet und es hat nicht funktioniert. Im Log waren auch Hinweise über HTTP/.... und den Domain Controller. Danach habe ich alle 4 SPN erfasst. So hat es funktioniert. Ich habe dann den Eintrag für den Domain Controller entfernt und es hat wieder nicht funktioniert. Anscheinend braucht grommunio alle 4 Einträge. Da diese zum Benutzer gemappt sind (mapuser Parameter bei ktpass.exe) findet grommuio alle SPN. Die Keytab-Datei beinhaltet aber nur den SPN gromox/mail.domain.ch.

Ich habe explizit nicht getestet, ob nur HTTP/mail... oder nur HTTP/autodiscover.... einzeln funktionieren. Ich habe immer beide zusammen getestet. Bei mir sind aber die HTTP-Einträge und der Eintrag für den Domain Controller zwingend nötig, sonst funktioniert nicht.

Getestet habe ich im LAB mit 1 DC (Windows Server 2022 mit GUI), VM mit Windows 10 22H2 Pro und Oulook 2021 LTSC. Client und DC sind in 2 separate virtuelle Netzwerke, Firewall-Regel sind eingerichtet und Domain-Join/Kommunikation ist OK.

Es läuft eben, aber gromox-http crasht sehr häufig.

Ob jetzt die Konfiguration korrekt ist, weiss ich nicht. Es funktioniert einfach. Da muss grommunio selbst einspringen und eine saubere Dokumentation liefern.

Ich habe zum Thema ein Ticket bei grommunio offen. Sobald Neuheiten kommen, werde ich sie posten.

CombinedNetworks

Hallo zusammen

Ich habe leider immer noch keine News vom grommunio Support betreffend der gromox-http Problematik.
Inzwischen habe ich aber die Konfiguration mit dem Reverse Proxy und Kerberos zum Laufen bekommen, allerdings nur mit Zertifikats-Authentifizierung am Client:
Outlook -> Reverse Proxy (FortiWeb) -> grommunio
Client authentisiert mit einem Benutzerzertifikat, Reverse Proxy und grommunio mit Kerberos.
An die grommunio-Konfiguration habe ich nichts angepasst und ich benutze das gleiche Keytab-File von grommunio auch für den Reverse Proxy.
Die Abstürze von gromox-http bleiben leider immer noch.
Ich werde noch eine Dokumentation für den Reverse Proxy schreiben.

mwilliams

CombinedNetworks

Das beschriebene Verhalten ist bei den Entwicklern in Prüfung.

CombinedNetworks

mwilliams
Vielen Dank für die Info.

high

Funktioniert das ganze jetzt eigentlich oder ist da noch was offen? Ich habe diese Voraussetzung auch gerade zum prüfen!

CombinedNetworks

high
Also, wir haben mit den aktuellsten Release alles nochmals getestet. Leider haben wir die gleiche Probleme wie letztes Jahr. Es hat sich nichts verbessert. gromox-http stützt ab, wenn wir die Kerberos-Konfiguration im Einsatz haben. Wir haben noch zusätzliche Tests ausgeführt, z.B. mit einem Standard SPN HTTP/.... statt gromox/..... und diverse Einstellungen versucht. Wir haben also versucht, Outlook über einen externen Proxy zu verbinden, was auch sehr gut funktioniert. Aber die ganze Konfiguration läuft nicht stabil. Ich werde in den nächsten Tagen ein Supportfall eröffnen.
Persönlich finde ich das Produkt so nicht enterprise-ready. Die Integration mit MFA und Reverse Proxy braucht Tagen und läuft nicht gut. Ich versuche jetzt einen anderen Weg. Ich werde die externe Clients direkt via VPN verbinden (IPSec). So kann ich die MFA mit Zertifikate oder Smartphone einrichten und ich muss am grommunio gar nichts ändern. Es ist schneller implementiert, einfacher und läuft stabil. Wir haben also versucht, SSO mit Webmail zu konfigurieren, über den Reverse Proxy. Auch hier nur Tagen verschwendet und keine funktionierende Lösung.

jengelh

Von einem Absturz war nichts sichtbar (kein Coredump). Stattdessen im gromox-http-Log:

E-9996: Unable to accept security context: Invalid token was supplied
E-9996: Unable to accept security context: Unknown error

Den String findet man wieder in auth_krb():

        auto ret = gss_accept_sec_context(&status, &ctx.m_gss_ctx,
                   ctx.m_gss_srv_creds, &gss_input_buf, GSS_C_NO_CHANNEL_BINDINGS,
                   &gss_username, nullptr, &gss_output_token, nullptr, nullptr, nullptr);
        if (gss_output_token.length != 0)
                output.assign(static_cast<const char *>(gss_output_token.value), gss_output_token.length);
        else
                output.clear();

        if (ret == GSS_S_CONTINUE_NEEDED)
                return -99; /* more authentication forth and back needed */
        output.clear();
        if (ret != GSS_S_COMPLETE) {
                krblog("Unable to accept security context", ret, status);
                return 0;
        }

Das ist in etwa die Abfolge wie man sie in squid, samba und kgwc findet.

Als Admin könnte man versuchen, auf SSO via NTLMSSP auszuweichen, indem man in http.cfg gss_program=/usr/bin/ntlm_auth ... wie dort beschrieben einträgt. Dazu setzt man dann samba-winbindd auf. Dann macht smbd/winbindd das GSS-Gedöns und Gromox leitet die Negotiate-Header nur weiter. Das Ergebnis würde mich interessieren.

jengelh

Mit gromox-3.0.34 ist GSS einsatzfähig, entweder mit dem Squid-Helper (Test mit squid-6.10) oder wahlweise nativ.

WalterH

jengelh Danke, nun fehlt nur mehr eine Erklärung welche SPN man anlegen muss?

iconics

jengelh

Wird es für dieses Feature noch eine offizielle Dokumentation geben? Ich kriege es mit den vorhandenen Informationen in diesem Thread und in https://docs.grommunio.com/man/http.8gx.html nicht zum Laufen.

Ich bin mir sicher, dass die grundsätzlichen Kerberos-Parameter funktionieren und meine krb5.keytab korrekt ist. Denn:

# kinit -k HTTP/grommunio.firma.de
Kein Fehler.

# klist
Ticket cache: DIR::/run/user/0/krb5cc/tkt
Default principal: HTTP/grommunio.firma.de@FIRMA.LOCAL

Valid starting     Expires            Service principal
11/06/25 16:28:32  11/07/25 02:28:32  krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
        renew until 11/07/25 16:28:32

Passt. Dann:

# /usr/lib/squid/negotiate_kerberos_auth_test grommunio.firma.de
Token: YIIGgAY....

Der letzte Baustein muss die Gromox-Konfiguration sein, die noch nicht passt. Ich habe in der /etc/gromox/http.cfg:

http_auth_spnego=yes
gss_program=/usr/lib/squid/negotiate_kerberos_auth -s HTTP/grommunio.firma.de@FIRMA.LOCAL

Das funktioniert nicht. Eine Anmeldung in Outlook ist nicht mehr möglich. Es wird in einer Endlosschleife nach einem Passwort gefragt. Bisher habe ich nicht verstanden, wie ich den Squid-Helper sinnvoll debuggen kann.

Die native Implementierung habe ich auch probiert:

http_auth_spnego=yes
http_krb_service_principal=HTTP/grommunio.firma.de@FIRMA.LOCAL

Ebenso probiert ohne "@FIRMA.LOCAL"

Dann steht in journalctl, sobald Outlook versucht mit GSS zu authentifizieren:

Nov 06 16:37:52 grommunio gromox-http[23525]: E-9996: Unable to acquire credentials handle: No credentials were supplied, or the credentials were unavailable or inaccessible
Nov 06 16:37:52 grommunio gromox-http[23525]: E-9996: Unable to acquire credentials handle: No key table entry found matching HTTP\/grommunio.firma.de/firma.local@

Hier wird also der konfigurierte SPN nicht korrekt interpretiert.

jengelh

Administrator fragen. Kann auch GSS_C_NO_NAME sein. Orientier dich bei allen Kerberos-Dingen an Squid, die GSS-Logik ist dieselbe. https://manpages.debian.org/testing/squid/negotiate_kerberos_auth.8.en.html

WalterH

jengelh Administrator fragen.

Nein grommunio fragen. Ich versuche es so zu erklären.
Als Beispiel ein Kunde, der extern die Domain kunde.at verwendet, auf der gibt es auch den A Record autodiscover.kunde.at. Intern für die AD Domain wird kunde.local verwendet. Intern gibt es einen Splitt DNS damit autodiscover.kunde.at auf den grommunio Server zeigt. Zusätzlich gibt es eine 2. Domain die sonstwer.com lautet und auch den autodiscover.sonstwer.com hat.
Welche SPNs muss ich nun anlegen? Das kann man dann als Blaupause für alle anderen nehmen.

amaccuish

WalterH Du musst für alle Hostnames den entsprechenden HTTP SPN anlegen. Wenn der Server auch unter dem externen Hostnamen erreichbar sein soll, benötigst du dafür auch einen SPN. Sonst kommt ja keine Kerberos Authentifizierung zustande.

« Previous Page Next Page »