I have an Authentication service built on Identity Server 3 and a set of WebAPI services using BearerTokenAuthentication. On startup, each of the WebAPI services makes a call to the Authentication service's .well-known/openid-configuration. That has been working fine until we recently configured the firewall between the WebAPI services and the Authentication service to only allow traffic with the TLS 1.2 protocol. Now the WebAPI services all fail to start and report that they cannot access the Authentication .well-known/openid-configuration because they "Could not create SSL/TLS secure channel".
Update: The problem described is occurring in my Test environment and is eliminated when we modify the firewall to allow TLS 1.0. In my Dev and Staging environments, the firewall is configured to require TLS 1.2 and that configuration is not producing the above symptoms. Something else is different. I just haven't figured out yet what it is.
Based on this latest update, I have a different question. Any suggestions on what to look for in the server/environment that would cause the TLS 1.2 requirement not to work in one environment while working in the other two? I've started to look at the registry settings that control the server's use of SSL and TLS protocols, but haven't found a difference there when comparing a working server to the non-working one.
Final Update: I never did figure out what was different. Someone from the systems group rebuilt the Test server, which was exhibiting the problem, by cloning the Staging server, which was not exhibiting the problem. The rebuilt server handles TLS 1.2 just fine. So it was clearly something in the server, not the code. But that's about all we know.
Related
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
I have on-prem TFS within a small domain that we RDP into. Development machines are in this domain/enclave as well. Prior to the most recent TFS upgrade, we were able to connect Visual Studio to TFS and browse the TFS web UI using HTTP only within the enclave. We could also use HTTPS from outside the enclave (no http) to access the web UI. With the latest upgrade, I have mirrored the IIS authentication, SSL and binding configurations but now pointing a browser or Visual Studio at the HTTP only address always redirects to the HTTPS address and forces the SSL login. This is a problem for us because we use a large enterprise PKI infrastructure (access cards, non-local services, etc) that is very flaky: constantly dropping the Visual Studio connection to TFS and asking for PIN re-entry every 2 - 3 minutes. How can I stop the http address from re-directing to https all the time in our enclave? Is TFS doing this now? or IIS?
Since TFS2017 server changed the Authentication from NTLM to KERBEROS by default. You could use the following command to use NTLM back:
TFSConfig Authentication /provider:NTLM
And please try to create a new DNS, then check the result again.
If you want to remove Https, you should change the "Public URL" to http in TFS administration console, removed the HTTPS bindings from IIS.
If above is not work, try to uninstall and re-install the Application Tire and choose the http only option.
For more details take a look at this similar question: TFS 2018 - remove HTTPS
Got it. Found this article describing the redirect behavior from the URL. Long story short-> In IIS, select the TFS under Sites, then Application Settings, setting name sslOnly was set to true. Changed to false. Now I can access the TFS portal from inside the enclave using http OR https and from outside using https only. This means that VS can also connect to TFS via http only.
What is the reason for two separate but similar servers?
What are the differences?
Can I run both in docker?
Do both support same things, like all authentication types?
Kestrel vs HTTP.sys - I've highlighted the fundamental differences below.
(The words are Microsoft's and I've only edited it for brevity and clarity. See the sources linked at the bottom).
Update:
Kestrel previously always required the use of a reverse proxy with edge deployments (exposed to traffic from the Internet) for security reasons. With Kestrel in ASP.Net Core 2.x this is no longer the case. Take a look at the documentation for more information. Kestrel Web Server Documentation
Weblistener was renamed HTTP.sys in ASP.NET Core 2.0
Sources:
Docs.Microsoft.com Web server implementations in ASP.NET Core
Docs.Microsoft.com HTTP.sys web server implementation in ASP.NET Core
HTTP.sys is windows-only HTTP / Web Server for ASP.NET Core that allows you to expose the server directly to the Internet without needing to use IIS. HTTP.sys is built on top of Http.Sys ( the same mature technology that also powers IIS' HTTP Listener) as is as such very feature rich and provides protection against various attacks.
Kestrel on the other hand, is a cross-platform web server for ASP.NET Core that is designed to be run behind a proxy (for example IIS or Nginx) and should not be deployed directly facing the Internet. Kestrel is relatively new and does not have a full complement of defenses against attacks. It's also not as feature rich as HTTP.sys and comes with timeout limits, size limits and concurrent user limits.
In essence, the choice comes down to your web application's Deployment scenario.
HTTP.sys Use Cases :
Kestrel Use Cases :
Following comparison will help you to choose which one is better
The ASP.NET 5 documentation (created by Microsoft on August 25, 2015) found here lists the chart found in the other answer (see page 107 of the bottom right book pages, but page 111 of the PDF): https://media.readthedocs.org/pdf/aspnet/theming/aspnet.pdf
Kestrel in general has better performance, if you used for one of the following below:
Great option if used in conjunction with a reverse proxy for apps exposed to Internet
Internal apps connecting with other internal apps on a private virtual network (not exposed to Internet)
WebListener is more secure, slower, and has more features. It is used in these cases:
Expose app to the Internet but can't use IIS
Require higher security and exposing server directly to Internet.
Additional features: List item, Windows Authentication, Port sharing, HTTPS with SNI, HTTP/2 over TLS (Windows 10), Direct file transmission, Response caching
I have an ASP.NET webservice which is deployed on Server2008 IIS7. We use two servers, Production and UAT (test server) and this webservice is deployed on both servers, the same compile is on both of them (no code changes, revisions etc, pure copy/paste from one to another).
The only difference between the applications is a connection string in web.config, one points to PROD database, the other UAT.
If I make a call to the test webservice I get an expected response and all is well, but when I do the same thing on the production webservice I promptly get and error
Server was unable to process request. ---> Object reference not set to an instance of an object.
I am suspecting there must be a configuration issue as the webservices are running under their own Pool which is run by a service account/user (local admin on the servers) and they are set to only run through SSL (https:// only) on a special port.
I tired sniffing with Fiddler and got two identical SOAP requests, the only difference being the server name in URL. I can access the WSDL of both webservices from IE browser, I can successfully refresh my web reference in Visual studio (for both prod and uat services).
Does anyone have any hints what should I be looking at, perhaps someone had a similar problem?
This is resolved. As I suspected the error was in production server configuration. When the sys team added a service user into the local Administrators they added it through Active directory groups, which as I am told requires a logoff/logon or a restart.
Server restart was the solution in my case.
I have a nettcp service which I have to host. I have three options -
IIS 7
Windows Service
A console application
I would be grateful if anybody could give some valuable thoughts on which option is better vis-a-vis other one.
Here are some of my observations:
IIS 7:
Pros:
Ready made hosting environment inside IIS
Will work with pretty much any hosting environment
Cons:
HTTP Only
Configuration slightly more complex
WAS:
Pros:
Ready made and familiar process model to that of IIS
No dependency on IIS
All protocols supported
Cons:
Not all shared hosting environments will support non-http protocol bindings or unusual port numbers.
Configuration slightly more complex
Windows Service:
Pros:
Starts when windows starts
You can start/stop the service via the service control manager
All protocols supported
Cons:
Some extra steps to deploy/re-deploy (installutil)
You need some extra boilerplate code to support the service implementation
Not ideal if you can't have access to the server to install (e.g. shared hosting)
Console Application:
Pros:
Fast and simple to deploy for testing purposes
All protocols supported
Cons:
You need to be logged on to start the process
Loss of session or machine shutdown will kill the service
Console/RDP access required