Jean-Philippe Monfort

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.



Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Jean-Philippe Monfort

Any ideas on this anyone

Thanks a lot,

jpm





Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Eric Perlin - MSFT

Is the client coming across as Anonymous by any chance




Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Jean-Philippe Monfort

Eric,

Thank you for responding.

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

jpm





Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Eric Perlin - MSFT

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






Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Jean-Philippe Monfort

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





Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Eric Perlin - MSFT

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






Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Jean-Philippe Monfort

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





Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Eric Perlin - MSFT

Are you experiencing this locally (both browser and server on the same machine) or remotely (browser on one machine, server on another)

Regards
Eric






Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Jean-Philippe Monfort

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





Re: Security for Applications in Windows Vista problems with ImpersonateSecurityContext on Vista

Eric Perlin - MSFT

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