Forum Discussion
AltostratusKerberos Authentication Failing for Exchange 2016 Behind F5 Cloud WAF
To 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
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?
Altostratus
Thank 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?
- Kayjay88
Hi JoshBecigneul Yes internal users working without issue and they are not connected to WAF. their traffic directly go to our internal LB and from there to exchange server,
