soap security negotiation failed

Question

I have a service with no security, atleast i didn't configure any. When I try to call it from another machine it throws an exception saying thta soap security negotiation failed. It works fine when the client is on my development machine but not when it is on other machines. Any ideas?

Steve

Answer 1

All the pre-defined bindings except for basicHttp default to enabling security.  So you you didn't make any changes, you're problably using security.

 

Thanks,

 

Scott

Answer 2

One more thing....

Since it works locally but not remotely, that sounds like you haven't set your UPN or SPN correctly on the proxy.

Is this a self-hosted service?

Thanks!

Scott

Answer 3

By self hosted I assume you mean that I have it hosted in my own app which i do. It works fine when the client is on my dev machine but not on another machine in the domain.

What should the UPN/SPN be set to?

Steve

Answer 4

If you're running your service in a console or winform app (which you are) then you need to set your UserPrincipalName on your client to the username running the server.  If the service is running as either the System or NetworkService account then this is not necessary as it will use the default SPN (host\machine).

The config for this on the client would look something like this:

      <endpoint address="http://localhost:8001/dvdcollection/service"
          binding="wsHttpBinding" bindingConfiguration="MyWSHttpBinding"
          contract="IMyContract" name="MyWSHttpBinding">
        <identity>
          <userPrincipalName value="[e-mail]" />
        </identity>
      </endpoint>

This is not necessary on the local machine as it will use NTLM to authenticate.

Thanks!

Scott

Answer 5

Not to beat this horse anymore but is there going to be some guidance on this? For instance how does this play out with large number of remote clients? Do they all have to know the account that the service is running on? Also is there guidance about hosting choices?

Thanks for your help on this.

Steve

Answer 6

The clients need to know who they're talking to.  If the service is running as the System or NetworkService account on that machine then you don't really need to do anything as the client will use the default SPN (ServicePrincipalName) which would be host\machinename as opposed to the UPN (UserPrincipalName).  When you create your proxy code with svcutil, the UPN (if necessary) will be created inside the config file.

As far as hosting choices are concerned, I would have to say that IIS (or WAS in Vista) would be the host of choice.  IIS is designed for large scale applications and thus it's performance and stability would be considerably better. 

Thanks!

Scott

Answer 7

Hi,

I have a similar issue and I think it maybe related to the UPN and SPN settings.  Any help will be much appreciated.

Basically I am running the UserNamePasswordValidator sample program (except I am using net.tcp), everything works fine if both the client and the server are running on the local machine when the endpoint is specified as 'localhost' (e.g. address="net.tcp://localhost:1234/....).  But if I changed the endpoint address to a real IP address such as 172.16.2.2 on both the client and server config, I got the following exception on the client (even though both client and server are running on my local machine):

Unhandled Exception: System.ServiceModel.Security.MessageSecurityException: Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was '172.16.2.2' but the remote endpoint provided DNS claim 'localhost'. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity 'localhost' as the Identity property of EndpointAddress when creating channel proxy.

I did try to run the client and server on different machines, and I get the same error too.

I did play around with the UPN and SPN settings, but no luck at all.

Thanks again!
W Wong

Answer 8

Hi Scott,

What is the idea behind the client knowing the account that the service is running under? Is this so that the client can authenticate the service for mutual authentication? Is it possible to configure the client to only work against a service that is running under a specific account? What causes svcutil to inject the UPN into the client config? Is it the negotiation setting in the service config? Basically, what is the rationale behind this setting?

Thanks,

Vitaly

Answer 9

Right - it is about mutual authentication. You want to make sure you are connected to the right server before you send sensitive data.

Setting the SPN does exactly have this effect - you will only be able to talk to this server. There are some situations where the authentication is silently downgraded to NTLM (e.g. when no SPN can be found with that name). If you set AllowNtlm to false, you force mutual authentication with the account specified in the SPN.

The proxy constructs the SPN from the URL (which assumes the service is running as a machine account).

 

Answer 10

Dominick,

Appreciate your reply.  So just to put this feature into context, is it meant primarily for the following 2 scenarios:

1. If I know the endpoint URI, then technically speaking, I know which endpoint I want to hit from the client.  However, if there's some proxy in the middle, we need to make sure that it can't redirect to some arbitrary endpoint (implementing same WSDL contract, but a rogue service perhaps) -- correct?
2. Duplex contract -- Are we making sure that a service connecting to the client for a callback is a trusted service? In other words, the client becomes a service to the service, so to speak, thus the same authentication needs to occur.

Thanks,

Vitaly

Answer 11

Hi,

 

1) yes - it is about authenticating the server :) Or you DNS could be poisoned and you talk to another box than you intended. Basically the same idea as SSL...

2) The security protocols negotiate a security context (details depend on binding/mechanism used) - this is typically a symmetric key used for 2-way communication.

 

Answer 12

 i have commented the below line in web.config and it started working fine,, not sure of the security settings though !!!

<identity >

<userPrincipalName value="user......" />

</identity>