Show Page Tree structure

The selected root page could not be found.

Kantega SSO Enterprise for Jira, Confluence, Bitbucket, Bamboo and Fisyeye/Crucible follow an almost identical pattern on each of the products. If you have one of those, this guide is for you.

Introduction

This guide will show how to establish password-less Integrated Windows Authentication (Kerberos) single sign-on for a Confluence instance available at https://wiki.example.com. 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 so that you can create and configure user accounts in AD. If you do not have these permissions yourself, you will have to ask a colleague for help.

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

This YouTube video shows the necessary steps to set up Kerberos login and how the login experience will be when it is configured. It was created a couple of years ago Some screenshots may have been altered slightly since then:

Setup wizard

In the configuration page, click Run Kerberos Setup Wizard.

This wizard helps you in the following ways:

It helps you collect some essential 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 on your Active Directory server, which Kantega SSO needs to import to authenticate users.

Start page

In many cases, the wizard can suggest appropriate configuration values for you automatically. If you already have connected a user directory of the type Active Directory this makes it easier for the wizard to guess the right values. If all values in this page look good, you can jump straight to the task summary (by clicking User these values) in below screenshot using the suggested values instead of going through each step.

If you instead click Run wizard to change values, you will come to pages looking like the ones below.

Canonical host name

In our case wiki.example.com is the actual Canonical name (A RECORD) and we can use this. (If wiki.example.com was a DNS CNAME alias, say for server123.example.local, then the canonical name should be server123.example.local.)

The wizard will try to lookup the right Canonical name using DNS, but it is not always available to do so in some environments.

Realm

On this page you select the realm to use in your setup. If you have a complex AD structure with multiple realms you will be able to lookup users in an AD forest.

Active Directory Account

You need to select the name you want for the account linked to the Kerberos keytab file. This account will later need to be created in your AD.

Ecryptition type

We strongly suggest you select the highest encryption type AES 256 for better security. Only in a mixed environment of older AD servers you might need some of the weaker encryption, but please note that this will leave your system weak for attacks.

Summary / Tasks

On the summary page you are give certain tasks like creating the right user account in AD and selecting the appropriate encryption. You will also have to run a PowerShell script shown on the page with the command ktpass to create the keytab file to import into Kantega Single Sign-on Enterprise. As a final step you upload the keytab file. Read more on the following steps to make things work here: https://kantega-sso.atlassian.net/wiki/x/NQBQYQ

The Get-ADUser part of the above command will clear potential earlier attempts to link the SPN HTTP/wiki.example.com@EXAMPLE.LOCAL to other accounts in AD. The $null value in the end is correct syntax to clear the value of the UserPrincipalName field making ktpass command more likely to succeed.

A quick review of the ktpass syntax

Command / parameter	Description
ktpass	ktpass is pre-installed in Windows 2008 onward. Located in c:\Windows\System32
/princ HTTP/issues.example.com@EXAMPLE.LOCAL	HTTP is always used for web servers, also when using https. issues.example.com 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/issues.example.com
/crypto AES2568-SHA1	Specifies the encryption type used when generating keys in the keytab. Must match the account supported encryption type.
/ptype KRB5_NT_PRINCIPAL	The general ptype, recommended by Microsoft.
/out c:\issues.example.com	Output location of the generated keytab file

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

Specifically, ktpass will:

Add a servicePrincipalName attribute on the account with the value HTTP/wiki.example.com.
Set the userPrincipalName attribute to HTTP/wiki.example.com.
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/wiki.example.com@EXAMPLE.LOCAL.

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

Kerberos setup wizard