DABCC Radio Podcast: AppSense User Rights Management!

October 26, 2010

AppSense has further enhanced our world leading ‘User Virtualization solution, adding the much awaited User Rights Management functionality.  Doug Brown has posted a Radio Podcast interview, details below:

In episode 141, Douglas Brown interviews Simon Rust, Vice President of Technology at AppSense. Simon and Doug discuss new AppSense User Rights Management technology available now as part of AppSense Application Manager 8.1. Simon does a great job explaining what is it, how it works, what is takes to install, why we should care, and much more.

User rights management benefits users by:

  • Elevating user privileges for running applications – by specifying applications to run with administrative privileges. This enables the user to be removed from the local administrators group, thus removing the risk of all applications executing under the administrative user context.
  • Organizing user rights for running control panel applets – by allowing a standard user to make the required changes and complete their job tasks without running as a local administrator. This is extremely useful when users need to change printer, wireless network, time and date settings, etc.
  • Prioritizing user rights to restrict application rights – by enabling system administrators to set and enforce policy for specific applications so that the user runs as an administrator but other applications are forced to run as a standard user, ensuring security is not compromised.
  • Managing access to system settings – by permitting system administrators to prevent admin level users from changing configuration settings that can expose enterprises to new security concerns such as security or firewall settings.
  • User rights management is available now as part of AppSense Application Manager 8.1.

To listen to the Podcast, please click on the image below or use this link here

 

A special thanks to Doug for taking the time to record and post this Podcast, thanks buddy :)

We hope you enjoy it…

Thanks

Gaz




The case of the failing signed driver install

February 11, 2010

I was asked recently to look at a couple of support cases that had been logged where installations of our Application Manager and Performance Manager products were failing. The logs from the failed installations, obtained from invoking msiexec with the /l*vx syntax, gave the following error:

(Error code 0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.)

A web search for the error gave many matches which didn’t really help so I then tried to reproduce the error in a Windows Server 2003 x86 virtual machine but the installation worked fine, as it usually does. Analysis of the msiexec log from the failing system indicated that the error was occurring when installing our signed device drivers. So next I ran the great Process Monitor tool from SysInternals, now Microsoft, to try and understand what was happening, file system and registry wise, during the installation, particularly around the area where the msiexec process installs the device drivers.

What this showed me was immediately before our driver catalog (.cat) file was read, the “State” registry value in the following key was being read:

HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing

Given the error text from the failed installation, this looked relevant. A quick web search threw up a number of interesting articles, namely:

http://msdn.microsoft.com/en-us/library/aa388201(VS.85).aspx

and

http://blogs.msdn.com/spatdsg/archive/2006/06/05/618082.aspx

which led me to try changing the “state” value in the registry in my test VM from 0x23c00 to 0x40000  (WTPF_ALLOWONLYPERTRUST as per the MSDN link above and the wintrust.h header file so effectively much more restrictive than what was in this value by default).

Retrying the previously successful installation in my test VM then gave exactly the same error that our customers had been experiencing. On passing this information on, both customers confirmed that their “state” registry values were either not as per the default or were missing, due to the parent key being absent, and that setting the “state” value to the default allowed the drivers to be successfully installed.

Case(s) solved! But this leaves me with the desire to know what caused this to happen, particularly as we have had two cases from different customers logged so closely together, given that I stopped believing in coincidences many years ago. This is the main reason for me blogging about this issue – I hope that by the power of search engine indexing that if others suffer this issue then they will be brought here and their problem solved.

Guy Leech

10th Feb 2010