You may sometimes need more than one Service Principal Name (SPN) for a Service Account in AD. For example:
Why we recommend one SPN per service account only
The problem with multi-SPN accounts and keytabs is that, whenever you need to update an SPN, there's a high risk of breaking existing keytab files used by the other applications.
For example, imagine Confluence, Bitbucket, Jira and Bamboo all using CNAMEs, with SPNs that are all registered to svc-atlassian@EXAMPLE.LOCAL:
Then a year down the line, the application server for Confluence dies and is restored on a new application server. The CNAME is moved accordingly to point to the new server: appsrv.prd777.b.example.com. For Kerberos to work, you will now need to remove the old SPN for Confluence and instead add:
.... One tiny mistake when running ktpass, and the keytabs for Jira, Bamboo and Bitbucket are now invalid, and Kerberos no longer works in any of the Atlassian applications.
That said, if you're still convinced multiple SPNs is what you need, this document describes one way of achieving it.
Assume you want the following SPNs for Confluence:
Step 1: Run ktpass to generate the initial keytab for the correct/canonical SPN:
ktpass /princ HTTP/wiki.example.com@EXAMPLE.LOCAL /mapuser mqdom\MQ_S_CONFLUENCE /crypto AES256-SHA1 /pass * /ptype KRB5_NT_PRINCIPAL /out C:\my.keytab
As this sets the account pass, the Kerberos key potentially changes, so kvno is increased by 1.
Step 2: Run ktpass again to add a key for the alias, without setting the password again:
ktpass /princ HTTP/confluence.example.com@EXAMPLE.LOCAL /mapuser mqdom\MQ_S_CONFLUENCE /crypto AES256-SHA1 /pass * /ptype KRB5_NT_PRINCIPAL /in C:\my.keytab /out C:\my_merged.keytab -setpass
Note: Make sure to use the same password the second time.
Then simply upload C:\my_merged.keytab replacing the existing keytab, and things should now work using either hostname. The manage keytab page should now show you two keytab entries: One for each SPN/hostname.
Some further explanation of the second ktpass command:
There are more ways of doing this with ktpass. For further information, refer to the official Microsoft documentation: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass
To initially test this from your local machine with only a browser, you can add both DNS names to your local hosts file (unless this causes secondary problems with vhosts etc). This overrides DNS and causes each name to be temporarily treated as a canonical name by the browser when it tries to acquire Kerberos tickets (the test page may give a warning as the server will have a different view on this than your modified hosts file). Then log into Confluence using the host name you wish to test, and, and run the Kerberos test page, e.g.:
The SPN listed under "Your browser sent the following Kerberos token in the test page should now reflect the Confluence hostname/URL you used. When you use DNS, only #2 should appear when tested from the browser.