Keytab created for etype AES256/AES128 does not work with Active Directory
Opened this issue · 1 comments
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