question

L4rp avatar image
0 Votes"
L4rp asked L4rp edited

Specific IIS user not working with TLS 1.2

I have already posted this question on Stackoverflow, but nobody that could help me, so I'm hoping for better luck ath the Microsoft Q&A site.

What is the case?

We have run into a problem with IIS, TLS 1.2 and domain users. I searched this 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.

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...

I did 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.

windows-serverwindows-server-iis
· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Hi @PeetersLarryRotterdam-8420 ,

Have you set any identity or authority judgments in the code? In theory, the permissions of the identity running the application will not affect the connection to the remote service, and the error message is that the endpoint cannot be found, rather than the server connection failure.

I think you can use Network Monitor to grab net package. Compare with the package when dedicated domain account is admin and non-admin. Or if the identity information and permission information of the app pool are also included in the net package and sent to another server.

0 Votes 0 ·
L4rp avatar image L4rp BruceZhang-MSFT ·

Thanks. We'll give it a look. For now we created a work around by splitting the web app code in two: one part to call the executable with the correct permissions and one part that handles other processes with different permissions. Not what we want, but it relieves some pressure.

0 Votes 0 ·

0 Answers