Current keytab.AddEntry(..) adds salts derived from the PrincipalName. This does not work in AD for AES* since Microsoft decided to implement it differently.

To deal with the issue ktutil in Linux added additional param to specify salt in version krb5-1.16-final

Supporting a similar change in gokrb5 is a minor change (maybe an additional method or option pattern) as crypto.GetKeyFromPassword already supports salts as PADATA.

Happy to provide PR.

INFO: AD salt derivation logic

AD uses the below algorithm for deriving salt.

For computer account:

realm_name+"host"+samAccountName_nodollar+"."+lower_realm_name

(Note: samaccountname_nodollar is lower case for machine accounts)
(Note: only for DES/AES; arcfour-hmac-md5 doesn't use salts at all)

Salt for service accounts is created in a different way

• if userPrincpalName is not set:

realm_name+samAccountName

(Note: samAccountName is case sensitive for service accounts)

• if userPrincpalName is set:

realm_name + first component from userPrincpalName

Reference:
https://syfuhs.net/2017/07/09/on-adding-aes-support-to-kerberos-net/
http://kerberos.996246.n3.nabble.com/Creating-a-keytab-for-an-AD-user-td48559.html
http://kerberos.996246.n3.nabble.com/ktutil-problems-generating-AES-keys-salt-td41104.html