New options for ktab to provide non-default salt

ADDITIONAL SYSTEM INFORMATION :
Windows 10
openjdk version "1.8.0_275"
OpenJDK Runtime Environment Corretto-8.275.01.1 (build 1.8.0_275-b01)
OpenJDK 64-Bit Server VM Corretto-8.275.01.1 (build 25.275-b01, mixed mode)

A DESCRIPTION OF THE PROBLEM :
Up to now, DES and RC4/ARCFOUR encryption types are often used in Kerberos environments. This is mainly the case, when the Kerberos KDC is provided by Microsoft Active Directory.
The mentioned encryption types should be replaced by more advanced type like AES. Encryption types like AES always use salt strings, which have to be taken into account when building a keytab file. As Kerberos default, these salt strings are build from realm name and principal name. But with Microsoft Active Directory, things are a bit more complicate. In Microsoft Active Directory, the salt string is derived from AD attribute UserPrincipalName, a field, which can be set in any way and can be unequal to the underlying SamAccountName. Furthermore, Microsoft Active Directory does not know Service Principal Names as an independent entity, instead, they are linked to an AD user account or an AD machine account. By this, salt string synchronization while building a keytab file becomes important. Recent version of the MIT ktutil utility now have an “-f” option to do this. Nevertheless, the Java ktab utility still lacks this feature, while the java based kinit already uses salt string synchronization during the pre-authentication phase, when passwords are provided interactively.
The Java ktab utility should be extended to also allow for the described salt string synchronization by pre-authentication.
PA data is shown here for encryption type 23 (rc4, without salt) and 18 (aes, with salt) from the debug output of a kinit session:
>>>Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 18, salt = PNW.LOCfritz.fischer, s2kparams = null
PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null>>>Pre-Authentication Data: