There are several ways to provision administrator accounts for Unity SAWeb access. The method I prefer to use is associating domain user accounts to a privileged subscriber using the GrantUnityAccess tool.
A Word on Privileged Accounts
The phrase “Best Practice” is somewhat loaded and on some level is simply just an opinion. So, keep in mind that each person must choose their own “best” path. From my point of view, I believe that any system administrator (Cisco voice application or other) should try to enforce a policy whereby administrative users have two accounts. One account is their standard, non-privileged user which should have the same permissions as standard users (more or less). The other account is a privileged account that is used for administrative tasks only.
With Cisco UC applications, a “standard” user account is used for more and more application interfaces. It used to be you just had the old CCMuser pages that users could access. Now, user accounts are associated with CUCI-MOC, CUPC, Click-to-Call, various Outlook plugins, etc.
Revision Information
The procedure outlined in this article has been tested on Unity 4.x and 5.x in Exchange 2003 and Exchange 2007 environments.
Overview of Process
The idea is that you create one or more mailbox subscribers and assign a specific Class of Service (COS) to the subscriber. The COS will allow the subscriber to have administrative privileges on the system. We typically create a minimum of two such subscribers. One that is for help desk/Tier 1 staff only and another that grants full access to the SAWeb interface.
We use only one or two subscribers so that we don’t eat up unnecessary licenses. To accomplish this objective, we leverage the Unity “GrantUnityAccess.exe” tool.
Class of Service Overview
Unity can leverage subscriber Class of Service (CoS) settings to assign administrative privileges. Administrative privileges are assigned in the Subscriber System Access Rights section of a particular CoS (see below).
You can create a custom CoS such as Tier1-CoS or Tier3-CoS and then choose the options that are appropriate for your environment.
Local System Authorization
The Unity administration guide recommends that any administrative user that is going to access the SAWeb portal be granted Local Admin rights on the Unity system. According to the guide, if this is not acceptable the accounts require “logon locally” permission. This permission can be assigned through the local system policy editor. You will need to make sure that domain group policies don’t override the system local policy.
NetCraftsmen believes that granting users local admin rights on the Unity system defeats the objective of controlling access. So, we opt to use the “logon locally” permission instead. Our testing has found that this permission is not enough by itself. Admin user accounts will also require special permissions to several COM+ objects. Specifically, admin accoutns require “Local Launch” and “Local Activation” permissions to the following objects:
- AvCSGateway
- AvDSGlobalCatalog
- AvLic
To modify the permissions on these objects, you will need to launch the Component Services Microsoft Management Console on the Unity system (repeat on each Unity system in the environment). You can launch the Component Services MMC from the Start menu (Start>Programs>Administrative Tools>Component Services).
Once launched, you will need to find and edit each of the above listed component services as follows:
- Right click on the COM object and choose properties
- Go to the Security tab
- Select “Customize” under “Launch and Activation Permissions”
- Click on Edit and Add
- Select your users (or, better yet configure a Local permissions group like “SAWebAdmins” that you can associate with privileged domain accounts)
- Allow “Local Launch” and “Local Activation” to your user(s)/group(s)
- Click OK in all pop up windows to save
As noted above, we like to create a local permissions group to assign the COM object permissions and to grant the “logon locally” permission. This allows us to simply add domain accounts to the appropriate local permissions group instead of repeated all of the necessary steps for each account.
Create Unity Subscribers
You need to create a Unity subscriber for each class of admin user you want to support. This means that there is an AD user object created and associated to the subscriber. This is not an issue as you can safely disable the associated AD user account so that someone can’t use it as a backdoor account.
Using the GrantUnityAccess Tool
At this point you have created a local permissions group, granted that group “logon locally” permissions and COM+ object permissions, created a custom CoS, and created the privileged Unity subscriber. Now, you need to be able to associate domain user objects to the privileged Unity subscriber. To do this, you need to use the GrantUnityAccess tool, which is located in the d:commserver folder (drive letter may vary with platform overlay).
The GrantUnityAccess tool is ran as follows:
d:commservergrantunityaccess.exe -u <domain account> -s <associated subscriber alias>
For example:
In this example, we are grabbing the domain account bbell-admin@netcraft.priv and associating this account with the tier1 subscriber (vmtier1admin). This example subscriber has a CoS which only allows associated users to add/remove/edit other subscribers.
You can also use the GrantUnityAccess tool to check current associations. This can be handy if you needed to check to see who has permissions on the box:
The output shows all domain accounts that are associated to Unity subscribers. In the green box you can see the privileged account association with the Tier1 and Tier3 subscribers.
After completing the subscriber associations with the GrantUnityAccess tool, your privileged user accounts can now logon to the https://unityhost/web/sa web portal and do their thing. When the user logs on, they will use their AD account credentials not the account credentials for the associates subscriber (e.g. vmtier1admin). Remember, this account is disabled.