none
Calling a web service passes the machine name as user? RRS feed

  • Question

  • Hi, we have two sites using Windows Authentication.  When the consumer or client site calls my site hosting the service, it seems it's passing the client Machine name instead of the logged on user which I thought would occur.  Here the client web.config.   Is there a setting in my services config I need? 

    Let me add, this worked fine from my local machine but when I move this code to our dev server, the dev server seemed to be passing it's machine name. Both my local and the dev box are part of the same domain as where the service is hosted.

    <system.web>
        <compilation  targetFramework="4.0" />
       <authentication mode="Windows" />
       <identity impersonate="false" password="Pa55word" userName="us\iusr_myserviceacct" />
    .... 

    <system.serviceModel>
        <bindings>
          <basicHttpBinding>
            <binding name="BasicHttpBinding_IMyService">
              <security mode="TransportCredentialOnly">
                <transport clientCredentialType="Windows" />
              </security>
            </binding>
          </basicHttpBinding>
        </bindings>
        <client>
          <endpoint address="http://mysite.com/MyService.svc"
            binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyService"
            contract="AtpServiceRef.IMyService" name="BasicHttpBinding_IMyService" />
        </client>
      </system.serviceModel>

     

     


    • Edited by dat1 Monday, March 3, 2014 8:00 PM
    Monday, March 3, 2014 7:42 PM

Answers

  • All ASP.NET applications Web service or non Web service run under the context of the ASP.NET Worker process account, unless the client application and possibly IIS are configured to use another account. Apparently, the client machines are using the ASP.NET Worker process user account from their machines which is being presented to the service possibly.

    Yeah it's going to work on your local machine most likely due the ASP.NET Worker User account on your machine is passing verification, which is not happening from a remote client machine. And also maybe, Windows Authentication is not even being used by IIS on the virtual directory for the hosted Web WCF Web service on the Web server. 

     
    Tuesday, March 4, 2014 3:07 AM
  • Hi,

    I saw that you used the impersonate="false", but when we have set to Windows Authentication and we should make sure our services are primed for impersonation.

    Because you are accessing resources across the network, you need to make sure the impersonation level is set to delegate, not impersonate, unless the resources you're accessing are local. This is set at the client endpoint behaviour level:

     <clientCredentials>
            <windows allowedImpersonationLevel="[Impersonation or Delegate]"/>
     </clientCredentials>

    Best Regards,
    Amy Peng

    Tuesday, March 4, 2014 3:07 AM
    Moderator

All replies

  • All ASP.NET applications Web service or non Web service run under the context of the ASP.NET Worker process account, unless the client application and possibly IIS are configured to use another account. Apparently, the client machines are using the ASP.NET Worker process user account from their machines which is being presented to the service possibly.

    Yeah it's going to work on your local machine most likely due the ASP.NET Worker User account on your machine is passing verification, which is not happening from a remote client machine. And also maybe, Windows Authentication is not even being used by IIS on the virtual directory for the hosted Web WCF Web service on the Web server. 

     
    Tuesday, March 4, 2014 3:07 AM
  • Hi,

    I saw that you used the impersonate="false", but when we have set to Windows Authentication and we should make sure our services are primed for impersonation.

    Because you are accessing resources across the network, you need to make sure the impersonation level is set to delegate, not impersonate, unless the resources you're accessing are local. This is set at the client endpoint behaviour level:

     <clientCredentials>
            <windows allowedImpersonationLevel="[Impersonation or Delegate]"/>
     </clientCredentials>

    Best Regards,
    Amy Peng

    Tuesday, March 4, 2014 3:07 AM
    Moderator
  • I guess I'm still confused.  The service would work if I test it by setting:

    myProxy.ClientCredentials.Windows.ClientCredential = new System.Net.NetworkCredential("dat1", "myPassword", "myDomain"));

    But obviously don't want to be using my hard-coded password that way.

    When I run a script to display the server variables on the site I see that I'm the I'm the logged on user below. 

    AUTH_USER US\dat1
    LOGON_USER US\dat1
    REMOTE_USER US\dat1
    SERVER_NAME DEVSVR01
    HTTP_HOST DEVSVR01:1503

    So I would think I'd be able to pass this same user context or token as below when I call the service as follows since both machines are on our network and using Windows Authentication.

    myProxy.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;

    using (OperationContextScope scope = new OperationContextScope(myProxy.InnerChannel))
    {

    DataSet ds = myProxy.GetData();

    But in the site hosting the service, when I display the the AUTH_USER and it's passing DEVSRV01$ not dat1 and the HttpContext.Current.User.Identity.Name is empty.

    So it's not technically possible passing dat1 as the user of the service?


    Thanks again, Dave.




    • Edited by dat1 Tuesday, March 4, 2014 5:05 PM
    Tuesday, March 4, 2014 2:26 PM
  • Amy,

    Is this set in the server's web.config (where the WCF is hosted) but in the client section of the web.config.

    What does delegate do exactly vs impersonation?  I'm struggling with the config side of WCF...

    Thanks, Dave.

    Wednesday, March 5, 2014 3:01 AM
  • Hi,

    >>Is this set in the server's web.config (where the WCF is hosted) but in the client section of the web.config.

    We should set it in the client side as following:

     <client>
          <endpoint...............
              behaviorConfiguration="DelegateBehavior">
          </endpoint>
        </client>
        <behaviors>
          <endpointBehaviors>
            <behavior name="DelegateBehavior">
              <clientCredentials>
                <windows allowedImpersonationLevel="Delegate" />
              </clientCredentials>
            </behavior>
          </endpointBehaviors>
        </behaviors>

    >>What does delegate do exactly vs impersonation?

    Impersonation flows the original caller's identity to back-end resources on the same computer. Delegation flows the original caller's identity to back-end resources on computers other than the computer running the service.

    For more information, please try to refer to:
    #Impersonation/Delegation:
    http://msdn.microsoft.com/en-us/library/ff647248.aspx .

    Best Regards,
    Amy Peng



    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, March 5, 2014 3:34 AM
    Moderator
  • Amy, 

    Any other suggestions?  The remote service thinks the user is DEVSRV01$ as the AUTH_USER not my domain\username when I call it.

    Do I have to do anything else? Such as use OperationBehavior attribute on my operation itself?

    [OperationBehavior(Impersonation = ImpersonationOption.NotAllowed)]


    Thursday, March 6, 2014 4:30 PM
  • Hi,

    Yes, please try to use the following:

    [OperationBehavior(Impersonation = ImpersonationOption.Required)]

    And I see that HttpContext.Current.User.Identity.Name is empty, then if you want to the get HttpContext.Current.User.Identity.Name value, please try to check that you have added the following in the config file:

    <system.ServiceModel>
      <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
    </system.ServiceModel>
    And the following in code:
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
    public class Service : IService
    {
    }
    Best Regards,
    Amy Peng

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Tuesday, March 11, 2014 8:48 AM
    Moderator