In addition to elevating the rights of privileged applications and administrative tasks, Privilege Guard (Edit: now Defendpoint) can empower users to install approved software. Although most organizations will have some form of centralized software distribution in place, packaging every application for distribution is not always economical and often unnecessary. With Privilege Guard you can easily complement your existing software distribution solution to enable standard users to self-provision any corporate approved software or if necessary give some users an even greater level of autonomy and audit their actions.
Although you can authorize individual software packages with Privilege Guard, it may be more appropriate to allow a group of users to install software from a network share, as this is extremely simple to set up and maintain. The users should only be given read and execute access to this share, enabling them to launch any software packages that are made available by the IT department. A couple of simple rules can be added to Privilege Guard to automatically elevate any executables or installer packages that reside in the shared folder.
You could easily extend this principle to be more granular, such as creating a set of folders within this share for different roles and then ensuring that the software installers are only elevated for the relevant groups of users.
This can be taken a stage further by blocking software installers for those users who should not have access to them. You can achieve this by adding a simple “catch all” policy to block all installations from the software share, which should be placed at the end of the policies and applied to all users (policy precedence will ensure that this policy will only match if a higher precedence policy has not matched first). A suitable message should be displayed to the user, with instructions on gaining access to the software, assuming they have a legitimate business purpose. You may optionally allow the user to email a request for an application or you can provide a hyper-link in the message that directs the user to an appropriate web site, such as a help desk portal.
You may need to allow some users to install authorized software directly from the internet. The recommend way to define policies for this purpose is to make use of the publisher rule, as opposed to the filename rule, and then combine this with other product rules, as required. For instance, we could allow the user to install all software signed by a particular vendor.
You could extend this rule to make it specific to a particular product by using the product name or product description, and you can optionally include a check for specific versions of the product or a minimum version.
In addition to elevating installation packages you can also specify rules to block the installation of software that you do not want users installing, as some software packages do not require administrative rights to be installed, as they install within the user's profile.
For users with more flexible requirements, you can create an “on demand” policy where users are trusted to make their own decisions on software installations. This should be configured with a custom message, to warn the user of their actions and ask them for a reason, which is then audited. You may optionally force a user to re-authenticate before installing the software to ensure that they self-approved the installation.
Even with an on demand policy you can still prevent these users from installing certain software packages, by creating a higher precedence policy that blocks the installation of any unauthorized software. Alternatively, you can delegate the on-demand installation of software to an appropriate group of staff, such as departmental heads, who would need to authorize the installation on the user’s behalf.
Privilege Guard can also handle the installation of ActiveX controls. For ActiveX controls, the primary rule to match on is the URL of the codebase. The URL can point to a specific codebase or a more general URL can be used to match multiple ActiveX controls hosted on a site. It’s a good idea to insert a catch all rule for ActiveX controls that blocks access to any ActiveX controls that have not been defined in the policy. This will provide the user with a corporate message and instructions on how they should request access to the blocked ActiveX control if they have a legitimate business reason for installing it.
As with “on demand” software installation, users with more flexible requirements can be authorized to install any ActiveX control. This should be configured with a custom message and audit trail, to ensure that the user is warned of their actions, and you may optionally force the user to re-authenticate. Remember that you can still block access to unauthorized ActiveX controls with a higher precedence policy.
The end user experience is a crucial element when allowing users to self-provision software, whether you are asking a user to justify their actions before proceeding, or blocking the installation of a software package and giving the user meaningful feedback and direction. Small touches, like strong corporate branding in end user messages, ensure that users pay more attention than when presented with a standard Windows message. You can define any number of end user messages in Privilege Guard, with corporate branding, multi-lingual configuration of all text elements and control over many other aspects, such as re-authentication and asking for justification before proceeding. It is always better to display a message that is relevant to a user’s actions, as opposed to a broad generic message, as this will lead to an improved end user experience and a reduction in help desk calls.