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

Question

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;
   }

}

Answer 1

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.

Answer 2

It is common mistake to forget granting admin access to shares containing profiles or home drives at the time of their creation. Permissions are usually driven through CREATOR OWNER and inheritance is broken in such shares. Only way for admins to get inside is to take ownership. Taking ownership will of course cause issues for end users. In some cases, where it is clear who is the owner of particular folder (eg. folder name is equal to user account name) you can use script which will take ownership-> set admin permission->set permission back to user account name gathered from folder name. If you are still interested, I can post the code here

Answer 3

You can't and should not "impersonate" any account you don't have the password - and thereby no permission to use - because you're not meant to do anything on his or her behalf even if you're an administrator and can change his or her password - unless explicitly authorized for. Nor you should modify permissions on any folder you are not the owner of - unless authorized. Being an "administrator" doesn't mean you're a god-like creature and you're exempt from company policies.

It is all about "accountability" - accounts are not only to permit or deny access, but to record and audit also who made what, and thereby accountable for. There are legal requirements that can ask to identify and control whoever has access to some kind of sensitive informations - and restrict the number of people who can access them. Windows have facilities to audit users actions - including file accesses.

That's why Windows doesn't let you act on behalf of any users unless explicity allowed to - even if your're an administrator.

There are good reason also to remove access by administrators from folders - the fact that an administrator could always gain access to something doesn't mean he or she is allowed to do that - and doing without permission could put you in trouble. Removing permission from (some) administrators means you can't "by mistake" access files you're not explicitly allowed to access.

In properly setup systems, also logs are shipped to different machines where most administrators but highly privileged ones have no access - to ensure company policies about data protection are enforced and audited, without administrators being able to clear the logs to hide their tracks.