I have an application that connect to an external web service.
The application works fine but with one client I can't get through their proxy.
Since the proxy is configured on the computer i started with
<binding useDefaultWebProxy="true" ... >
With this I get the error message:
The remote server returned an error: (407) Proxy Authentication Required.
Then I tried to add:
<security mode="Transport">
<transport proxyCredentialType="Windows"
realm="" />
</security>
but the error message did not change
With some googling I found out that the default setting is to not send credentials to the proxy. The following setting is supposed to enable sending credentials:
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>
However, I now get another error message:
Insufficient permissions for setting the configuration section 'defaultProxy'.
Request for the permission of type 'System.Net.WebPermission, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
I don't understand this message. The application is running on the local computer so it should have full trust. Checked with caspol -m -l and it shows
1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
Now I am out of ideas.
I don't know how to add WebPermission to an assmebly running on the local computer and I don't know if this solves the original problem with proxy authentication.
Some other details which I don't know if it matters.
Windows 7 64-bit
webservice uses https (I can reach the service via internet explorer)
user is local admin
Related
The server is in workgroup (not domain). The self-hosted WCF service is configured with Windows security. Binding is netTcpBinding.
<security mode="Transport">
<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
</security>
The WCF client runs on the same server.
A server certificate is used to encrypt traffic (probably it does not matter)
I implemented a simple test program. Everything works fine.
But when I implement it in our product, client cannot login. In event log I see an Audit Failure:
Failure Information:
Failure Reason: An Error occured during Logon
Status: 0xc000006d
Sub Status: 0x0
By googling I located this page for workaround: http://support.microsoft.com/kb/896861
After disable loopback check in registry, the logon succeed.
But I don't want to disable loopback check security in production environment. I need to find out the cause of this problem.
My question is: why my test program works fine but the product, which exposes multiple endpoints, hits the problem with loopback check security? Is there some WCF component/configuration that causes this problem?
More info: For testing I created a simple wcf client against my product. The test client call is authenticated successfully with loopback check enabled. Seems to me the problem is at wcf client side... Any idea?
Found my issue: I used a self-signed certificate with CN="WCF Security". The endpoints on both server and client have "identity" defined as:
<identity>
<dns value="WCF Security" />
</identity>
After changing to
<dns value="localhost" />
or even completely removing "identity", logon now succeeds without disabling Loopback Check Security.
I don't fully understand the relationship between the endpoint identity and certificate CN though.
We have a WCF Data Service which is self-hosted under a Windows service (not using IIS) which we are currently working to secure using SSL and Windows Authentication.
After some time playing around with netsh and server certificates, we now have the service secured with SSL and we have also enabled Windows Authentication on the webHttpBinding in our app.config - however we are now seeing some strange behaviour when attempting to authenticate certain users - some can log in fine, others have their credentials rejected and are prompted with HTTP 400 errors.
After some testing and digging around it would appear that we might be running into this problem, where the authentication header used by Kerberos may be greater than the maximum permitted header length (which I believe is 16k) for certain users - and although there is a documented workaround for IIS, there does not appear to be an equivalent setting we can use for a self-hosted service, or in our app.config - unless I'm missing something? We tried setting the maxReceivedMessageSize and maxBufferSize fields to their maximum values to see if that would make any difference, but apparently not.
Binding config:
<webHttpBinding>
<binding name="DataServicesBinding"
maxReceivedMessageSize="2147483647"
maxBufferSize="2147483647">
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</webHttpBinding>
We've managed to work around this issue temporarily by setting the clientCredentialType in our binding to use Ntlm instead, but we'd like to get Kerberos working if possible for obvious reasons.
So, as it turns out, this was caused by our service not being configured with a SPN (Service Principal Name). This can be done using the setspn tool with Windows Server. (See this MSDN article for more information.)
Once the SPN was applied, Kerberos authentication started to work as expected.
Use wireshark to see what the client sends. Make sure that this input is correct and then come back.
I've got a WCF service that's running on IIS 6, with integrated authentication and impersonation using NTLM.
Relevant portions of Web.Config
<system.web>
<identity impersonate="true"/>
<customErrors mode="Off"></customErrors>
</system.web>
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
...
</system.web>
...
<wsHttpBinding>
<binding name="wsHttpEndpointBinding">
<security mode="Transport">
<transport clientCredentialType="Ntlm" />
</security>
</binding>
</wsHttpBinding>
I just added the aspNetCompatibility because I want to know who the user is that's logged in (at least as far as IIS is concerned). From the few searches I've done that's how you get the user.
Well, after adding that line and publishing my server I get what's possibly the stupidest error I've seen:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
I thought, "Well obviously they're doing a very case-sensitive comparison." So I searched my entire client solution for Ntlm and replaced all non-variable occurrences with NTLM. No luck.
My primary goal, of course is to get whatever user was authenticated through IIS+NTLM. If I'm going about it the wrong way, I'd be happy to know of an easier/better way. Otherwise, how do I tell my client (or my server) that it's OK to go ahead and authenticate?
One other possibility if you are running across this error is that you are experiencing an issue with the loopback check with NTLM. I have a service which runs self-contained on a non-domain (workgroup) server. WCF is configured using BasicHttpBinding with Transport security mode and Ntlm client credentials. When trying to access the service using https://servername it works great. If I try to access it using the FQDN (https://servername.domain.com) it fails with the same error:
The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'.
If you look inside the Windows security log you will see an Audit Failure with event ID 4625. In this you will see the following failure information:
Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xc000006d
Sub Status: 0x0
To resolve this you need to either add the back connect host names (preferred) or disable the loopback check. This was a security enhancement added for NTLM in Windows Server 2003 SP1 and later to close out an attack vector against the protocol. The fix, however, causes a lot of unclear error messages like this one from WCF and continues to haunt me in many obscure ways to this day.
Start Here . This should resolve your issue
I have got quite a long way with this. I want a WCF service hosted in azure that uses client certificate authentication.
Everything works with the client cert requirement turned off and server cert on; ie
<transport clientCredentialType="None" />
but when I change to
<transport clientCredentialType="Certificate" />
I get
The SSL settings for the service 'SslRequireCert' does not match those of the IIS 'None'.
This seems to suggest that I need to change my IIS configuration. But I am running inside azure emulator, not IIS.
I tried adding
<system.webServer>
<security>
<access sslFlags="ssl">
</security>
</system.webServer>
but the web server did not like that at all; says this is a locked configuration option
All help gratefully received
answer: unlock the iis config file with appcmd
unlock the iis config file with appcmd
We are currently migrating a WCF service from IIS 6 to IIS 7. The service contains some non-SSL endpoints for internal streaming purposes and some exposed endpoints secured with SSL.
The public, secure endpoints are implemented using wsHttpBinding and security mode="TransportWithMessageCredential". The binding reads as follows:
<wsHttpBinding>
<binding name="CustomSecurityBinding">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
</binding>
</wsHttpBinding>
The credentials are authenticated against a custom user repository for validation.
After deploying the service to IIS 7 (64bit Win2k8), all services (basicHttpBindings) respond correctly, expect for the wsHttpBindings. If triggered using https, we always get a HTTP 400 status code (Bad Request).
After enabling tracing in IIS, we could kinda narrow down the problem, although the message from the trace did not really help:
MODULE_SET_RESPONSE_ERROR_STATUS Warning
ModuleName="ManagedPipelineHandler", Notification="EXECUTE_REQUEST_HANDLER",
HttpStatus="400", HttpReason="Bad Request", HttpSubStatus="0", ErrorCode="Der
Vorgang wurde erfolgreich beendet. (0x0)", ConfigExceptionInfo=""
Steps done so far:
re-installed WCF extensions in IIS 7 (ServiceModelReg.exe -r -y)
enabled https protocol for host, added self-signed certificate to host
played around with dns/identity setting in wcf configuration
added a base address to wcf service config
After 2 hours of googling and trying to make this work, i ask you as a last resort of hope: Does anybody know this strange behaviour of IIS 7?
Have you verified that the SSL binding is configured in applicationHost.config (%windir%\system32\inetsrv\config\schema\IIS_Schema.xml) and that the HTTP.sys store contains a valid certificate has and store name for the binding? Secondly, the true error could be masked by the 400 error, have you tried altering your wsHttpBinding in configuration to increase the maxBufferPoolSize and maxReceivedMessageSize to some extremely high values and see if this continues?