Confluence NTLM/SSPI (Domain Trusted Login) using Apache HTTP Server

Atlassian does not support  and does not intend to provide the auto-login feature when the computer is in Windows Domain.

There are only 2 possible solutions:

  • Use crowd or any LDAP connector that makes it possible to login using Domain username and password (you have to actually provide the username and password, but it’s always the domain credentials)
  • Use ntlmauth4confluence with jcifs plugin that might cause even more trouble (Starting from Windows Vista the default NTLM level is 5 and that means jcifs won’t work unless you change this value for each computer directly in windows registry files)

I’ve found a way how to use Apache Http Server NTLM authentication (mod_auth_sspi that works without any problem)  to authenticate in Confluence running inside Apache Tomcat. The steps below are for Confluence 3.x, succesfully tested with 3.2 and 3.3. The plugin might work even in 2.x but I’ve never tested that.


  1. Install Apache Http Server and Apache Tomcat
  2. Install mod_auth_sspi to your Apache Http Server
  3. Install proxy_ajp_module to your Apache Http Server (should be included by default)
  4. Setup Apache Http Server to forward requests to Apache Tomcat via AJP connector
  5. Install Confluence
  6. Build the attached Confluence plugin using Atlassian SDK or download the jar directly
  7. Configure the attached Confluence plugin and change default Confluence config in edit-webapp
  8. Start Confluence

Install mod_auth_sspi

Open conf/httpd.conf file in your Apache Http Server installation and add or uncomment the following LoadModule lines:

# NTLM section BEGIN
LoadModule sspi_auth_module modules/
# NTLM section END

Install proxy_ajp_module

Open conf/httpd.conf in your Apache Http Server installation and add or uncomment the following LoadModule lines:

# Proxy to local tomcats
LoadModule proxy_module modules/
LoadModule proxy_ajp_module modules/
LoadModule proxy_http_module modules/
ProxyErrorOverride on

Forward Apache Http Server requests to Apache Tomcat

Open conf/httpd.conf and add the lines below to the end (note, some installations of Http Server have separate file for this). Here you might ask why we need 3 separate locations. If you checked my article about Jira domain login you might realize there is no special section to distinguish protected and unprotected content. It’s not possible because of the way confluence constructs and protects the URL.

<Location /confluence>
    ProxyPass           ajp://localhost:8009/confluence
    ProxyPassReverse    ajp://localhost:8009/confluencee
    AuthName "Confluence - Enter your domain name and password"

    AuthType SSPI
    SSPIAuth On
    SSPIAuthoritative On
    SSPIOfferBasic On
    SSPIOmitDomain on

    Require valid-user

Configure Apache Tomcat to receive AJP requests from Apache Http Server

Open conf/server.xml in Apache Tomcat directory and change the following:

  • disable HTTP connector (comment out Connector element with protocol HTTP/1.1)
  • enable AJP connector (uncomment Connector element with protocol AJP/1.3)
  • add URIEncoding=”UTF-8″ parameter to AJP Connector (this will fix the issue with accent/national characters)
  • add tomcatAuthentication=”false” parameter to AJP Connector (this will force Tomcat to read the username from AJP – the one provided by Http Server)
  • add address=”″ parameter to AJP Connector (this will force Tomcat to listen only on localhost)

The AJP section should look like this:

    <Connector port="8009"
      tomcatAuthentication="false" />

Configure the plugin and Confluence

The plugin contains 2 different options to authenticate:

  • using Apache Http Server SSPI module
  • using jcifs library (copied from ntlmauth4confluence plugin)

We’ll use the Apache Http Server Authentication. Http Server sends the authenticated user via AJP to Tomcat. The domain is not included (SSPIOmitDomain on), if the user is not connected to domain a basic authorization is offered (SSPIOfferBasic On). We have configured Tomcat to receive requests only from localhost and to use the username provided via AJP.

NOTE: If you enable remote access to Tomcat (AJP or HTTP) the username can be changed by the request sender and Confluence can be tricked this way to think that the user is not who he/she claims to be!

Now we have to set a new Filter in Confluence edit-webapp/web.xml to tell Confluence that the user is succesfully authenticated if username is provided via AJP. The filter also checks if the user is in required group in LDAP (Active Directory in this case). Add the following lines just above trustedapps Filter:

    </filter> has to be copied into classes folder and the following lines have to be changed:




jcifs.smb.client.domain=[your-domain, e.g. MYDOMAIN]
jcifs.http.domainController=[your-domain-controller, e.g. domain.MYDOMAIN.local]

The ntlmauth.autojoin=false and ntlmauth.autoupdate.user.details are usable when you have confluence connected to LDAP via crowd – the user record is readonly for external confluence user providers. If you don’t intend to use Crowd, just enable these options (set yo yes) and the user info will be retrieved from LDAP/DC automatically. Also, the user will be automatically created if it is found in LDAP.

If you have any trouble the LDAP/AD permissions just provide the username and password:


The last step is to copy the compiled plugin into edit-webapp/lib directory also with jcifs jar.

pošli na

  1. #1 by Ed Letifov on 2012-11-09 - 09:41

    TechTime Initiative Group (, an Atlassian Expert in New Zealand has been providing NTLMv2 authenticator for Confluence and Jira (, based on Jespa from IOPlex ( for over 3 years at a quite reasonable one-off price of NZ$150 (plus Jespa’s license fee payable to IOPlex).

  2. #2 by lacike on 2012-11-09 - 12:13

    Hi Ed,

    that is true. However, my solution does not require any external java libraries to do the NTLM thing and is free to use (note that the TechTime full package costs $380or $630) 🙂

    Anyway, if I was to decide again I’d go for the payed package with support. If it was available for Jira 3.x I worked with at the time.

    I needed a quick solution 3 years ago, I did quite a huge research and was not able to find anything. I had to create my own solution. In the end I was preparing a JESPA aware package, but in the middle of that I left the company I was developing this thing for..

(will not be published)

Blue Captcha Image