CODEWITHSUNDEEP
c++
sofr
sofr

Reputation: 5607

using checkTokenMemberShip return always true even if the process user is not administrator

the following is the code I'm using (copied from msdn) but even when the the pocess user is not a local admin it returns as if it is any ideas?

BOOL IsUserAdmin(VOID)
/*++ 
Routine Description: This routine returns TRUE if the caller's
process is a member of the Administrators local group. Caller is NOT
expected to be impersonating anyone and is expected to be able to
open its own process and process token. 
Arguments: None. 
Return Value: 
   TRUE - Caller has Administrators local group. 
   FALSE - Caller does not have Administrators local group. --
*/ 
{
BOOL b;
SID_IDENTIFIER_AUTHORITY NtAuthority = SECURITY_NT_AUTHORITY;
PSID AdministratorsGroup; 
b = AllocateAndInitializeSid(
    &NtAuthority,
    2,
    SECURITY_BUILTIN_DOMAIN_RID,
    DOMAIN_ALIAS_RID_ADMINS,
    0, 0, 0, 0, 0, 0,
    &AdministratorsGroup); 
if(b) 
{
    if (!CheckTokenMembership( NULL, AdministratorsGroup, &b)) 
    {
         b = FALSE;
    } 
    FreeSid(AdministratorsGroup); 
}

return(b);
}

Upvotes: 3

Views: 4267

Answers (2)

Steve-o
Steve-o

Reputation: 12866

Updating Gabriel's answer, there is an article from a Microsoft engineer on the topic:

How to Determine Whether a Process or Thread Is Running As an Administrator archive

Upvotes: 0

Gabriel
Gabriel

Reputation: 1273

In the MSDN doc here... There is a note mentioning issues when using this on VISTA (or later).

To paraphrase, if you're using this on Vista - the API will return true - because of the way Vista uses a split token for security.

Here is the original note (originally written by tchao):

When UAC is enabled in Windows Vista--which is the default setup, a thread in an administrator account will have a pair of split tokens: a filtered token and an elevated token. The filtered token will have the local administrators group SID in its group, but that SID is not enabled until the thread gets the elevated token after user's approval via the UAC dialog or programmatically. The above sample code shows that both a filtered administrator token and an elevated administrator token as having the local administrators group SID "enabled," but that is not the case with the filtered administrator token which has its TOKEN_ELEVATION_TYPE as TokenElevationTypeLimited.

If you look at the local administrators group association with the administrator filtered token, it's for deny only, but CheckTokenMembership() will show that the administrator filtered token is a member (enabled?) of the local administrators group. Perhaps this is also a function implementation bug?!

Upvotes: 2

Related Questions