AppFusions' Kerberos SSO Authenticator for AD & Atlassian Servers solution supports Confluence, JIRA, Crowd, FishEye, Crucible, Bamboo, SVN as of this writing. It was first released in June 2011 and continually supported since, through dozens of Atlassian version releases (esp. JIRA and Confluence; the others came later).

Deployed, the Kerberos SSO over HTTP authentication flow is as follows:

1. User gets a Kerberos ticket from Active Directory during Windows login to a domain joined PC.
2. With a Kerberos-enabled browser (MSIE, Chrome, and Firefox), the user accesses an Atlassian web application protected by the AppFusions Kerberos SSO Authenticator.
3. The AppFusions Kerberos SSO Authenticator denies access to the browser with a 401 response and negotiates with the browser to use Kerberos for authentication or fall back to basic authentication if Kerberos is not possible.
4. If Kerberos is negotiated, the web browser gets a service ticket from a domain controller for authentication.
5. The web browser sends the service ticket to the AppFusions Kerberos SSO Authenticator for validation with a domain controller.
6. Upon service ticket validation, the AppFusions Kerberos SSO Authenticator uses Atlassian Seraph to log the user into the Atlassian web application.

Flow diagram is here. Contact Info@appfusions.com for more information. Many many references, successes, renewals, upgrades.

In my opinion it is perfectly fine that Confluence does not support Kerberos authentication. It would be nice, however, if Atlassian could provide an (preferably bundled) authenticator that supported auth via the REMOTE_USER HTTP header. This way, whatever authentication (e.g. Kerberos) could be handled by the webserver, and Confluence only has to handle the forwarded REMOTE_USER. I know that it's death simple to write an own authenticator, and we have done this already for this setup (Kerberos > Apache webserver > Custom REMOTE_User auth > Confluence), but it would be so nice if Atlassian would officially support this.

I would be happy with a host base authenticator/authoriser (eg PAM based) - then confluence would work with anything that linux supported.

I find the lack of a supported Kerberos authenticator disturbing due to the fact Active Directory is kerberos based too...

I agree with the comments here, too. This is NOT resolved and it's a shame, that an enterprise wiki (like Confluence) doesn't support SSO via Kerberos. Crowd is NOT the answer for everything. We need a reliable and well supported solution for this. I'll have an eye on the AppFusion plugin, but an (gladly a commercial one) Atlassian plugin would be better.

AppFusions has released a solution for this to the Plugins Exchange.

https://plugins.atlassian.com/plugin/details/39713

Of course we can adapt this solution for JIRA, Crowd, or any other Atlassian product.

Let us know if you want some help and get this resolved for you quickly!

Kerberos is also something highly desirable for our company, and we don't use crowd (nor plan on it in the future).

Agree with the comments here, this is not resolved, we need a built-in / native kerberos solution in Confluence. when can we get that? roadmap? Thanks.

Please set this to unresolved, as Crowd can not displace our existing enterprise authentication infrastructure.

I agree totally. Crowd won't help us . As a large enterprise we use other solutions already and is relying on Kerberos when using applications like Confluence.

Having this support only in Crowd does not solve the issue. Confluence itself should be able to provide this capability with out also having to purchase Crowd. Extremely disappointed that this was closed as I do not believe it has been resolved.