I have two applications: one is WebAPI REST Service written on .NET 4.5, and another one is its client application written on .NET Core 2. There's a windows authentication enabled on the service side. Client one makes simple GET call using HttpClient with HttpClientHandler loaded with credentials from configuration, it is some service account. Very basic stuff that can easily be googled in tons of examples, there's nothing fancy there at all.
When this call is performed from my local dev laptop to DEV server then everything works as expected: user provided in the client's configuration gets authenticated successfully on the service and is able to perform whatever operations he is allowed to perform.
It also works fine if I perform this call from the browser (Chrome) - it asks me for credentials and then returns result that perfectly correlates with whatever credentials I put there. It works this way with both remote and local services.
However, if I run the service locally on my laptop (local IIS Server, not an Express one) and call is performed using localhost address then I observe strange behavior: windows authentication seems to work as well, but the user that service authenticates is not the one from client's configuration. Instead, it is my AD account with which I have logged on interactively in windows (btw, it's win 10 ent x64).
Of course, I've verified five times every single config setting and runtime value in my applications, all settings on local and dev server's IIS, on web application and IIS Server level and app pools used for apps. Everything I see looks good - except it behaves differently when on localhost. Also, I googled every question that I could imagine but still can't seem to find an explanation to this behavior.
So, why HttpClient uses my account on the localhost instead of explicitly provided credentials? What am I missing here?
Related
I have an UWP application one client cannot retreive data from the API. She had the application installed and working, but after an update this single client cannot access data from API, none of the API calls succeeds, all fails with error: A connection with the server could not be established.
We have checked the users internet-access and that the user has access to the API from that machine, we have tried Postman so the machine can access the API. But when the application tries to access API it does not reach the API.
I have checked the firewall and the app is allowed there on all three profiles. We have capabilities in the manifest for both internet and privateNetworkClientServer. (it works on all other machines, but stopped working after an update, not even older versions works from that machine any more).
The log files does not say anything either.
Where can I look for stuff that might block UWP traffic?
edit
We added the internetClientServer capability and then it worked.
I have an network deployed forms desktop application (clickonce) which connects to an WCF service.
On most machines it works well but there are a few machines on which I get this error:
Client is unable to finish the security negotiation within the
configured timeout (00:00:09.9377020). The current negotiation leg is
1 (00:00:09.9065530).
When I reset InternetExplorer (Settings->InternetSettings->Advanced->Reset), then this error doesn't appear any more and the application works well, so it's no timeout problem at all. (Applications are started over the InternetExplorer via link)
I think, that there is something stuck on AssemblyCache and that's why Windows can't provide credentials for the service.
I don't use certificates for the connection, and remember this phenomenon only appears on 10 out of 150 machines but the reset workaround is not acceptable over the time.
In some cases the clickonce application didn't even start.
What happens in Windows when starting an ClickOnce app?
Do you know why a reset helps, that the Client can provide credentials?
I have a Web API using OWIN for OAuth, running in Katana/TopShelf.
When I install the Web API as a Windows Service, everything responds correctly, except a POST via resource owner flow (grant_type=password, username=x, password=y) returns 400 Bad Request (invalid_grant).
The exact same Web API, running in the same folder, except this time running in Command Line mode, using the exact same request from the same remote address, is successful.
The only delta is whether I run the .exe file directly in Console mode or I install and start it as a Windows Service.
I have to think this is a conflict at the network level but Windows Service is just acting as a thin host around the same HttpListener based host.
Whenever we see an issue like this with Topshelf it is almost always permission related. There's some resource that you have rights to but the service user doesn't. Are there resources on disk the service accesses or something similar?
I'm using a web service which works fine when I run it on my machine in an ASP.NET application using the default IIS Express VS 2010 comes with. However, when I move it to our server with IIS I get the error:
Error: There was no endpoint listening at 'web service name here' that could accept the message. This is often caused by an incorrect address or SOAP action.
'web service name here' is just a placeholder I put for this post. It has the right web service name.
So I pulled out the small login code that this is failing on into a console application and ran that from the IIS server and it worked! So I have to assume this is some kind of permissions issue with the IIS server on how it's running my web service code? In my ASP.NET program I have a separate DLL that handles the web service. The ASP.NET application fires off a separate thread that uses the DLL I made that uses the web service. Is it something to do with the separate thread permissions maybe? Any ideas?
Your first step when faced with this sort of issue is to search your config files for "web service name here" (or if this isn't actually the message you're getting the address given in the message). My suspicion is somewhere you'll have a WCF reference set up which needs a proper IP address.
Once you've got the address (assuming it looks valid) you need to check you can access it from the machine which is having the difficulties - it may be a firewall issue.
Now that you've established that your console application is connecting correctly from the same machine the next step is to check that both your IIS App Pool and Console application are running under the same user account/permissions. It may be that one identity has permission to access the network/internet and the other one doesn't.
I have a .net/C# application when launched on a test server running VMWARE / Windows Server 2008, receives a USERPROFILE Environment Variable pointing to C:\windows\system32\config\systemprofile, but other applications seemingly built in a similar fashion inhert the correct value of C:\Users\{username}.
A slight twist - the application receives the correct value when run locally on my development machine. So I'm thinking this is a profile/registry issue with some combination of setting in my app.
The issues is manifested when you attempt to open an OpenFileDialog or similar. You get the exception "Location is not available: C:\Windows\system32\config\systemprofile\Desktop refers to a location that is unavailable..."
Any ideas?
UPDATE: The application is WPF running web services against IIS via WCF. Locally in development I am using IISExpress. I've found that after touching the WCF services in the client, the application inherits the APPDATA and USERPROFILE of the IIS AppPool the services are running under. If I adjust the AppPool values to use my user account instead of ApplicationPoolDefault and set LoadUserProfile = true - things work. Obviously this is a bad thing. As an alternative, I cache off the environment variables when the WPF app runs, and after it initially connects to WCF, I reset the variables. This appears to get around the issue but I'd like to solve it a better way but I have no idea what is influencing this behavior in WCF and my IIS Services.
It might have to deal with what account the web app is running under in IIS. You can change it from the default "Network Service" account to an actual user account.