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:
Creates an Authenticator and sets it as the default with a user name/password in AD that has permissions to the project server site
Create a java.net.URL object
Create a java.net.HttpURLConnection and invoke getInputStream
It is at this point where a failure occurs.
With HttpURLConnection debugging turned on I can see:
the initial authentication failure (401.2) returned from the server with "negotiate" and "NTLM" included in the response.
the client creating an NTLM token and sending it back to the server
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
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);
Related
I developing a web application with kerberos (v1.0.1) authentication.
My aim is to provide a login through the windows authentication Active Directory (Windows Server 2008 R2).
The problem is that the browser send to the Back End NTLM ticket instead of Kerberos ticket.
I used wireshak to check the communication work flow:
I make a rest call on the back end
application server response to me 401
browser call the kerberos service on the active directory and received the TGS_REP
now I expected that browser calls my rest service with the Kerberos token, but I received the NTLM token instead
My back end service, developed in JAVA, throw the following exception:
GSSException: Defective token detected
EDIT 1:
The first problem is that we used the IP to generate the SPN and the KEYTAB. So, we created the keytab in this way:
ktpass /out c:\keytab\myuser.keytab /mapuser myuser#company.com /princ HTTP/myuser.company.com#WELLD.CH /pass mypassword /ptype KRB5_NT_PRINCIPAL /crypto All
Then we added our BE server on the DNS
<ip_server> myuser.company.com
At the moment we can login with kerberos, and the BE (spring boot) successfully validate the kerberos' token, but we can't download the user information with KerberosLdapContextSource, so we adopt a workaround and used the DefaultSpringSecurityContextSource Bean.
Someone have any idea or references to rely on?
Thanks
I am new to Windows authentication and am facing a weird issue.
I have setup an application with SPNEGO filter library for Java.
All settings as per the documentations have been set.
Now when i open the URL of my application from another machine in the same domain, using any browser, i get a negotiation header as
TlRMTVNTUAABAAAAl4II...
This means that it is an NTLM negotiation request.
if i start fiddler and then try to run the same request for testing, i am getting a kerberos authentication request.
YIIGgwYGKwYBBQUCoIIGdzCCBnOgMDAuBg...
This means that when I am calling using fiddler, the browser is assuming that the system is on same network.
I am unable to figure out why this is happening..??
I need the kerberos ticket even in normal execution.
Server: JBoss 4.3.2 GA
anybody has any idea...??
thanks in advance
Folks,
We have a Java Applet communicating with the server through a BigIp Load-Balancer. The Java Applet is using an HttpURLConnection and the communication protocol is https.
The Load-Balancer implements a cookie based persistence policy to maintain session affinity.
This all works fine when the Java Applet using Java 1.5, 1.6 and early versions of Java 1.7.
Somewhere around Java 1.7.0_21 something went wrong with the Java Applet and now when we open HttpURLConnection for the 2nd time and on, the load balancer does not pass the request to the server but instead replies with the same response sent for the 1st request from the Applet as if thinking the request is for static content that can be cached.
Any ideas what has changed in recent versions of Java with respect to HttpURLConnection ?
You may want to check that you are properly negotiating an SSL connection. You can do this two ways: create an iRule to log to /var/log/ltm:
when HTTP_REQUEST {
log local0. “Requested hostname: [HTTP::host] from IP: [IP::local_addr]”
}
Turn on SSL debug logging:
tmsh modify /sys db log.ssl.level value Debug
If you are failing to negotiate SSL, you will not see anything logged from the iRule, but should have an answer as to why you are failing to handshake. Most often you need to adjust your cipher string.
I'm trying to implement SSO on an intranet application we are developing. I am using SPNEGO for this. Now I'm having some trouble configuring the SSO and hope someone here is able to help me.
The setup is like this:
Linux server with tomcat to serve the intranet application
Windows Server 2008 as domain controller (Active Directory)
Windows 7 client with IE9 and Firefox
When I open the intranet application I see a GET request going from the client to the tomcat server. The first response of the tomcat server and the SpnegoFilter is a 401 unauthorized which is right, cause the client needs to be authenticated.
806 6.117724 192.168.65.50 192.168.65.50 HTTP 284 HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate\r\n
The response of the client then is a GET request with a flag NTLMSSP_NEGOTIATE. Here it breaks. I don't expect a NTLM response, but a kerberos/spnego response. Somehow I just can't figure out how to send the correct response to the tomcat server.
808 6.123277 192.168.65.50 192.168.65.50 HTTP 637 GET / HTTP/1.1 , NTLMSSP_NEGOTIATE
By default NTLM isn't supported by SPNEGO so I get the following entry in my log:
java.lang.UnsupportedOperationException: NTLM specified. Downgraded to Basic Auth (and/or SSL) but downgrade not supported.
So I'm doing something wrong, but aftert a day fiddling with configurations and policies I just can't figure out what it is.
Hoping for some response.
Kerberos does not work on IPs, use fully qualified domain names.
Have you registered the SPN and is the client domain joined? The WWW-Authenticate: Negotiate will tell the web browser to try kerberos. The browser hands of that request to the OS (SSPI) based on URL in the address bar. There must be a SPN in AD for the URL. As others noted above, using an IP in your URL is more complicated, but can be done. If your client is not domain joined, there is extra config work to get it to contact your AD KDC. Firefox takes extra setup as well. Solve ths with IE, to eliminate that and them come back to FF when the issue is resolved.
I have a java client connecting to a WCF service. This service is configured to run on the host as a separate domain user (i.e. not as Local Service or Network Service). The Service publishes a userPrincipalName in its WSDL.
During the SpNego token exchange I get the following exception in the client
Defective token detected (Mechanism level: AP_REP token id does not match!)
This is the call stack:
at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:450)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:230)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:162)
If I configure the WCF service to run under Local System account the SpNego token exchange works.
Do I need to modify the code for services not running under Local system account?
Update-1
After some debugging by getting a C# client to connect with the WCF service, I found that the C# client is using a modified version of SpNego protocol called MS-SPNG. Does Java 6 support this? When I inspect the token I get an error about unsupported mechanism 1.2.840.113554.1.2.2.3.
These links explains whats happening. MS has a extension for SpNego protocol, which kicks in when we run a WCF service as a user (i.e. not as Local Service etc).
This is the MS specification for the new protocol, and here is the openjdk doc that xplains the workarounds.