Sign in
Microsoft.com
 
Windows Server TechCenter
 
 
 
Windows Server TechCenter > Windows Server Forums > Directory Services > S4U2self - Allowing Protocol Transition, but only to impersonate authenticated users
Ask a questionAsk a question
Search Forums:
 

QuestionS4U2self - Allowing Protocol Transition, but only to impersonate authenticated users

  • Thursday, October 22, 2009 6:05 PMNick Piper Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    My questions are around my concern that by allowing Protocol Transition, allows the service account can impersonate anybody; while it should be limited to only those users who have authenticated in some way.

    I have the following code an an asp.net application:

        WindowsIdentity winId = (WindowsIdentity)HttpContext.Current.User.Identity;

    
    WebRequest request = WebRequest.Create(http://be);
    request.Credentials = CredentialCache.DefaultCredentials;
    WindowsImpersonationContext ctx = null;
    ctx = winId.Impersonate();
    WebResponse response = request.GetResponse();
    ctx.Undo();
    which works well, if

    • The user authenticates to IIS using Kerberos, and our AD is at the Server 2003 functional level, and the IIS application is running as Network Service, and the IIS computer is marked in AD as 'Trust this computer for delegation to any service (Kerberos only)'.
    • or the same as above, except the user authenticates to IIS using Basic, or Digest, Network Service is having "Act as part of the operating system" (I realise that's a bad idea, I could create a new account for IIS' pool, and then set up SPNs, etc.), and the IIS computer is marked in AD as 'Trust this computer for delegation to specified services only/Use any authentication protocol' and the http/be service is listed. (phew.)

    However, if I allow Protocol Transition (i.e., 'Trust this computer for delegation to specified services only/Use any authentication protocol'), then this also works:

        // we can just pretend this user is using our website, even though they are not!
    WindowsIdentity winId = new WindowsIdentity(user4@treyresearch.net);

    WebRequest request = WebRequest.Create(http://be/);
    request.Credentials = CredentialCache.DefaultCredentials;
    WindowsImpersonationContext ctx = null;
    ctx = winId.Impersonate();
    WebResponse response = request.GetResponse();
    ctx.Undo();

    My questions are, for Basic/Digest authenticated users:
    1. Is it possible to NOT allow WindowsIdentity(string).Impersonate(), but to ALLOW HttpContext.Current.User.Identity.Impersonate()?
    2. Using Impersonate() on HttpContext.Current.User.Identity for Basic/Digest users worked *without* needing "Act as part of the operating system". How/Why?
    My proof of (2) is the output on a web page served by the front end server:

     Running as NT AUTHORITY\NETWORK SERVICE, authenticated TREYRESEARCH\USER via Digest at 10/22/2009 6:46:19 PM from FE

 Running as TREYRESEARCH\sa-iis, authenticated TREYRESEARCH\USER via Negotiate at 10/22/2009 6:46:19 PM from BE

    The first line is from the 'front end' IIS server. The second line is from the 'back end' IIS server (which is running it's workers under a service account.) Both have authenticated the user USER. The backend IIS does NOT have 'Act as part of the operating system'. This is using HttpContext.Current.User.Identity's Impersonate().

    If instead, I use WindowsIdentity("user@treyresearch.net"), then I get either the error "The remote name could not be resolved: 'be' " or one about not being allowed to open a local socket. This is (I suppose) because of the lack of 'Act as part of the operating system', so it has only a Identify-level token rather than a Impersonation-level token . In this case, how does Using Impersonate() on HttpContext.Current.User.Identity get an Impersonation-level token?

    This arrangement would actually solve (1), if we could keep the situation that way; but the web server configuration is not controlled by us, so the IIS worker could be put into the TCB; suddenly letting the web server pretend to be 'anybody' with respect to the back-end REST API.

    My overall aim, is to allow:
    • A web server running in our domain
    • to accept NTLM authentication (not all users can reach the KDC to get a TGT)
    • to then access a backend REST / HTTP API, authenticating as the original user
    • but to NOT allow that web server to just impersonate anyone randomly when it calls the REST API (we don't control the web server.)
    Many thanks,

     Nick
    • Edited byNick Piper Thursday, October 22, 2009 6:08 PMformatting
    • Edited byNick Piper Thursday, October 22, 2009 6:06 PMformatting
    • Edited byNick Piper Thursday, October 22, 2009 6:18 PMSwitched to IE incase this allows formatting to work...
    • Edited byNick Piper Thursday, October 22, 2009 6:10 PMformatting, still. It's a battle. Looks fine in the editor. Looks broken on the forum :-/
    •  
     

All Replies