Why Applications Don’t work for standard users


We have all seen it. You know what I mean! You have a computer where you have configured the user to be a standard user, instead of a local Administrator. Then, you install an application so that all users can run the application, only to find the application does not work for the standard user, only for the users configured to be a local administrator. You are not alone in this scenario! Home users, small businesses, medium sized organizations, and huge corporations are all fighting this dilemma. We all want our users to run as a standard user to protect the desktop, network, and servers, but some applications just don’t play well. Why is the case? What is causing the application to force the user to run as a local administrator? Here we will answer that!

Logon Token

The issue of the application failing to run for users that are not local administrators starts with the user logging in. When a user logs in to a computer the user must be authenticated. In our discussion here, let’s discuss a typical company environment where the user logs on to a desktop in an Active Directory environment. In this scenario, the user is authenticated by the domain controller for the Active Directory domain.

The user inputs the credentials: username and password. From the drop down list, the user must select the correct domain where their respective account resides. Once the domain is selected, the credentials are sent to the domain controller for authentication. Once the domain controller verifies that the username and password is correct, the domain controller will return, to the desktop, an authentication token. On this token is key information about the user for future access to files and running of applications.

By using a tool such as Process Explorer, you can clearly see what is on the authentication token. Figure 1 illustrates and example authentication token.

Figure 1: Authentication token.

You can clearly see on the authentication token the following information:

  • User name and user SID (security identifier)
  • Group names
  • User associated user rights (privileges)

System Folder/File Permissions

Every computer has different files and folders that are used. Most users store files in either their Documents folder or under “user created” folders, typically off the C:\ drive. Personally, I prefer to create a folder under the C:\ drive, which allows me to have better control over the documents no matter which user I log in with.

The computer and operating system on the other hand uses its own set of files. The standard computer has a suite of folders and files that are used by the operating system for the majority of the functions that it performs. The following is a list of common folders that are used by the operating system:

  • C:\
  • C:\Windows
  • C:\Program Files
  • C:\Windows\System
  • C:\Windows\System32

There are, of course, many other folders used by the system. These are just the most common folders that are on nearly every Windows computer.

If you look at the security of these folders, you will see a common configuration. For example, the security permissions on the C:\Windows\System folder are shown in Figure 2.

Figure 2: Permissions for the C:\Windows\System folder.

Notice that users do have access, but not for updating (Modify) the contents. Users can only run (Execute) contents within this folder. If you look at the other folders used by the system, you will find a similar pattern. If you were to look at the permissions for the administrator or Administrators group, you would see that it is this level of privilege that is granted Modify permission.

Registry Permissions

In a similar way that folders and files are protected for use by the operating system, the Registry is also protected. There are many different areas that are used solely by the operating system. There is one key part of the Registry which is dedicated to the operating system and its use.

  • HKEY_Local_Machine

You can see HKEY_Local_Machine and the subkeys which are included within the key in Figure 3.

Figure 3: HKEY_Local_Machine and subkeys

Every key in the Registry has a list of permissions associated with it, similar to folders in the file system. These permissions control which users and groups have access, as well as define the access. At the root of the HKEY_Local_Machine key, the permissions are as shown in Figure 4.

Figure 4: HKEY_Local_Machine permissions.

Clearly, you can see that the Registry is protected from users. Users only have Read permission, where Administrator and Administrators have Full Control so that changes can be made to these locations in the Registry. Users have Full Control access to their own portion of the Registry, which is typically limited to HKEY_Current_User.

User Rights

Not only do files, folders, and Registry keys have protection, the entire computer is protected as well. This protection of the computer is handled by User Rights. User Rights are configurations that limit what a user can do to a computer. Examples of User Rights are shown in Figure 5.

Figure 5: User Rights as listed in Group Policy.

Most User Rights that alter the condition of the computer are limited to only administrators. This might be the altering of the clock, backing up of files, installing drivers, etc. The only way a user can perform many of the tasks that are associated with User Rights is to have their name or a group they are assigned to be included in the list of User Rights. Without them, the user will not be able to perform that task.

What Is The Issue Then?

Well, when a user logs on with limited privileges, which are detailed on their authentication token, that token limits them to the rest of their time when they are logged on to the computer. The token and the entries on the token are compared to the file, folder, and Registry permissions at the time the user or application attempts to access that resource. If the level of access needed to perform the action is not granted for the permissions, the user is denied access.

For example, many applications require that the user create temporary files in order for the application to run. If the application needs to create this file under the C:\windows\system folder, the user does not have the correct permissions and will therefore receive an “Access Denied” error, or an error indicating that the user needs to be a local administrator in order to run the application.

It is the same thing for actions that require User Rights. Since User Rights are listed on the authentication token, any action the application needs a User Right for and the logged in user does not possess those User Rights, the action will be denied.


You can clearly see that permissions and privileges are key for users to perform certain tasks on a computer. When an application runs, the application needs to access certain files, folders, and Registry keys. The application might also need to perform an action on the computer, such as installing a driver, which requires elevated User Rights. If the user does not have the correct level of access, the user must: be included in the local Administrators group, be added to the permissions, or have a tool in place which can elevate them automatically. Without a solution like this, the applications just won’t run for standard users!

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top