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

[simo]

On Fri, 2012-11-02 at 18:38 +1100, Andrew Bartlett wrote:
> On Thu, 2012-11-01 at 09:41 -0400, simo wrote:
> > 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.
> 
> The errors occur at the application layer, not at the kerberos layer. 

Not sure how this makes the problem different ?
It doesn't really matter in the end where the errors originate what
matters is whether calling a client in a loop will pound the KDC or not.
Think something like:
for i in `ls -1 file*` do smbclient -k -c put $i; done

> Either way, I plan to sort this out with one way or the other when I
> hook up with Alexander after his conference and my family commitments
> next week.

Sure, there is no rush, I just wanted to point out that unconditionally
retrying may cause more harm than the original issue in some corner
cases, although may make life a lot easier in others.

> > 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.
> 
> Yes, in all three protocols authentication and authorization are
> distinct steps. 

This is good.

Simo.


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