0

If the parent process has used LogonUser so that the access token being used for file access is different than than the token the process was started with, how can the DLL find out the NT User name that the file accesses will be processed under?

If I had a specific file location then I could use GetFileSecurity, however I don't know any guaranteed accessible paths in the context of the DLL.

If I used the following:

PSID ownedSID(NULL);
SECURITY_INFORMATION siRequested = OWNER_SECURITY_INFORMATION;
wSecInfoOK = GetSecurityInfo(GetCurrentProcess(), SE_KERNEL_OBJECT, siRequested, &ownedSID, NULL, NULL, NULL, NULL);

then the PSID returned references the Windows user of the logged on process rather than that under which any writes will be treated as!

New Question in light comment / answer from @arx

I am now using TokenUser with GetTokenInformation on the handle from OpenThreadToken, but again I am getting the launching user but not the impersonated user

HANDLE hThreadToken = NULL;
if (OpenThreadToken(GetCurrentThread(), TOKEN_ALL_ACCESS, TRUE, &hThreadToken))
{
// success

    CHeapPtr<TOKEN_USER, CGlobalAllocator> pToken;
    DWORD length = 0U, dwError(0UL);
    if (!GetTokenInformation(hThreadToken, TokenUser, NULL, 0, &length) && ERROR_INSUFFICIENT_BUFFER == GetLastError())
    {
        pToken.AllocateBytes(length);
        SetLastError(ERROR_SUCCESS);//Reset last error - we have now allocated the required memory so the buffer is now big enough i.e GetLastError() != ERROR_INSUFFICIENT_BUFFER
        if (pToken && GetTokenInformation(hThreadToken, TokenUser, pToken, length, &length)) 
        {
            if (IsValidSid(pToken->User.Sid))
                sFailedUser = WinSecurityInfo::GetAccountSID(pToken->User.Sid, dwError);
        }
        dwError = GetLastError();
        if (dwError)
        {
            boost::system::error_code sidError = MakeSysError(dwError);
            TRACE("Error text for GetLastError() = '%s'\n", sidError.message().c_str());
        }
    }
}

P.S WinSecurityInfo::GetAccountSID is just a wrapper around LookupAccountSid P.P.S Tried both FALSE and TRUE in OpenThreadToken, no change

Peter Nimmo
  • 1,045
  • 2
  • 12
  • 25
  • 1
    This sounds like an [XY problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). Why does your DLL care about the access token? – Eric Brown Apr 07 '14 at 17:33
  • 1
    +1, why? Anyway, [OpenThreadToken](http://msdn.microsoft.com/en-us/library/windows/desktop/aa379296%28v=vs.85%29.aspx). – arx Apr 07 '14 at 20:19
  • We have a Out of process COM server that needs to log to disk, however we have found that depending on how this server is kicked off, it has a direct effect on whether the logging to disk will work. When it is kicked off from a windows service it fails to log. I want to add an event to the event log describing what windows user the attempted file access is under. In the real world there is no Impersonation happening so the SID of the process token will be the same as the on used for file access, but I wanted to make it robust with respect to Impersonation being used – Peter Nimmo Apr 08 '14 at 10:18
  • Tried OpenThreadToken, but I'm still getting the launch user rather than the impersonated user. As a test I wrote a file to a non-mapped location and the Owner is still the launch user. So it must be the impersonated user I need to discover so that people will be able to tell from the Event Log why it was not possible to write to the mapped location – Peter Nimmo Apr 08 '14 at 11:01

1 Answers1

0

You are looking at the wrong information in the thread token retrieved with OpenThreadToken. To get the identity of the user being impersonated you need to look at the TokenUser, not the TokenOwner.

Use GetTokenInformation to retrieve the user.

However, rather than going to great lengths to work in the face of impersonation, it is more usual to specify as part of your API contract that you don't. And then ignore the problem.

arx
  • 16,686
  • 2
  • 44
  • 61