For the sake of KTPASS syntax... This is what could be done...
Let's say you have the following user:
repadmin /showattr SECDC01.piesec.ca "CN=geji,CN=Users,DC=piesec,DC=ca" /atts:userPrincipalName,serviceprincipalname,sAMAccountName,msDS-KeyVersionNumber
DN: CN=geji,CN=Users,DC=piesec,DC=ca
1> sAMAccountName: geji
1> userPrincipalName: geji-upn@piesec.ca
2> servicePrincipalName: host/spn2@piesec.ca; host/spn1@piesec.ca
1> msDS-KeyVersionNumber: 2
That would be an odd way for the SPN format, but eh, why not... You could create a keytab that has both of these SPNs listed as principals (although as discussed in this thread, you will not be able to use those keytabs to do a KINIT because the keytabs will in that case not contain the actual user account UPN). Oh and AES uses salt... So you'd have to overwrite the salt since it is derived from the UPN you provide in /princ... Salt is domain FQDN followed by the first part f the user's UPN. Lots of tricks just for the sake of making it work...
ktpass /out geji.keytab /princ host/spn1@piesec.ca -SetUPN /rawsalt piesec.cageji-upn /mapuser P\geji /crypto AES256-SHA1 /pass MyPass -SetPass
Targeting domain controller: SECDC01.piesec.ca
Successfully mapped host/spn1 to geji.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to geji.keytab:
Keytab version: 0x502
keysize 70 host/spn1@piesec.ca ptype 0 (KRB5_NT_UNKNOWN) vno 2 etype 0x12 (AES256-SHA1) keylength 32 (0xf55444beb1501ff719c96e28c6cfc9776ab4dea73da8ad57148b7322a86759ed)
Then:
ktpass /in geji.keytab /out geji.keytab /princ host/spn2@piesec.ca -SetUPN /rawsalt piesec.cageji-upn /mapuser P\geji /crypto AES256-SHA1 /pass MyPass -SetPass
Existing keytab:
Keytab version: 0x502
keysize 70 host/spn1@piesec.ca ptype 0 (KRB5_NT_UNKNOWN) vno 2 etype 0x12 (AES256-SHA1) keylength 32 (0xf55444beb1501ff719c96e28c6cfc9776ab4dea73da8ad57148b7322a86759ed)
Targeting domain controller: SECDC01.piesec.ca
Successfully mapped host/spn2 to geji.
WARNING: pType and account type do not match. This might cause problems.
Key created.
Output keytab to geji.keytab:
Keytab version: 0x502
keysize 70 host/spn1@piesec.ca ptype 0 (KRB5_NT_UNKNOWN) vno 2 etype 0x12 (AES256-SHA1) keylength 32 (0xf55444beb1501ff719c96e28c6cfc9776ab4dea73da8ad57148b7322a86759ed)
keysize 70 host/spn2@piesec.ca ptype 0 (KRB5_NT_UNKNOWN) vno 2 etype 0x12 (AES256-SHA1) keylength 32 (0xf55444beb1501ff719c96e28c6cfc9776ab4dea73da8ad57148b7322a86759ed)
That command does not require any permission in AD else than being a regular user. You are not setting the UPN (thanks to the -SetUPN) nor resetting the password (thanks to the -SetPass). That way you also have the right kvno on the keytab.
Would that result into a working keytab? I don't know. Likely not.
- For TGT nope it will not work as the real user's UPN will in that case not be written.
- But since it seems that the keytabs could be use at the discretion of the application, check with the dev of that one I suppose...
This is just a mental exercice as this command (although correct from a syntax's perspective) is not a real case.