Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum

CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Impersonation not working in PopulateWindowsIdentity()

    Not Answered This post has 0 verified answers | 2 Replies | 2 Followers

    Not Ranked
    3 Posts
    SPeters posted on Fri, Mar 21 2014 10:09 AM

    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.



    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"?>



        <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" />



    PRIVATE :)



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

        <authentication mode="Windows" />

        <identity impersonate="true" />

        <pages controlRenderingCompatibilityVersion="4.0"/>



        <validation validateIntegratedModeConfiguration="false" />



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


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

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





            <behavior name="WcfPortalBehavior">

              <serviceDebug includeExceptionDetailInFaults="true" />

     <serviceAuthorization impersonateCallerForAllOperations="true" />






            <binding name="BasicHttpBinding_IWcfPortal" 



                       maxBufferSize="2147483647" >

              <readerQuotas maxBytesPerRead="2147483647"




                              maxDepth="2147483647" />

              <security mode="TransportCredentialOnly">

                <transport clientCredentialType="Windows" />







    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?


    All Replies

    Top 10 Contributor
    4,106 Posts
    Andy replied on Thu, Apr 17 2014 7:30 PM

    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.

    Not Ranked
    3 Posts
    SPeters replied on Mon, Apr 21 2014 11:36 AM

    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.

    Page 1 of 1 (3 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems