UAC and administrator privileges for a program are easy to set by understanding the simple process of the UAC.
On a system with activated UAC every application run without administrator rights, even though you are logged in with an administrator account.
The application can only run with administrator rights if the application request elevated privileges in its own source code
or the logged in administrator start the application with the additional command run as administrator.
In both cases the System send an UAC dialog where you have to confirm this request.
There are a lot of reasons why to run an application as administrator in Windows.
In all cases you have to be a member of the group administrators and the appropriate program have to request elevated rights.
In spite of many reasons, there are only few moments in few applications you really need this rights.
For everyday work you need only be a member in the group standard user, because no changes on the system settings are necessary.
Nevertheless a lot of users working daily with an administrator account in order to call this few programs or its functions directly.
This often usage of that privileged account can be easily discovered to manipulate the system.
It is missing an option to give a specific program privileges, like you can do it with a user account.
A user then doesn’t need administrator rights to call these programs with administrator rights, because the application itself has already that right.
Work daily with an administrator account open attackers to manipulate the system.
Therefor Microsoft implements the User Access Control UAC to ask these administrators in an UAC dialog, if they really want to start a program that need system rights.
The principle works, because since the beginning of the UAC all software developer must implement in their source code to ask the UAC for elevated rights if it is needed.
If the software developers don’t do it, there is no UAC warning dialog for the administrators, their program will not run with elevated administrator rights and a simple setup routine of their software doesn’t work.
It is still possible for the administrators of the computer systems to run this program with administrator privileges, but he must request explicit elevated privileges from the UAC for this software.
This is necessary if the developer of the software forgot to do this, the software is developed before the UAC, but in most cases it is necessary for applications you need the option to run it without and with administrator rights.
Best example is the command line cmd.exe or a batch file. Sometimes it needs elevated privileges for some commands in it but only in a few cases.
Therefor the cmd.exe or a batch file doesn’t request elevated rights and it is the job of an administrator to give it the rights if it is needed and not the job of the developer of the cmd.exe.
This point and other reasons make the UAC to a security instrument which is often misunderstanding. But a wrong understanding of security instrument is a security whole.
Normally the User access control can’t bypass directly. If it would be possible to bypass the UAC, each malware could use it for an attack and the UAC has no longer any sense. An outcry from all security experts, that fundamental component of Microsoft's overall security vision is dead. But there are some options the administrator of the system can bypass the UAC
On a system without UAC the differences are clear. A standard User logs on with a standard user access token, has limited rights and can’t change system settings. An Administrator logs on with an administrator access token, work with elevated rights to configure the system.
On a system with an active UAC is the differences complicated and not clear anymore, because an administrator logs on with a standard user access token and an administrator access token which is not active. Three conditions must be met to be an administrator
For any suggestions, errors, questions, specific requirements or adjustments please contact: