How and when does ktpass set the salt?

Question

A user's password and salt determine the Kerberos keys generated by ktpass. I have noticed that ktpass sometimes changes the user's salt, but other times it does not. I was able to discover the salt by capturing a packet trace of a kinit. The salt appears to be generated based on the Kerberos realm and the userPrincipalName. However, it's not this simple. If the UPN is later updated manually, the salt is not updated. (I suspect that whether the /mapop option is specified may play a role.)

1. In what circumstances does ktpass set the user's salt?
2. How is the salt determined?
3. Is the salt stored in AD, or just in the KDCs?
4. Is there a straightforward way to read the current value of the salt?
5. Is there a way to manually change the salt?

Answer 1

1. In Microsoft Windows Active Directory, which has used Kerberos v5 since its inception in Windows 2000, the ktpass command sets the salt automatically. The salt is always used in Kerberos v5. In Kerberos v4, a salt was never used.
2. The complete principal name (including the realm) is used as the salt, e.g., accountname/somedomain.com@SOMEDOMAIN.COM, which is then paired with the encrypted hash of the password to absolutely ensure the result is unique throughout the AD forest.
3. As mentioned, the salt is the complete principal name (including the realm). It is stored in the ntds.dit file, which is the Active Directory database. The KDC get spun up in a process spawned by by kdcsvc.dll - and it relates to the values stored in ntds.dit. So while the KDC and AD database are not one and the same inside the runtime environment, they are, so to speak, "joined at the hip". I think when the domain controller shuts down, all the important elements within the KDC is persisted inside of ntds.dit. Microsoft does not provide exact details on how this is done. I have looked extensively, and my partial knowledge is drawn from careful study and inferences made from bits and pieces of articles found on the web. Note that the ntds.dit database is also the LDAP database. It is also the DNS database, if DNS is AD-integrated. All these protocols working together, plus a few more, form "Active Directory".
4. Open up Active Directory Users and Computers, go to the Account tab. The "user logon name" is the most straightforward way to "read" the salt. You don't see the realm name concatenated with it right there but it is implied. The SPN, if also defined, is listed in a straightforward way like you are looking for under the Attribute Editor tab (look for servicePrincipalName). Make sure you have View > Advanced Features selected in order to expose this tab. A corresponding UPN will also be listed lower down in this same section, in the manner that looks exactly like: accountname/somedomain.com@SOMEDOMAIN.COM.
5. When you change the account name on the AD Account tab, you have just changed the salt. Note if there is a keytab out there tied to this AD account, you will have just invalidated it, as its secret key inside is a concantaention of the password hash and the salt. When either the salt or the password changes, then the keys will no longer match between the AD account and that inside the keytab. You will have to re-generate it at this point.

Makes sense? This is really a field explanation. To learn more about Kerberos as it relates to AD, start here: Kerberos Survival Guide