I have a rest api hosted on [IIS 10 Windows Server 2016] when I call the API from a [Rest Client] using [Basic Authentication] the request fails randomly.
The same request (API call) fails and succeed randomly without changing anything.
Related
I have a two windows servers, a windows server 2016 as a DC and a windows server 2019 as ADFS server. For successful federation service based logon success and failure, I am getting events under Security in Federation Server. But the same logs are not available in DC. Is there any way to get those logs in DC. Is it even possible?
In a dev environment a local IIS and signalR client web app creates a session with a spring boot RSocket server, and message flow is working fine.
After deployment to another server and a fresh IIS install, the signalR client can send messages to the server, creating a session from IIS port 6060 to server configured port, X (instead of 8082).
However, after the spring boot reactor Flux sends messages on port X back to the signalR client the messages are not being received by the client.
It's as if the IIS and signalR can fire and forget a send message to port X but not get a session that the port X can reply on.
Can anyone shed light on what's happening?
With a fresh install of the IIS <-> SignalR <-> RSockets <-> WebFlux messaging stack on another demo server and the same error appeared to happen. Though did not run TCP packet captures to check the send / receive message situation with Wireshark.
First of all per SignalR .Net Core 3.1 Web Application not working on local IIS the IIS WebSockets feature was not switched on.
Then, per SignalR 2.2 returns 404 Not Found on IIS 8.5 the requests to the server returned 404 errors. A / was discovered in a JSON date String in urlAPI was causing call to
using (_myStream = new StreamReader(await client.GetStreamAsync(urlAPI)))
to find another endpoint in the urlAPI that did not exist, producing HTTP 404 errors. So that was due to malformed URL.
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?
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.
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.