/
Configuring multiple SPNs for one Service Account in AD

Configuring multiple SPNs for one Service Account in AD

Owned by Jon Espen Ingvaldsen (Unlicensed)
Last updated: Feb 28, 2025 by Steinar Line
3 min read

You may sometimes need more than one Service Principal Name (SPN) for a Service Account in AD. For example:

  • The Atlassian application is using a CNAME, but you need to support clients that don't perform hostname canonicalization. Kerberos for REST or Kerberos for Git (any client or script built on libcurl) is a prime example of this. For such clients to work, you will need to register two SPNs one way or another. You can either create a second service account for the non-canonicalized name and merge the keytabs in Kantega SSO, or register both SPNs to a single service account using the ktpass method described in this document.

  • You prefer to have one service account for all your Atlassian applications. We don't recommend this, but it's possible.

Why do 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:

  • HTTP/appsrv.prd777.b.example.com@EXAMPLE.LOCAL

.... 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 are what you need, this document describes one way of achieving it.

Assume you want the following SPNs for Confluence:

  • HTTP/wiki.example.com@EXAMPLE.LOCAL

  • HTTP/confluence.example.com@EXAMPLE.LOCA

  Step 1: Run ktpass to generate the initial keytab for the correct/canonical SPN: 

ktpass /princ HTTP/wiki.example.com@EXAMPLE.LOCAL /mapuser svc-confsso-wiki@EXAMPLE.LOCAL /crypto AES256-SHA1 /pass * /ptype KRB5_NT_PRINCIPAL /out C:\wiki.example.com_will_be_corrupted_after_next_ktpass_command.keytab

As this sets the account pass, the Kerberos key potentially changes, so kvno is increased by 1. This keytab file will be corrupted after the next command is run, so I may just be deleted.


Step 2: Run ktpass again to add a key for the alias, without setting the password again:

ktpass /princ HTTP/confluence-test.example.com@EXAMPLE.LOCAL /mapuser svc-confsso-wiki@EXAMPLE.LOCAL /crypto AES256-SHA1 /pass * /ptype KRB5_NT_PRINCIPAL /out C:\confluence_merged.example.com.keytab

Note: Make sure to use the same password the second time.

This keytab file will only contain the last inserted SPN and can therefore also be deleted.


To install both keytabs into Kantega SSO, you will have to go to Import from Active Directory (see below), then give in the service account name and password in the boxes and press Connect to AD:

bilde-20250228-123933.png

And on the page that comes up:

Skjermbilde 2025-02-28 kl. 13.38.51.png

Select both service principal names and the correct encryption types and press Create keys. This will make a merged keytab with both the SPN names into Kantega SSO.

There may be 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 hostname 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. 



Related content