0

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?

Howard_Roark
  • 55
  • 6
  • Are you trying to access the site via shortname (service) or fqdn (service.example.com)? also is the service a cname of the actual server hostname or are the kerberos principle names for the service match the hostname that you're accessing. – Jacob Evans Dec 18 '20 at 18:45
  • We access the site via the fqdn. ie- service.domain. it is a service cname. ie- http://my-service-uat.domain -> IIS Webserver VM – Howard_Roark Dec 18 '20 at 20:14
  • 1
    that makes sense, you'd need to add the CNAME to the SPN list, otherwise it would need to do rdns to find the fqdn with a valid spn. – Jacob Evans Dec 20 '20 at 16:12
  • But isn't this error coming from the IIS webserver? 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? – Howard_Roark Dec 21 '20 at 18:35
  • because the server is not fully configured to provide an authentication principle for the name provided (cname) and thus must fallback to rdns lookups to find the actual server's name. – Jacob Evans Dec 23 '20 at 04:14

1 Answers1

3

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/app.example.com@EXAMPLE.COM 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.)

user1686
  • 8,717
  • 25
  • 38
  • `This MIT/Heimdal Kerberos behavior is different from Windows clients, which always behave as if they had rdns=off, if I remember that correctly` Yes I don't believe Microsoft implemented this in Kerberos, probably because it really isn't a modern security feature. A lot of large AD implementations don't even have reverse lookup zones. Other Microsoft technologies may do reverse lookups, for example WMI does it for some authentication types. Certificates and IPSEC are much more robust validation of identities though. – Greg Askew Dec 22 '20 at 15:40
  • I should mention that even MIT Kerberos has already switched in 1.18 to trying the original name first, and only using rDNS as a fallback... – user1686 Dec 22 '20 at 16:04
  • @Greg: I'm not entirely sure what you mean by "more robust" though? – user1686 Dec 22 '20 at 16:06
  • The existence of a reverse DNS record doesn't mean much or provide that much value from a security standpoint. – Greg Askew Dec 22 '20 at 16:31
  • Ah, yes – from what I've found out, it was not meant to be a security measure in the first place, but rather it was originally added to deal with MIT's Athena computing cluster having a single DNS name for multiple machines... – user1686 Dec 22 '20 at 16:41
  • Seems like it would be a headache too, at least from this question anyway. – Greg Askew Dec 22 '20 at 16:47
  • @GregAskew I'm not totally sure I follow the logic of comparing Kerberos authentication with ipsec encryption, maybe user certificates? but even then not as easily managed as Kerberos (when considering checking validity of an account via crl or oscp distribution, whereas Kerberos is already designed to have multiple redundancies/replicas – Jacob Evans Dec 23 '20 at 04:13
  • @JacobEvans: It isn't a comparison of Kerberos or encryption, it is of archaic implementations of Kerberos that use reverse DNS to confirm the identity of the name requested, and modern technologies that are actually designed to do that. "Many current implementations do some degree of canonicalization of the provided service name, often using DNS even though it creates security problems. However, there is no consistency among implementations as to whether the service name is case folded to lowercase or whether reverse resolution is used." https://tools.ietf.org/html/rfc4120 – Greg Askew Dec 23 '20 at 13:43
  • @JacobEvans: So now we have an optional implementation feature that doesn't really measure up to the intended purpose, but does seem to cause issues. – Greg Askew Dec 23 '20 at 13:45