Forum Discussion
NimbostratusKerberos Authentication Failing for Exchange 2016 Behind F5 Cloud WAF
Hi Team,
We’re running Microsoft Exchange Server 2016 CU24 on Windows Server 2019, and have enabled Kerberos (Negotiate) authentication due to NTLM being deprecated in F5 Cloud WAF.
Environment summary:
- Exchange DAG setup: 4 servers in Primary Site, 2 in DR Site
- Active Directory: Windows Server 2019
- F5 Component: Cloud WAF (BIG-IP F5 Cloud Edition) handling inbound HTTPS traffic
- Namespaces: mail.domain.lk, webmail.domain.lk, autodiscover.domain.lk
- Authentication configuration: Negotiate (Kerberos) with NTLM, Basic, and OAuth as fallback
- SPNs: Correctly registered under the ASA (Alternate Service Account) computer account
- Certificate: SAN includes mail, webmail, and autodiscover
Current status:
- Internal domain-joined Outlook 2019 clients work without issue.
- Outlook 2016, Office 2021, and Microsoft 365 desktop apps continue to prompt for passwords.
- Internal OWA and external OWA through F5 Cloud WAF both work correctly.
Observation:
Autodiscover XML shows <AuthPackage>Negotiate</AuthPackage> for all URLs.
Kerberos authentication works internally, so SPNs and ASA setup are confirmed healthy.
Password prompts appear only when traffic passes through F5 Cloud WAF, which terminates TLS before reaching Exchange.
Suspected cause:
- F5 Cloud WAF may not support Kerberos Constrained Delegation (KCD) in the current configuration.
- TLS termination on F5 breaks the Kerberos authentication chain.
- NTLM/Basic fallback might not be fully passed through from WAF to backend.
We would appreciate clarification on:
- Does F5 Cloud WAF support Kerberos Constrained Delegation (KCD) for backend Exchange 2016 authentication?
- If not, can Kerberos pass-through or secure fallback methods (NTLM/Basic) be enabled?
- Recommended configuration for supporting Outlook 2016 and Microsoft 365 clients when Exchange advertises Kerberos (Negotiate)?
- Is there an F5 reference configuration or iRule template for this scenario (Exchange 2016 + Kerberos)?
Thank you for your guidance.
6 Replies
Its been a minute since I touched Kerberos auth, and the bulk of my knowledge is with BIG-IP (not XC), so hopefully I'm not misstating anything.
It is my understanding that Kerberos auth is not really supported for use over the open internet, since the AD/Kerberos server wouldn't be available.
F5's support for Kerberos Constrained Delegation is a feature of Access Policy Manager. As you mention, TLS termination also plays a role.
Some research indicates that the version of Exchange you mention should support Hybrid Modern Authentication. Is that an option in your environment?
Kayjay88Thank you again for your insights on Kerberos auth—it's helpful to have your perspective, especially on the BIG-IP side. I appreciate the note on Kerberos not being ideal over the open internet and the role of KCD in APM.
To clarify our setup: We're focusing Kerberos primarily for internal, domain-joined clients connecting to our on-premises Exchange servers (via Negotiate for Outlook Anywhere and MAPI/HTTP). However, we also need seamless connectivity for both domain-joined and non-domain-joined users accessing from outside our network (through the internet), such as remote workers or mobile devices. External access uses OWA/ActiveSync, so Kerberos isn't exposed directly to the internet. We've completed the on-premises config (ASA, SPNs on http/mail.<domain> and http/autodiscover.<domain>, virtual directories set to Negotiate), but we're seeing end-user password prompts in Outlook, suggesting a potential delegation or pass-through issue at the F5 layer.
Could you guide us on BIG-IP-side tweaks to resolve this? Specifically:
- Recommendations for enabling Kerberos Constrained Delegation (KCD) in APM policies or iRules to properly handle Negotiate auth delegation from BIG-IP to the backend Exchange servers, while supporting external access for both domain-joined and non-domain-joined users?
- Any common virtual server or pool configurations needed for Kerberos ticket forwarding (e.g., ensuring HTTP profiles support Negotiate without breaking external connectivity)?
- If there's a sample iRule or policy snippet for Exchange Kerberos that we could adapt, that would be gold.To clarify, are all internal users working as expected? Do internal users use the F5 Distributed Cloud WAF, or just the internal BIG-IP?
CodebydvTo enable authentication externally via XC/WAF, configure F5 APM to use Entra ID (or another external IdP) for user auth via SAML or OAuth, instead of negotiating NTLM/Kerberos at the front end — since the WAF will interfere with that exchange.
Once APM consumes the SAML/OAuth token, it can extract the user’s identity and use Kerberos Constrained Delegation (KCD) to request service tickets (TGTs) and present them to Exchange on behalf of the user.
APM acts as the SAML SP for Entra ID and uses Kerberos Constrained Delegation to grab tickets on behalf of the user.
If you haven’t seen it, check out the lab below — it walks through the F5 APM ↔ Entra ID ↔ KCD setup step-by-step:
https://clouddocs.f5.com/training/community/iam/html/class1/module3/lab01.html#task-1-publish-and-protect-bluesky-app
- Nikoolayy1
MVP
F5 XC does not support NTLM and probably it never will but in does Kerberos. I think http1.1 needed to be selected/hard coded between the client and XC and XC and origin servers. That is what I can share. XC on-boarding team should be also aware of this when you ask them this to be configured 😉
