title: Log a user in to an ASP.net application using Windows Authentication without using Windows Authentication?
body: <p>I have an ASP.net application I'm developing authentication for.  I am using an existing cookie-based log on system to log users in to the system.  The application runs as an anonymous account and then checks the cookie when the user wants to do something restricted.  This is working fine.</p>
  
  <p>However, there is one caveat: I've been told that for each page that connects to our SQL server, I need to make it so that the user connects using an Active Directory account. because the system I'm using is cookie based, the user isn't logged in to Active Directory.  Therefore, I use impersonation to connect to the server as a specific account.</p>
  
  <p>However, the powers that be here don't like impersonation; they say that it clutters up the code.  I agree, but I've found no way around this.  It seems that the only way that a user can be logged in to an ASP.net application is by either connecting with Internet Explorer from a machine where the user is logged in with their Active Directory account or by typing an Active Directory username and password.  <I>Neither of these two are workable in my application.</i></p>
  
  <p>I think it would be nice if I could make it so that when a user logs in and receives the cookie (which actually comes from a separate log on application, by the way), there could be some code run which tells the application to perform all network operations as the user's Active Directory account, just as if they had typed an Active Directory username and password.</p>
  
  <p>It seems like this ought to be possible somehow, but the solution evades me.  How can I make this work?</p>
  
  <p><B>Update</b> <i>To those who have responded so far, I apologize for the confusion I have caused.  The responses I've received indicate that you've misunderstood the question, so please allow me to clarify.</i></p>
  
  <p><i>I have no control over the requirement</i> that users must perform network operations (such as SQL queries) using Active Directory accounts.  I've been told several times (online and in meat-space) that this is an unusual requirement and possibly bad practice.</p>
  
  <p><I>I also have no control over the requirement</i> that users must log in using the existing cookie-based log on application.  I understand that in an ideal MS ecosystem, I would simply dis-allow anonymous access in my IIS settings and users would log in using Windows Authentication.  <i>This is not the case</i>.  The current system is that as far as IIS is concerned, the user logs in anonymously (even though they supply credentials which result in the issuance of a cookie) and we must programmatically check the cookie to see if the user has access to any restricted resources.</p>
  
  <p>In times past, we have simply used a single SQL account to perform all queries.  My direct supervisor (who has many years of experience with this sort of thing) wants to change this.  He says that if each user has his own AD account to perform SQL queries, it gives us more of a trail to follow if someone tries to do something wrong.</p>
  
  <p>The closest thing I've managed to come up with is using WIF to give the user a claim to a specific Active Directory account, but I still have to use impersonation because even still, the ASP.net process presents anonymous credentials to the SQL server.</p>
  
  <p><b>It boils down to this:</b> Can I log users in with Active Directory accounts in my ASP.net application without having the users manually enter their AD credentials? (Windows Authentication)</p>
  
  <p><b>Update June 1:</b>  I tried replacing the <code>HttpContext.Current.User</code> Principal with one constructed from an identity returned by <code>C2WTS</code> in global.asax.  global.asax seems fine, but after the authentication method runs, the following exception is thrown:</p>
  
  <p>[UnauthorizedAccessException: Attempted to perform an unauthorized operation.]
    System.Security.Principal.WindowsIdentity.get_AuthenticationType() +2176525
     Microsoft.IdentityModel.Claims.WindowsClaimsPrincipal..ctor(WindowsIdentity identity, String issuerName) +82
     Microsoft.IdentityModel.Claims.WindowsClaimsPrincipal.CreateFromWindowsIdentity(WindowsIdentity identity, String issuerName) +138
     Microsoft.IdentityModel.Claims.ClaimsPrincipal.CreateFromPrincipal(IPrincipal principal, String windowsIssuerName) +225
     Microsoft.IdentityModel.Claims.ClaimsPrincipal.CreateFromHttpContext(HttpContext httpContext, Boolean clientCertificateAuthenticationEnabled) +67
     Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnPostAuthenticateRequest(Object sender, EventArgs e) +45
     System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +68
     System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&amp; completedSynchronously) +75</p>
  
  <p>Thanks again to everyone helping out with this.</p>
  
  <p><b>Update again</b></p>
  
  <p>After giving this some more thought, I found this page: <a href="http://www.leastprivilege.com/GenevaHTTPModulesClaimsPrincipalHttpModule.aspx" rel="nofollow noreferrer">http://www.leastprivilege.com/GenevaHTTPModulesClaimsPrincipalHttpModule.aspx</a>. The author points out that there is a class in WIF that I'm not yet familiar with called <code>WindowsClaimsIdentity</code>  which seems to be a hybrid Windows/Claims Identity. I'm trying to find how to set up my impersonation using this class.  In order to set this identity when the user logs on, I'm using the <code>ClaimsAuthenticationManager</code> class.  I think I'm getting closer to a solution.</p>
  
  <p><b>Update again</b></p>
  
  <p>In response to the latest answer, I have successfully created the <code>WindowsPrincipal</code> object.  I successfully used the <code>WindowsPrincipal</code> to impersonate in code.  However, doing the impersonation from <code>web.config</code> (which is what the boss wants) doesn't work.  I have the problem narrowed down some more.</p>
  
  <p>There are three places you can retrieve the logged-in user from:
  
  <li>HttpContext.Current.User</li>
  <li>Thread.CurrentPrincipal</li>
  <li>WindowsPrincipal.GetCurrent</li>
  </p>
  
  <p><code>HttpContext.Current.User</code> and <code>Thread.CurrentPrincipal</code> both return the identity down-castable to a Windows Principal.  However, <code>WindowsPrincipal.GetCurrent</code> still returns the account specified in the "Anonymous Access" section of the IIS configuration.  In the past, I have tried logging users in with <code>Windows Authentication</code> (which as I said before, I absolutely cannot use with this application) which does cause <code>WindowsPrincipal.GetCurrent</code> to return the logged-in users account.  What must I do to get <code>WindowsPrincipal.GetCurrent</code> to return the logged-in users account without <code>Windows Authentication</code>?</p>