No, but there are a couple possible factors at play here:
One is that, if /mapuser is specified without also specifying -SetUPN, ktpass will change the UPN of the account in question to match whatever SPN was specified with the /Princ parameter in the command (in either case, /mapuser will register the SPN being requested to the specified user, but it only changes the UPN of that account if -SetUPN is absent).
This is apparently so that Linux clients can successfully get a ticket with this keytab (since from a Linux client using kinit, if we try to obtain a Kerberos ticket using an SPN that is registered to an account as an SPN, but that does not match any account's UPN, kinit will tell us the principal does not exist). Windows clients are able to obtain tickets for SPNs that are just registered as SPNs, without requiring that the service account's UPN match the SPN being requested.
So, if we were to try and authenticate using the account's "regular" UPN (the UPN it had prior to running ktpass, e.g. user@domain.com), after generating the keytab without specifying -SetUPN, then authentication would fail because that UPN is no longer valid.
The other issue is that ktpass does seem to "mangle" the password that is entered when using the /Pass * parameter to force it to prompt for password input. ktpass will either set the password to what we specify (if -SetPass is not included) or it will just create the keytab using the password we specify, taking our word that it is correct (but of course the resulting keytab won't work if an invalid password is given).
Based on my testing, if we enter the password in the command itself (e.g. /Pass P@ssw0rd), the keytab will work fine (assuming the password was correct) and password authentication should also work, although only if we either specify the username in DOMAIN\username format or if we included -SetUPN in our ktpass command, due to the UPN issue noted above.
However, the problem comes when we try to use the /Pass * parameter to avoid having to enter the password in plaintext on the command line. In this case, ktpass prompts us for a password, but it apparently modifies whatever value we enter somehow (behind-the-scenes). This will produce two possible results, depending on the options we specified in our command:
- Either the resulting keytab file will be invalid and won't work - this happens if we included the
-SetPass parameter (which tells ktpass not to change the account's password), because then ktpass generates a keytab with the mangled password even though the "real" password on the account is the value we entered at the prompt.
- Or, the resulting password on the account will be set to an unknown value (and not the value we expect it to be) - i.e. the mangled version of the password we entered - this happens if we did not include
-SetPass, in which case ktpass changes the password of the account to whatever value it mangles our input into. In this scenario, the keytab will work, but when we try to authenticate with this account using a password we will get an invalid password error (because the password on the account is not the one we think it is - its not the value we entered at the prompt).
I tested and confirmed this behavior on 2008R2, 2012 and 2012R2 - I was not able to test on anything newer.
To summarize - if you need to know the account's password so that you can authenticate with either method (password or keytab) after the keytab is generated, then you need to enter your password in the ktpass command itself instead of asking ktpass to prompt for it (i.e. use /Pass P@ssw0rd rather than /Pass *). Just be sure you do this in a secure setting where there is no possibility of somebody looking over your shoulder or silently monitoring your screen (luckily Windows by default doesn't log cmd history persistently).
On the other hand, if you don't need to know the account's password once the keytab is created, then its probably best to just use +rndPass - this will force ktpass to generate a random password for the account and the keytab will work just fine.
*EDIT/UPDATE: One other quirk I found when testing is that it seems if a new account is created w/ a known password, and ktpass is run to create a keytab for that account, specifying the password in the command as noted above, but with the -SetPass parameter, the resulting keytab will not work. If we run ktpass and specify the password without -SetPass, to let ktpass "reset" the password (to the same value it already was - the value we set when creating the account), the resulting keytab works fine, as does password authentication. And any subsequent keytabs created from that point onward will work (even if created with -SetPass). I do not have an explanation for this behavior (observed on Server 2012 and 2012R2).
