locked
WS-Discovery specifying credentials question RRS feed

  • Question

  • Hi Folks,

    I have the scenario where I have a SQLCLR udf that is calling an asmx web service (proxy) hosted in IIS 7.5 using windows auth.  The proxy web service performs some work and then needs to call a managed windows service (net.tcp, .net 4.0) using a different set of credentials (a service account) and discards the original user credentials so I can avoid a double hop scenario. 

    The managed windows service performs some additional work including a call to another database server which is fine.

    Both the proxy in IIS and the Managed windows service run under a service account (rather than a user account or built-in accounts). I only need to pass credentials one level so can avoid chaining credentials across applications.

    The issue that I am getting is that one in every five calls to the from the SQL CLR user defined function is returning an error:  A call to SSPI failed ---> The target principal name is incorrect.

    The error is not happening consistently and is occurring within the proxy (at the call to the managed windows service) - if I debug the service and step through slowly it is more likely to succeed than if I let it run at normal speed.

    As I am using WS-Discovery I am pulling back the Service Endpoints from a FindCriteria/FindResoponse and then creating a NetTCPBinding with portsharing enabled, SecurityMode.Transport and TcpClientCredentialType.Windows.  I am then creating a new ChannelFacotry and passing in the EndPointAddress.

    In theory one would assume that the credentials being used are that of the currently logged in user (which should be the service account the managed windows service is running under).  However, I am at a loss on how to check that and if required correctly specify a credential to use?

    Just wondering if anyone has any pointers on how to get a resolution on this?

    Regards

    Andy

    Monday, September 23, 2013 9:17 PM

Answers

  • As an update I am investigating a solution based on specifying an incorrect SPN causing the service to fall back to NTLM which it does not appear to do automatically.

    In my client, I have set the ChannelFactory to AllowNTLM = true, AllowedImpersonationLevel to Idendification.   I then create a new EndPointAddress based on the URI returned from the discovery and a call to EndPointIdentity.CreateSpnIdentity("SomeInvalidValue").

    What appears to happen is that it can't do the Kerberos stuff so falls back to NTLM, which it does not appear to do if no SPN is specified at all.  (Would be good if there was a AllowKerberos=False flag.

    Need to do a little bit more testing but will update if this resolves the issue.


    Tuesday, September 24, 2013 12:14 AM

All replies

  • As an update I am investigating a solution based on specifying an incorrect SPN causing the service to fall back to NTLM which it does not appear to do automatically.

    In my client, I have set the ChannelFactory to AllowNTLM = true, AllowedImpersonationLevel to Idendification.   I then create a new EndPointAddress based on the URI returned from the discovery and a call to EndPointIdentity.CreateSpnIdentity("SomeInvalidValue").

    What appears to happen is that it can't do the Kerberos stuff so falls back to NTLM, which it does not appear to do if no SPN is specified at all.  (Would be good if there was a AllowKerberos=False flag.

    Need to do a little bit more testing but will update if this resolves the issue.


    Tuesday, September 24, 2013 12:14 AM
  • Yes,  it wii be good if there was a AllowKerberos=False flag.

    Your solution resolved my issue.

    Well Done AndyW2007
    • Edited by dns jinung Monday, September 30, 2013 6:53 AM
    Tuesday, September 24, 2013 5:57 AM