Java 6 HTTPURLConnection and Project Server NTLM Authentication from RHEL5.5

Question

Currently at a loss for authenticating with a Microsoft Project Server 2007 instance running on IIS with Integrated Windows Authentication enabled from a Java 1.6(u19) client running on linux, RHEL 5.5.

Note: The client works on my Windows workstation.

I initially was trying to implement a JAX-WS call and found that I could not retrieve the WSDL due to authentication errors, specifically a 401.2, followed by a 500. So I simplified it to a Java class that:

1. Creates an Authenticator and sets it as the default with a user name/password in AD that has permissions to the project server site
2. Create a java.net.URL object
3. Create a java.net.HttpURLConnection and invoke getInputStream
4. It is at this point where a failure occurs.

With HttpURLConnection debugging turned on I can see:

1. the initial authentication failure (401.2) returned from the server with "negotiate" and "NTLM" included in the response.
2. the client creating an NTLM token and sending it back to the server
3. the server returning with a 500 status code

On the Windows server in the logs, I can see that there is no user name included in the log file only for my requestion and only a "-" which I believe means "anonymous".

My thought is that Project Server isn't liking the NTLM token that is being passed and choking. Based on the many postings on this, NTLM (v1 & v2) are suppose to be supported within Java 1.6.

Any help would be greatly appreciated...

UPDATE 6/20/12: narrowed the issue down to a local security policy setting for Network security: Minimum session security for NTLM SSP based (including RPC) servers. The setting that causes the Java client to fail is Require NTLMv2 security. The goes against what is claimed for NTLM support with the 1.6 JDK..

Some references:

• Java HTTP Authentication
• Blog showing Java Authenticator Impl

Jacobah

Do you have a source for your claim that NTLMv2 is supported in Java's Authenticator class? The two pages you cite don't talk about versioning and without explicitly saying that they support NTLM2, I'm sort of dubious. – Huertas

I would add more links, but I was limited given my lack of "rep" points. Most seem to think that NTLMv2 is supported, but to your point it isn't specifically stated in the Java documentation. However, the LAN Manager Authentication level is set to "Send NTLMv2 Only/Refuse" and authentication works from the Java client when "NTLMv2 Session Security" is unchecked within the "Minimum Session" security attribute. I believe the "NTLMv2 Session Security" requires additional wrapping in the token that may be impacting authentication.. the session security attribute could really be considered NTLMv3. – Jacobah

I'm actually not sure what "NTLMv2 Session Security" means... technet.microsoft.com/en-us/library/cc776157(v=ws.10) suggests that it means "require NTLMv2", though I'm not sure how that differs from "Send NTLMv2 response only. Refuse LM & NTLM". I might experiment with this a bit -- I haven't looked at NTLM in Java for a while so it might be interesting to know what the state of the art (so to speak) is here. For what it's worth, we ended up writing our own implementation: msdn.microsoft.com/en-us/library/cc236621(v=prot.13).aspx – Huertas

This has a pretty good explanation: Technet Security Watch: NTLM Misundertood .. assuming I've interpreted it correctly. – Jacobah

My reading of that suggests that Authenticators are capable of sending LM-based NTLMv2 messages, but are incapable of sending NTLMv2 Session Security-style messages. Does that seem accurate based on your reading also? – Huertas

That's what it looks like to me also... so it appears that the options are 1. disable that requirement in the security policy, 2. setup kerberos on linux (as that is indeed supported) – Jacobah

For what it's worth, it shouldn't be too hard to set up MIT krb5 w/ Active Directory, and the first time I used it, I wondered why I hadn't set it up years ago. But other libraries may have other support - Apache httpcommons httpclient 4 purports to support NTLMv2, but again, it's been a few years since I looked into this. (HttpClient 3 certainly does not support NTLMv2.) – Huertas

If it were an open environment we were talking about then, you're right, it shouldn't be to hard :-) ... But it's a complex IT landscape and I don't have any control over the parts. I'm also not freely able to pull in other third party toolkits and was focusing on JAX-WS (bundled with the JDK 6). Need to do some additional checks before I close the loop on this. – Jacobah

So, at this point, I have everything working as it should with the NTLMv2 Session Security attribute disabled. I'm fairly confident that the statement, JAX-WS 2.1.x or all 2.1's that ship with JDK6 do not support NTLMv2 Session Security. – Jacobah

Hi @Jacobah are you solved it? I'm developing a new service to do NTLM authentication nafiux.com/wasp if I can help you please let me know – Agile

Answer 1

A while back when i had this problem, i ended up using a scheme created by somebody else.

http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html

Worked for me when i had to get image files from and iis server with ntlm. Snippet using the code above..

AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.xyz.JCIFS_NTLMScheme.class);
            HttpClient client = new HttpClient();
            client.getState().setCredentials(AuthScope.ANY, new NTCredentials(userName, password, "", strDomain));
            GetMethod get = new GetMethod(strImageFile);
            get.setDoAuthentication(true);
            client.executeMethod(get);

Hygrometer

Thanks for the response. This looks like it has potential, however, it does require an additional library outside of Java 6; which is what I was trying to work within. The blog also references relaxing the session security attribute to ensure the solution works, which would not work for my scenario. If I get some time to test I will post back. I would vote this up, but I don't have enough rep points :( – Jacobah