Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Kerberos auth can be limited to specific IP address ranges and/or User-Agents.

By default, every client will receive a Kerberos authentication challenge (SPNEGO) if Kerberos is enabled in KSSO. If a given client does not support Kerberos or is not part of the domain, this can result in a bad user experience. The way clients handle a Kerberos challenges is both application and platform dependent. The most common issue is to 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 for any reason, 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.

The purpose of Kerberos client restriction is to improve user experience only. It is not a security measure.

Client IP restrictions

The screenshow below shows how IP restrictions 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 blocked list or a unblocked list 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 ^.

NB: For Kantega Single Sign-on to evaluate IP restrictions correctly when behind a reverse proxy, the IP address must be communicated to the Atlassian application. See the yellow notification box in the below 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.

There is an already built-in list of known User Agents that is not Kerberos compatible. The functionality below lets you add your own User Agent restrictions to this list.

  • No labels