Sometimes it is convenient to avoid your client browser, service or application getting a Kerberos challenge. Not all clients support getting such. Therefore Kantega SSO includes features both for avoiding Kerberos on configured IP subnets and User Agents.
This page sums up the two ways of configuring client restrictions.
| Table of Contents |
|---|
...
Kantega SSO allows Kerberos to be limited to specific IP address ranges and/or User-Agents.
By default, every client will receive a Kerberos authentication challenge (SPNEGO) when Kerberos is enabled in KSSO. Not all clients support Kerberos however, and this can result in a bad user experience. The way a client handles a Kerberos challenge is both application and platform dependend. The most common issue is when you also have Windows desktop browsers that are not part of the AD domain, for example an employee working from home or external consultants. When a Windows browser is unable to obtain a Kerberos ticket, it shows an NTLM fallback popup like the following:
...
To prevent this from happening, this browser must not receive a Kerberos challenge in the first place. This is where client restrictions come in.
| Info |
|---|
The purpose of Kerberos client restriction is to improve user experience only. It is not a security measure. |
| Table of Contents |
|---|
Client IP restrictions
The image screenshow below shows a screenshot from the how IP restrictions configuration. You may enable Kerberos for any IP in the whitelist except what is given in the blacklist. Or you may disable Kerberos for IP given in the blacklist except what is given in the whitelist. Both blacklist and whitelist may contain regular expression syntax can be configured. The default is for every client will receive a Kerberos challenge. In the screenshot, all clients except any IP starting with 172.* will receive a challenge.
It’s possible to use a blacklist or a whitelist strategy, depending on what is most convenient for your environment. Both lists allow either prefix notation or regular expression syntax, which is enabled by starting with ^ as the examples show.
NB: For Kantega Single Sign-on to perform evaluate IP restrictions correctly when behind a reverse proxy, the correct IP address must be communicated . Setting this up is explained in to the Atlassian application. See the yellow notification box in the image belowbelow screenshot, which tells you the IP currently “seen” by the application.
...
User Agent restrictions
You may also restrict Kerberos from happening for a given User Agent. This is relevant if you have some client calling your Atlassian product that does not understand the Kerberos challenge Kantega Single Sign-on gives.
...