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

[Andrew Bartlett]

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. 

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.

> 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. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org