kpasswd TCP implementation

[Dave Daugherty]

________________________________

Jeremy Allison Thu 6/15/2006 4:14 PM

>> On Thu, Jun 15, 2006 at 05:16:10PM -0500, Gerald (Jerry) Carter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Guenther,
> >
> > > Author: gd
> > Date: 2006-06-15 21:25:57 +0000 (Thu, 15 Jun 2006)
> > > New Revision: 16268
> > >
> > > WebSVN: http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=16268 <http://websvn.samba.org/cgi-bin/viewcvs.cgi?view=rev&root=samba&rev=16268> 
> > >
> > > Log:
> > > Add TCP fallback for our implementation of the
> > > CHANGEPW kpasswd calls.
> > >
> > > This patch is mainly based on the work of Todd
> > > Stecher <tstecher at isilon.com> and has been
> > > reviewed by Jeremy.
> > >

.> .> So are you proposing this for inclusion in 3.0.23rc3?

>  think that's a yes. It's going in SLES 10.

> Jeremy.

I rolled this patch into Centrify's MIT Kerberos code base and it appears to work well for me too.   We are waiting to see if the MIT folks will accept Todd's patch before proceeding with it, as it is a pretty big change that we would not want to maintain if MIT decided to do something different.  IMHO Todd's approach makes sense and I am hoping MIT accepts it.
 
A couple of related problems to kpasswd changes...
 
1) If you contact a BDC to change the password, it is supposed to synchronously contact the PDC and propagate the password change to it, before returning success to the computer requesting the password change.   If the PDC happens to be down, this process can take up to 3 minutes (in our testing).  To solve the problem we modified Todd's data structure he passes into the password exchange code that allows a hard timeout (rather than the built in backoff) to be passed in. If this value is present it is used instead of the back off
 
2) We have observed that the above synchronous BDC -> PDC password exchange does not happen (the BDC decided its the PDC or thinks the PDC is down??).  But later (5 minutes or so in our tests) a synch message is sent so the PDC gets the word about the new password.  This leads to the situation where for a short time, if you contact the PDC and try to use the new password, it will fail.
 
3) We still see a problem in the case of a  user belonging to 1500 groups or more -  the W2k3 server in our lab will not accept a password change (returns a kerberos "KRB5_KPASSWD_HARDERROR if I recall correctly").  We traced a Windows XP change password in the case where the password had expired and XP prompted for a password change before reattempting the login (which will fail regardless - see below).  We see it using an MS-RPC mechanism to change the password instead of Kerberos.  We plan to experiment with requesting a ticket from the W2k3 server that does not contain the PAC and use it to attempt the passworrd change, but have not done this yet.  I would hate to have to implement the RPCs but it might be the only way...
 
As a side note, if we try to use that user who belongs to 1500 groups or more to log on to Win XP client, it fails.  Here is at least one of the issues related to this: http://support.microsoft.com/default.aspx?scid=kb;ko-kr;275266
 
Dave Daugherty
Centrify Corp.