netTcpBinding without Windows credentials?

Question

I've got a machine-control application where I have a single client computer and five server boxes communicating on the machine subnet. There is no domain controller. I would like to use netTcpBinding to allow for reliability and transaction support.

Is is possible to use username / password authentication with this binding, when a domain controller is not present? I would prefer not to use a certificate as I don't want to manage certificates across 900 computers (150 machines) that will not be connected to the office LAN.

Lisk

Answer 1

Yes, of course - but only if you use Message security (rather than transport security). Define your binding configuration like so:

  <netTcpBinding>
    <binding name="UserNameSecurity">
      <security mode="Message">
        <message clientCredentialType="UserName"/>
      </security>
    </binding>
  </netTcpBinding>

and then reference that binding configuration in your endpoints (on server and client):

 <endpoint address="....."
           binding="netTcpBinding"
           bindingConfiguration="UserNameSecurity"
           contract="IMyService" />

Marc

UPDATE:
Ah, yes, on the server-side, you'll need a certificate to authenicate the service to the client calling it, and it's also used to encrypt+sign the messages. That's on the server only - clients need not install anything.

Configuration:

<behaviors>
  <serviceBehavior>
    <behavior name="ServerInternet">
      <serviceCredentials>
        <serviceCertificate
           findValue="MyServiceCertificate"
           storeLocation="LocalMachine"
           storeName="My"
           x509FindType="FindBySubjectName" />
      </serviceCredentials>
    </behavior>
  </serviceBehavior>
</behaviors>
<services>
  <service name="MyServiceInternet"
           behaviorConfiguration="ServerInternet">
     ....
  </service>
</services>

Make sure to install your server's certificate into the "Local Machine" folder on your server, under the "subject name" that you specify in your config.

Era

So, that's what I had originally. But, I get an exception asking for a service certificate: "The service certificate is not provided. Specify a service certificate in ServiceCredentials. " Any ideas? – Lisk

Hmmm. That's what I suspected. Thanks for confirming it. – Lisk

In this approach is there any harm of using a self signed cert in production environment? If it's only used to encrypt messages but not to verify identity. When would you not use a self signed-cert for message encryption? – Kumamoto

@Era -Why should he be required to have a server certificate? Shouldn't this work: myNetTcpBinding.Security.Mode = SecurityMode.TransportWithMessageCredential; myNetTcpBinding.Security.Message.ClientCredentialType = MessageCredentialType.UserName; myNetTcpBinding.Security.Transport.ProtectionLevel = ProtectionLevel.None; – Honeycutt

@Honeycutt you cannot set protection level to "None" in this scenario; it throws an exception. – Euphorbia

Answer 2

There is something you can try first. Set serviceNegotiationCredentials to true:

<message negotiateServiceCredential="true"/>

This will create a secure conversation between your client and your service without a domain controller.

BUT, if there isn't any domain controller, the client doesn't trust your service, so it will fail.

So you should set the expected identity of the service. You can find that in the WSDL of your service. By default, if you are hosted on IIS, it seems to be:

<client>
    <endpoint>
        <identity>
            <servicePrincipalName value="host/NETWORKSERVICE"></servicePrincipalName>
        </identity>
    </endpoint>
</client>

I don't think you'll need it, but maybe you'll have to allow anonymous logon on the service side:

<serviceBehaviors>
    <behavior>
        <serviceCredentials>
            <windowsAuthentication allowAnonymousLogons="true"/>
        </serviceCredentials>
    </behavior>
</serviceBehaviors>

Fennie

Thanks. I think that the negotiateServiceCredential does not exist for the netTcpBinding. I will likely go down the certificate path, since that seems (relatively) straight forward. – Lisk