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