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
Related
I have embedded Jetty running on port 7000. Also, I have a keycloak server running on same machine on port 8100.
My all clients access goes via Jetty i.e. localhost:7000. So, I have put keycloak as reverse proxy on Jetty i.e localhost:7000/keycloak/auth will redirect to localhost:8100/auth. It is hitting correctly.
Now, there is KeycloakInstalled client to authenticate the user. I have provided auth-url as http://localhost:7000/keycloak/auth. When I run this client, it correctly authenticate the user, but when retruning the token, it gives out the exception that auth-url (localhost:7000/keycloak/auth) given to it does not match the url from keycloak sever (localhost:8100/auth).
I tried out doing following also:
https://www.keycloak.org/docs/1.9/server_installation_guide/topics/clustering/load-balancer.html
But, I am unable to generate X-Forward headers from Jetty.
Am I doing any basic thing wrong here?
Any pointers here would be very helpful.
Thanks.
I workaround it by mapping http://localhost:7000/auth (not localhost:7000/keycloak/auth) to http://localhost:8100/auth via Jetty reverse proxy. It worked perfectly.
P.S. I also need to add proxy-address-forwarding="true" in keycloak standalone.xml
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 have set up WSO2API manager on EC2 server and using nginx for serving requests.
If I access https://example.com/carbon with my domain ssl, it works fine. and I got the verified indication on browser URL.
But when i access https://example.com:9443/store/forum it gives me SSL error at the top. When I investigate the issue i found "Common name as localhost"
How to solve this issues?
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.
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);