Single sign on with active directory credentials

Are there any options or plugins that we can use to pass active directory credntials through to confluence (using Kerberos)?

We would like to have a user login to their PC on the domain, launch confluence and automatically be logged in using those same crednetials. Our environment is already LDAP integrated, however currently a user has to login in with their domain credentials into windows, then again into confluence with the same login.

You are certainly entitled to your opinion, but I see this as a very misleading comment.

If you take single sign-on out of Crowd - what does Crowd actually do, that the Atlassian applications like JIRA or Confluence don't do themselves (since they have Embedded Crowd inside).

Crowd "single sign-on on the web" i.e. "having to login once and then switch between multiple web applications without the need to login again" can not really be compared to a true single sign-on plugin, as in "login into your workstation and proceed to the application without the need to login ever". They are similar but not the same.

A true single sign-on plugin does little things that become important when you think about economy of scale:

saves you time (3 seconds spend entering your login/password, multiplied by the number of your people, every day, multiple times per day can mean a lot to many organisations)

increases security - no more saved passwords, if you are not using HTTPS - no more plaintext passwords send over the network

saves you money (by removing the possibility to have locked accounts incidents completely and thus reducing calls to your service desk)

removes barriers for adoption and as such removes barriers for collaboration (compare the dread of "if I click on the link in this email I will be faced with yet another login window" vs. "here is something interesting, click, reply")

simplifies rollouts ("here is the link, you will be logged in automatically" vs. "here is the link, use your Domain user/password")

Perhaps none of this is important enough by itself, but you just need to see a person who moves from an organisation where SSO was deployed to the organisation where there is none. "It's like air. You only notice it when it is not there." - this is the real comment from a customer of ours who found themselves in this situation. Why don't you install one of the plugins using an eval license, which you can re-generate several times, let it run in your organisations for at least a month, and then pull it out. And then please report the reaction of your users.

"Expensive" needs to be viewed in the context.

Yes, it seems more expensive than asking your fellow sysadmin to read-up on some docos and spin up a home-grown solution using Apache and some kerberos library. However, he is not going to do it instantaneously, and any minute spend on this is a minute he could have spend on something more important. What do you do when this sysadmin leaves or when client OS vendor pushes a security update that stops the solution from working? What do you when Atlassian application changes? How much cost do you put on your SSO "down-time"?

You need to take into account what the solution actually does. For example our SSO plugin does auto-enrolling users, automatic failover to a different Domain Controller based on DNS, support for AD sites and services, filtering by gazillion different criteria, dare I mention fallback to NTLM when Kerberos is not possible? Take a look at our FAQ - try to guess the "complexity" of the task. And (if you know what you are doing) the deployment is still "under 15 minutes". If in doubt - get in touch and I'll be happy to prove it to you via a desktop sharing session. I bet you, your sysadmin can't beat this even following a well written configuration document.

You need to understand the cost of actually maintaining an add-on as an Enterprise solution (as Ellen briefly alluded to above). Where Atlassian is capable of spreading the costs across multiple products and customers - smaller marketplace vendors cannot. Every time when a new major version comes out Marketplace marks a plugin as "incompatible". We have 5 SSO plugins for 5 Atlassian applications - keeping them up-to-date does take effort. We support Windows, Linux and Mac OS X, IE, FF, Safari and Chrome - testing across all of these platforms is daunting. As commercial vendor I undertake responsibility for my product, so you don't have to take the risk. I have at least 4 full-time people involved in supporting this add-on - developers, support, marketing. In New Zealand the minimum wage is about US$10/h. If I were to pay these 4 people just the minimum wage that's US$80k right there. Take mine or Katenga's "active installation" numbers from Marketplace, our average customer is 250-500 users - do the calculation.

You also need to take into account what the customer should be able to afford as far as we the vendors think. Let's take 25 users level, one where we are more expensive than Katenga. Our cost is US$600 for the first year, US$300 renewals after. Let's say you are on the bottom level of 25 users i.e. 11 users - don't fit into the Starter license anymore, but feel the pain of suddenly "having to pay more that $10 for everything". Your JIRA license costs you US$1800 and renews are at US$900. 11 users - applying the same "minimum wage" argument - you are paying them at least US$220k in salaries. If you can afford that - you overall gross revenue should be at least 2-3 times more. So now look at $600 per year in this context - still too expensive?

Pardon me for this long diatribe. We get this feedback all the time. People try our plugin, then uninstall and Atlassian application pops up a dialog asking why. The choices are limited and "Too Expensive" is one of them. We try to get back to everyone who leaves their contact details. Interestingly, those who label it as "too expensive" NEVER come back to us to explain why. And it's truly a pity - since it would have helped us to reshape the pricing policy if we understood this particular segment of the audience.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

+1 from me. We need a working solution as well (for Confluence and JIRA), since our last one broke up Office-Connector <-> Office 2010 functionality. So any hints about this topic would be appreciated.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

TechTime Initiative Group, an Atlassian Expert in New Zealand has been providing a solution to do NTLM authentication with Confluence and Jira for over 6 years. Though one can argue that this is not an SSO solution but merely an auto-login one, it works well in Windows-based environments.

We have over 60 customers successfully using this solution in New Zealand, Australia, Switzerland, Finland, Norway, Sweeden, France, Germany, Netherlands, Slovenia, Czech Republic, Turkey, Russia, Latvia, the UK and the USA both in NTLMv2 and NTLMv1 environments with and without Crowd in the backend.

The NTLM Authenticator is delivered as a jar file and instructions how to deploy it to Atlassian Jira and/or Confluence to work in conjunction with IOPlex Jespa to perform NLTM authentication in Windows environment.

The cost is one-off NZ$150 (plus fees for Jespa license payable to IOPlex). We do sell bundles that include IOPlex Jespa license.

If you need it, the trial version is available from our TurningRight website. Our NTLM Authenticators for Jira and Confluence support the latest versions of both applications.

We are currently working on moving it to Marketplace (Jan/Feb 2014) and as byproduct eventually making it support the rest of Atlassian tools (planned for 2nd quarter of 2014)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

IWAAC is a generic plugin that works on all applications that are compatible with Crowd. Once you have purchased a proper license, you can deploy the plugin on as many applications (Confluence, Jira, Bamboo etc.) and server instances as you want since an IWAAC license is an Enterprise license that is valid for your entire organisation.

Microsoft is offering this integration for FREE. You can use Azure Active Directory FREE version which comes with 500K directory objects. See the Free SKU details from here.

You can connect you existing Active Directory with Azure Active Directory using Azure AD Connect. Once you have all the users in Azure AD then you can simply use our FREE plugin listed here and then configure SAML based single sign on with Confluence server. All the instructions are listed here.

Feel free to post your queries on the article and we are happy to help.