{"id":98875,"date":"2018-05-30T07:00:00","date_gmt":"2018-05-30T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=98875"},"modified":"2019-03-13T00:44:35","modified_gmt":"2019-03-13T07:44:35","slug":"20180530-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180530-00\/?p=98875","title":{"rendered":"When you call Open­Thread­Token<\/CODE> while impersonating, you have to say who is asking for the thread token"},"content":{"rendered":"

A customer reported that Open­Thread­Token<\/code> was failing with the error ACCESS_<\/code>DENIED<\/code> and wanted help understanding why. They shared a code fragment which operates on an account name test<\/code> with no special privileges. <\/p>\n

\n\/\/ Code in italics is wrong\n\nint main()\n{\n  HANDLE hToken = NULL;\n\n  \/\/ This succeeds.\n  LogonUser(L\"test\", L\".\", L\"test@123\",\n    LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,\n    &hToken);\n\n  \/\/ This also succeeds.\n  ImpersonateLoggedOnUser(hToken);\n\n  \/\/ During this Sleep, Process Hacker<\/a> shows that the thread\n  \/\/ is impersonating.\n  Sleep(10'000);\n\n  \/\/ This fails with ERROR_ACCESS_DENIED.\n  OpenThreadToken(GetCurrentThread(), TOKEN_QUERY,\n    FALSE, &hToken);\n\n  return 0;\n}<\/i>\n<\/pre>\n
According to the documentation for Open­Thread­Token<\/code><\/a>: <\/p>\n
\n
OpenAsSelf<\/i> [in] <\/p>\n
TRUE<\/b> if the access check is to be made against the process-level security context. <\/p>\n
FALSE<\/b> if the access check is to be made against the current security context of the thread calling the Open­Thread­Token<\/b> function. <\/p>\n
The OpenAsSelf<\/i> parameter allows the caller of this function to open the access token of a specified thread when the caller is impersonating a token at Security­Identification<\/b> level. Without this parameter, the calling thread cannot open the access token on the specified thread  because it is impossible to open executive-level objects by using the Security­Identification<\/b> impersonation level<\/u>. <\/p>\n<\/blockquote>\n
Furthermore, as I discussed some time ago<\/a>, <\/p>\n
\n
When a new kernel object is created, and you don’t provide an explicit security descriptor for the new object, then the object is given a default security descriptor. And that default security descriptor comes from the default DACL of the token that is in effect at the point of the call. <\/p>\n
When you apply this rule to tokens, you find that, even though the behavior is consistent with other kernel objects, it also means that it is very easy to create a token that doesn’t have access to itself<\/u>. When you impersonate with that token, bad things happen. <\/p>\n<\/blockquote>\n
 The code fragment above passes FALSE<\/code>, which means that the access check is made against the current security context, which is the impersonated test user, and that user doesn’t have access to the token. <\/p>\n
Note that changing FALSE<\/code> to TRUE<\/code> is only the first step in what may be a long uphill struggle. One of my colleagues on the security team added that if you don’t have the Se­Impersonate­Privilege<\/b> for your process, you will run into other problems as well. The customer didn’t explain the scenario where they think impersonation is a step in the solution, so it’s hard to elaborate on what else can go wrong, because we don’t know what they’re trying to do. <\/p>\n
Bonus reading<\/b>: Changes to  Se­Impersonate­Privilege<\/b> in Windows Vista<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"
I am for you.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-98875","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
I am for you.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98875","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=98875"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/98875\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=98875"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=98875"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=98875"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}