5

I have a load-balanced service that uses Message security:

<wsHttpBinding>
  <binding>
    <security mode="Message">
      <message clientCredentialType="Windows" establishSecurityContext="false" />
    </security>
  </binding>
</wsHttpBinding>

All of my calls to this service open and close their own channel, so there's no benefit to establishing a security context.

I am calling the service with a WSHttpBinding that matches the service config:

ws.Security.Mode = SecurityMode.Message;
ws.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
ws.Security.Message.ClientCredentialType = MessageCredentialType.Windows;
ws.Security.Message.EstablishSecurityContext = false;

This works sometimes, but sometimes I get errors such as

The security context token is expired or is not valid. The message was not processed.

or

The request for security token has invalid or malformed elements.

I finally found that setting EstablishSecurityContext to false doesn't actually prevent security context tokens from being used. Our load balancer doesn't currently use sticky sessions, and I'm trying to avoid going that route.

I did find that I should be able to set NegotiateServiceCredential to false on the client to allow for the load balancer without sticky sessions. My service is already running under an AD account, and I can see it in the WSDL:

<Upn>User@Domain</Upn>

However, when I try to add the service identity to my client

EndpointIDentity.CreateUpnIdentity("User@Domain")

I get the following error:

Authenticating to a service running under a user account which requires Kerberos multilegs, is not supported.

How do I get past this to be able to make a call to my service through the load balancer?

zimdanen
  • 5,508
  • 7
  • 44
  • 89
  • Why are you trying to avoid sticky sessions? That may end up being your only option. Have you even tried it? – R. Richards Jul 01 '17 at 12:44
  • @R.Richards: Mostly direction from my boss, probably because our network team has had issues in the past with maintaining sticky sessions. If it's the only option, then I'll push harder on it. – zimdanen Jul 02 '17 at 14:55
  • Documentation for NegotiateServiceCredential heavily implies that this is possible... – Dan Ling Jul 06 '17 at 21:20

1 Answers1

1

According to the documentation for NegotiateServiceCredential, you must run the service using an SPN identity instead of UPN:

If this property is set to false, and the binding is configured to use Windows as a client credential type, the service account must be associated with a Service Principal Name (SPN). To do this, run the service under the NETWORK SERVICE account, or LOCAL SYSTEM account. Alternatively, use the SetSpn.exe tool to create an SPN for the service account. In either case, the client must use the correct SPN in the <servicePrincipalName> element, or by using the EndpointAddress constructor.

Once you configure the SPN that your service is running under, your WSDL should display SPN instead of UPN, then you'll have to modify your client such that: EndpointIdentity.CreateSpnIdentity("service_spn_name")

Update:

The following command should properly configure the SPN:

setspn -A YourSvc/host.server.com domain\AppPoolAcccountName

  • YourSvc = a name identifying your svc
  • host.server.com = fully qualified hostname of the server your service is hosted on

See docs for setspn

Dan Ling
  • 2,965
  • 2
  • 29
  • 43
  • So this would require me to change the app pool to run under an account tied to the computer and not to our domain, right? And that's the only way to do this other than to set sticky sessions? – zimdanen Jul 07 '17 at 14:01
  • The app pool has to run under a a service account, which is different than a user account - the service account CAN be part of the AD domain. See documentation for the Setspn tool: https://technet.microsoft.com/en-us/library/cc731241(v=ws.11).aspx – Dan Ling Jul 07 '17 at 14:48
  • I looked at that, but I couldn't get it to work. Not sure I understand what a service account is in this context. I tried doing **setspn MachineName -s AppPoolUser** and **setspn MachineName -s Domain\AppPoolUser** but I get `Invalid SPN AppPoolUser`. – zimdanen Jul 07 '17 at 15:05
  • 1
    Sorry, you need to create an actual service account. I suppose this is typically handled by sys admins - but instructions to do so via an active directory powershell script are here: https://technet.microsoft.com/en-us/library/dd391964(v=ws.10).aspx – Dan Ling Jul 07 '17 at 15:49
  • Ah, thanks! I'm tracking info about our accounts down now. It looks like I should be able to [move the accounts into the right OU](https://community.spiceworks.com/topic/1348271-can-i-convert-a-regular-domain-user-account-into-a-service-account) if they're not there now and it should work, right? – zimdanen Jul 07 '17 at 16:17
  • Awarding you the bounty because you've given me a direction and I'm leaving for the weekend. Thanks! – zimdanen Jul 07 '17 at 20:45
  • I was totally mistaken about service accounts being different than user accounts. I added more info about how to use setspn in the answer. – Dan Ling Jul 10 '17 at 14:09
  • Okay, I've done `setspn -a ApplicationName/host.server.com domain\user` and got that it registered the SPN but that I don't have rights to assign the SPN on the account. Before I try to track down someone that has the rights - am I doing this right? Does this apply it to the actual service, or does this just make it available? If available, how do I use it? – zimdanen Jul 11 '17 at 14:51
  • As I understand, you are doing exactly the right thing. Once the account has an SPN associated with it, the WCF service should automatically change identies from UPN to SPN - you can verify that by checking the WSDL url again. Then you should be able to fix the identity in your clietn app and everyting shoudl be good to go, because the SPN does not require negotiation. – Dan Ling Jul 11 '17 at 19:19
  • Looks like our web ops team doesn't have access rights to assign SPN on the account either. What rights would be needed? Are these rights on AD or rights on the machine? – zimdanen Jul 13 '17 at 12:38
  • I'm also trying to get the rights sorted out on my end. I'm hoping the following suggestion will work: https://social.technet.microsoft.com/Forums/windowsserver/en-US/1262a5f8-20da-4df2-8ced-42529ece89fa/setspn-to-add-spn-results-in-error-8344-insufficient-access-rights?forum=winserverDS – Dan Ling Jul 13 '17 at 15:03
  • If I'm reading that link correctly, that's talking about computer accounts (local accounts?) but doesn't have a solution for user accounts (domain accounts?). – zimdanen Jul 14 '17 at 12:13