You are viewing the Kantega SSO legacy documentation. The new documentation site is:
Skip to end of metadata
Go to start of metadata

Our add-ons for Jira, Confluence, Bitbucket, Cruicible and Bamboo follow an almost identical pattern. If you have one of those products, this guide is for you.


This guide with establish password-less Integrated Windows Authentication single sign-on for a JIRA instance available at

The Windows uses are logged into their computers using the Active Directory domain EXAMPLE.LOCAL

In this example, we assume a Microsoft Active Directory/LDAP User Directory has already been set up for the same domain.

We also assume that you have Domain Admin rights such that you can create and configure user accounts in AD. If you don't have these permissions yourself, you might have to ask a colleague for help 

We recommend setting up a test environment before you go to production.

This youtube video shows the basic steps taken to setup kerberos login, and how the login experience will be when this is set up.

Setup wizard

In our add-on configuration page, click Run Kerberos Setup Wizard. 

This wizard helps you in the following ways:

  • It helps you collect some key information about your environment
  • It shows you how to create and/or configure an Active Directory account 
  • It shows you the ktpass command you will use to create a Kerberos keytab file, which our plugin needs to authenticate users. 

Start page

In many cases the wizard can suggest appropriate configuration values for you automatically.

If this is the case, you will be notified. You might want to jump straight to the tasksummary using the suggested values instead of going though each step.

For the purpose of this guide though, we will run through each steps of the wizard.

Active Directory Connection

Connecting to your Active Directory lets the wizard inspect your AD, suggest values and validate that your configuration is valid. 

You can choose a pre-configured User Directory, or connect to an Active Directory server of your choice:

Canonical host name

If issues.examle.local is a DNS CNAME record, say for server123.example.local, then the canonical name is:  server123.example.local

Otherwise, if it's a DNS A record, then the canonical name is

Usually, the wizard can determine this for you by looking it up in DNS on the server.

If that fails, the wizard will instruct you on how to determine this manually on the client side.

Note that even if you access JIRA using the short name http://issues, the canonical name is always in FQDN form. (It is never just issues, but

Kerberos Realm name

The Kerberos Realm name looks something like EXAMPLE.LOCAL or ACCOUNTING.COMPANY.COM

It is your Active Directory Domain name in upper case, dot-separated format.

If the wizard can't look this up in AD, it will instruct you on how to determine this on your client.

Active Directory account

Kerberos services need to be mapped to an Active Directory account. We recommend you use a separate AD account for the purpose of mapping each Kerberos service.

Unless your instance is already mapped, the wizard will suggest an account name such as svc-jirasso-issues

Encryption types

The wizard will suggest the strongest encryption type supported by your environment.

Some factors which may limit your choice of encryption strength:

  • If your Domain Functional Level is Window 2003, then only RC-4 is supported
  • AES-256 is only supported if the Java used for running your Atlassian product has the Unlimited Strength Policy Files installed

Enabling AES 256 support in Java

In January 2018 Java 8 update 161 was released having support for AES 256.
If you for some reason must use a Java-version older than this, you can download the JCE Unlimited policy files from Oracle: . Full installation instructions should be in the README, but it's basically just unzipping the contents into the correct folder of the local Java installation. Then restarting Java (i.e. Jira/Confluence/etc). If the files are not picked up, you should get a pretty clear message to that effect as soon as you try to do something that requires AES-256.

The JCE policy files were previously needed because of old US export policies for strong cryptography. Java disabled ciphers like AES-256 by default, requiring the installation of the aforementioned JCE policy files to unlock. While export requirements were relaxed more than a decade ago, it took until early this year for the first Java Runtime release to finally ship with the unlimited policy files included by default.

If your service is already mapped to account, then the strongest configured encryption type for that account is recommended. 

In this case, the wizard has recommended AES-256:

Task summary 

The final page of the wizard starts by displaying the configuration determined in the previous steps:

Step 1 of the task list describes describes how to create and / or configure the service account.

Depending on your AD permissions, you might need to hand this task over to your AD team.

The account svc-jirasso-issues needs to be created with "password never expires".

Then, in the account options, we need to enable "This account supports Kerberos AES 256 bit encryption":

Step 2:

Shows you how to create a keytab file using ktpass. Again, this is a task you might have to delegate to your AD team.

Step 3:

Finally, you may upload the keytab file created. After the upload has finished a logon test will be performed. 

Note that if you have multiple domains, then you are offered to add keys to the existing keytab file.

A quick review of the syntax:

Command / parameterDescription
ktpass is pre-installed in Windows 2008 onward. Located in c:\Windows\System32
/princ HTTP/

HTTP is always used for web servers, also when using https. is the canonical DNS name of JIRA

EXAMPLE.LOCAL is the Kerberos realm name of the Active Directory Domain

/mapuser svc-jirasso-issues@EXAMPLE.LOCAL

Maps the /princ name above to the account svc-jirasso-issues.

ktpass will add this attribute on the account:

servicePrincipalName: HTTP/
/crypto AES2568-SHA1
Specifies the encryption type used when generating keys in the keytab. Must match the account supported encryption type.
The general ptype, recommended by Microsoft.
/out c:\
Output location of the generated keytab file

Running the ktpass command will output a keytab file and register as an HTTP Kerberos service.

Specifically, ktpass will: 

  • Add a servicePrincipalName attribute on the account with the value HTTP/
  • Set the userPrincipalName attribute to  HTTP/
  • Ask the admin to provide a password and confirm it
  • Set that password on the account
  • Generate a keytab file with an AES-256 key for the principal  HTTP/

Note that ktpass must be running in a "run as administrator" cmd window by a user with Domain Admin permissions.

Browser configuration

After uploading the keytab file, you will be redirected to the Kerberos Authentication Test page.

If you're lucky this test will succeed on your first try:

Internet Explorer

In our case, we got a failing test. Internet Explorer has not been configured to send Kerberos tickets to It falls back to sending NTLM tickets instead (which is seen as a usename and password popup)

We need to make sure is placed in the Local Intranet Security Zone, since that is a requirement for Internet Explorer to send Kerberos tickets.

The zone settings are usually set enterprise-wide using Group Policies. Here's the GPO we used to place * and in the Local Intranet Zone (Zone 1):

Other browsers

For more details on configuring Zone settings, and configuring Chrome and Firefox on Windows, Mac and Linux, see our Browser Configuration Guide

Fallback to SAML

Mobile devices and computers not configured for Kerberos Single Sign-on can be offered SAML SSO instead.

  • No labels