AutoElevate

It would be nice if AutoElevate would be able to indicate that there was a possibly dangerous rule that was created. For example, if someone created a rule to allow the cmd prompt at the global level. That might be something that could be "flagged" and filtered by so that someone could check into it and change it if necessary.

We have some clients who exclusively use Azure joined devices and use Windows Hello for logins which overrides the UAC prompts to ask for Windows Hello. As more and more clients/companies are moving to cloud-based systems, we need Windows Hello to be able to work as it currently fails and locks the user accounts out.

From the "elevation events" page, there should be an indication that a rule has already been created from that specific event. Otherwise, you have multiple people that could be wasting time creating the same rule from the same event. This should be as easy as indicating with a field/column of "Rule created" (yes/no) or a visual indication like a green/red dot or a hover-over fly-out that says "rule created".

It would be nice to have temporal controls on rule creation. E.g., An user is cleaning up their installed programs - allow access to appwiz.cpl for 3 hours. Upon expiration the rule is deactivated or deleted entirely

It's currently only possible to give admins access to an entire company instead of a just a single (or multiple) locations/sites within a company.

Allow the click-through of dashboard graphs to see the underlying data.

We’ve identified an issue with the AutoElevate setting “Agent Security – Remove Admin Privileges” on Windows Home Edition systems. When a user account is removed from the local Administrators group, the user can become locked out of the computer. This occurs because, on Windows Home Edition, local administrator accounts are not members of the local Users group by default. As a result, once AutoElevate removes the account from the Administrators group, the user may no longer belong to any local groups. To prevent this scenario, it would be beneficial for AutoElevate to verify that a user is a member of the local Users group when removing them from the Administrators group, and automatically add them if they are not already a member.

We are experiencing a high volume of elevation requests related to shpafact.dll (identified as “Virtual Factory for Windows Defender Firewall CPL”), which appear to be triggered indirectly by various parent processes across different applications. 1 Currently, each of these requests must be reviewed and approved manually, resulting in a significant operational burden and increased technician workload. 1 Requested Enhancement We would like to request more granular rule criteria options to reduce unnecessary elevation prompts while maintaining security integrity. Specifically: Ability to create elevation rules based on parent process Support for rule conditions such as: Command-line arguments Event title File description Context-aware elevation rules that allow controlled approvals without broadly approving a DLL globally Business Impact Without these capabilities: Technicians must repeatedly investigate similar elevation events Productivity is reduced due to manual approvals There is increased risk of either over-approving or delaying legitimate operations Desired Outcome Providing more flexible and context-aware elevation rule options would: Reduce repetitive approval workflows Maintain strong security controls Improve operational efficiency for managed environments

There needs to be detailed reporting that indicates how many elevation events/requests/rules were created and used PER COMPANY and PER COMPUTER. This should be able to be filtered by time period. The report should also indicate other details such as event/rule percentage, which computer/user is creating the most events/requests, overall elevations per application, etc. This goes for Blocker as well.

Fromm original feature request: "Count of how many times a rule has been "used" in addition to a "Date last used" column. This will help to know when a rule is no longer applicable to a "company" and should be removed." Additional votes: 3