2

I know one can disable the reverse DNS lookup made by individual client applications when calculating SPN of the called server during Kerberos authentication. There are various ways, e. g.:

My question is whether this can be somehow achieved on a Windows (namely Windows 10) client machine globally - for all applications. The following variants don't seem to be a solution:

  • Tell Windows not to do the reverse lookup. I checked MS Kerberos registry documentation and I cannot see such a setting there.
  • Tell Windows / all applications in Windows to use the MIT implementation instead. There seem to be special settings e. g. in PuTTY or Firefox which enable choosing a concrete GSSAPI/Kerberos implementation. But what about the other applications, like Chrome or the Windows network disks mapper?
  • Highly theoretical and not practical: Change, recompile and deploy the hard-wired part of Windows responsible for the lookup.
Petr Bodnár
  • 159

1 Answers1

2

Unfortunately no. Implementations that use a krb5.conf style configuration can use directives like dns_canonicalize_hostname = false [1] and the builtin java krb5.conf does support this directive. But of course 90% of client are Windows so a krb5.conf is quite irrelevant.

So what does Windows do? While Windows does not perform DNS canonicalization itself, Windows libraries and applications frequently do. For example, non-Chromium Windows clients will perform Kerberos DNS canonicalization. As a result, the various browsers like Chrome and Firefox have followed this behavior.

How Kerberos DNS conanicalization works:

A client needs an SPN to get the service ticket. For HTTP for example, it should just use the hostname in the URL like https://www.example.com to make an SPN like HTTP/www.example.com. If you're running 10 sites behind the same IP, this means that you would need to set SPNs on the account for HTTP/as1.example.com, HTTP/as1b.example.com, HTTP/as1, HTTP/dev3.example.corp, ...

However, this is not what Kerberos clients do by default. By default, they use DNS to expand the URL hostname to an FQDN (adding a domain suffix as necessary). Then, they do a reverse DNS PTR lookup to get the canonical FQDN hostname for the IP. That is used to build the SPN to request the Kerberos ticket. So ALL hostnames hosted by the same IP are converted to one SPN like HTTP/s3US-66.example.corp.

For Chromium based browsers on Windows, there is a setting DisableAuthNegotiateCnameLookup to turn off DNS conanicalization in Chrome. But this would have to applied site-wide which means all existing HTTP services would have to add SPNs for all hostnames used in URLs. Many admins would just reject this as too much work.

For a more detailed explanation of this process in Chromium based browsers, see the Kerberos SPN generation section on this page:

https://www.chromium.org/developers/design-documents/http-authentication/

As a result, it is now virtually impossible to have multiple independent Kerberos configs from the same IP. Kerberos client DNS canonicalization creates a dependency between an IP and all of the applications running behind that IP. This is not how we deploy applications now. If you deploy a docker app, you have to know that the Kerberos config for that server is right for your app and this assumes that you even have access to the kerberos config / keys that now must be shared. You should be able to move an app from one host to another without changing the account it uses to accept auth.

Also note, that Kerberos client DNS canonicalization is a security risk if DNS can be poisoned.

Note: This is not a Microsoftizm. MIT uses the same default behavior.

[1] https://web.mit.edu/kerberos/krb5-latest/doc/admin/princ_dns.html

squarewav
  • 140