What is the correct format to specify SPN?

Question

First, the Service principal name is registered for a user using setspn command.

setspn -a CS/[email protected] dummyuser

setspn -l dummyuser

gives the output as

CS/[email protected]

Next, when ktpass command is executed with /mapUser option, the service principal name of the user account gets modified so that the domain component gets dropped.

ktpass /pass Password@123 -out dummy.1.keytab -princ CS/[email protected] -crypto DES-CBC-MD5 +DumpSalt -ptype KRB5_NT_PRINCIPAL +desOnly /mapOp set /mapUser dummyuser

setspn -l dummyuser

gives the output as

CS/dummy

Are both of the following commands correct and work in the same way?

setspn -a CS/dummy dummyuser

setspn -a CS/[email protected] dummyuser

While specifying service name in the SPN, is mandatory to include the domain component too? Can you please clarify?

Answer 1

As you did not mention it, I will assume you are in a Windows Active Directory domain environment? I say that because the command "ktpass" given in your example is native to Windows. Based on this I will assume that your Active Directory DNS domain name is abc.com and Kerberos realm name is ABC.COM.

1. When you create a keytab, the SPN gets mapped to the user or computer object (principal, in Kerberos terms) at that time so you don't need to adjust the SPN of that principal afterwards unless you are adding them as secondary SPNs.
2. Do yourself a favor and place the Kerberos realm name in upper-case inside your keytab creation command. Its best to randomize the password so nobody knows it. Kerberos SSO functionality will work just fine with that. And the Kerberos realm name needs to be appended to the "/mapUser" argument. I've modified your example into a better one you should use.
3. Its outside the scope of your question but don't use DES encryption anymore. It's long been out of favor in the industry. I won't say more on that because that's not what you're asking about.
4. Don't use the "setspn -a" syntax to add or create SPNs on principals, use "setspn -s" instead as the "-s" checks for duplicates SPNs while the "-a" does not (see: “setspn -s” vs. “setspn -a”).
5. Ensure that you fully-qualify the host part of the SPN (i.e., dummy.abc.com, rather than just dummy). Else, the authentication mechanism might immediately try NTLM instead of Kerberos which is not what you want.
6. In a simple environment consisting of just a single DNS domain and single Kerberos realm, and having the Kerberos realm to DNS domain mappings are already set (usually by /etc/krb5.conf when on UNIX/Linux, Windows handles that automatically but if it doesn't then it will try C:\Windows\krb5.ini if present), while you would not need to qualify the Kerberos realm as part of the SPN when running "setspn -a" or "setspn -s", you should do so inside your Kerberos creation command.

So, in your case, based on everything I mentioned, while you can use:

setspn -a CS/dummy dummyuser

It would be better to do it this way instead:

setspn -s CS/dummy.abc.com dummyuser

For extra credit I've also modified your keytab creation command accordingly, though keeping the DES part so as not to further confuse.

ktpass +rndPass -out dummy.1.keytab -princ CS/[email protected] -crypto DES-CBC-MD5 +DumpSalt -ptype KRB5_NT_PRINCIPAL +desOnly /mapOp set /mapUser [email protected]