querying salt and kvno via KDC-REQ

[Ben H]

Mark,

I haven't done any detailed tests on this - but thought I would throw out a
couple of ideas/comments:

1) Is the kvno # being changed on the PDC emulator when the password is
updated?  Or is it being changed on the specific DC that processes the
password change?  I would like to think that it was replicated to the PDC
emulator immediately and that you could query that DC to get the proper
one.  Even if that were the case however you could still run into issues
where the PDC emulator was not available from a particular location.

2) Have you read this article:
http://blogs.msdn.com/b/openspecification/archive/2009/11/13/to-kvno-or-not-to-kvno-what-is-the-version.aspx

Specifically the section after the 101 on what KVNO is where it states:
"Windows does not pay attention to KVNO. It simply ignores it. Like if KVNO
wasn’t even present"

Basically, it appears that windows will disregard the KVNO and simply try
to decrypt whatever it receives with it's current password (current kvno).
If that fails, and the server has available the previous password (kvno-1),
it will use that as well.

I had some exchanges with MS open-doc team on this, and they didn't exactly
elucidate things perfectly, but they did direct me also to:

MS-KILE
3.4 Application Server Details
3.4.5 Message Processing Events and Sequencing Rules
http://msdn.microsoft.com/en-us/library/cc233935.aspx
. . .
If the decryption of the ticket fails and the KILE server has older
versions of the server key, the server SHOULD retry decrypting the ticket
with the older keys.
If the decryption routines detect a modification of the ticket, the
KRB_AP_ERR_MODIFIED error message is returned.
If decryption shows that the authenticator has been modified, the
KRB_AP_ERR_MODIFIED error message is returned

Based on the above, I'm not actually sure how it is important to use the
proper KVNO in an Active Directory environment.

Don't know if any of the above helps...but thought I would throw it out
there.


On Sun, Aug 3, 2014 at 12:03 PM, Mark Pröhl <mark at mproehl.net> wrote:

> I would like to improve some parts of msktutil
> (https://code.google.com/p/msktutil/) and need a way to get information
> about salt and  principal's kvno via KDC requests. Do the MIT krb5
> libraries provide functions for this?
>
> Some background information:
>
> The problem with the salt is currently being discussed on this list
> ("ktutil - problems generating AES keys (salt?)).
>
> In the current version msktutil is getting the kvno via LDAP search
> (attribute msds-keyversionnumber). This leads to problems when AD
> replication is slow. Network sniffs performed after password changes
> show that AS-REP messages already contain the principal's new kvno (in
> the client part) while its LDAP attribute msds-keyversionnumber has
> still the old value.
>
> MIT's kvno utility only determines the kvno for service principals by
> getting a service ticket and printing its kvno. I am looking for a way
> to do this for client principals by analysing the client part of AS-REP.
>
> --
> Mark Pröhl
> mark at mproehl.net
> www.kerberos-buch.de
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>