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 <[email protected]> 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 > [email protected] > www.kerberos-buch.de > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
