locked
problems with ImpersonateSecurityContext on Vista RRS feed

  • Question

  • I have a service that impersonates a client in one of two ways
    depending on the connection method:
    - with ImpersonateSecurityContext
    or
    - with ImpersonateLoggedOnUser

    Both work well under previous versions of Windows but in Vista
    when the process uses ImpersonateSecurityContext, it is denied
    access when trying to open a file for writing in one of its
    directories, even if I try to grant Everyone full control
    to the directory's ACL.

     It still works fine with ImpersonateLoggedOnUser.

     

    What has changed in Vista for impersonation techniques?
    Is there a new requirement, or something I missed that was optional in previous versions?
    My process does not try to get a primary access token unless and
    until it needs to spawn a subprocess via CreateProcessAsUser...

    I checked the active privileges for the user in the impersonation token in both cases, they were identical. What else can I check?

     

    Thanks in advance for any clues to resolve this issue.

    Wednesday, May 9, 2007 6:14 PM

All replies

  • Any ideas on this anyone?

     

    Thanks a lot,

     

    jpm

     

    Monday, May 21, 2007 7:44 PM
  • Is the client coming across as Anonymous by any chance?
    Wednesday, May 23, 2007 10:42 PM
  • Eric,

     

    Thank you for responding.

     

    No, the clients are coming in with accounts that exist locally on the server.

     

     

    jpm

     

    Wednesday, May 30, 2007 12:20 AM
  • The only way we can troubleshoot this further is to obtain more information about the thread token after impersonation.

    The easiest method I know involves a debugger (!token extension). Can you do this?

     

    Thursday, June 14, 2007 2:33 AM
  • Eric,

     

    Thanks for the advice to use !token. It took me a while to get back to this because first the problem disappeared for a while, then it came back but is very sporadic.

    Symptoms remain the same though so I was finally able to debug it and get the following confusing output from !token:

     

    *************************************************

    0/ Before any impersonation

    *************************************************

    Thread is not impersonating. Using process token...
    TS Session ID: 0
    User: S-1-5-18
    Groups:
     00 S-1-5-32-544
        Attributes - Default Enabled Owner
     01 S-1-1-0
        Attributes - Mandatory Default Enabled
     02 S-1-5-11
        Attributes - Mandatory Default Enabled
     03 S-1-16-16384
        Attributes - GroupIntegrity GroupIntegrityEnabled
    Primary Group: S-1-5-18
    Privs:
     00 0x000000003 SeAssignPrimaryTokenPrivilege     Attributes -
     01 0x000000004 SeLockMemoryPrivilege             Attributes - Enabled Default
     02 0x000000005 SeIncreaseQuotaPrivilege          Attributes -
     03 0x000000007 SeTcbPrivilege                    Attributes - Enabled Default
     04 0x000000008 SeSecurityPrivilege               Attributes -
     05 0x000000009 SeTakeOwnershipPrivilege          Attributes -
     06 0x00000000a SeLoadDriverPrivilege             Attributes -
     07 0x00000000b SeSystemProfilePrivilege          Attributes - Enabled Default
     08 0x00000000c SeSystemtimePrivilege             Attributes -
     09 0x00000000d SeProfileSingleProcessPrivilege   Attributes - Enabled Default
     10 0x00000000e SeIncreaseBasePriorityPrivilege   Attributes - Enabled Default
     11 0x00000000f SeCreatePagefilePrivilege         Attributes - Enabled Default
     12 0x000000010 SeCreatePermanentPrivilege        Attributes - Enabled Default
     13 0x000000011 SeBackupPrivilege                 Attributes -
     14 0x000000012 SeRestorePrivilege                Attributes -
     15 0x000000013 SeShutdownPrivilege               Attributes -
     16 0x000000014 SeDebugPrivilege                  Attributes - Enabled Default
     17 0x000000015 SeAuditPrivilege                  Attributes - Enabled Default
     18 0x000000016 SeSystemEnvironmentPrivilege      Attributes -
     19 0x000000017 SeChangeNotifyPrivilege           Attributes - Enabled Default
     20 0x000000019 SeUndockPrivilege                 Attributes -
     21 0x00000001c SeManageVolumePrivilege           Attributes -
     22 0x00000001d SeImpersonatePrivilege            Attributes - Enabled Default
     23 0x00000001e SeCreateGlobalPrivilege           Attributes - Enabled Default
     24 0x000000021 SeIncreaseWorkingSetPrivilege     Attributes - Enabled Default
     25 0x000000022 SeTimeZonePrivilege               Attributes - Enabled Default
     26 0x000000023 SeCreateSymbolicLinkPrivilege     Attributes - Enabled Default
    Auth ID: 0:3e7
    Impersonation Level: Anonymous
    TokenType: Primary


    *************************************************
    1/ With ImpersonateSecurityContext (FAILING CASE)
    *************************************************

    TS Session ID: 0
    User: S-1-5-21-1222221106-2685493983-2931208152-1003
    Groups:
     00 S-1-5-21-1222221106-2685493983-2931208152-513
        Attributes - Mandatory Default Enabled
     01 S-1-1-0
        Attributes - Mandatory Default Enabled
     02 S-1-5-32-544
        Attributes - DenyOnly
     03 S-1-5-32-545
        Attributes - Mandatory Default Enabled
     04 S-1-5-2
        Attributes - Mandatory Default Enabled
     05 S-1-5-11
        Attributes - Mandatory Default Enabled
     06 S-1-5-15
        Attributes - Mandatory Default Enabled
     07 S-1-5-64-10
        Attributes - Mandatory Default Enabled
     08 S-1-16-4096
        Attributes - GroupIntegrity GroupIntegrityEnabled
    Primary Group: S-1-5-21-1222221106-2685493983-2931208152-513
    Privs:
     00 0x000000013 SeShutdownPrivilege               Attributes -
     01 0x000000017 SeChangeNotifyPrivilege           Attributes - Enabled Default
     02 0x000000019 SeUndockPrivilege                 Attributes - Enabled Default
     03 0x000000021 SeIncreaseWorkingSetPrivilege     Attributes - Enabled Default
     04 0x000000022 SeTimeZonePrivilege               Attributes -
    Auth ID: 0:23683f9
    Impersonation Level: Impersonation
    TokenType: Impersonation


    *************************************************
    2/ With ImpersonateLoggedOnUser (SUCCEEDING CASE)
    *************************************************

    TS Session ID: 0
    User: S-1-5-21-1222221106-2685493983-2931208152-1003
    Groups:
     00 S-1-5-21-1222221106-2685493983-2931208152-513
        Attributes - Mandatory Default Enabled
     01 S-1-1-0
        Attributes - Mandatory Default Enabled
     02 S-1-5-32-544
        Attributes - DenyOnly
     03 S-1-5-32-545
        Attributes - Mandatory Default Enabled
     04 S-1-5-4
        Attributes - Mandatory Default Enabled
     05 S-1-5-11
        Attributes - Mandatory Default Enabled
     06 S-1-5-15
        Attributes - Mandatory Default Enabled
     07 S-1-5-5-0-37269204
        Attributes - Mandatory Default Enabled LogonId
     08 S-1-5-64-10
        Attributes - Mandatory Default Enabled
     09 S-1-16-8192
        Attributes - GroupIntegrity GroupIntegrityEnabled
    Primary Group: S-1-5-21-1222221106-2685493983-2931208152-513
    Privs:
     00 0x000000013 SeShutdownPrivilege               Attributes -
     01 0x000000017 SeChangeNotifyPrivilege           Attributes - Enabled Default
     02 0x000000019 SeUndockPrivilege                 Attributes -
     03 0x000000021 SeIncreaseWorkingSetPrivilege     Attributes -
     04 0x000000022 SeTimeZonePrivilege               Attributes -
    Auth ID: 0:238aee2
    Impersonation Level: Impersonation
    TokenType: Impersonation


     

    Any ideas if the differences could account for the problem, and what is causing the differences?

     

    Thanks a lot for helping.

     

    jpm

    Wednesday, July 18, 2007 11:27 PM
  • The second token is from an interactive user at medium integrity, and he should indeed be able to open most files for write (as long as the DACL allows it).

    The first token is a little more surprising though: low integrity and network logon!

     

    The low integrity explains why opening a file for write fails (assuming the file is unlabeled or labeled at least medium, which you can verify using icacls).

    On the other hand, I'm not really sure in which scenario such a token would be generated. What's the client? What is it doing?

     

    Regards

    Eric

    Thursday, July 19, 2007 9:22 PM
  • Eric,

     

    Thanks a lot for analyzing the tokens!

    It prompted me to read more about the integrity design in Vista,

    and I think I now understand the problem and I have a workaround.

     

    First, to answer your question, the client is an IE browser window

    that authenticates to an HTTP server thread internal to our server application's processes,

    and in turn the HTTP thread authenticates to the back end server process that calls

    ImpersonateSecurityContext and generates the tokens seen in my previous email.

     

    Having read about Protected Mode Internet Explorer, I now understand that it runs at low

    integrity instead of medium, thus generating a low integrity token in that case.

    I confirmed this by changing IE security policy to trusted site for the URL of the application,

    and it immediately solved the problem.

     

    Therefore I assume all this is by design and our only solution is to require users of our software

    to add the application site to the list of trusted sites in their browser's internet options?

     

    Please confirm and thank you very much for your help.

     

    Jean-Philippe Monfort

     

    Monday, July 23, 2007 6:50 PM
  • Are you experiencing this locally (both browser and server on the same machine) or remotely (browser on one machine, server on another)?

     

    Regards
    Eric

     

    Monday, July 23, 2007 8:20 PM
  • Our Vista tests have been local so far, so we experienced this locally. Ultimately we need it to work both locally and remotely.

     

    Thanks

     

    Jean-Philippe

     

    Monday, July 23, 2007 9:31 PM
  • Can you please try it remotely at least once and reply with your findings?

    The course of action may depend on the outcome...

     

    Regards

    Eric

    Monday, July 23, 2007 10:01 PM