Limiting permissions so applications -- and their users -- can work in a safe, secure environment is a primary objective of Altiris' Application Control Solution. But how much is too much? Can limiting an application, like Outlook, create more grief than good?

Support Engineer Darin Bunker shows us how to walk the fine line between application control and chaos.

• Issues Discovered While Limiting MS Outlook Permissions
• Possible Error Messages when Reducing Outlook Rights and Privileges
• Possible User Profile Corruption
• Users Permissions Granted via Group Permissions
• Tools Used to Diagnose and Resolve Rights Issues
• Step-by-Step Rights Resolution
• Conclusion

Application Control - Limiting MS Outlook Rights

Application Control Solution provides administrators a powerful tool in protecting the computers they manage by limiting the rights of MS Outlook while running under administrative privileges on Windows XP or Windows 2003. However, once you implement reduced privileges for administrators running Outlook you potentially open the flood gates to a vast number of issues with privilege and the associated profiles that were previously left unchecked since they were always accessed with administrative rights and permissions.

Before Application Control was implemented into an environment where users ran as administrators an analogy can be made to the organization and structure of the old west back in the 1800s. Like many settlers and ranch folk, user privilege and profiles did what ever they wanted having administrative privileges to affect any part of the operating system. Introducing Application Control is like the having new law enforcement in town who takes on the role of enforcing laws and civility. However, enforcing user privilege also produces issues with assigning and maintaining appropriate security configurations that are part of the growing pains of a secure environment.

It should be noted that MS Outlook has been designed to be able to run under either user or administrative privilege, this means that any issues or errors derived from reducing administrative rights on the Outlook process are issues with configuration of user objects and not necessarily that Outlook requires higher rights to function. This document will describe common errors and permission issues that can occur when user profiles and objects are not correctly configured with necessary rights and privileges to the machine. Additionally, a step-by-step process for diagnosing the issue and implementing fixes are provided.

Issues Discovered While Limiting MS Outlook Permissions

Since Application Control reduces the process token provided to Outlook from its parent (usually the desktop) by removing administrative rights, there are a number of permission issues that can arise. These issues relate to all necessary processing that the Outlook application executes on the machine. This means that any process or application that Outlook launches (including add-ins) will also be launched and run under the reduced privileges from Outlook.

Possible Error Messages when Reducing Outlook Rights and Privileges

The following list details those possible errors and message pop-ups that users will see that can be explained by insufficient rights to the application files, directories and registry settings:

• File access is denied. You do not have the permission required to access the file….outlook.ost.
• Cannot start Microsoft Outlook
• Unable to open your default email folders
• An extension failed to initialize. Can't open file:…
• Word cannot save or create this file. Make sure that the disk you want to save the file on is not full, write-protected, or damaged. (This may appear if MS Word is used as the email editor for MS Outlook)
• Make sure you have the appropriate permissions to access the following registry key:…
• Outlook experienced a serious error the last time the add-in 'add-in name' was opened. Would you like to disable this add-in? To reactivate this add-in, click About Microsoft Office Outlook on the Help menu, and then click Disabled Items.
• The server {…..} did not register with DCOM within the required timeout

Possible User Profile Corruption

Over time user profiles can become corrupted and cause irregularities with permissions and access to profile files and objects. If the user's profile has been corrupted and is causing issues with other functionality of the user experience, then these issues will also cause problems when Application Control reduces the rights to the Outlook process. Generally, fixing the corrupted user profile or creating a new profile should also address access issues to user objects.

Users Permissions Granted via Group Permissions

Previous to the Windows XP operating system, when users who were part of the administrators group would create objects, files, folders or registry keys the rights and ownership for those objects would be granted to the administrators group on the computer and not necessarily to the user who created them. This meant that gaining access to any file created by a specific user, while being an administrator, could only be accessed if the user was part of the administrators group.

Furthermore, as these profiles from previous versions of Windows were converted and moved to newer Windows operating systems, such as XP, the rights to the files, folders, and registry settings retained access and ownership to the administrators group and not the user themselves.

This method of granting access to the Administrators Group and not the logged-on user is a problem when Application Control removes the administrative rights of the Outlook process token. With a process token given to Outlook by the parent object with reduced rights and permissions every action taken by Outlook would then be based on a user privilege request and not an Administrators Group privilege request. Therefore, if the logged-on user did not have ownership rights or access rights based on user privileges then access to those objects would be denied by the operating system.

There are two areas where access is required for all logged-on users. First, the user should have complete access to their own profile, usually stored in the "Documents and Settings" folder under their username. Secondly, the user should have complete access to the HKEY_CURRENT_USER hive in the registry. To remediate this issue, all user profile object permissions (including registry) need to be adjusted to allow for the specific logged-on user, either with administrative or user privilege to access the files.

Tools Used to Diagnose and Resolve Rights Issues

There are several tools that can be implemented to help in finding and diagnosing the permission issues with Outlook. The following list details the tools that will be discussed in this document:

• Windows Explorer. This will be used to view files and folders as well as the security/permissions assigned to them.
• Registry Editor (regedit.exe). This will be used to view registry keys and the permissions assigned to them.
• Filemon. This tool from Sysinternals will be used to view the file operations performed by Outlook when loading and running.
• Regmon. This tool from Sysinternals will be used to view the registry operations performed by Outlook when loading and running.
• SubInACL (SubInACL.exe). This tool is provided by Microsoft to allow administrators the ability to adjust user privileges from a Command-Line interface.

Step-by-Step Rights Resolution

For the most part the errors seen when reducing the administrative rights on the Outlook process can be grouped into two issues:

• Outlook won't start or Outlook basic functionality doesn't work
• Add-ins in Outlook are disabled or not functioning

These errors are either manifested to the user at the time of launching Outlook or can be found in the Event Logs of the system. The following steps will provide resolution details for both groups:

1. Outlook won't start or Outlook basic functionality doesn't work. This could mean that users can't open attachments, attach files to emails, or can't download pictures from emails received. These issues are indicative of the logged-in user not having appropriate access to Outlook files and settings. The following steps will walk through both manual and scripted resolution steps:
   1. The first step in troubleshooting is to re-produce. Re-produce the issue to confirm the details of the issue or error.
   2. Confirm that Application Control is causing the issue. To ensure that reducing the rights to the Outlook process is causing the problem, close Outlook, stop the "Altiris Application Control" Service and re-produce the issue identified. If the issue persists with the "Altiris Application Control" service off then the issue is not with Application Control or the limiting of rights to the Outlook process.
   3. If the issue still persists, adjust user rights and permissions on user profile objects and registry settings.
      1. Adjust Manually
         1. Open Windows Explorer and navigate to the user profile.
            

            Figure 1

            Click to view.
         2. Right click on the profile and select properties.
            
            

            Figure 2

            Click to view.

         3. Click on Security tab. If the user is not listed in the "Group or user names" box, click on the Add button to add them and enable "Full Control" in the Permissions box in the bottom pane for the added user.
            
            

            Figure 3

            Click to view.

         4. Next click on the Advanced button. This configuration screen allows permissions at the root to be forced down to all child objects. This is necessary since over time child objects can loose their settings derived from the parent objects. Check the box "Replace permissions entries on all child objects with entries shown here that apply to child objects". Then click "Apply".

            This action will take the settings shown in the "Permission entries" grid and apply them to every child object. This means that the user added will then be associated with security rights to all profile objects.

            

            Figure 4

            Click to view.

         5. Next step is to configure the registry. Click "Start", "Run" and type regedit.exe and then "OK". Navigate to "HKEY_CURRENT_USER" registry hive and right click and select properties.
            
            

            Figure 5

            Click to view.

         6. If the user is not listed in the "Group or user names" box click on the Add button to add them and enable "Full Control" in the Permissions box in the bottom pane for the added user.
            
            

            Figure 6

            Click to view.

         7. Next click on the "Advanced" button. This configuration screen allows permissions at the root to be forced down to all child objects. This is necessary since over time child objects can loose their settings derived from the parent objects. Check the box "Replace permissions entries on all child objects with entries shown here that apply to child objects". Then click "Apply".

            This action will take the settings shown in the "Permission entries" grid and apply them to every child registry object. This means that the user added will then be associated with security rights to all registry objects in the HKEY_CURRENT_USER hive.

            

            Figure 7

            Click to view.

      2. Adjust via Script (using Microsoft utility SubInACL.exe)

         Microsoft has developed a command line tool (SubInACL.exe) that provides the ability to adjust the security settings to the user profile and current user registry permissions. To obtain this tool and for more information, see the Microsoft Download Center.

         After downloading and installing SubInACL.exe, open a command prompt window and navigate to the location of SubInACL.exe. The following commands need to be executed with the target user logged in:

         • Subinacl.exe /subkeyreg HKEY_CURRENT_USER /grant=%USERDOMAIN%\%USERNAME%
         • Subinacl.exe /subdirectories "%USERPROFILE%" /grant=%USERDOMAIN%\%USERNAME%

         Note
         Note: This tool gives administrators ability to create a batch file that can be used for easy distribution to affected users.

   4. If the issue persists, it might be necessary to adjust privileges and rights to objects in other locations within the file system.

      When a profile is converted or transferred it is possible that the existing Outlook OST files could be left in the previous profile folders. Since the steps outlined above provide adjustment of rights to current profile locations the changes would not alleviate permission issues of the previous location profile objects. To determine if any other files or registry objects are still having security issues, perform the following:

      1. Start Filemon.exe for logging of file access.
      2. Start Regmon.exe for logging of registry access.
      3. Attempt to start Outlook.
      4. Review the Filemon log and search for "Denied". For each object found denied adjust the privileges as outlined above.
      5. Review the Regmon log and search for "Denied". For each object found denied adjust the privileges as outlined above.
   5. Ultimately, if the issue continues to persist after adjusting permissions as outlined above it may be necessary to recreate the user profile or reinstall the operating system.
2. Add-ins in Outlook are disabled or not functioning.

   The Outlook process is responsible for launching add-ins associated to the application. One of the ways that the Outlook process launches add-ins is through the use of DCOM. The DCOM service (DCOM Server Process Launcher) provides launch functionality for DCOM services. If the Outlook process, with administrative reduced rights, attempts to launch a DCOM service it is possible that insufficient privileges will cause Outlook to hang or throw an exception message to the user.

   Further investigation into this issue noted that if the Outlook Add-in process was already launched at startup and existing in memory, then DCOM not recognizing the existing full administrative rights Add-in process would attempt to launch a duplicate instance of the Outlook Add-in with the reduced rights of the process token from Outlook. Having the Add-in launched at startup is generally the case when installing a new Outlook Add-in since most application installs place a shortcut in the Startup folder of the Start menu to ensure that the application is launched each time the computer is rebooted.

   To remediate this, a second Application Control Policy should be implemented to reduce the rights of the add-in process each time it is executed. This additional policy will ensure that each time the add-in is launched either by rebooting or through the Desktop (Windows Explorer) the process will have its rights reduced and thereby Outlook, via DCOM, will be able to recognize and utilize the existing Add-in process.

   The following steps will guide through creating a new Application Control Policy for an Outlook add-in:

   1. Launch Altiris Console and navigate to the Application Control Solution.
   2. Create an Application Filter for the add-in. Navigate to:
      1. Tasks
      2. Windows
      3. Application Control Tasks
      4. Application Filters
      5. Right click on Dynamic Filters
      6. Select "New" and then "Win32 Executable File Filter"
      7. Complete the Filter information and click "Apply"
         
         

         Figure 8

         Click to view.
   3. Finally, create the Application Control Policy:
      1. Right click on Application Control Policies and select "New" then "Restrict Process Rights"
      2. Select a collection defined to include all computers with the Outlook add-in installed.
      3. Select the Application Filter created above.
      4. The remainder of the settings may be left as defaulted.
      5. Click Apply
         
         

         Figure 9

         Click to view.

Once the client computers receive the next Altiris Agent configuration and then reboot (this will ensure that existing add-in processes are restarted with reduced rights) the Outlook add-ins should function appropriately.

If the steps outlined above do not resolve issues being seen in the environment related to Outlook Add-ins, another option exists. Changing the "Log On" user for the DCOM service should fix the permission issues. The following steps provide guidance to change the "Log On" user for the DCOM service:

1. Click "Start", "Run", type services.msc then click "OK". Highlight the "DCOM Server Process Launcher", right-click and select properties.
   

   Figure 10

   Click to view.
2. Select the "Log On" tab and enter the account for the user having the issues with launching DCOM services.
   
   

   Figure 11

   Click to view.
3. Click "OK" and reboot.

Conclusion

Using Application Control to reduce the privileges on the MS Outlook process from Administrative rights to user rights is a key configuration is providing a more secure and stable user environment. In some cases, it may be overwhelming with issues when implementing this policy in the user environment, but with a little effort and determination the issues can be resolved and overall enterprise security enhanced.