Recently we helped one of our customers to identify and troubleshoot a Kerberos authentication issue after they switched the load balancer of PingFederate from AWS to Akamai with a DNS change. In this article we’ll cover some basics of the Kerberos authentication troubleshooting process.
First, let’s have a quick high-level review of how Kerberos authentication is working with PingFederate:
- When a browser based authentication request comes to PingFederate, it will invoke the Kerberos IdP adapter (or IWA IdP adapter) as needed (for example, based on auth policy configuration).
- Then PingFederate will set a header of ‘WWW-Authenticate: Negotiate’ in the response which is a challenge for either Kerberos or NTLM token from the client (ie, user browser).
- Upon receiving this response, the browser would query DNS by using the hostname to determine the SPN (Service Principal Name), which would be used to lookup the specific service ticket at the operating system level.
- On the backend, the operating system would then send a request to DC/KDC for the service ticket for that specific SPN by exchanging the TGT (ticket grant ticket) which was initially issued/generated by DC/KDC and stored in the system upon user login to this machine.
- Upon receipt of the service ticket back from DC/KDC, the browser will then provide this back to PingFederate in the request as the ‘Authorization’ header.
- PingFederate would then validate the Kerberos token received against DC/KDC, and upon successful validation, would be able to get the user identity from that Kerberos token and return success of authentication.
Back to our customer’s specific issue, we confirmed (using Fiddler trace) PingFederate did its job to challenge the browser for Kerberos ticket, however for some reason the browser wasn’t able to get the Kerberos service ticket which caused the authentication fall back to NTLM. It seems something was not going well in step 3 (above), so we determined to use Wireshark to further investigate the communication between the browser and the DC/KDC.
In the Wireshark trace, we saw the service principal name (SPN) was not correct (which should be the base url of PingFederate, ie. sso.company.com).
This caused the error returned from DC/KDC complaining about unknown SPN.
Based on the trace, we believed the possible reason was when browser canonicalizing the service principal name (SPN), it was using reverse DNS, it somehow no longer matched the desired SPN of sso.company.com, so no Kerberos service ticket could be found. We then checked the DNS entry for sso.company.com.
We noticed that the base URL of PingFederate was changed to be a CNAME (alias) instead of an address record (A record) in DNS as it used to be. Because browsers determine the service principal name using the canonical name of the host (sso.company.com), where the canonical name of a host is the first “A” record returned when resolving a DNS name to an address. That explained why the browser construct the Service ticket request for e13524.a.akamaiedge.net, not for sso.company.com. To solve that issue, we added additional SPN in DC/KDC which fixed this issue.
As you know, sometimes the Kerberos authentication issue might be hard to troubleshoot as it requires several parties to be configured properly to make it work. Generally, you need a tool like Fiddler to capture the browser traffic to investigate any issue on http/tcp layer and you may need Wireshark to capture messages in the KBR5 protocol to investigate the communication with KDC. In addition to those, tools would be useful to check the service tickets and TGT in local machine.
ProofID’s support team of certified Ping professionals are on hand 24/7 to help customers with technical support and product help. Your global identity security partner, providing peace of mind and focused on achieving your business outcomes. Learn more.
Be the first to hear about news, product updates, and innovation from proofid
