Bug 976300

I reassign this ticket to realmd because it adds the entry to krb5.conf.

Stef, maybe there should be an option to set 'rdns=true' for environments where it is known to work and expected to work?

Actually it's not realmd either; it's from the default krb5.conf provided by krb5-libs:

* Fri Feb 08 2013 Nalin Dahyabhai <nalin> 1.11-2
- set "rdns = false" in the default krb5.conf (#908323)

I am too clueless about Kerberos to have any clue about the discussion in bug 908323. All I know is that this used to work fine, and now it doesn't.

Perhaps if the initial canonicalisation attempt has obviously failed, and the name we tried doesn't exist in the database, we could try harder?

Would it help for me to fire up a Windows VM and see if Kerberos authentication works to this host... and how. (Please say no ☺)

Having said that, we'll probably find that this is one of the *numerous* cases in which Windows silently falls back to NTLM authentication. cf. bug 975464

(In reply to David Woodhouse from comment #4)
> Having said that, we'll probably find that this is one of the *numerous*
> cases in which Windows silently falls back to NTLM authentication. cf. bug
> 975464

Most probably.

What is the real server name ?
That is what the CNAME should point to.

The real server name is the one provided by RDNS, shown above (orsmsx104...).

The CNAME points to a global load-balancing system (.glb.intel.com) which then gives a different A record according to... well, whatever the hell its criteria are.

I'm not sure the load balancing system is sophisticated enough to use CNAMEs instead of A records. And even if it was, I'm particularly unsure that our IT department would entertain a request to change it, when this setup works fine with Windows.

(In reply to Sumit Bose from comment #1)
> I reassign this ticket to realmd because it adds the entry to krb5.conf.

realmd does not add the entry to /etc/krb5.conf. It does not touch that file at all. It expects it to not be broken. Manually configuring krb5.conf is the legacy approach for legacy networks, and as such is still available to administrators of legacy networks.

David, using rdns to canonicalize kerberos records is insecure, and not appropriate as a default for an operating system. It would be somewhat similar to using reverse DNS to lookup an https hostname before verifying that name.

However, it may be appropriate on your network and the machines you deploy, depending on the wire-security of network.

Stef: I'm not sure I understand the nature of the insecurity.

We attempt to connect to a given machine by a non-canonical name. We establish that the name we used does *not* exist as a server in the Kerberos realm.

We do a reverse DNS lookup, and a forward DNS lookup to validate, and we establish that the name we now have *does* exist as a server in the Kerberos realm.

What is the threat model, if we then attempt to obtain a ticket for that hostname, and use it against the server in question?

But I suppose I'm perfectly happy with the response "Your setup is broken for Kerberos authentication to this host. You have to live with fallback to automatic NTLM authentication". It's not as if that's a *rare* thing.

(In reply to David Woodhouse from comment #8)
> Stef: I'm not sure I understand the nature of the insecurity.
> 
> We attempt to connect to a given machine by a non-canonical name. We
> establish that the name we used does *not* exist as a server in the Kerberos
> realm.
> 
> We do a reverse DNS lookup, and a forward DNS lookup to validate, and we
> establish that the name we now have *does* exist as a server in the Kerberos
> realm.
> 
> What is the threat model, if we then attempt to obtain a ticket for that
> hostname, and use it against the server in question?

Because an attacker can cause you to authenticate with a server you were not expecting. Sure, your kerberos credentials will not be leaked to that server (because of the nature of kerberos) but you will be communicating with the wrong host. 

This is similar in nature to SSL MITM, but obviously also different, in that only servers part of your realm can be used to MITM one another.

Given your environment, this may not be a relevant threat for you. And in that case I would recommend that you turn rdns=true for your deployed machines.

I'm still confused, I'm afraid.

Either I'm *already* talking to the wrong host (because I'm using http not https presumably) and I get a Kerberos ticket for the host I *think* I'm talking to. And present it, but nothing is lost. If the fake server wants pretend to accept my authentication it could have done that anyway.

Or I'm talking to the *right* host, but I end up getting a ticket for a "wrong" host that still exists in my Kerberos domain. And I authenticate as if to that wrong host... and still I don't see what I've lost.

What am I missing?

(In reply to David Woodhouse from comment #6)
> The real server name is the one provided by RDNS, shown above (orsmsx104...).
> 
> The CNAME points to a global load-balancing system (.glb.intel.com) which
> then gives a different A record according to... well, whatever the hell its
> criteria are.
> 
> I'm not sure the load balancing system is sophisticated enough to use CNAMEs
> instead of A records. And even if it was, I'm particularly unsure that our
> IT department would entertain a request to change it, when this setup works
> fine with Windows.

Ok fine kerberos is broken in this case. Good luck!

To understand why relying on reverse DNS is a problem read this: http://ssimo.org/blog/id_015.html

David, your Exchange team needs to setup an application service account if they want to provide kerberized access to the Exchange web services, including autodiscover.
See [1] for a detailed explanation. In my case it was even necessary to set rdns=false to reliably access the EWS with kerberos.

[1] http://technet.microsoft.com/en-us/library/ff808312(v=exchg.141).aspx

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.