Search code examples
c++active-directorydnsimpersonationshared-directory

How to impersonate another domain user as i have the administrator account of this AD domain?


i'm working on a windows software which can display all the users, groups and shared folders info in a domain when you input the domain administrator account. I have some trouble fetching some shared folders info because these folders even did not grant share permissions to domain admins(remove the Everyone in the share tab). The GetFileSecurity or the GetNamedSecurityInfo returns error code 5). But as a domain administrator, i think i could have the access to the permission information of the shared folders(just ACLs, no need to full access permission) in my domain computers.

I learnt about the impersonate method to log on to be another user, and if i log on as a domain user who is granted read permission in the share tab of the shared folder, i could get the ACLs successfully. But the problem here is that i do not know the password of a domain user in a practical environment even though i know their usernames and can change their passwords.

So how to get a domain user' access token to impersonate when i already have the domain admin account, or is there any way else?

I develop it using C++ and ADSI. Here's the log on and get NTFS security desciption methods:

BOOL ADDirectorySearch::logOnByUserPassword(CString strDomainName, CString strUserName, CString strPassword) {

CString strFullUserName = strDomainName + _T("\\") + strUserName;
HANDLE hToken;
BOOL bResult;
bResult = LogonUser(strFullUserName, strDomainName, strPassword, LOGON32_LOGON_NEW_CREDENTIALS, LOGON32_PROVIDER_DEFAULT, &hToken);
if (bResult == FALSE)
{
    MyMessageBox_Error(_T("logOnByUserPassword Error."), _T("Error"));
    return FALSE;
}
else
{
    bResult = ImpersonateLoggedOnUser(hToken);
    if (bResult == FALSE)
    {
        MyMessageBox_Error(_T("logOnByUserPassword Error."), _T("Error"));
        return FALSE;
    }
    else
    {
        return TRUE;
    }
}

}

PSECURITY_DESCRIPTOR ADDirectorySearch::getNTFSSecDescriptor2(CString strFileName, CString strServerName, CString strServerIP) {

//CString strServerNameWithSlash = _T("\\\\") + strServerName;//"\\\\veotax3";
CString strFilePathName = _T("\\\\") + strServerName + _T("\\") + strFileName;//"\\\\veotax3\\nrdc1001";
CString strFilePathName2 = _T("\\\\") + strServerIP + _T("\\") + strFileName;//"\\\\192.168.1.7\\nrdc1001";
_bstr_t bstrFilePathName = strFilePathName;

BOOL bSuccess = FALSE;
PSECURITY_DESCRIPTOR pSecDescriptorBuf = NULL;
DWORD dwSizeNeeded = 0;label2:;
   bSuccess = GetNamedSecurityInfoW(bstrFilePathName, SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, NULL, NULL, &pSecDescriptorBuf);
   //bSuccess = GetFileSecurityW(bstrFilePathName, DACL_SECURITY_INFORMATION, NULL, 0, &dwSizeNeeded);
   if (ERROR_SUCCESS != bSuccess)
   {
       if (strFilePathName != strFilePathName2)
       {
           strFilePathName = strFilePathName2;
           bstrFilePathName = strFilePathName2;
           goto label2;
       }
       else
       {
           MyMessageBox_Error(_T("getNTFSSecDescriptor2 Error."), _T("Error"));
           return NULL;
       }
   }
   else
   {
        return pSecDescriptorBuf;
   }

}


Solution

  • I read another question from you. I think I understand what you try to do. In order to acheive your goal, you need to have an access token with impersonation level "Impersonate" or "Delegate". You can get it by different ways. Providing the password is the most straight forward approach. Another approach is to setup a machine to do Protocol Transition.

    My personal suggestion is to avoid doing impersonation. Just make sure all shared folders have domain administrator granted to have read access. As I showed in another question, this is not a security compromise at all. Domain administrator can always have a way to read the folder anyway if they want to.

    Also, fyi, there are some existing tools avaliable from SysInternals doing similar things.

    Check out AccessChk.exe and AccessEnum.exe from SysInternals

    They both suffer from the same permission problem as what you are facing now.