Tag: SOA

Another tidbit I ran into recently that I hit once long ago, and don’t want to forget it again:

I have a VM who’s name I changed.  Trying to develop a WCF webservice for an SOA initiative, I ran into a completely inexplicable authentication failure when I tried to authenticate with my own local user on the machine.

Turns out the quick & easy fix (identified in this post from MS  http://support.microsoft.com/kb/926642 ) ended up pointing me to the solution of:

 adding

REG_MULTI_SZ key “BackConnectionHostNames” to my registry at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 . 

One alias per line…

I added a couple lines for various aliases that I use for the machine, enabling me to authenticate as {alias}\{userName}, locally, on the machine.

Here’s something I don’t want to forget…  working on a WCF Service…

Using TLS, the address of the wsdl didn’t match what was in the SSL certificate.  (the server certificate had the FQDN “friendly name” (host.domain.com), and I was just getting back the “host” name. 

Naturally, this was causing problems. 

There was lots of guidance about setting the host name using some old vbs script that turned out to be a red-herring for IIS 7, anyway.

The quick & simple solution was to add in the behavior for the service:

    <behaviors>
      <serviceBehaviors>
        <behavior>
          <useRequestHeadersForMetadataAddress />
          <!– To avoid disclosing metadata information,

          set the value below to false and remove the metadata

               endpoint above before deployment –>
          <serviceMetadata httpGetEnabled=“false“ httpsGetEnabled=“true“  />
          <!– To receive exception details in faults for debugging purposes,

          set the value below to true.  Set to false before deployment

          to avoid disclosing exception information –>
          <serviceDebug includeExceptionDetailInFaults=“True“ />
        behavior>
      serviceBehaviors>
    behaviors>
…
  system.serviceModel>
configuration>