AutoElevate utilizes 3 different methods of elevation in Windows – Admin, User, and System elevation.
The elevation type affects the ‘context’ of what each application has access to (or doesn’t have access to). This would include mapped or network drives, network resources, file shares, cached settings, user desktops, application customizations, and personal settings etc.
By default, the agent elevates approved applications and features using “Admin Elevation”. When something is being launched from a network resource (file share), it will automatically switch to “User Elevation”, and “System Elevation” is currently used as a fallback in case the other elevation methods fail. Rules can be set to use the Elevation Type of your choice which may be desirable in certain circumstances or use cases.
Admin Elevation
- What is it?
- The default elevation type that is used automatically for any approval. Additionally, it will automatically be used for all CLSID (COM object) approvals.
- How does it work?
- It inserts Admin credentials (the local ~0000AEAdmin user is utilized) into the UAC dialog box so that the program’s execution is not interrupted and will also run with the context of the Admin user (previously referred to as “password mode”).
- If for some reason this method is not possible, the agent will automatically attempt elevation as the System (using token elevation - the old default elevation method).
- It inserts Admin credentials (the local ~0000AEAdmin user is utilized) into the UAC dialog box so that the program’s execution is not interrupted and will also run with the context of the Admin user (previously referred to as “password mode”).
- Why is it beneficial?
- Many requests for elevation do not happen immediately when a process is launched and therefore, dismissing the UAC and trying to launch the process again with an elevated token just simply doesn’t work. Many times, it results in program errors and a frustrating experience.
- In addition, many Windows features use CLSIDs (COM Objects) that cannot be relaunched with the user’s intent, therefore it’s best to simply let the UAC “do its thing” and supply it with a username/password so that it can properly launch what the user was intending.
- Many requests for elevation do not happen immediately when a process is launched and therefore, dismissing the UAC and trying to launch the process again with an elevated token just simply doesn’t work. Many times, it results in program errors and a frustrating experience.
- How can I use it?
- It is set by default, but if you have an existing Rule set to “User Elevation”, you can set it back to “Admin Elevation” by using the corresponding Action in the Rules grid.
- It is set by default, but if you have an existing Rule set to “User Elevation”, you can set it back to “Admin Elevation” by using the corresponding Action in the Rules grid.
User Elevation
- What is it?
- An alternate elevation type to be used for cases where the application needs to run in the context of the user who made the request. It will automatically be used by default for all approvals for applications coming from a network resource.
- How does it work?
- It promotes the role of the requesting User to an Administrator specifically for the elevation of the requested application and then automatically inserts the user credentials into the UAC dialog box. Immediately after elevating the requested application or feature, if needed, it will then demote the role of the User back to a Standard user.
- Why is it beneficial?
- This ensures that the elevation process avoids problems due to access restrictions for the ~0000AEAdmin user to the network resource. In these cases, the app would elevate, but the user would be prompted for a network credential. This could result in the user becoming confused or thinking that elevation hasn’t happened successfully.
- Some applications that require Admin privileges and are run by the user on an ongoing basis, need to run as the logged in user to retain custom settings, cached preferences, application customizations, or will access resources that are specific to the user. (i.e. Visual Studio, Autodesk AutoCAD, etc.)
- Some applications need access to network mapped drives, printers, file shares, or other network resources.
- IMPORTANT: When “User Elevation” occurs for the 1st time for any given user, the agent will prompt the user to enter their password (as seen below) which is then stored securely in Microsoft’s “Windows Credential Manager” for future use in the automated elevation process. This password remains only on the local machine and is never sent over the network or internet and is not stored on AutoElevate servers. Below is a screenshot of what this dialog looks like:
- This ensures that the elevation process avoids problems due to access restrictions for the ~0000AEAdmin user to the network resource. In these cases, the app would elevate, but the user would be prompted for a network credential. This could result in the user becoming confused or thinking that elevation hasn’t happened successfully.
- How can I use it?
- It can be set for an existing Rule using the corresponding Action in the Rules grid.
- It can be set for an existing Rule using the corresponding Action in the Rules grid.
System Elevation
- What is it?
- Elevation type used to relaunch an application with an elevated token that is in the context of the System.
- How does it work?
- The agent first dismisses the UAC, typically causing the target application to quit or error out. It then locates the executable of the application and any arguments that were being passed to it and launches the executable as a new process with an elevated System token.
- How can I use it?
- Currently, it cannot be set explicitly. If in the very rare case that one of the other elevation types fail, System elevation will be used as a fallback.
Comments
0 comments
Article is closed for comments.