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.
Our goal is to This guide with establish password-less Kerberos single Integrated Windows Authentication single sign-on for a JIRA instance available at https://issues.example.com
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 Kerberos in a test environment before you go to production.
Search and find our add-on Universal Plugin Manager, press Free trial. Then in the Manage Add-ons page, click the Configure button on the Kantega Single sign-on Add-on.
In our add-on configuration page, click Run Kerberos Setup Wizard.
- 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.
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 task summary 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
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 issues.example.com)
Kerberos Realm name
The Kerberos Realm name looks something like EXAMPLE.LOCAL or ACCOUNTING.COMPANY.COM
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
The wizard will suggest the strongest encryption type supported by your environment.
Anchor tasksummary tasksummary
The final page of the wizard starts by displaying the configuration determined in the previous steps:
Note that ktpass must be running in a "run as administrator" cmd window by a user with Domain Admin permissions.
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:
In our case, we got a failing test. Internet Explorer has not been configured to send Kerberos tickets to issues.example.com. It falls back to sending NTLM tickets instead (which is seen as a usename and password popup)
The zone settings are usually set enterprise-wide using Group Policies. Here's the GPO we used to place *.example.com and issues.example.com in the Local Intranet Zone (Zone 1):
For more details on configuring Zone settings, and configuring Chrome and Firefox on Windows, Mac and Linux, see our Browser Configuration Guide