End-User Furlough - ' 2 ' (
Page 2 of 4 )
DesktopStandards PolicyMaker Application Security 2.5 provides outstanding tools to help companies solve the problem of application compatibility in restricted desktop environments. However, the Microsoft Group Policy-based management structure could prove confining in large, complex domains, and the manual approach to finding and restricting applications could easily become unwieldy.
PMAS 2.5 presents a clean and elegant solution to the problem of getting legacy applications to work for users who dont have administrative rights on the desktop.
Rather than raising permissions via a "Run as" command that requires users to know and input an administrator user name and password, or requiring administrators to jury-rig file system and registry ACL (Access Control List) commands to get troublesome applications working, PMAS modifies an applications security token on the fly, elevating process permissions without altering the rest of the user session or security settings.
Click here to read about Microsofts recent bevy of security betas.
With great success, eWEEK Labs tested PMAS 2.5 against a number of applications known to founder without administrative rights. By simply adding the built-in administrator account to an application token via policy, we quickly were able to get Microsofts AntiSpyware Beta 1, various Lenovo ThinkPad management tools, Intuits TurboTax (and its AutoUpdate feature), Nero 7 Ultra Edition and an older version of Jascs Paint Shop Pro operational.
In each case, the application process is still owned by the user with restricted rights, but the local administrator rights were seamlessly added to the security token.
To define applications whose permissions we wanted to elevate, we could identify executables in several ways: by name; by folder; or, to ensure that an application had not been unexpectedly altered, by hash.
Getting Sysinternals DiskMon to work for a restricted user, however, required additional steps: We had to explicitly add Debug and Load Drivers privileges, but this was easily accomplished through the policy interface .
The PMAS management console is fully integrated into the Windows Group Policy management framework, and administrators may add PMAS policies to either User or Computer Group Policy objects . We simply installed the PMAS snap-ins, security driver and client-side extensions on our Group Policy management workstation, and the PolicyMaker license and configuration data was then automatically stored in the domain SYSVOL (System volume).
Administrators will need to deploy the security driver and client-side extensions to managed workstations to enable the workstations to see and execute PMAS policy, but PMAS includes a small MSI (Management System Information) installer package that can be deployed via Group Policy.
Our tests showed that there are both advantages and disadvantages to PMAS management being contained entirely within the Group Policy framework. Domain administrators already familiar with the ins and outs of Group Policy and the Group Policy editor (or the newer, more robust Group Policy Management Console) will be quite at home with PMAS management.
However, the Group Policy construct could limit flexibility in complex networks. Group Policies can be applied only to containers (the domain, site or Organizational Unit) or at the local machine (with the latter greatly complicating centralized management).
Unfortunately, application distribution likely will not mirror the Organizational Unit, or OU, container structure in Active Directory, as a user in accounting may need access to the same application as a user in human resources. To address this shortcoming, PMAS offers filtering capabilities, allowing administrators to limit policy execution to, among other things, certain Windows Security Groups.
Next Page: How it stacks up
