Patch: System keytab usage improvements

[Dan Perry]

>
> Why only kvno -1?  Could we not need keys even older than that?
>

As per http://support.microsoft.com/default.aspx?scid=kb;en-us;325850
"When two computers try to authenticate with each other and a change to the
current password is not yet received, Windows relies on the previous
password.  If the sequence of password changes exceeds two changes, the
computers involved may not be able to communicate, and you may receive error
messages. "

By keeping kvno and kvno - 1 I was trying to duplicate the Windows behavior
exactly.  Of course, there's no technical reason to limit this, aside from
the fact that the more password/kvno's you keep around, aside from the fact
that functions like kerberos_verify() will need to run through every entry
until they find a match.   Keeping every entry around could slow things down
after many password changes.   Keeping kvno and kvno - 1 seems like a
reasonable limit.   Of course, the best way to do this would be to timestamp
each entry and remove it after say a week.   Doing that would probably
involve a structure in the secrets.tdb and having a daemon like smbd keep
things tidy.


> > - makes smbd's kerberos_verify() routine check the default system 
> keytab.
> > Since the default system keytab will have entries with the current kvno >
and
> > kvno - 1, as per the comment above, this allows smbd to use the older 
> kvno -1
> > keytab entry and prevents a machine password change from interrupting 
> exist
> client sessions.
>
> This is the main part of the patch I object to.  I think that we should
> structure the storage in secrets.tdb in this way (we need the previous
> password anyway, to fix a bug in some other parts of Samba).  I know we
> avoided recording the password into the keytab for a reason...
>
> I think that after checking the passwords in secrets.tdb, we should
> *then* check the system keytab, because we might be in an MIT realm, or
> some other interesting thing. 

Like I mentioned above, things will probably head towards using secrets.tdb
eventually.   However, this patch is getting kind of big already.  Perhaps
maybe using secrets.tdb could come after the patch at hand is merged.  I'd be
happy to work on getting secrets.tdb to store a better keytab structure...

Upon re-reading the email I sent, perhaps I should explain the changes my
patch makes to kerberos_verify() a little more clearly.   The patch does not
create a situation in which kerberos_verify would break, by changing
kerberos_verify() to be keytab only.   The patched kerberos_verify() works
like this:

	FIRST PASS - checks the keys in the keytab, if it even exists.   If a
key works, great, the session succeeds.

	SECOND PASS - if the keys in the keytab fail, (for example if the
keytab doesn't exist, the system admin doesn't have a correct reverse dns
zone, etc.)  Then kerberos_verify() tries to use the machine password from
secrets.tdb to make keys, just like it the function did before the patch was
applied.  

	THIRD PASS - nothing left to try, NT_STATUS_ACCESS_DENIED is
returned.

This behavior should be completely backwards compatible and just as lenient
to a poor Kerberos / dns setup as the kerberos_verify() function was before
the patch.   It does, however, let users with existing Kerberos sessions keys
continue to use those keys after a machine password change.  However, if you
know a better way to implement, please let me know.


I really would like to see the changes to keytab behavior applied, and I do
appreciate the feedback.   

Thanks,
Dan