IIS hosted WCF throws exception when running under domain account - wcf

A little bit too verbose explanation of my problem, but here it goes
I have number of WCF services, most of which are self hosted in windows services on custom ports.
For those self hosted I switched identity under which services are running and got the following error
HTTP could not register URL http://+:5731/.
Your process does not have access rights to this namespace
(see http://go.microsoft.com/fwlink/?LinkId=70353 for details). :
at System.ServiceModel.Channels.SharedHttpTransportManager.OnOpen()
In order to solve this under Windows 2003 I used httpcfg to add ACL for that url
URL : http://+:5731/
ACL : D:(A;;GX;;;S-1-5-21-1644697732-2861104425-3354422928-30323)
And after that self hosted ones work just fine
But IIS hosted are not. After I changed Application pool identity it is throwing
ServerTooBusyException: The HTTP service located at
http://127.0.0.1/Service.svc is too busy
I double checked that password entered for Application Pool identity is correct and just in case added permission using httpcfg, which should not be necessarily
URL : http://+:80/
ACL : D:(A;;GX;;;S-1-5-21-1644697732-2861104425-3354422928-30323)
And I'm still getting ServerTooBusyException.
What else should be reconfigured in order to make IIS hosted service to work under specific domain user ?

I was able to solve it adding domain user to local admin group and doint net stop and net start for w3svc, which is extreme. Working to find more appropriate set of permissions for domain user.

Related

Which app pool & authentication to select on IIS when using itfoxtec-identity-saml2 library

I am getting error when using below line from itfoxtec-identity-saml2 library. When i am on localhost and usin iisexpress, it works with proxy server id,password & port i.e. 127.0.0.0 / port. But when i load the application on companies IIS server [no internet], i get below error
return ReadIdPSsoDescriptor(webClient.DownloadString(idPMetadataUrl));
webClient.DownloadString(idPMetadataUrl) is giving below error.
Access Denied (authentication_failed)
Your credentials could not be authenticated: "Credentials are missing.". You will not be permitted access until your credentials can be verified.
Why I need internet on the IIS server? & what proxy settings I should provide in prod release which will go on IIS where there is no internet connection.
When loading the application on the IIS server what application pool I should set to the application [.net core 3.1 web-based application which will be hosted on AWS ec2 windows system] & under IIS authorization which mechanism I should select [windows/anonymous ?]. I am currently using SAML so selected anonymously.
Please guide, thanks in advance !!
You have configured to download the IdP metadata online, therefor your server need access to the place where the IdP metadata is hosted. Alternatively, you can download the metadata manually and place it as a file on the server.

Unexpected 401 error when connecting to a web service (possible kerberos \ double hop error related)

We have a client that connects to a web service (service1.svc) with the URL https:\destination.domain\Service1.svc. This web service connects to a second web service (service2.asmx) with the URL https:\localhost.domain\service2.asmx. Both service are hosted on the same webserver. The DNS on the Domain controller sets destination.domain to point to the IP of webserver and localshost.domain to 127.0.0.1. The application pool account is a global service managed account that is configured to allow delegation and is called webserveraccount. The application pool is configured to use the appPoolIdentity.
We see a 401 autherisation error connecting to the second webservice (service2.asmx). I have also see the a KDC_ERR_BADOPTION which makes me this our SPN configuration is incorrect. What would the correct format for SPN in the above scenario? Or is this not a kerberos related issue?

IIS Client Certificate Mapping Returns 500 When Anonymous Authentication Disabled

I have a WCF client application hitting a WCF web service running under IIS 7.5 on Windows 2008 Server R2. I have a "client" certificate on the client machine, and a "server" certificate on the server machine. I have successfully configured IIS and the client app to use straight "1-way" SSL. However, I am not able to get "2-way" SSL (SSL w/Client Certificate REQUIRED) to work.
I have taken the client certificate, exported as Base-64, formatted the resulting text string, and added that in as an entry under IIS Client Certificate Mapping on the IIS server. I've tied this to a Windows user, and given that user access to the folder where the web service runs from. I have done all of this configuration at the site level under IIS Manager.
The problem shows up when I DISABLE anonymous authentication. If I do this, then IIS gives me a return code of 500 and an accompanying error telling me I must enable anonymous authentication. This is not what I want. If I RE-ENABLE anonymous authentication, then any client using a valid client certificate is able to make the web service call. I want to limit the ability to call the service only to those clients that present a client certificate that I have mapped to the Windows user.
Has anyone else come across this?
Thanks!
Brian

WCF, Clientcredentials, multiple hop, kerberos and windows authentication - how to get working

I have a web app running on Server A that calls a WCF service (K2 Workflow) on Server B that requires impersonation/delegation to run as the calling user. If I run the web app from Server A, the app works great. If I run the app from my local PC in debug, it also works great. If I hit the app from a browser on my PC to Server A, I get the following error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'Ntlm,Negotiate'. System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout).
I use the following code to run the service:
SvcWorklist.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Delegation;
SvcWorklist.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
I feel like I've done everything, here is a list of what I've tried:
Setup a SPN (including port) with by Server A App pool domain user to Server B
(NETBIOS and FQDN)
Set the same domain user as the app pool user on Server A and B
Ensure the app pool user is allowed to delegate in Active directory
Ensure both servers are allowed to delegate in AD
Set authentication to windows and impersonate=true in web.config on Server A
Ensured Thread.CurrentPrincipal.Identity.Name has my user ID
Ensured IIS is set for windows and impersonation
Tried restricting the IIS configuration on server A and B to only Ntlm and/or Negotiate
Any help or ideas are truly appreciated.
For the dude who had the same issue - I figured it out. I had the SPN set on the target service, not the service it's hosting. I also needed to set sharepoint to use negotiate versus ntlm.

Error 407 when calling WCF web service via a Windows-authenticated proxy

I have the following setup:
Server machine running a WCF service exposed via an IIS application that requires Windows authentication.
A proxy server (Squid) requiring Windows authentication.
A client machine running a Windows service which tries to make a connection to the WCF service through the proxy server. The service is set with a domain account credentials.
All machines are on the same domain.
If I drop the proxy from the setup and set just the following properties on the client security binding, all works well:
SecurityMode = TransportCredentialOnly
Transport.ClientCredentialType = Windows
The connection is made successfully and the correct credentials are passed to the server.
If I add the proxy but drop the required Windows authentication on the proxy server, everything works fine too. The only setting I change here on the security binding is:
ProxyAddress = http://myproxyserver:3128
I can see the calls go through the proxy server with the correct credentials.
The problem is that when I set the Windows authentication requirement on the proxy server, the proxy server returns 407 error. When I check the log files, I can see there is no second attempt to respond to the 407 error with the correct credentials. The setting I add is:
Transport.ProxyCredentialType = Windows
Things I tried and didn't work:
Set UseDefaultProxy - since this is a Windows service, it doesn't accept the default proxy.
Manually set Windows Credentials in ClientCredentials.Windows (including domain).
Add default proxy in app.config and machine.config.
Any ideas on what's going on and how to fix it?
Two things that might be the problem. First, and I can not be sure about this as I have not tried using a Windows credential with TransportCredentialOnly, is that transport security tends to be point-to-point. That means that an intermediate service, such as a proxy, would have to authenticate your transport credential itself, as well as reestablish the appropriate credentials for its repeat of your request to the real endpoint. Again, I am not certain how this works with a Windows credential...but given that it is a transport-level security setting, I would be doubtful that it can pass through the proxy without additional setup to ensure the proxy repeats the appropriate credentials. (Keep in mind, doing so effectively nullifies your security at the proxy...which in a controlled setting is not a problem, but can be in a real-world scenario.)
Second, the transport child element of the security element for your binding configuration should have a proxyCredentialType setting. If your proxy is interfering with your security, you may need to authenticate against the proxy itself. The proxyCredentialType setting defines what kind of proxy credential to use to authenticate against the proxy itself. You would then need to supply proxy credentials before you send your message.