Static KVNO value is problematic when KVNO > 1

[bryanmcnulty]

I've found that the static key version number (KNVO) set in credentials.go#L167 becomes problematic when the KVNO returned in the AS-REP message is greater than 1 (i.e. when a key is rotated due to a password reset)

I've found this using goexec - which relies on the adauth library for Kerberos support. Here's what I ran, and the associated error.

./goexec tsch demand "$target" \
  --user "${auth_user}@${domain}" \
  --aes-key "$auth_aes_256" \
  --exec 'C:\Windows\System32\cmd.exe' \
  --args '/C whoami /all' \
  --out - \
  --dc "$dc" \
  --debug

bind: init security context: security provider: krb5: init: apreq: affirm login: could not get valid TGT for client's realm: [Root cause: Decrypting_Error] KRBMessage_Handling_Error: AS Exchange Error: AS_REP is not valid or client password/keytab incorrect < Decrypting_Error: error decrypting EncPart of AS_REP < Decrypting_Error: error decrypting AS_REP encrypted part: matching key not found in keytab. Looking for \"Administrator\" realm: LUSTROUS.VL kvno: 2 etype: 18

I've confirmed that this is related to the fact that the KVNO was 2 in the AS-REP message by setting the kvno parameter on credentials.go#L167 to 2 in my Go workspace - this resolved the error.

P.S. Great job on this module - I've really found it well-featured and easy to use 😃

[oiweiwei]

perhaps using EncryptionKey fits more here instead of keytab (i've removed code part for catching kvno error as it doesnt make any sense given I maintain my own fork): https://github.com/oiweiwei/go-msrpc/blob/6a796596cac732a1eee67a6ed557261c0825a11b/ssp/credential/encryption_key.go#L55

https://github.com/oiweiwei/gokrb5.fork/blob/54662d018fbf5d2499c3aaff4bf516e318d918a4/v9/credentials/credentials.go#L118

[bryanmcnulty]

Working on a PR now 😺

[rtpt-erikgeiser]

@oiweiwei, sure EncryptionKey is more elegant and we should utilize it, thank you for the hint.

As far as I understand this issue, the error is a client-side issue where the correct key from the keytab is ignored due to the kvno mismatch. Do I understand correctly that you have removed the relevant code from your fork and it would now work with the curent go-msrpc version even with a kvno mismatch? I'm just asking to find out whether I need to fix the keytab for ldapauth which also uses your fork.

[oiweiwei]

Hi @rtpt-erikgeiser if it goes about gokrb5 fork, I've tried to touch as less as possible, so keytab auth method would complain about knvo mismatch as previously. The only addition to fork for this was adding encryption key input to address such "hacking" requirement, and remove error parsing in go-msrpc side (building keyrab, parsing error, updating kvno in a single key).

If ldapauth relies on constructing v8 client - then it will barely help. If say, AP/TGT exchange is working using v9 fork code, you can also use encryption key to establish the session.

[oiweiwei]

Seems like encryption key should either fit in ldap case as you are implementing GSSAPIClient interface on your own (you can try changing password for your testing env and see if it will work for LDAP because i don't know how it supposed to work previously with kvno 1).

[rtpt-erikgeiser]

ldapauth uses github.com/oiweiwei/gokrb5.fork/v9 under the hood to make stuff work, it only uses github.com/jcmturner/gokrb5 structs in the API because I did not want to favor any fork and I want to make it compatible with other code that uses the "official" Kerberos library.

Somehow, AES key auth works in my env even after changing passwords with examples/dcerpc with and without #5 and also with examples/ldap. Maybe it comes down to how the password is changed, e.g. which protocol (LDAP, Kerberos, SAMR, ...).

[oiweiwei]

That's weird, maybe ccache is used somehow or rolling over the key matters, but given that the error is 100% observed I can't deny that kvno change cause an error.

[rtpt-erikgeiser]

Yeah, I was able to reproduce it with another account (both with DCERPC and LDAP). I deleted the keytab code completely from the code base in favor of client.NewWithEncryptionKey and now LDAP works too. Thanks for your help!