tags:

views:

341

answers:

2

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);
}
+1  A: 

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?!

Gabriel
+1 ... in other words, Vista with UAC, admin accounts are still members of the Administrators group, but there are some (ineffective) efforts to keep processes from exercising rights under that SID without the UAC prompt. The only other comment I would make is that CheckTokenMembership with a NULL first argument checks against the current _thread impersonation_ or _thread primary_ token, not the process token as wrongly implied by the MSDN sample code.
Marsh Ray
A: 

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

http://msdn.microsoft.com/en-us/windows/ff420334.aspx

Steve-o