Vorab gesucht
Wir haben das Forum nach ähnlichen Fällen durchsucht. Gefunden haben wir:

SPNEGO/Kerberos-Authentifizierung für Outlook: Dort wird von instabilem gromox-http mit Kerberos berichtet, eine Ursache wird nicht genannt.
Outlookprobleme nach Update 25.05.2026 und EWS hangs while gromox-http stays active: Outlook hängt dort, allerdings ohne Bezug zu Kerberos und mit älteren gromox-Versionen.

Einen Beitrag zu upstream prematurely closed connection im Zusammenhang mit MAPI und einem externen gss_program haben wir nicht gefunden.

Umgebung
grommunio 2026.06.2 (openSUSE Leap 16.0),
gromox 3.12.158,
grommunio-admin-api 1.21.23,
nginx 1.27.2 mit grommunio-Standardkonfiguration,
squid 6.14 (nur negotiate_kerberos_auth),
Outlook LTSC 16.0.17932 (classic, MAPI/HTTP, Online-Modus),
AD auf Windows Server 2022.

Hintergrund: UPNs bei uns nicht "Standard"

AD-Realm ist AD.LOCAL. Die UPNs der Benutzer entsprechen aber der Mailadresse (user@maildomain.de, über ein zusätzliches UPN-Suffix). Der sAMAccountName ist z. B. M.Mustermann.
Kerberos liefert als Client-Namen immer sAMAccountName@AD.LOCAL, nicht den UPN.
Der LDAP-Sync (Vorlage ActiveDirectory) setzt als Altname den sAMAccountName ohne Realm. ldap_user_altname übernimmt genau ein Attribut 1:1, eine Umformung ist nicht möglich, und es gibt nur einen Altnamen pro Benutzer. Ein AD-Attribut mit name@AD.LOCAL gibt es nicht, der implizite UPN steht in keinem Attribut.
Mit internal-gss sucht gromox deshalb M.Mustermann@AD.LOCAL und findet niemanden:
ntlm/krb auth success on "M.Mustermann@AD.LOCAL", but not found in Gromox
Wir nutzen daher den Squid-Helfer mit -r. Damit funktioniert SSO:

http_auth_spnego=yes
gss_program=/usr/libexec/squid/negotiate_kerberos_auth -r -s GSS_C_NO_NAME -k /etc/gromox/http.keytab

Beobachtetes Verhalten

Mit dem externen Helfer nimmt gromox-http vereinzelt Anfragen an, antwortet aber nie und schließt die Verbindung.
nginx meldet upstream prematurely closed connection while reading response header from upstream.
Betroffen sind auch Clients, die sich per Basic anmelden, solange http_auth_spnego=yes mit externem Helfer aktiv ist.
gromox selbst protokolliert dazu nichts, auch nicht mit http_log_level=6. Im http_debug-Mitschnitt sieht man die eingehende Anfrage, aber keine Antwort.
Kein Absturz und kein Neustart von gromox-http, der Dienst läuft weiter.

Messung, jeweils ein Outlook-Start mit ca. 60 Sekunden Auswertung:

SPNEGO über Squid-Helfer: 640 / 873 / 714 MAPI-Anfragen, davon 3 / 5 / 5 Abbrüche
http_auth_spnego=no (nur Basic): 588 MAPI-Anfragen, 0 Abbrüche
SPNEGO mit internal-gss (Testaltname name@AD.LOCAL von Hand): 894 MAPI-Anfragen, 0 Abbrüche

Unsere Vermutung: Es hängt damit zusammen, dass pro Verbindung ein Helferprozess gestartet und beendet wird.

Erwartetes Verhalten
Jede Anfrage bekommt eine Antwort (200 bzw. 401 zur Aushandlung), unabhängig davon, ob SPNEGO über internal-gss oder über ein externes gss_program läuft. So verhält es sich auch mit http_auth_spnego=no und mit internal-gss.

Reproduktion

grommunio mit LDAP-Sync aus dem AD, Altname = sAMAccountName (Vorlage ActiveDirectory).
Server per adcli join in die Domäne aufnehmen, SPNs HTTP/<host> und HTTP/autodiscover.<maildomain>. Daraus eine Keytab nur mit den HTTP-Einträgen für gromox erzeugen (root:gromox 0640).
http.cfg wie oben (Squid-Helfer mit -r), systemctl restart gromox-http.
nginx mit grommunio-Standard (server localhost:10443;).
Auf einem Windows-PC in der Domäne Outlook (classic) starten. Bei uns öffnet Outlook dabei 7 Postfächer gleichzeitig (eigenes und freigegebene), das erzeugt viele parallele MAPI-Anfragen.
In /var/log/nginx/nginx-mapi-error.log bzw. nginx-error.log erscheinen innerhalb der ersten Minute upstream prematurely closed connection …, gefolgt von no live upstreams. Parallel angemeldete Basic-Clients sind ebenfalls betroffen.
Gegenprobe: http_auth_spnego=no bzw. gss_program=internal-gss → keine Abbrüche.

Folge mit der Standard-nginx-Konfiguration
server localhost:10443; ergibt zwei Upstream-Einträge (127.0.0.1 und ::1) mit den Standardwerten max_fails=1 und fail_timeout=10s. Nach je einem Abbruch folgt no live upstreams, und alle Benutzer bekommen etwa 10 Sekunden lang 502. Outlook hängt dann beim Start und weicht auf den SRV-Weg aus, inklusive Umleitungsabfrage.

Workaround: server localhost:10443 max_fails=0; in /usr/share/grommunio-common/nginx/upstreams.d/gromox.conf. Damit scheitert nur noch die einzelne Anfrage, und Outlook wiederholt sie unbemerkt. Die Datei wird aber bei jedem Update von grommunio-common überschrieben. Wir setzen den Wert deshalb per Monitoring-Skript nach Updates automatisch neu.

Vorschlag: Upstream über eine Zusatzdatei anpassbar machen
/etc/grommunio-common/nginx/upstreams.d/*.conf wird zwar vor der Paketdatei eingebunden. Ein zweites upstream gromoxhttp ist in nginx aber nicht erlaubt, und die proxy_pass-Zeilen stehen in den Paketdateien. Es gibt also derzeit keinen updatesicheren Weg, Parameter wie max_fails, fail_timeout oder keepalive anzupassen. Möglich wäre z. B.:

die server-Zeile bzw. den Inhalt des Upstream-Blocks in eine Datei unter /etc/grommunio-common/nginx/ auslagern, die als %config(noreplace) ausgeliefert und im Upstream-Block per include eingebunden wird (ähnlich wie bei ssl_*.conf), oder
einen optionalen include /etc/grommunio-common/nginx/gromoxhttp-*.conf; im Upstream-Block vorsehen.

Eventuell wäre auch max_fails=0 als Standard sinnvoll, da es ohnehin nur ein einziges Backend gibt.

Fragen

Ist das Verhalten mit externem gss_program bekannt?
Wäre eine Option denkbar, bei der internal-gss den Realm vor der Benutzersuche abschneidet, analog zu -r beim Squid-Helfer, z. B. per Schalter in http.cfg? Dann bräuchten Umgebungen mit abweichenden UPNs keinen externen Helfer.