I am installing spnego on a java app server that will authenticate users against Active Directory. I've followed all of the directions closely, and the AD Preauth account has the java app server FQDN in the servicePrincipalName attribute. We already have another java app server with spnego installed that works correctly (I did not do that install and they are no longer here).
I've developed a simple java EE 6 web app to test that spnego is working correctly (jsp page with request.getRemoteUser() ). I correctly get my username response when I run this app on the existing server. When I run it on the new server I'm setting up, I get the following error:
java.lang.UnsupportedOperationException: NTLM specified. Downgraded to Basic Auth (and/or SSL) but downgrade not supported.
Using Fiddler to inspect the sessions, The Authorization: Negotiate token request to the correctly working server is a huge string (the Kerberos token I believe?). The Authorization: Negotiate token request to the non-working server is only 56 characters long (so, NTLM token?). When the server receives that NTLM token, I believe that's when the error is thrown.
I've inspected the responses from the earlier negotiation sessions, but can't find where the server is asking for Kerberos vs. NTLM tokens. How does the browser determine what do send?
Additional details: Java App Server machine: Windows 2008 R2, Java 1.7, Glassfish 3.1.2.2
Client Machine: Windows 7 Enterprise, IE8 on a standard corporate windows domain
Thanks.
The servicePrincipalName isn't just the FQDN; it needs to include the service as well. Like: HTTP/MYSERVER.MYDOMAIN.COM.
The address you're visiting in your web browser must match that FQDN. In fact, you can add any IP in your OS HOSTS file to match this FQDN and it should work OK (even if the IP is 127.0.0.1 and you want to test SPNEGO-Kerberos locally)
From the command-prompt of the browser OS, run: klist get HTTP/MYSERVER.MYDOMAIN.COM, and verify you get a ticket. My guess is that this will fail.
Assuming the third point fails, then you have a larger problem with Kerberos configuration (not your browser/webserver), either on your client OS or your KDC.
Related
I have an ASP.NET application hosted on IIS version 10.0 on Windows Server 2019 (Amazon EC2).
In this application i turned on the SSL. So, my client makes a GET request to the server and if the user has any Digital Certificate installed on the machine the browser prompt a certificate select window.
When the user chooses a certificate, the request goes to the backend where we validate the certificate. The problem is in some cases there is no response from the server, it refuses the request, the request appear as (failed) in chrome dev tools and our code dont event get to log the error. In this cases we already analised the clients certificates and there is nothing wrong with them.
What could be happening?
We are getting following error in Microsoft EDGE in our Dev environment when we run our ASP.NET Application Hosted in IIS 8 in Windows 2012 R2 Server.
Error:
XMLHttpRequest: Network Error 0x800c0019, Security certificate required to access this resource is invalid.
Following are more details about implementations and environments.
Our application runs on 2 different secured ports (HTTPS). In IIS both apps are hosting as different Web Applications and using same certificate. The certificate is generated using OpenSSL SHA2 encryption and it has been added in Secured Certificate Store.
From `Microsoft EDGE when we first load our application, it issues certificate warning message, and we are allowing to proceed. Once page is loaded, on a button click we are calling an API using AJAX call and that is hosted on different port.
In EDGE it is not allowing to proceed that API and giving above mentioned error.
In Chrome and IE 11 also, we are getting same warning message but from there it is allowing to execute next API.
Any help would be appreciated to fix the issue.
If you know your certificate is valid, a possible reason this might happen is if you have a tool running in the background somewhere that hijacks the SSL connections through a proxy, such as Fiddler.
Since such a tool is effectively using a man-in-the-middle attack to report the requests, the warnings are "normal". It's pretty easy to forget them running, too.
I have an asp.net web app deployed on IIS7. I call the webapp AOps and When I try accessing the web app over https it just crashes saying "Security sertificate required to access this resource is invalid" (first image).
When I try over http the download works fine.
When I access the default IIS app over both http and https it works fine - except that it complains that the address is mismatched.
I have added a .pfx certificate in the certificate store with the same host name as my host, so the certificate should be fine. Any idea where to start reviewing my configuration?
I am used to apache and tomcat but IIS is a different animal. I looked in the IIS log but it's pretty much a black box. Any help would be greatly appreciated.
The certificate error is generated by your browser not the server. There are 3 things the browser cares about.
The name on the certificate needs to match the url you are using. So in your case, the browser wants a certificate issued to "localhost"
The certificate has to be issued by a trusted certificate authority (not self-signed)
The certificate cannot be expired
To solve 1, use a host entry in /etc/hosts. To solve 2, you need to add the certificate to trusted CA store on your local machine. And 3 is pretty obvious.
Blockquote
I'm trying to test an already deployed web service through SoapUI. The service URL is https://hostname:82/Service.asmx. I modified the test Endpoint to reflect this. Web requests go through a proxy that uses Windows Authentication.
First I attempted to run the test directly but without success. All I got was an error:
401 - Unauthorized: Access is denied due to invalid credentials
Next, I entered proxy details and domain username/password into SoapUI proxy settings. This creates another error:
status# HTTP/1.1 502 Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. Forefront TMG is not configured to allow
SSL requests from this port. Most Web browsers use port 443 for SSL requests. )
I wasn't really paying attention to this until now so I ignored the error and went on to install Burp Suite hoping that this would help with Windows Authentication. I got the Internet working through Burp Suite but soapUI still doesn't do anything and I can't run any tests. This time the error is a bit different:
XML Parsing Error: syntax error Location:
https://hostname:82/Service.asmx Line Number 1, Column 1:Burp proxy
error: failed to connect to IP.
What am I doing wrong? :)
Figured it out in the end. I configured Burp proxy the wrong way. Instead of redirecting to my WS server, I was redirecting to our internet proxy which of course didn't know what to do.
I have a WCF service which is being called from my web application.
The WCF service call is made on SSL port 443.
When my application makes the call, i recieve the following error message in my log file:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'Negotiate,NTLM'
I checked the iis authentication headers on my machine(IIs 5.1) and the machine where the WCF service is deployed(IIS 6.0) using the cscript command:
For iis 5.1
adsutil set w3svc/1/ntauthenticationproviders "Negotiate,NTLM"
Simlilarly, the header has been set on server machine IIS 6.0 using the command:
adsutil set w3svc/1/root/ntauthenticationproviders "Negotiate,NTLM"
I have repeatedly checked the headers and they have the same value of "Negotiate,NTLM" at both ends, yet my service call is failing.
Kindly help.
With NTLM authentication, the user executing on the calling server must be verifiable within the domain within the headers. This would mean that your IIS 5.1 machine would have to have its IIS instance (application pool) running under a domain viable user. Since the application pool is almost universally run by either Local System, Network Service, or AppPoolService (or similar system account) nome of which are domain available, you will need to configure the IIS instance that is performing the call to be run by a service account with appropriate permissions in the domain.