WAP AD FS Token Validation Mismatch: Debugging Kerberos SPN Misconfiguration on Perimeter Layer

Question

WAP AD FS Token Validation Mismatch: Debugging Kerberos SPN Misconfiguration on Perimeter Layer

Michael Johnson 20

Hey everyone,

We’re hitting a wall with our edge infrastructure. Our perimeter WAP server is dropping inbound traffic to our secure internal HR portals, throwing continuous Kerberos auth failures in the logs.

The AD FS token looks good on paper, but we’re highly suspecting an SPN mismatch at the WAP proxy layer when it tries to perform constrained delegation to the backend.

Does anyone have a clean methodology for debugging and fixing the federation metadata validation mapping here? Looking for the fastest way to trace the exact validation handshake and fix the mapping without breaking adjacent relying party trusts.

Appreciate any insights or tools you can throw my way.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

I would first verify the assumption that WAP is the problem. If AD FS is issuing tokens successfully, federation metadata is likely not the root cause. WAP itself typically does not perform Kerberos constrained delegation in a standard AD FS publishing scenario.

The fastest troubleshooting path is to check the exact Kerberos error code and validate SPNs using:

setspn -X

setspn -L <service account>

Missing or duplicate SPNs are the most common cause of backend Kerberos failures.

Also review DC Security logs (Event IDs 4769 and 4771), AD FS Admin logs, and a network trace to identify whether the failure occurs during ticket issuance, service ticket lookup, or backend authentication. I would avoid modifying relying party trusts until SPN and delegation settings have been fully validated.