Share the troubleshooting process of setting the program to run invalid problems with administrator privileges

Table of contents

1. Problem description

2. UAC permission control and system login user type

2.1, super administrator login

2.2. Set the program to run with administrator privileges

3. Create a new administrator account for verification

3.1. Create a common administrator account

3.2. Use the newly added ordinary administrator user to test and verify

4. Go to the colleague's machine to check

5. Determine whether the program is running with administrator privileges through the code

6. Finally


VC++ common function development summary (column article list, welcome to subscribe, continuous update...) https://blog.csdn.net/chenlycly/article/details/124272585 C++ software exception troubleshooting series tutorial from entry to mastery (column article list , Welcome to subscribe, keep updating...) https://blog.csdn.net/chenlycly/article/details/125529931        Today, my colleague wants to set an exe main program to run with administrator privileges, and as a result, set the corresponding option in the project properties After that, it didn't work. So I found me, and I hope I can help him troubleshoot and see why it doesn't work after setting the option. Today, I will share the complete investigation at that time to provide you with a reference and reference.

1. Problem description

        Because the program needs to read the device information in the U-Shield, it needs administrator privileges, that is, the program runs with administrator privileges. The program is developed with Visual Studio. In Visual Studio, set it to run with administrator privileges in the project properties of the program, as follows:

After setting and recompiling the program, the following prompt box for UAC privilege escalation does not pop up when it starts running:

It should be that the setup program failed to run with administrator privileges. So he found me and asked me to help him troubleshoot.

2. UAC permission control and system login user type

        Windows has introduced the UAC permission control mechanism since the Vista system, strengthened the concept of administrator permissions, and made stricter permission restrictions and security controls. For example, some permissions-sensitive paths, such as C:\Program Files, C:\Windows\system32, if you want to create files and write data to files under these paths, you need administrator permissions. For another example, in the registry of the Windows system, if you want to write or modify content to the HKEY_LOCAL_MACHINE node, you also need administrator privileges. These operations are not limited in the previous Windows XP system.

       Whether the program runs with administrator privileges is mainly related to two factors, one is the type of user currently logged into the system (whether it is a super administrator Administrator), and the other is whether the program has applied for administrator privileges.

2.1, super administrator login

       The super administrator is the built-in administrator account Administrator of the Windows system. The super administrator user is not enabled by default. If you need to use this account, you need to manually open it. In the case of a super administrator login, the system sets the user to have the highest authority, and all programs started by the user run with administrator authority, regardless of whether the program is set to run with administrator authority. There will also be no UAC prompt box as follows:

Therefore, first of all, I confirmed with my colleagues whether the system is logged in as the super administrator Administrator during the test, because when this user logs in, all programs run with administrator privileges, and the UAC prompt box will not pop up.

       Colleagues reported that he is currently logged in as an ordinary administrator user, not the super administrator Adminstrator, so the UAC prompt box does not pop up, and it has nothing to do with the super administrator Administrator.

In fact, it is also simple. You can start an installation package program for comparison. Generally, the installation package program must be set with administrator privileges. See if the UAC prompt box pops up when the installation package program starts.

2.2. Set the program to run with administrator privileges

        There are three main categories of Windows system login users: super administrator Adminstrator, common administrator users, and standard users. For the super administrator Administrator, it has the highest authority. As mentioned above, the programs started under this user are all run with administrator authority, and the UAC prompt box will not pop up.

       For ordinary administrator users, they belong to the administrator group, but their permissions are less than those of super administrators. In the case of ordinary administrator login, all programs run with standard user rights by default. If the program is to run with administrator privileges, you need to set the attribute of administrator privileges for the program. For Visual Studio 2010 and above, you need to set the required Administrator property in the project properties of the program, that is, set the program to run with administrator privileges.

       Set the program to run with administrator privileges. In the scenario of ordinary administrator login, a UAC prompt box will pop up:

Prompt the user that the current program applies to run with administrator privileges, which may modify data in sensitive locations (such as writing data to the sensitive location C:\Program Files, writing data to the HKEY_LOCAL_MACHINE registry node). Click Yes to agree to run with administrator privileges; click No to agree to run with administrator privileges, and the program will not run.

For the installation package program, the general default installation path is under C:\Program Files, and some registry information needs to be written to HKEY_LOCAL_MACHINE, and these operations require administrator privileges to perform, so the installation package program needs to be set run with administrator privileges.

       In the scenario where ordinary administrator users and standard users log in, generally when you see an exe program that requires administrator privileges, a small shield will be displayed in the lower right corner of the program icon, as shown below:

Seeing these small shields means that these programs require administrator privileges. Note that these small shield icons will not be displayed when the super administrator logs in, because all programs run with administrator privileges when the super administrator logs in, no matter whether the program has applied for administrator privileges or not. A colleague logs in as an ordinary administrator on his computer. If the program is set to run with administrator privileges, the icon of the compiled exe program should be marked with a shield in the lower right corner. However, colleagues reported that the shield was not displayed.

       Ordinarily, this is unscientific. It is enough to set the required Administrator in the project properties of the program. Why is it invalid?

3. Create a new administrator account for verification

       As mentioned above, my colleague has set requiredAdministrator in the Visual Studio project properties, but it doesn't seem to take effect after the actual measurement. This is how it is supposed to be handled, why doesn't it take effect? This is a bit strange. I am currently using the Administrator super administrator on my machine, so I want to manually create an ordinary administrator user, and go to the ordinary administrator user for field verification.

3.1. Create a common administrator account

        The steps to create an administrator account are a bit convoluted. Let me explain in detail here.

        First open the control panel, select the "small icon" view mode, then find the user account button and click:

In the opened page, click the "Manage other accounts" button to pop up the following window:

In the window click "Add new user in PC settings":

Click the "Add others to the computer" button in the pop-up window, and the following window will pop up:

Then, click the user node on the left first, then switch to the user list page on the right, click the right button on the blank space, and the right-click menu as shown above will pop up, click the "New User" menu item, and enter the user name admin2 in the pop-up new user window , click OK, and a user admin2 is created. But this user is not an administrator yet, you need to click the group node on the left, a group list will pop up on the right, find the "Administrators" group, right click:

Click the "Add to Group" menu item in the pop-up right-click menu, and the following window will pop up:

Click the "Add" button in the window, and the selection user interface will pop up:

Enter the user name admin2 just added in the input box in the figure, and then click the "Check Name" button to find the user just added and add it, as follows:

In this way, admin2 is added to the administrator group, and the addition of the administrator user is completed so far.

3.2. Use the newly added ordinary administrator user to test and verify

        Click the avatar button in the start menu of the Win10 system, see other users, find the newly added user, click it, and log in to the system with the newly added user. The newly added user is an ordinary administrator user, and the login environment of the colleague's ordinary administrator account is the same.

       So start Visual Studio 2010, create an MFC test project, configure the requiredAdministrator option in the project properties, that is, set the program to start with administrator privileges, and then compile the project to generate an exe file. Go to the directory to view the exe file. There is a shield mark in the lower right corner of the file icon. This mark indicates that the program will apply to start with administrator privileges when it starts. So double-click the exe file to start it, and the UAC prompt box will indeed pop up, as shown below:

This shows that configuring the requiredAdministrator property in the project properties can make the program run with administrator privileges. Therefore, when encountering uncertain problems, you can write test code to verify, or go to a similar environment to verify.

4. Go to the colleague's machine to check

        Created a new ordinary administrator account on my computer for testing. Configuring the requiredAdministrator attribute in the project properties can make the program run with administrator privileges. Why is there a problem in the environment of my colleagues? Looks like I'll have to check it out on the spot. I went to my colleague and checked it. There is indeed a problem. There is no UAC prompt box popping up, and there is no small shield logo in the lower right corner of the program icon.

        So he used Visual Studio 2010 to create a test project on his machine, set the requiredAdministrator attribute in the project properties, and the compiled exe program can be run as an administrator. Strange, then why is there a problem with the software developed by my colleagues? The software they wrote is more complicated, and some functions are called in the program, which makes the setting of administrator privileges invalid? It is not right, the requiredAdministrator attribute setting has nothing to do with the program code.

       So I thought of comparing the created test project properties with the software project properties developed by my colleagues to see if there are any different configurations. Sure enough, I found the problem. In the properties of the software project developed by my colleagues, I selected "No" for the item to generate the list, as follows:

That is, the manifest list file is not generated, and the default selection in the test project is "Yes"!

       So I changed the attribute of my colleague's software project to "Yes", and recompiled it. There is a small shield in the program icon, and a UAC prompt window pops up when the program starts. Therefore, when we encounter problems, we need to test and compare more to find out the difference, which may be the problem. Comparing differences is also a common method for our daily troubleshooting.

5. Determine whether the program is running with administrator privileges through the code

        Sometimes we need to judge whether the target process is running with administrator privileges in the code, so here we will talk about how to judge whether the process is running with administrator privileges through code.

       The Windows system provides the API function GetTokenInformation to detect whether the program is running with administrator privileges. When calling the GetTokenInformation function, the first parameter is passed in the token value of the process to be detected, the second parameter is passed in the TokenElevation mark (to detect whether the process has been successfully elevated), and the third parameter is passed in the TOKEN_ELEVATION structure object address, TOKEN_ELEVATION The structure is defined as follows:

typedef struct _TOKEN_ELEVATION {
    DWORD TokenIsElevated;
} TOKEN_ELEVATION, *PTOKEN_ELEVATION;

When the GetTokenInformation function returns, check whether the TokenIsElevated in the TOKEN_ELEVATION structure is non-zero. Non-zero means that the privilege escalation is successful, that is, the target process is running with administrator privileges.

       The relevant code to determine whether the target process is running with administrator privileges is as follows:

CString strTip;
DWORD dwPid = 14060; // 目标进程的进程id
HANDLE hProcess = ::OpenProcess( PROCESS_QUERY_INFORMATION, FALSE, dwPid );
if ( hProcess == NULL )
{
strTip.Format( _T("OpenProcess to get the process handle failed, possible reason: the process id doesn't exsit, GetLastError: %d"), GetLastError() );
AfxMessageBox( strTip );
return;
}

BOOL bRunAsAdmin = IsRunasAdmin( hProcess );
if ( bRunAsAdmin )
{
strTip.Format( _T("Pid(%d) run as admin!"), dwPid );
}
else
{
strTip.Format( _T("Pid(%d) don't run as admin!"), dwPid );
}
AfxMessageBox( strTip );

BOOL IsRunasAdmin( HANDLE hProcess )
{
    BOOL bElevated = FALSE;  
    HANDLE hToken = NULL;  

    CString strTip;

    // Get target process token
    if ( !OpenProcessToken( hProcess/*GetCurrentProcess()*/, TOKEN_QUERY, &hToken ) )
    {
        strTip.Format( _T("OpenProcessToken failed, GetLastError: %d"), GetLastError() );
        AfxMessageBox( strTip );
        return FALSE;
    }

    TOKEN_ELEVATION tokenEle;
    DWORD dwRetLen = 0;  

    // Retrieve token elevation information
    if ( GetTokenInformation( hToken, TokenElevation, &tokenEle, sizeof(tokenEle), &dwRetLen ) )
    {  
        if ( dwRetLen == sizeof(tokenEle) )
        {
            bElevated = tokenEle.TokenIsElevated;  
        }
    }  
    else
    {
        strTip.Format( _T("GetTokenInformation failed, GetLastError: %d"), GetLastError() );
        AfxMessageBox( strTip );
    }

    CloseHandle( hToken );  
    return bElevated;  
}

       We can first check the process id of the target process in the Windows task manager, then call the API function OpenProcess to obtain the process handle through the process id, and then pass the process handle to the function IsRunasAdmin encapsulated above.

6. Finally

       This article describes in detail the complete troubleshooting process of the problem, and expounds the content related to administrator privileges in the Windows system, hoping to bring some reference and reference to everyone.

Guess you like

Origin blog.csdn.net/chenlycly/article/details/128158192