UserPrincipalNames and AES Authentication

[JoeDibley]

I happened across some weirdness with UserPrincipalNames, especially ones which contain a forward slash, and AES authentication with UserPrincipalNames and thought I would try and implement the findings in asktgt and asktgs as it may save someone a couple of hours of debugging in the future.

Here are some notes from research on this as well as what this PR will help with:

• If a userPrincipalName (full with @) is used in AskTGT the left hand side is used for username and right hand side is used as domain
• When using a UserPrincipalName with a forward slash there is some different behavior that occurs:
  • The cname-string is an array split by the forward slash
  • The password salt does not include the forward slash
  • When using /opsec the name is normalized to DOMAIN\SAMACCOUNTNAME in the AS_REP but when not using /opsec. I think its the hostname that does this, I believe the KDC looks up the account in AD and if Windows will 'upgrade' the ticket but I have not fully tested this theory.
  • When not using /opsec with a name with a forward slash the name is returned in the cname-string array, TGS_REQ in rubeus was using cname-string[0] which resulted in bad match errors as the username was only half complete.
• Fixed TGS_REQ with /opsec using a short SPN such as "cifs/DC", prior to this only SPNs with FQDN would would with /opsec I believe.

This PR does result in the userName at this line being incorrect when using a UserPrincipalName with a forward / that has been split. I was unsure what the specifics were across different kerberos scenarios here so seeking advise on what to do on this display of username.

[HarmJ0y]

I'll try to check this out soon 👍