I have a WCF service using the basicHTTP binding. The service will be targeted to be deployed in production in a DMZ environment on a Windows Server 2008 64 bit running IIS 7.0 and is not in an Active Directory domain.

The service will be accessed by a business partner over the Internet with SSL protection. Originally, I had built the service to use x.509 Message authentication with wsHTTPBinding and after a lot of problems I punted and decided to back up and use basicHTTP with UserName authentication.

Result: same exact, obscure error message as I received with certificate mode.

The service works perfectly inside our domain with the exact same authentication but as soon as I move it to the DMZ I get an error reading: "An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail".

The inner exception message is: "An error occurred when verifying security for the message."

The services' web config with binding configuration is as follows:

  <services>
  <service behaviorConfiguration="HSSanoviaFacade.Service1Behavior" name="HSSanoviaFacade.HSSanoviaFacade">
    <endpoint address="" binding="basicHttpBinding" contract="HSSanoviaFacade.IHSSanoviaFacade" bindingConfiguration="basicHttp">
      <identity>
        <dns value="localhost" />
      </identity>
    </endpoint>
    <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
    <host>
      <baseAddresses>
        <add baseAddress="https://FULLY QUALIFIED HOST NAME CHANGED TO PROTECT/>
      </baseAddresses>
    </host>
  </service>
</services>
<bindings>
  <basicHttpBinding>
    <binding name="basicHttp">
      <security mode="TransportWithMessageCredential">
	<message clientCredentialType="UserName" />
	</security>
     </binding>
  </basicHttpBinding>
</bindings>
<behaviors>
  <serviceBehaviors>
    <behavior name="HSSanoviaFacade.Service1Behavior">
     <serviceMetadata httpsGetEnabled="True" />
      <serviceDebug includeExceptionDetailInFaults="True" />
    </behavior>
  </serviceBehaviors>
</behaviors>

The test client's configuration that gets the error:

    <bindings>
        <basicHttpBinding>
            <binding name="BasicHttpBinding_IHSSanoviaFacade" closeTimeout="00:01:00"
                openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                useDefaultWebProxy="true">
                <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
                    maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                <security mode="TransportWithMessageCredential">
                    <transport clientCredentialType="None" proxyCredentialType="None"
                        realm="" />
                    <message clientCredentialType="UserName" algorithmSuite="Default" />
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
     <client>
        <endpoint address="https://HOST NAME CHANGED TO PROTECT"
            binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IHSSanoviaFacade"
            contract="MembersService.IHSSanoviaFacade" name="BasicHttpBinding_IHSSanoviaFacade" />
    </client>

As mentioned earlier, the service works perfectly on the domain and the production IIS box is not on a domain. I have been tweaking and pulling my hair out for 2 weeks now and nothing seems to work. If anyone can help I would appreciate it. Even a recommendation for a work around for authentication. I'd rather not use a custom authentication scheme but use built-in SOAP capabilities.

The credentials pass in thru the proxy i.e. proxy.ClientCredentials.UserName.UserName and proxy.ClientCredentials.UserName.Password are valid accounts on both the internal domain in the test environment and as a machine account on the DMZ IIS box.