Frequently Asked Questions (FAQ)

The process of creating a list of applications and allowing only those to run is called as application allowlist. Application Control enables allowlist creation on the basis of policies like vendor, product name, file hash and executables with valid digital signatures. IT admins can easily manage the lists created as applications will automatically get added to them, as and when they are discovered, if they comply with the policies set.

The process of creating a list of applications and prohibiting only those from running is called as application blocklisting. Application Control enables blocklist creation on the basis of policies like vendor, product name, file hash and executables with valid digital signatures. IT admins can easily manage the lists created as applications will automatically get added to them, as and when they are discovered, if they comply with the policies set.

All the applications that are clustered together to build either a allowlist or a blocklist, will be considered as an application group. These groups will be automatically built based on the rules you set for each of them.

Application control requirements and approaches vary from enterprise to enterprise. Refer Application Control Best Practices to understand the recommended routine.

In cases of less stringent application control requirements, both certified and uncertified applications from specific vendors are displayed. Admins can selectively add chosen vendors applications to the allowlist/blocklist, minimizing access issues and streamlining management. This feature enables broad parameter-based list creation, enhancing administrative control.

If you want to allowlist/blocklist only certain products from the same vendor, this type of policy can be opted for instead of the vendor rule.

Applications are made of multiple executable files, with vendors assigning a digital certificate to each executable to vouch for its authenticity. Application Control Plus displays these verified executable files to you, from which you can select the EXE files to be allowisted/blocklisted. This policy is critical when it comes to maintaining a secure network, as a file will not be allowed to execute if its digital certificate has been tampered with. Even EXEs added to applications in the form of updates will not be allowed to run if they aren't allowlisted.

This is the most secure policy, as it's based on the hash value of the executable file. All EXEs of the running processes, including those that don't have a valid digital certificate, will be displayed. You can choose all the files that you wish to allowlist/blocklist; after that, even the smallest change to the file, such as a revision of the file's version, will change its hash value, meaning the file will be removed from the list. This policy is perfect if you want to run only extremely specific executables.

In case you want to add an application which hasn't been run yet to a allowlist/blocklist, you can opt to manually add the files.

Application Control does an all-inclusive job when it comes to application allowlisting and blocklisting. Built-in with leading Endpoint Privilege Management capabilities, it ensures that it protects organizations from most application-related threats. Endpoint Central's Block Executable feature on the contrary is rudimentary and is aimed to help organizations with maintaining their levels of productivity.
Application Control instantly discovers and displays all running applications and categorizes them based on their vendor, product name, folder path and digital certificates. Applications running specific to a group of users can also be filtered and viewed. Necessary apps can simply be selected and added into allowlists/blocklists from the list displayed. Endpoint Central's Block Executable feature has no options to filter and categorize applications, the IT administrator must manually enter the name of the application and executable that he wishes to block.
Allowlists and Blocklists can be created on both broad and granular levels by leveraging the predefined set of rules that Application Control has to provide. Rules based on Vendor, Product Name and Folder Path can be opted for when organizations are just beginning with their control process, as they are flexible with the changes that occur during patching. The Verified Executable and File Hash rule can be chosen by experienced networks that prefer complete security. Endpoint Central's Block Executable feature, however, allows blocklisting based only on two rules, Path and Hash. With no added capabilities to manage patching changes, IT administrators will have to manually update these lists after every patching cycle.

After selecting the rule of your choice, navigate to the Filters tab on the right. You can check if the Vendors/Product/EXE is verified or not by using the Publisher Credibility filter.

Blocklists will always take precedence over allowlist. In this case, all Products from the Vendor will remain blocklisted, including the one added to the allowlist.

Adding a single rule that is satisfied by the application is sufficient.

Yes, by allowlisting a Vendor you will allowlist all Products from them.

This rule can be used to allowlist/blocklist all files from a particular folder or folder path.

Users who require similar groups of applications can be clustered together to form Custom Groups. This grouping process can be based on roles, departments or any other criteria of your preference.

The two flexibility modes available are audit mode and strict mode. It is recommended to initially deploy policies in the audit mode, where unmanaged applications will be allowed to run along with the allowlisted ones. Once the admin has a clear picture of the applications their users actually require, they can move all of them to a allowlist and shift to the strict mode. In the strict mode none of the unmanaged applications will be allowed to run.
Note: By default blocklisted applications will not run in any of the modes.

If the same application is present in different allowlist and blocklist policies deployed to the same target group, here is the order of precedence that will be followed:
 
Blocklisting using Filehash Rule > Allowlisting using Filehash Rule > Blocklisting using Verified EXE Rule > Allowlisting using Verified EXE Rule > Blocklisting using Product Name Rule > Allowlisting using Product Name Rule > Blocklisting using Vendor Rule > Allowlisting using Vendor Rule

All Windows functionality that comes in-built with the Operating System are automatically allowlisted. Application Control will be enhanced with the option to block these apps in the future.

Unmanaged applications are those that exist in a network without being a part of any of the allowlists or blocklists created. This essentially means that these applications are unmonitored, as they have no policies associated to them. They will run based on the mode of flexibility chosen, i.e they will run when in audit mode and will be prohibited in strict mode. Please note that it is ideal to minimize the number of unmanaged applications to ensure maximum security. Learn more.

• If your Build version is 676 or below, applications will be displayed in the Unmanaged Application list only after they have been executed in the computers atleast once.
• If your Build version is 677 or above, applications will be displayed in the Unmanaged Application list as soon as they are detected in the network i.e if they haven't been added to a allowlist or blocklist deployed prior to this. Unmanaged application data is usually collected from the computer only after at least one policy is deployed to it.
• If applications are still missing from the Unmanaged Application list, kindly upload the server logs, agent logs and all the contents from the\appctrl\data folder of affected machines for us to analyze.

While deploying a policy in strict mode, it can be configured to permit user requests by enabling the option 'Allow users to request applications which are unmanaged'.

Endpoint Privilege Management is the process of allocating application-specific privileged access to users based on their requirements. You can easily adopt the principle of least privilege through out your network, without it affecting your productivity using this feature. It enables privileged access to applications without compromising the privileged credentials or any unnecessary privilege elevation.

Using the Endpoint Privilege Management feature, you can elevate application specific privileges of certain users, without compromising the privileged credentials or elevating their entire organizational level privileges.

The 'Run as ManageEngine' option is displayed to standard users whose endpoints were added to Custom Groups that were associated with the Privileged Application List during policy deployment. By selecting this option, the standard users can run said applications as administrators without entering any extra credentials, even while they remain as standard users with minimum privileges.

These are the suggested resolution techniques:

• Only allowlisted applications can be elevated, even if present in the Privileged Application List otherwise. Check whether the application in question is allowlisted to the target user-device.
• Ensure that you have checked 'Yes' for the Associate Privileged Application List option during policy deployment.
• Only standard users can access applications with elevated privileges using the 'Run as Manageengine' option. Other administrators will have to use their credentials as usual, even if the Privileged Application List is associated with them. Lowering their privileges to standard user type can remedy this.
• Modify the Privileged Application List by enabling elevation to "All allowlisted application", this might act as an intermediate fix. Also try testing elevation of other applications in the endpoint to assess the extent of the issue.
• If nothing works, you can upload the agent logs from the "C:\Program Files (x86)\DesktopCentral_Agent(or UEMS_Agent)\logs" for us to analyze. Specifying if only a single application has the issue or if it is prevalent with all apps can help us fix it sooner.

Allowisted applications that are added to the Privileged Application List, can be accessed with elevated privileges by the user-devices that are present in the custom groups associated with them. Even standard users can access applications as administrators using this feature, as it elevates the privileges specific to the application and not the user.

No, they have to be allowlisted for them to executed.

User accounts in computers can be classified as standard user accounts and local admin user accounts. Local admin accounts enable users to accomplish management activities on their local computers, whereas standard user accounts grant minimal to no management privileges. Here are a few capabilities that local admin accounts possess:

• Installing and uninstalling any software
• Adding or removing devices like printers
• Creating, deleting or modifying files, folders, and other computer settings
• Creating accounts for other users on the computer

Windows machines come with built-in administrator accounts. They can be used to set up other standard user and local admin accounts initially. These accounts also have privileges similar to the local admin account. However, unlike local admin accounts, they can never be deleted from the machine, only disabled.