Impersonation not working in PopulateWindowsIdentity()

Impersonation not working in PopulateWindowsIdentity()

Old forum URL: forums.lhotka.net/forums/t/12520.aspx

SPeters posted on Friday, March 21, 2014

Hi guys,

I think I have an interesting one.  I have been reading many, many discussions on this topic and altering my code and have found an interesting quirk.  Below are the most useful discussions I've read and taken ideas from.

http://forums.lhotka.net/forums/p/12036/56156.aspx

http://forums.lhotka.net/forums/p/8931/42494.aspx

I have a .NET 4.5, CSLA 4.5.40, Silverlight 5, IIS 7.5 application that has been working terrifically locally but I've been trying to deploy to a webserver.  My AppPool settings have gone through every possible permutation but I have settled with Integrated and Identity: LocalSystem.  If I change the identity it gives similar results as mentioned below but with a different system account.  IIS site authentication only has ASP .NET Impersonation and Windows Authentication Enabled.

Here is the web.config with all the tags that have been identified as required:

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <appSettings>

    <add key="EventLogName" value="GreyDev" />

    <add key="CslaAuthentication" value="Windows"/>

    <add key="CslaWriter" value="Csla.Serialization.Mobile.CslaBinaryWriter, Csla" />

    <add key="CslaReader" value="Csla.Serialization.Mobile.CslaBinaryReader, Csla" />

  </appSettings>

  <connectionStrings>

PRIVATE :)

  </connectionStrings>

  <system.web>

    <compilation debug="true" targetFramework="4.5" />

    <authentication mode="Windows" />

    <identity impersonate="true" />

    <pages controlRenderingCompatibilityVersion="4.0"/>

  </system.web>

  <system.webServer>

    <validation validateIntegratedModeConfiguration="false" />

  </system.webServer>

  <system.serviceModel>

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true" />

    <services>

      <service behaviorConfiguration="WcfPortalBehavior" name="Business.Compression.CompressedHost">

        <endpoint binding="basicHttpBinding" contract="Csla.Server.Hosts.Mobile.IWcfPortal" bindingConfiguration="BasicHttpBinding_IWcfPortal" />

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior name="WcfPortalBehavior">

          <serviceDebug includeExceptionDetailInFaults="true" />

 <serviceAuthorization impersonateCallerForAllOperations="true" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

    <bindings>

      <basicHttpBinding>

        <binding name="BasicHttpBinding_IWcfPortal" 

maxReceivedMessageSize="2147483647"

                   maxBufferPoolSize="2147483647"

                   maxBufferSize="2147483647" >

          <readerQuotas maxBytesPerRead="2147483647"

                          maxArrayLength="2147483647"

                          maxStringContentLength="2147483647"

                          maxNameTableCharCount="2147483647"

                          maxDepth="2147483647" />

          <security mode="TransportCredentialOnly">

            <transport clientCredentialType="Windows" />

          </security>

        </binding>

      </basicHttpBinding>

    </bindings>

  </system.serviceModel>

</configuration>

On to my results.  In my AppIdentity class I call the CSLA method PopulateWindowsIdentity().  Digging into this method I found that the main call to retrieve the impersonated windows user is:  var currentUser = System.Security.Principal.WindowsIdentity.GetCurrent();
No matter what config, IIS or AppPool settings I have changed, the returned WindowsIdentity.Name is always "NT AUTHORITY\SYSTEM" (this varies when changing the AppPool Identity as mentioned before).  It never impersonated the user, in my case 'speters' (my AD name).  I have made a small ASP web app with the same config and IIS settings and in that app, Impersonation works!  In that application, I have found that the web.config setting <identity impersonate="true" /> directly turns off or on the Impersonation with the true/false setting.
After 3 days of trying every setting I could find, reading every article I could find, I decided to call another method in my AppIdentity class, var cslaname = Csla.ApplicationContext.User.Identity.Name.
This Csla.ApplicationContext call successfully retreives my Impersonated AD credentials.  With this information I have managed to check the result of both Identity calls and choose the one that is needed, so technically my applicaton is working.  However, I still would love to know what it takes to get the WindowsIdentity to properly Impersonate.
In Summary, with all the above settings:
System.Security.Principal.WindowsIdentity.GetCurrent().Name; Does NOT Impersonate Client User AD
Csla.ApplicationContext.User.Identity.Name;  Does Impersonate/Fetch Client User AD
Any thoughts on whats happening here?

 

ajj3085 replied on Thursday, April 17, 2014

I think I just saw an older thread about this.  I believe the solution was to change your apppool to run as network service, not system.

SPeters replied on Monday, April 21, 2014

Sadly I've tried every possible appPool setting and none of them change the behavior.  The only difference by changing the appPool setting is that when it fails to alias the windows user, it shows the service account rather than the system account.

Copyright (c) Marimer LLC