NTLM Authenticator does not work any more with Confluence 4.x (probably same problem with 3.5.x) ?!?

[Sven]

Hello,

I just tried to get this to work:

https://studio.plugins.atlassian.com/wiki/display/NTLM/Confluence+NTLM+Authenticator

But from the Errors/Logfiles I've seen that there is a "missing" atlassian-users.xml-file. And this file doesn't exists any more after confluence 3.5...

Are there really so less Windows users who want to login to confluence with their windows credentials?

Is there currently no solution available?

Could there be a way to restore such an xml-file from confluence 3.4 and get it working this way?

Thanks for any hint,

Bye

Sven

--------------------------------

From the log-file

2011-11-29 13:19:17,728 ERROR [main] [net.ldap.atlassianuser.AUParser] parse The 'atlassian-user.xml' file could not be found at all. Bug!
2011-11-29 13:19:17,728 ERROR [main] [net.ldap.atlassianuser.AUParser] parse Problem reading 'atlassian-user.xml' file - The 'atlassian-user.xml' file could not be found at all. Bug!
2011-11-29 13:19:17,728 FATAL [main] [com.jnj.confluence.NTLMFilter] <clinit> Error loading ldap configuration (this isnt going to work)Unable to process atlassian-user file, IOProblem: The 'atlassian-user.xml' file could not be found at all. Bug!
2011-11-29 13:19:19,288 ERROR [http-80-1] [com.jnj.confluence.NTLMFilter] doFilter Exception during NTLM filter:java.lang.NullPointerException, msg=null

[Joe Clark · Accepted solution]

You could try either of these approaches (Note that both these mechanisms are unsupported by Atlassian unless you are using the SharePoint Connector for Confluence):

• http://confluence.atlassian.com/display/SPCON/Configuring+Tomcat-Connector+for+IIS+7.0+%28Windows+Server+2008%29
• http://confluence.atlassian.com/display/SPCON/Configuring+Confluence+to+use+Jespa+for+NTLM+Authentication

There is also a third-party vendor who supports an NTLM solution for Confluence, but I am unsure if they support Confluence 4 or not:

http://techtime.co.nz/display/TECHTIME/Home

[Sven]

Another question:
On the suggested page about Jespa it is written "for Sharepoint Connector Customers only". What does this mean? Do I have to order the Sharepoint Connector to use this .jar-File? Do I need an additional Jespa-License in addition to the price of the sharepoint connector?

Thanks in advance for a short clarification...

[Joe Clark]

It will work perfectly fine without the SharePoint Connector, but Atlassian won't offer any support to you.

[Sven]

Hi, tanks for the suggestions.

I already contacted techtime, they say its compatible with 4.x! The Jespa-Pricetag is 200 USD from 25 to 500 Users, too. Hmm. I will look into the other options...

[Sven]

Ok, so I don't need a Sharepoint Connector license. But will I need a Jespa-License???

Other related question: If we buy the sharepoint connector, is the jespa-license included?

Thanks for clarification

[Joe Clark]

No SharePoint Connector licence required. Jespa licence is required - you will need to obtain this separately from IOPlex.

The Jespa licence is not included in the cost of the SharePoint Connector licence fee.

[Sven]

Ok, using IIS is an option for us.

I've configured everything like indicated here:
http://confluence.atlassian.com/display/SPCON/Configuring+Tomcat-Connector+for+IIS+7.0+%28Windows+Server+2008%29

and I CAN connect to confluence (port 8090) via IIS (port 80), but NTLM is not working.

Well in one step between there was a prompt for credentials in the browser, now it disappeared (good sign perhaps), but it takes me again to the confluence login-page...

I checked all the ports and so on, AJP is listening on 8009... The only thing which is strange to me is that the file:
C:\tomcat_iis_connector\logs\isapi_redirect.log

is still empty?

Any clue where to look for an indication...

Thanks a lot

[Joe Clark]

Make sure that your IIS application pool identify has permission to read and write to the C:\tomcat_iis_connector directory.

You can get additional logging information by editing your worker.properties file and changing the log level to DEBUG (recycle IIS to pick up changes).

Additionally, it may be helpful to use something like WireShark or Fiddler to examine the HTTP connection between your browser and IIS to see if the authentication attempt is actually successful.

[Sven]

Thanks for the hint. With some google-searches I've found this page:
http://confluence.atlassian.com/display/SPCON011/Access+Confluence+using+Integrated+Windows+Authentication+via+IIS

Obviously in addition to the mentioned page, there was a special authenticator need to let confluence accept the security tokens, passend in by tomcat...

PS1: Would be worth to collect the information from this answers-thread in a page in documentation which shows all the options?

PS2: What's missing @Atlassian is a "Mega-Search" where I can search all wiki, documentations. old forums, this answers site and so on with one search... Ok, I've done it with google but would be much more comfortable ;-)

[Sven]

to PS2: Just found it ;-)

http://www.atlassian.com/en/search?query=attachment%20macro

[Sven]

Hello,

unfortunately, after upgrading today to confluence 4.1 SSO-NTLM stopped working. I get always the error:

2011-12-14 07:55:19,875 ERROR [http-8090-1] [com.pixelpark.seraph.SSOAuthenticator] getUser Not logged in as REMOTE_USER (User: null)

[...]

2011-12-14 07:55:22,059 ERROR [http-8090-4] [com.pixelpark.seraph.SSOAuthenticator] getUser Not logged in as REMOTE_USER (User: null)
-- url: /rest/shortcuts/latest/shortcuts/3126/5705083e4a21007aa8839555d8f746ae
2011-12-14 07:55:24,228 ERROR [http-8090-4] [[Standalone].[localhost].[/].[action]] log Servlet.service() for servlet action threw exception
java.lang.ClassCastException: com.atlassian.confluence.user.SessionSafePrincipal cannot be cast to com.atlassian.user.User

=> Has something changed in 4.1 in comparison to 4.0.5 ?

I've already done some searching, perhaps the "Custom Authenticator" is now outdated?

Step 3.3: Add Custom Authenticator

By default, Confluence will not understand the pre-authenticated requests that come through via the IIS Web Site. In order to allow this authentication information to pass through, you must modify the authenticator module used by Confluence.

<colgroup><col width="24"/><col/></colgroup>

Custom authenticator is currently attached to this page Currently, the Custom Authenticator is attached to this page as a JAR file. We are working on moving this to a better download location.

1. Download the customauth-0.4.jar file attached to this page and place it in your %confluence_install%\confluence\WEB-INF\lib directory.
2. Edit the %confluence_install%\WEB-INF\classes\seraph.xml file.
3. Locate the Authenticator element and comment it out entirely.
4. Add a new Authenticatorelement that looks like this:
   <Authenticatorclass="com.pixelpark.seraph.SSOAuthenticator"/>
5. Save your changes and close the file.
6. Restart Confluence and ensure that the server initialises successfully.

Source: http://confluence.atlassian.com/x/zIkCDQ

Perhaps I just have to wait that this file gets updated? How to speed up things?

[Manse Wolken]

The error sounds more as if IIS has not authenticated the user (i.e. allowed anonymous access) thus the plugin gets no user (REMOTE_USER NULL).

Check if IIS can use NTLM only as authentication source. If there is any other source, remove it.

[Sven]

Thanks for the suggestion. I've changed nothing in IIS configuration. I just double-checked it. No there is only Windows-Authentication allowed in IIS...

I only upgraded from 4.0.5 to 4.1 and re-applied the changes...

(Hmm. Do the configuration files change from version to version? I just copied "my" modified files from the previous version...)

[Joe Clark]

The error you've reported against Confluence 4.1 is new to me - never seen that before. I'll take some time today to see if I can reproduce the problem; will keep you posted.

[Sven]

Thank you very much for all your efforts.

Don't hesitate to ask if you need additional debugging information (don't know how to enable and where)...

BTW: Are you the author of "customauth-0.4.jar" ? Is the source-code available? (should be as officially only the office connector-source is not available)

If nothing else helps I/we could introduce some debugging here...

[Sven]

just to say that we still have no solution. Thanks for any hints and happy xmas and good new year 2012!

[Joe Clark]

I've just setup a clean install of Confluence 4.1 on Windows 7 and successfully used the Custom Authenticator for the Sharepoint Connector (customauth-0.4.jar) and I am able to authenticate successfully.

Are you able to post the full stacktrace of the error you are getting? Also, could you perform a test with any 3rd party and non-system plugins disabled?

[Joe Clark]

An updated custom authenticator is now available for download that fixes the Confluence 4.1 incompatibility: http://confluence.atlassian.com/download/attachments/218271279/customauth-0.4.jar?version=1&modificationDate=1274934373463

[Sven]

after sharepoint connector 1.5 came out yesterday, I've done another try: and it just works. No idea why ;-)

Hope that after the next update it will continue to work, too... ;-)

[Sven]

ok, now I even perhaps know what changed from 4.0.x to 4.1:

Before 4.1 it was possible to have two connectors configured in server.xml:

        <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8090" minProcessors="5"
                   maxProcessors="75"
                   enableLookups="false" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="20000"
                   useURIValidationHack="false" URIEncoding="UTF-8"/>
						   
		
		<Connector port="8009" address="127.0.0.1" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" URIEncoding="UTF-8" />

So I was able to login to confluence on port "8090" with the confluence-user "admin" and on standard-port (via IIS) with all the LDAP-Active-Directory-Users.

Now, if I try the same again, I'll get this already stated error:

caused by: java.lang.ClassCastException: com.atlassian.confluence.user.SessionSafePrincipal cannot be cast to com.atlassian.user.User
at com.atlassian.confluence.user.AuthenticatedUserThreadLocal.getUser(AuthenticatedUserThreadLocal.java:25)

=> I have no problem with leaving the second "connector" permanetly out, BUT

my SOAP-Client is not working any more. It is throwing:

401 - authorization failed, when I try to login with SOAP...

Any hint how to solve this?

[Andy Brook [Plugin People]]

The project in the subject only broke a while back, I think when Oauth came in. The justification of effort to rewrite what is only an NTLM v1 'fakey' authenticator wasnt there. I dont support it and it should be pulled.

Jespa is the only native Java NTLM V2 authenticator library, +1 to TechTime for their impl and maintaining platform neutrality. I think that the product David refers to makes use of windows native DLLs making it platform dependant, which may or may not matter to you.

The issue with JESPA is that the license doesnt really work for resellers, its targetted at you, the end user who has the specific userbase.

[Bill_Campbell]

Where does one obtain the new edition of "customauth-0.4.jar"? ie: "i've reported to atlassian and they send me new customauth-0.4.jar build which fixes errors for logg message "java.lang.ClassCastException: com.atlassian.confluence.user.SessionSafePrincipal cannot be cast to com.atlassian.user.User""

Thanks,

Bill

[Joe Clark]

The latest version is linked for download from our documentation - the latest version is currently 0.6 and is available for download here.

[Sven]

Thanks a lot Tibor, with the help of this little updated .jar-file everything works again as before!

[Sven]

I've done another try - and it just works again... Don't know why ;-)

[Sven]

oh. yes, thats really something missing in here:

sven (dot) schaetzl (at,at) gmail (dot) com

(hope I'll not be spammed now, I doubled the "at" for fighting against spam bots... ;-)

Thanks in advance!

[Eleveo Admin]

paste here your email because there is no private messages.

[Sven]

hey, yes, that sounds great! Yes please send it to me!

thanks a lot in advance!

[Eleveo Admin]

Hi svenni, we had same problem as you wrote in comment on Dec 14 at 03:36 AM. steps you did we did same based on http://confluence.atlassian.com/display/SPCON/Access+Confluence+using+Integrated+Windows+Authentication+via+IIS+with+SP+2007

i've reported to atlassian and they send me new customauth-0.4.jar build which fixes errors for logg message "java.lang.ClassCastException: com.atlassian.confluence.user.SessionSafePrincipal cannot be cast to com.atlassian.user.User"

so i can send you if you want it

[Sven]

/EDIT

As of confluence 4.1 this is not working any more ;-(

/EDIT

Thank you everyboy for all your suggestions and informations.

I got it working without 3rd-Party-Software following this guide:

http://confluence.atlassian.com/display/SPCON011/Access+Confluence+using+Integrated+Windows+Authentication+via+IIS

There are some limitations, though. Perhaps I'll come back to a 3rd party connector ;-)

[Sven]

Its working again, don't know why ;-)

[Sven]

For Info:

What was not working any more with the downloadable "customauth-0.4.jar" is the following configuration in the server.xml-File:

        <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8090" minProcessors="5"
                   maxProcessors="75"
                   enableLookups="false" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="20000"
                   useURIValidationHack="false" URIEncoding="UTF-8"/>
					   
		
		<Connector port="8009" address="127.0.0.1" enableLookups="false" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" URIEncoding="UTF-8" />

=> that means using two different connectors: One (port 80 via 8009) with IIS 7/NTLM/LDAP-ActiveDirectory authentication and the standard port "8090" to be able to still login with native confluence users ("admin") or SOAP-Clients.

This works again with the help of a new edition of "customauth-0.4.jar" (see comments to the original question).

[Ed Letifov _TechTime - New Zealand_]

Our NTLMv2/NTLMv1 authenticator supports Confluence 4.x as well as Jira 4.x. Our fees at the moment are one-off same as those from IOPlex. The authenticator works in Crowd environment as well as without Crowd. We are always open to requests if some killer feature is missing.

[David at David Simpson Apps]

This could be an alternative:

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

[Sven]

Thanks for the answer! Only the pricetag is far too high ;-(

We have only a 50 user license, so about 1000 USD for a little more "comfort and security" is out of reach.

Is there no version "without install support" available? (around max. USD 200 or so ;-)

Thanks,

Sven

[Ed Letifov _TechTime - New Zealand_]

With all due respect, Kerberos may be theoretically better and the technology of the future, but in practice there are A LOT of caveats. As a company offering hands holding service to install your own solution in the clients' environments you should know that very well.

This is what I got in response when I asked Jespa's author for his opinion about NTLM vs. Kerberos:

==

Kerberos does not work if they client does not have access to the DC (and under a variety of other conditions) so NTLM will never be deprecated in favor of Kerberos. At least not Kerberos in it's current form. I suspect Microsoft will eventually add some extension of Kerberos that does not have these restrictions. But if they don't have that on the drawing board yet it will be many years before they can shelve NTLM.

Note that NTLM is actually better than Kerberos in many ways. Kerberos is very fickle. Kerberos clients must have direct access to DCs, DNS has to be exactly right for clients and servers, time has to be synchronized to within usually 5 minutes on the client, server and DC, if new Kerberos keys are distributed tickets can become stale and need to be purged. IOPLEX's first product was actually a Kerberos module for PHP. When I did Jespa I conscientiously decided to do NTLM instead because Kerberos is so fickle. I think that is one of the reasons why Jespa is so popular. It's easy to setup and once it is, it just works.

==

[Ellen Feaheny [AppFusions]]

Microsoft does not even recommend NTLM technology any more..

http://en.wikipedia.org/wiki/NTLM

Seems a bit short-sighted to go down this path with impact to lots of users, imho.

[Joe Clark]

I agree with Ed. Kerberos is undoubtedly a superior authentication mechanism to NTLM, but it does come with a lot of baggage that makes it unsuitable for use in all situations where NTLM could be used.