Warum dieser Test nach dem SSO-Upgrade wichtig ist

Teil 15 der Reihe hat das Upgrade von grommunio 2026.06.1 auf 2026.06.2 mit Keycloak SSO, MFA, AutoDiscover und Mailflow abgenommen. Dieser Beitrag schließt daran an: Was bedeutet zentrale Anmeldung praktisch für native Clients wie Thunderbird, Outlook, EWS und ActiveSync? Die Upgrade-Anleitung bleibt hier verlinkt: grommunio 2026.06.2 Upgrade und technische Abnahme.

Die wichtigste Erkenntnis: Browser-SSO und native Mailprotokolle sind unterschiedliche Prüfbereiche. Keycloak kann Web-Logins und OIDC-fähige Anwendungen zentralisieren, aber IMAP, SMTP, EWS, CalDAV, CardDAV und EAS müssen nach einem Upgrade separat getestet werden. Ein erfolgreicher Web-Login ersetzt keine Client-Abnahme.

Kurzüberblick

Thunderbird wurde mit einem frischen Profil gegen die aktualisierte Appliance geprüft. AutoConfig, AutoDiscover V1/V2, IMAP, SMTP, EWS und ActiveSync wurden technisch nachgewiesen. CalDAV und CardDAV sind als DAV-Erreichbarkeit geprüft, aber nicht als vollständiger Kalender- und Kontakte-CRUD. Outlook wurde ohne echte GUI-/MAPI-Abnahme bewusst nicht als PASS bewertet.

MFA wurde für Browser-SSO eingeordnet, nicht pauschal auf native Protokolle übertragen. Genau diese Trennung ist für Kunden wichtig, die grommunio mit Keycloak produktiv betreiben.

Screenshot: Thunderbird 156.0 mit frischem Profil und grommunio-IMAP-Konto nach dem Upgrade. Die Oberfläche stammt aus einer isolierten GUI-Testumgebung; bewertet wurden Profil, Login, Inbox, IMAP, SMTP und Mailflow.

Prüfgrundlage im Lab

Appliance

Wert
grommunio 2026.06.2 auf openSUSE Leap 16.0
Einordnung
Upgrade-Zielstand nach 2026.06.1

Systemstatus

Wert
Keine fehlgeschlagenen systemd Units, kein Reboot-Bedarf laut zypper ps -s
Einordnung
Betrieblich sauberer Startpunkt

Benutzer

Wert
alice@example.test und bob@example.test
Einordnung
Getrennte Testkonten für Client- und Mailflow-Prüfung

Client

Wert
Thunderbird 156.0 mit isoliertem Profil
Einordnung
Keine Altlasten aus bestehenden Profilen

SSO-Kontext

Wert
Keycloak/OIDC für Browser-Flows bereits in Teil 15 abgenommen
Einordnung
Native Protokolle zusätzlich separat geprüft

Thunderbird AutoConfig

Thunderbird soll nach Möglichkeit nicht durch manuelle Servereinträge erraten werden, sondern über AutoConfig sinnvolle Einstellungen erhalten. Geprüft wurden die bekannten AutoConfig-Pfade mit Host/SNI auf mail.example.test. Beide relevanten Pfade lieferten XML und waren damit für die Kontokonfiguration verwendbar.

/.well-known/autoconfig/mail/config-v1.1.xml
/mail/config-v1.1.xml

Für eine Kundenumgebung sollte derselbe Test mit dem echten Mail-FQDN, gültigem TLS-Zertifikat und extern erreichbarem DNS wiederholt werden. Wichtig ist, dass die Antwort nicht nur HTTP 200 liefert, sondern die erwarteten IMAP-/SMTP-Hosts und Ports enthält.

bash
curl -fsS https://mail.example.test/.well-known/autoconfig/mail/config-v1.1.xml
curl -fsS https://mail.example.test/mail/config-v1.1.xml

IMAP und SMTP wirklich testen

Für den Benutzer zählt nicht, ob ein Port offen ist, sondern ob Thunderbird sich anmelden, Ordner lesen, Mail senden und Zustellung sehen kann. Deshalb wurden IMAP-Folder-Listing, SMTP Submission mit STARTTLS/AUTH und ein Mailflow von Alice zu Bob geprüft. Zusätzlich wurde eine Nachricht mit Attachment erzeugt.

bash
openssl s_client -starttls imap -connect mail.example.test:143 -servername mail.example.test
openssl s_client -starttls smtp -connect mail.example.test:587 -servername mail.example.test

IMAP Login

Erwartung
Client kann sich authentifizieren und Ordner lesen
Ergebnis
PASS

SMTP Submission

Erwartung
STARTTLS und SMTP AUTH akzeptieren den Benutzer
Ergebnis
PASS

Mailflow Alice zu Bob

Erwartung
Nachricht wird zugestellt und per IMAP gefunden
Ergebnis
PASS

Attachment

Erwartung
Nachricht mit Anhang wird angenommen und zugestellt
Ergebnis
PASS

Reply im GUI-Client

Erwartung
Antwort wird im Client erzeugt und zugestellt
Ergebnis
NOT TESTED

Sent Items im GUI-Client

Erwartung
Gesendete Nachricht erscheint im Ordner Gesendet
Ergebnis
PARTIAL

AutoDiscover, EWS und Outlook

AutoDiscover ist für Exchange-nahe Clients entscheidend. V1 und V2 wurden technisch geprüft. EWS wurde mit einem SOAP-GetFolder-Test validiert. Das ist ein belastbarer Protokollnachweis, ersetzt aber keinen echten Outlook-GUI- oder MAPI-Test. Darum bleibt Outlook in dieser Abnahme bewusst NOT TESTED.

Praktisch wichtig ist der Unterschied zwischen Discovery und Client-Abnahme: AutoDiscover kann korrekt antworten, obwohl ein bestimmter Client später trotzdem an Profil, Zertifikat, Authentifizierungsart oder Richtlinien scheitert. Deshalb gehören AutoDiscover, EWS und ein echter Clienttest getrennt dokumentiert.

AutoDiscover V1

Prüfung
POST auf /Autodiscover/Autodiscover.xml
Ergebnis
PASS

AutoDiscover V2 EWS

Prüfung
JSON-Discovery für alice@example.test mit Protocol=EWS
Ergebnis
PASS

EWS

Prüfung
SOAP GetFolder gegen msgfolderroot
Ergebnis
PASS

Outlook GUI / MAPI

Prüfung
Echtes Outlook-Profil mit Mailflow und Kalender
Ergebnis
NOT TESTED

ActiveSync und mobile Clients

ActiveSync wurde als Protokollpfad mit kontrolliertem Client geprüft. Für produktive Freigaben sollte zusätzlich ein echtes iOS- oder Android-Gerät gegen die Kundenrichtlinien getestet werden. Der detaillierte MDM-Kontext aus der Reihe bleibt hier relevant: grommunio MDM 2026 Schritt für Schritt.

bash
curl -I https://mail.example.test/Microsoft-Server-ActiveSync

EAS Challenge

Prüfung
Microsoft-Server-ActiveSync liefert erwartete Auth-Challenge
Ergebnis
PASS

EAS kontrollierter Client

Prüfung
FolderSync-/Protokollpfad technisch geprüft
Ergebnis
PASS WITH CONDITIONS

Echtes Mobilgerät

Prüfung
iOS/Android mit Policy, Sync und Remote-Wipe
Ergebnis
NOT TESTED

CalDAV und CardDAV

Kalender und Kontakte dürfen nicht aus der Mailprüfung abgeleitet werden. Im Lab wurden DAV-Discovery und authentifizierter PROPFIND geprüft. Das reicht für die Aussage, dass der DAV-Pfad grundsätzlich erreichbar ist. Vollständige Kalender- und Kontakte-CRUDs in Thunderbird bleiben eine eigene Client-Abnahme.

Wo Keycloak wirklich wirkt

grommunio Web

Typische Authentifizierung
Browser-SSO über Keycloak/OIDC
MFA-Einordnung
MFA kann im Browser-Flow greifen

grommunio Admin

Typische Authentifizierung
SSO/OIDC abhängig von Konfiguration
MFA-Einordnung
MFA kann im Browser-Flow greifen

grommunio Files

Typische Authentifizierung
OIDC/Browser-Flow
MFA-Einordnung
MFA kann im Browser-Flow greifen

grommunio Chat

Typische Authentifizierung
SSO-Zuordnung nach Migration prüfen
MFA-Einordnung
MFA kann im Browser-Flow greifen

Thunderbird IMAP/SMTP

Typische Authentifizierung
Native Protokollauthentifizierung
MFA-Einordnung
Nicht automatisch identisch mit Browser-MFA

EWS

Typische Authentifizierung
Exchange-Web-Service-Protokollauthentifizierung
MFA-Einordnung
Nicht als Browser-MFA werten

EAS

Typische Authentifizierung
ActiveSync-Protokollauthentifizierung
MFA-Einordnung
Gerätespezifisch testen

Outlook/MAPI

Typische Authentifizierung
Client- und Profilabhängig
MFA-Einordnung
Ohne echten Outlook-Test nicht behaupten

Technische Abnahme

PASS bedeutet, dass der konkrete Prüfpunkt im Lab ausgeführt und belegt wurde. PARTIAL und NOT TESTED bleiben bewusst sichtbar, damit aus einem erfolgreichen Browser-SSO keine falsche Aussage über alle nativen Clients entsteht.

Appliance Health

Prüfung
Paketstand, zypper ps -s, systemctl --failed, Dienste
Ergebnis
PASS

Thunderbird Profil

Prüfung
Frisches Profil, IMAP-Konto sichtbar, Inbox Screenshot
Ergebnis
PASS

Thunderbird IMAP

Prüfung
Login, Folder Listing, Inbox sichtbar
Ergebnis
PASS

Thunderbird SMTP

Prüfung
STARTTLS/AUTH und Zustellung
Ergebnis
PASS

Thunderbird Attachment

Prüfung
Nachricht mit Anhang erzeugt und zugestellt
Ergebnis
PASS

AutoConfig

Prüfung
Thunderbird-Konfigurations-XML über bekannte Pfade
Ergebnis
PASS

AutoDiscover V1

Prüfung
XML-AutoDiscover
Ergebnis
PASS

AutoDiscover V2

Prüfung
JSON-Discovery für EWS
Ergebnis
PASS

EWS

Prüfung
SOAP GetFolder
Ergebnis
PASS

EAS

Prüfung
Kontrollierter Protokolltest
Ergebnis
PASS WITH CONDITIONS

CalDAV/CardDAV

Prüfung
DAV Discovery und authentifizierter PROPFIND
Ergebnis
PARTIAL

Outlook GUI / MAPI

Prüfung
Echtes Outlook-Profil
Ergebnis
NOT TESTED

MFA native Clients

Prüfung
Nicht pauschal aus Browser-SSO abgeleitet
Ergebnis
PASS

Schritt-für-Schritt-Abnahme nach dem Upgrade

1

Was prüfen
Appliance Health, Dienste und Reboot-Bedarf prüfen
Warum wichtig
Clientfehler dürfen nicht von einem kaputten Grundsystem kommen

2

Was prüfen
AutoConfig und AutoDiscover mit dem echten Hostnamen testen
Warum wichtig
Clients brauchen funktionierende Discovery

3

Was prüfen
Thunderbird mit frischem Profil einrichten
Warum wichtig
Altprofile verschleiern Konfigurationsfehler

4

Was prüfen
IMAP, SMTP und Mailflow mit echten Testkonten prüfen
Warum wichtig
Web-Login beweist keinen Mailflow

5

Was prüfen
EWS separat prüfen
Warum wichtig
Exchange-nahe Clients hängen an eigener Discovery und Authentifizierung

6

Was prüfen
EAS mit realem Gerät nachtesten
Warum wichtig
Richtlinien, Sync und Geräteverhalten sind produktionsrelevant

7

Was prüfen
MFA-Matrix dokumentieren
Warum wichtig
Browser-MFA darf nicht mit nativer Protokollauth verwechselt werden

8

Was prüfen
Ergebnis mit PASS, PARTIAL und NOT TESTED festhalten
Warum wichtig
Kunden sehen sofort, was wirklich abgenommen wurde

Mindestprotokoll für Techniker

Damit die Abnahme nachvollziehbar bleibt, sollte das Ergebnis nicht nur als Freitext notiert werden. Bewährt hat sich ein kurzes Protokoll pro Client und Protokollpfad: Version, frisches oder bestehendes Profil, verwendeter FQDN, TLS-Status, Authentifizierungsart, erwartetes Ergebnis, tatsächliches Ergebnis und klare Bewertung.

Clientversion

Beispiel
Thunderbird 156.0
Warum erfassen
Screenshots allein zeigen die Paketversion nicht zuverlässig

Profilzustand

Beispiel
frisch angelegt
Warum erfassen
Altprofile können erfolgreiche Tests verfälschen

FQDN

Beispiel
mail.example.test
Warum erfassen
Discovery hängt an Hostname, SNI und Zertifikat

Auth-Pfad

Beispiel
IMAP/SMTP Basic, Browser-SSO separat
Warum erfassen
MFA und Keycloak nicht falsch vermischen

Testdaten

Beispiel
Alice sendet an Bob mit Attachment
Warum erfassen
Mailflow muss reproduzierbar sein

Bewertung

Beispiel
PASS, PARTIAL oder NOT TESTED
Warum erfassen
Offene Punkte bleiben sichtbar

Fazit

Nach dem Upgrade auf grommunio 2026.06.2 reicht es nicht, nur Web, Admin und Keycloak zu öffnen. Native Clients müssen mit ihren eigenen Protokollen abgenommen werden. Thunderbird, IMAP, SMTP, AutoConfig, AutoDiscover und EWS waren im Lab belastbar. EAS ist technisch nachgewiesen, braucht für Kundenfreigaben aber ein echtes Geräte-Szenario. Outlook/MAPI bleibt ohne echten Outlook-Test bewusst offen.

Genau diese saubere Trennung macht die Anleitung nachvollziehbar: zentrale Anmeldung verbessert den Browser- und SSO-Betrieb, aber jedes native Protokoll braucht nach dem Upgrade seine eigene Prüfung.