Quantcast
Channel: CSLA .NET
Viewing all articles
Browse latest Browse all 764

Impersonation not working in PopulateWindowsIdentity()

$
0
0

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?

 


Viewing all articles
Browse latest Browse all 764

Trending Articles