Handling of kerberos machine account password changes (eg domain rejoin)

[simo]

On Fri, 2012-11-02 at 00:15 +1100, Andrew Bartlett wrote:
> On Thu, 2012-11-01 at 07:22 +0100, Andrew Tridgell wrote:
> > The branch, master has been updated
> >        via  dd60dcf test-chgdcpass: test the ldap case for server password change
> >        via  0e6c5c0 s4-ldapclient: cope with logon failure retry in LDAP
> >        via  b0cc0d5 s4-librpc: set error code to LOGON_FAILURE on RPC fault with access denied
> >        via  538dd04 samba-tool: "drs options" does not need a samdb connection
> >        via  5d6ae34 s4-librpc: try a 2nd logon for more error cases
> 
> >        via  fce66b2 test_chgdpass: added test for kerberos retry
> >        via  d4ea637 libcli: use cli_credentials_failed_kerberos_login() to cope with server changes
> >        via  994696c auth: added cli_credentials_failed_kerberos_login()
> >       from  ffb608b util: remove accidently committed hunk
> > 
> > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=master
> 
> 
> Alexander,
> 
> I wanted to thank you for the chat we just had on IRC about these
> kerberos changes.  I think we have determined that it won't hit your use
> case, because we are careful to only remove a ticket once we have some
> evidence that the server it is for won't accept it.  
> 
> We do take particular care not to just blow away the ccache, because we
> might not have a password to recreate it (and it might, as in your
> application have come from an external kinit or s4u2proxy call).
> 
> The reason for the change is to cope with the re-installation of a
> kerberos host, where the rejoin to the domain has no record of the old
> password, and so for up to 10 hours valid tickets in a ccache would be
> rejected, without any attempt to get a fresh ticket. 
> 
> That said, Kerberos can be a tricky beast, and I'm very happy to
> continue to work with you to address any further concerns you might have
> after your conference.  

I think it would be nice to have a system configuration option to
disable this behavior. In general it is useful, but there are simple
corner cases that may end up generating a lot of Kerberos traffic
loading the KDC.

In case the server hasn't changed the keytab but simply has the wrong
key (can easily happen, seen multiple times in production), then we may
have a client that runs in a loop (for whatever reason, either
intentional, or not) to generate loads of TGS requests against the KDC.

In general KDCs (at least on *nix) tend to be single threaded, and this
could end up mounting a little DoS. I guess this is why by default
libkrb5 does not do what this patch does on its own.

Bonus question, can this code distinguish an access denied due to an
invalid ticket, from an access denied simply due to the fact the target
server has an ACL that prevents access to your user ? If not this is
another corner case where discarding tickets is not optimal, as it
forces the client to needlessly repeat network operations against the
KDC.

Maybe there is a simple way to set something in the ccache so that we
never retry more than once to fetch a ticket by storing a special name ?

Something like:
1. if we get access denied, we delete the ticket but also add a
synthetic ticket of the form: X-denied/service/fqdn
valid for MIN(X hours, original ticket validity) and retry.
2. On further access denied conditions we check for this special ccache
entry, if it is found (and is not expired) we do not delete the current
ticket from the cache and simply return the error. Otherwise we delete
the special ccache entry so we can retry.

This would allow also to remove the retries argument, as we would retry
exactly once in several hours if the problem is access denied.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>