Kerberos rdns=false Breaking Connections From Linux Clients to Windows IIS Server

Recently I changed the krb5.conf file on Linux clients to use:

[libdefaults]
rdns = false

These clients can still successfully use kerberos auth to connect to other Linux webservers. However, now their connections break to IIS webservers. An example error I see is:

< HTTP/1.1 401 Unauthorized
< Content-Type: text/html
< Server: Microsoft-IIS/8.5
* gss_init_sec_context() failed: Server not found in Kerberos database.

However, when I remove rdns=false, the Linux clients can auth/connect without issue. I am able to consistently recreate this behavior by adding rdns=false and seeing failures and then removing it and seeing successes. Why does rdns=false break connections from Linux Clients to IIS Webservers?

But isn't this error coming from the IIS webserver?

No, it's coming from the GSSAPI library (libkrb5) used by curl.

Why does a client's configuration setting impact the webserver's functionality? ie- what does the webserver care if the client does a reverse lookup or not and how does it even know if the client does a reverse lookup?

Kerberos tickets get issued for a specific server FQDN, similar to TLS certificates. When you want to talk to app.example.com over HTTP, your client has to request a ticket for the HTTP/[email protected] service principal.

However, unlike TLS (which looks at the domain in your URL and nothing else), traditional Kerberos implementations determine the principal name using reverse DNS of the server's IP address, which can result in the client requesting tickets for a completely different SPN than the one displayed in the URL.

This is especially common with multiple domains pointing to single webserver, or with a domain using DNS round-robin to multiple webservers. For example, if your "app.example.com" actually points to a server that was AD-joined as "web01.example.com", then previously curl was successfully requesting tickets for "HTTP/web01.example.com" (which AD knows) but now it is requesting tickets for "HTTP/app.example.com" which your AD domain controllers do not know, and therefore cannot issue tickets for.

If the domain points to just one IIS server, setspn would solve this by essentially adding an alias for the same Kerberos key.

(This MIT/Heimdal Kerberos behavior is different from Windows clients, which always behave as if they had rdns=off, if I remember that correctly.)