JIRA is Unable to Use NTLM Authentication
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
The content on this page relates to platforms which are not supported. Consequently, Atlassian Support cannot guarantee providing any support for it. Please be aware that this material is provided for your information only and using it is done so at your own risk.
Symptoms
When attempting to integrate a NTLM proxy within JIRA, any of the below can occur:
JIRA will be unable to access the Atlassian Marketplace through the Universal Plugin Manager.
Fisheye application links may not work.
Support Tools (Hercules scan) will be unable to run as it cannot fetch the require metadata.
Built-in feedback will no longer work.
'What's new' gadget will not be able to retrieve information.
The below JVM arguments may not be recognised:
-Dhttp.proxyHost-Dhttp.nonProxyHosts-Dhttp.proxyPort-Dhttp.proxyUser-Dhttp.proxyPassword-Dhttp.auth.ntlm.domain
The following appears in the atlassian-jira.log:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
2012-06-22 11:22:22,363 StreamsCompletionService::thread-3 ERROR bmills 681x247x6 1ku2b0i 10.128.49.73 /plugins/servlet/streams [apache.commons.httpclient.HttpMethodDirector] Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials
org.apache.commons.httpclient.auth.InvalidCredentialsException: Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials
at org.apache.commons.httpclient.auth.NTLMScheme.authenticate(NTLMScheme.java:331)
at org.apache.commons.httpclient.HttpMethodDirector.authenticateProxy(HttpMethodDirector.java:319)
at org.apache.commons.httpclient.HttpMethodDirector.authenticate(HttpMethodDirector.java:231)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:169)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:324)
at com.atlassian.sal.core.net.HttpClientRequest.executeMethod(HttpClientRequest.java:479)
at com.atlassian.sal.core.net.HttpClientRequest.executeAndReturn(HttpClientRequest.java:306)
at com.atlassian.plugins.rest.module.jersey.JerseyRequest.executeAndReturn(JerseyRequest.java:158)
at com.atlassian.applinks.core.auth.ApplicationLinkRequestAdaptor.execute(ApplicationLinkRequestAdaptor.java:85)
at com.atlassian.streams.internal.AppLinksActivityProvider.fetch(AppLinksActivityProvider.java:416)
at com.atlassian.streams.internal.AppLinksActivityProvider.access$200(AppLinksActivityProvider.java:96)
at com.atlassian.streams.internal.AppLinksActivityProvider$1.call(AppLinksActivityProvider.java:178)
at com.atlassian.streams.internal.AppLinksActivityProvider$1.call(AppLinksActivityProvider.java:170)
at com.atlassian.streams.internal.FeedBuilder$ToFeedCallable$1.call(FeedBuilder.java:115)
at com.atlassian.streams.internal.FeedBuilder$ToFeedCallable$1.call(FeedBuilder.java:110)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at com.atlassian.util.concurrent.LimitedExecutor$Runner.run(LimitedExecutor.java:96)
at com.atlassian.sal.core.executor.ThreadLocalDelegateRunnable.run(ThreadLocalDelegateRunnable.java:34)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)Cause
Currently JIRA and Stash does not support all implementations of integration with NTLM proxies and due to this certain areas of JIRA will not function fully when using one. For further information, please take a look at the below issues:
Workaround
As you can see from past comments: here and here, customers reported success by following the steps below:
Install Cntlm Authentication Proxy locally to their JIRA/Stash server
Configured and tested it to make sure "Cntlm" works with their corporate NTLM and then used the parameters
How to test Cntlm is working with your NTLM
Update your user, domain, and proxy information in
cntlm.ini, then test your proxy with this command (run in your Cntlm installation folder):cntlm -c cntlm.ini -I -M http://google.roIt will ask for your password, and hopefully print your required authentication information, which must be saved in your
cntlm.iniSample
cntlm.ini:Username user Domain domain # provide actual value if autodetection fails # Workstation pc-name Proxy my_proxy_server.com:80 NoProxy 127.0.0.*, 192.168.* Listen 127.0.0.1:54321 Listen 192.168.1.42:8080 Gateway no SOCKS5Proxy 5000 # provide socks auth info if you want it # SOCKS5User socks-user:socks-password # printed authentication info from the previous step Auth NTLMv2 PassNTLMv2 98D6986BCFA9886E41698C1686B58A09Note: on linux the config file is
cntlm.confHave the configuration described on Configure an outbound proxy for use in Jira server point to the local "Cntlm" proxy instead - and that one will do the job to talk to NTLM.
There are no other current workarounds for Fisheye - please see FISH-436 for further information.
Was this helpful?