Wednesday, 9 December 2015

AppSense Application Manager Best Practices

This post contains best practice guidance for implementing Application Manager. It is not intended to be definitive guidance and should be used as a guideline for building and maintaining Application Manager configurations.

General Guidance

Keep the configuration as simple as possible... I cannot over-emphasise this enough. I've seen dozens of configurations where a customer has over-configured the product to the point where their support teams are unable to maintain the configuration. This leads to frustration and ultimately the customer has to face a choice... rip it out and start again, have expensive resource managing the configuration indefinitely or let their users suffer a bad experience indefinitely.

Effort up front will pay dividends...  putting in time and effort up front will help in the long term. The best way of designing and implementing an Application Manager configuration is by analyzing your estate as much as possible, then deploying a configuration which is auditing all 9000 events to the Management Center for analysis, to a manageable number of users. Following analysis, update the configuration and repeat. Yes, it is time consuming but will ultimately yield the best results.

Trusted Ownership... is not easy to implement particularly in a brownfield site BUT it is worth the effort. Files failing trusted ownership should be dealt with in one of the following ways:
  1. Modify the NTFS owner attribute to reflect a group that is on the trusted owners list
  2. Add the executable files vendor certificate to the trusted vendors list
  3. Potentially use process rules if the process is a child of another (e.g. ProcMon64.exe)
  4. Create rules targeting the specific files using meta data from the file


Group rules are typically the most frequently used rule for good reason. Targeting individual users will result in an extremely large and unmanageable configuration.

The Everyone Group should not be used for allowing access to items. Instead use this group for denying access to applications and then allow access for another group (e.g. Domain Users). The everyone group is a superset of the Authenticated Users group that contains both Authenticated Users as well as the Guest account.

Applications that require digital signatures (Hashes) should be configured to use a restrictive group that only contains users requiring access to that application. For example users that need access to SAP should be listed in an Active Directory group (e.g. SAP Users) and a group rule should be created for that group with only the application(s) listed with a digital signature. Once a digital signature is added to a configuration every application that is executed must be hashed and then compared to all rules within the configuration. In the event that an applications digital signature was listed in the Everyone group every application launch would have to be hashed and compared against the hash listed in the Everyone group. 

User Rules should be avoided wherever possible as these will over-complicate and bloat the configuration. Specific service accounts can be added if required. The most common example of this being implemented is where the Citrix Web Interface (Storefront) is installed on a XenApp server hosting applications or desktops. The Web Interface application pools typically run under a local user account however application manager may restrict the account as it would fall into the everyone group. In this instance a user rule can be created for that specific user account. 

Device rules are typically used for application requiring "Device Based License Control". Best practice is to use hostnames instead of IP Address, Group or OU Membership as these are easily spoofed or assigned dynamically. 

Scripted rules can be implemented to run complex Visual Basic or Powershell scripts to perform various conditions not found natively within Application Manager. The most common use case for this is evaluating a client or connecting device name against the contents of a text file to detemine whether the client can run specific applications. This is typically used for larger accounts where "Device Based License Control" is required but are unable to deploy a new configuration file each time a device is granted access to the application. Scripted rules are not re-evaluated mid session which means any changes (e.g. adding a device to the text file) require the user to logoff and log back on.

Process Rules are typically used to allow executables which call one or more child executables to run. Typically these child executables are created dynamically and are not signed nor owned by a trusted owner so typically these would be blocked. Using a process rule the administrator can whitelist the child application(s) thereby ensuring that the parent process can execute the child processes. When implementing Process Rules it is important to ensure the integrity of the parent executable. Only executables from known reputable vendors should be configured in this way as it could cause a system to be compromised if a malicious child executable is added to the whitelist.

Application Manager 10 will enhance the Custom Rules so that these can leverage a pre-defined number of Environment Manager conditions (e.g. Registry Value Exists, File Exists, etc) to allow administrators to configure fine grained Application Manager rules. Application Manager 10 is due to be released to market in CY2016.

Rule Items

When specifying file items within a rule Administrators should, wherever possible, browse to the file as this will populate the metadata fields with the correct metadata from the source file. In addition, the full path to the file should be specified to ensure maximum security. In addition, metadata should be added to rule items wherever possible and "Allow Untrusted Owner" should be avoided.

Remote File shares are blocked by default so always ensure accessible folder items are added for file shares (e.g. DFS Root, Home Drives, etc). As with file above, "Allow Untrusted Owner" should be avoided wherever possible.

Avoid implementing signature rule items unless absolutely necessary. When required, ensure these are configured for only the groups requiring access to the executable instead of a wide reaching group (e.g. Domain Users) as doing this will force every executable to be evaluated against the hash contained within the configuration which could lead to performance issues. An engineering key, EnableSignatureOptimization, has been added which will ensure that hash checking is only done if the full path to the file matches however this cannot be used in cases where signatures have been used to allow content from removable media as the drive letter will most likely be different.

User Rights

When configuring applications for user rights management, "Apply to Child Processes" and "Apply to Common Dialogs" should be avoided unless absolutely necessary. Implementing these could compromise the endpoint as they could be used to launch external processes with the administrative rights assigned to the configured application. For example, a user could launch an Administrative Command prompt and ultimately stop Application Manager with both of the options selected. 

Elevated websites should be restricted to only trusted internal websites that are regularly scanned and known to contain no malicious code. 

Critical Services (E.g. AppSense Application Manager, AppSense Environment Manager, Antivirus, etc) should be added to the System Controls list to ensure that they cannot be stopped or disabled by anyone other than System Administrators. 

Care should be taken when implementing self elevation and where required, ensure end users must enter a reason for elevation. Once configured ensure event 9023 is audited to the Management Center or another 3rd Party solution (e.g. System Center Operations Manager) and reported on regularly. This log could help drive future configuration rule items if a trend is spotted for certain applications. 

Self elevation should always be configured in a way that applications that could cause harm to the system are not elevated. These applications include, but are not limited to; CMD.EXE; REGEDIT.EXE; REG.EXE; FORMAT.EXE; etc. 


As with all best practice, it does not fit all scenarios. There are cases where elevating explorer.exe, for example, is the only way to achieve a specific goal. These should merely be used as a guideline where, in a perfect world, all would be adopted. 

If you would like to discuss any of the items above or have any items to add to the list please get in touch with me and I will gladly add them to the list.