soap security negotiation failed

soap security negotiation failed

• AlexJD

  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

  
  
  

• Byron118766

  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

  
  
  

• Peter L

  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

  
  
  

• rusold

  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

  
  

• dalangalma

  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

  
  

• Al Grant

  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

  
  
  

• MatthieuMEZIL

  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).

  
  
  

• Joyce_David

  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

  
  

• Jero

  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

  
  
  

• rkewish

  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.

  
  
  

• ACSM99

  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="smason@redmond.corp.microsoft.com" />
  </identity>
  </endpoint>

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

  Thanks!

  Scott

  
  
  
• soap security negotiation failed