Why this test matters after the SSO upgrade

Part 15 covered the upgrade from grommunio 2026.06.1 to 2026.06.2 with Keycloak SSO, MFA, AutoDiscover and mailflow acceptance. This article continues from there: what does central login mean for native clients such as Thunderbird, Outlook, EWS and ActiveSync? The upgrade guide is linked here: grommunio 2026.06.2 upgrade and technical acceptance.

The most important lesson is simple: browser SSO and native mail protocols are different acceptance areas. Keycloak can centralize web logins and OIDC-capable applications, but IMAP, SMTP, EWS, CalDAV, CardDAV and EAS still need separate testing after an upgrade. A successful web login does not replace native client acceptance.

Overview

Thunderbird was tested with a fresh profile against the upgraded appliance. AutoConfig, AutoDiscover V1/V2, IMAP, SMTP, EWS and ActiveSync were technically validated. CalDAV and CardDAV were checked for DAV reachability, not full calendar and contacts CRUD. Outlook was deliberately not marked PASS without a real GUI/MAPI acceptance run.

MFA is classified for browser SSO and is not applied generically to native protocols. This distinction matters for customers running grommunio with Keycloak in production.

Screenshot: Thunderbird 156.0 with a fresh profile and a grommunio IMAP account after the upgrade. The UI was captured in an isolated GUI test environment; the acceptance covered profile, login, Inbox, IMAP, SMTP and mailflow.

Lab baseline

Appliance

Value
grommunio 2026.06.2 on openSUSE Leap 16.0
Classification
Target state after upgrading from 2026.06.1

System status

Value
No failed systemd units, no reboot required according to zypper ps -s
Classification
Clean operational starting point

Users

Value
alice@example.test and bob@example.test
Classification
Separate test accounts for client and mailflow checks

Client

Value
Thunderbird 156.0 with isolated profile
Classification
No legacy state from existing profiles

SSO context

Value
Keycloak/OIDC browser flows already accepted in part 15
Classification
Native protocols checked separately

Thunderbird AutoConfig

Thunderbird should not rely on guessed manual server entries where AutoConfig can provide correct settings. The known AutoConfig paths were checked with Host/SNI set to mail.example.test. Both relevant paths returned XML and were usable for account configuration.

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

In a customer environment, repeat the same check with the real mail FQDN, a valid TLS certificate and externally resolvable DNS. The response should not only return HTTP 200; it should contain the expected IMAP/SMTP hosts and ports.

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

Actually test IMAP and SMTP

For users, the relevant question is not whether a port is open. The client must authenticate, read folders, send mail and show delivery. The lab therefore checked IMAP folder listing, SMTP Submission with STARTTLS/AUTH and mailflow from Alice to Bob. A message with an attachment was also created.

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

Expectation
Client authenticates and reads folders
Result
PASS

SMTP Submission

Expectation
STARTTLS and SMTP AUTH accept the user
Result
PASS

Mailflow Alice to Bob

Expectation
Message is delivered and found through IMAP
Result
PASS

Attachment

Expectation
Message with attachment is accepted and delivered
Result
PASS

Reply in GUI client

Expectation
Reply is created and delivered in the client
Result
NOT TESTED

Sent Items in GUI client

Expectation
Sent message appears in Sent Items
Result
PARTIAL

AutoDiscover, EWS and Outlook

AutoDiscover is critical for Exchange-like clients. V1 and V2 were technically checked. EWS was validated with a SOAP GetFolder test. That is strong protocol evidence, but it does not replace a real Outlook GUI or MAPI test. Outlook therefore remains NOT TESTED in this acceptance run.

The practical distinction is important: AutoDiscover can answer correctly while a specific client still fails later because of profile state, certificates, authentication mode or policies. AutoDiscover, EWS and a real client test should therefore be documented separately.

AutoDiscover V1

Test
POST to /Autodiscover/Autodiscover.xml
Result
PASS

AutoDiscover V2 EWS

Test
JSON discovery for alice@example.test with Protocol=EWS
Result
PASS

EWS

Test
SOAP GetFolder against msgfolderroot
Result
PASS

Outlook GUI / MAPI

Test
Real Outlook profile with mailflow and calendar
Result
NOT TESTED

ActiveSync and mobile clients

ActiveSync was checked as a protocol path with a controlled client. For production acceptance, a real iOS or Android device should additionally be tested against the customer policy set. The MDM part of the series remains relevant here: grommunio MDM 2026 step by step.

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

EAS challenge

Test
Microsoft-Server-ActiveSync returns expected auth challenge
Result
PASS

EAS controlled client

Test
FolderSync/protocol path technically checked
Result
PASS WITH CONDITIONS

Real mobile device

Test
iOS/Android with policy, sync and remote wipe
Result
NOT TESTED

CalDAV and CardDAV

Calendars and contacts must not be inferred from mail tests. The lab checked DAV discovery and authenticated PROPFIND. That is enough to state that the DAV path is basically reachable. Full calendar and contacts CRUD in Thunderbird remains a separate client acceptance step.

Where Keycloak actually applies

grommunio Web

Typical authentication
Browser SSO through Keycloak/OIDC
MFA classification
MFA can apply in the browser flow

grommunio Admin

Typical authentication
SSO/OIDC depending on configuration
MFA classification
MFA can apply in the browser flow

grommunio Files

Typical authentication
OIDC/browser flow
MFA classification
MFA can apply in the browser flow

grommunio Chat

Typical authentication
SSO mapping must be checked after migration
MFA classification
MFA can apply in the browser flow

Thunderbird IMAP/SMTP

Typical authentication
Native protocol authentication
MFA classification
Not automatically identical to browser MFA

EWS

Typical authentication
Exchange Web Services protocol authentication
MFA classification
Do not count as browser MFA

EAS

Typical authentication
ActiveSync protocol authentication
MFA classification
Test device-specific behavior

Outlook/MAPI

Typical authentication
Client and profile dependent
MFA classification
Do not claim without a real Outlook test

Technical acceptance

PASS means the specific check was executed and evidenced in the lab. PARTIAL and NOT TESTED remain visible so a successful browser SSO flow is not mistaken for full native client acceptance.

Appliance health

Check
Package state, zypper ps -s, systemctl --failed, services
Result
PASS

Thunderbird profile

Check
Fresh profile, IMAP account visible, Inbox screenshot
Result
PASS

Thunderbird IMAP

Check
Login, folder listing, Inbox visible
Result
PASS

Thunderbird SMTP

Check
STARTTLS/AUTH and delivery
Result
PASS

Thunderbird attachment

Check
Message with attachment created and delivered
Result
PASS

AutoConfig

Check
Thunderbird configuration XML through known paths
Result
PASS

AutoDiscover V1

Check
XML AutoDiscover
Result
PASS

AutoDiscover V2

Check
JSON discovery for EWS
Result
PASS

EWS

Check
SOAP GetFolder
Result
PASS

EAS

Check
Controlled protocol test
Result
PASS WITH CONDITIONS

CalDAV/CardDAV

Check
DAV discovery and authenticated PROPFIND
Result
PARTIAL

Outlook GUI / MAPI

Check
Real Outlook profile
Result
NOT TESTED

MFA for native clients

Check
Not inferred generically from browser SSO
Result
PASS

Step-by-step acceptance after the upgrade

1

What to check
Check appliance health, services and reboot need
Why it matters
Client errors must not come from a broken baseline

2

What to check
Test AutoConfig and AutoDiscover with the real hostname
Why it matters
Clients need working discovery

3

What to check
Configure Thunderbird with a fresh profile
Why it matters
Old profiles can hide configuration problems

4

What to check
Check IMAP, SMTP and mailflow with real test accounts
Why it matters
Web login alone proves no mailflow

5

What to check
Check EWS separately
Why it matters
Exchange-like clients depend on separate discovery and authentication

6

What to check
Retest EAS with a real device
Why it matters
Policies, sync and device behavior are production-relevant

7

What to check
Document the MFA matrix
Why it matters
Browser MFA must not be confused with native protocol auth

8

What to check
Record PASS, PARTIAL and NOT TESTED
Why it matters
Customers immediately see what was actually accepted

Minimum technician log

To keep acceptance reproducible, do not record the result only as free text. A compact log per client and protocol path works well: version, fresh or existing profile, FQDN used, TLS status, authentication mode, expected result, actual result and explicit classification.

Client version

Example
Thunderbird 156.0
Why record it
Screenshots alone do not reliably prove package version

Profile state

Example
freshly created
Why record it
Old profiles can distort successful tests

FQDN

Example
mail.example.test
Why record it
Discovery depends on hostname, SNI and certificate

Auth path

Example
IMAP/SMTP Basic, browser SSO separate
Why record it
Avoid mixing MFA and Keycloak claims incorrectly

Test data

Example
Alice sends to Bob with attachment
Why record it
Mailflow must be reproducible

Classification

Example
PASS, PARTIAL or NOT TESTED
Why record it
Open points remain visible

Conclusion

After upgrading to grommunio 2026.06.2, opening Web, Admin and Keycloak is not enough. Native clients must be accepted with their own protocols. Thunderbird, IMAP, SMTP, AutoConfig, AutoDiscover and EWS produced solid evidence in the lab. EAS is technically validated but still needs a real device scenario for customer acceptance. Outlook/MAPI deliberately remains open without a real Outlook test.

That clean separation makes the guide reproducible: central login improves browser and SSO operations, but every native protocol needs its own post-upgrade check.