What does the OCS Setup Delegation Wizard do, exactly?

John | Office Communications Server | Wednesday, June 4th, 2008

We’ve just been through the exercise that every IT consultant / engineer / analyst goes through at some point:  The reverse engineering of permissions applied on active directory objects. 

Hopefully this post will spare you the tedious task.

In this particular case, we needed to give a non-Domain Administrator the ability to install and activate an OCS 2007 server. 

The OCS installation wizard (setup.exe) and command-line configuration tool (LCSCmd.exe) both give you a simple way to delegate installation & activation of OCS Servers.  The challenge however, was that our client wanted to know “what, exactly” was being delegated.   It’s a fair question.  What would be the point of having a Domain Admin delegate permissions to a user, if the user received 90% of the privileges of the Domain Admin as a result of the delegation? 

Presumably, the OCS delegation wizard only delegates the minimum permissions required to do the job.  That is what we set out to prove.

OCS Installer Group Required

First, you must pre-create an AD security group that will receive the delegated permissions.  Let’s call this “OCSInstallersGroup” for the purposes of the example.

Any user who will perform installation and activation of OCS servers will become a member of this group.   The delegation wizard delegates permissions to this group, not to an individual user.

OCS Service Accounts Required

Before running the delegation wizard (or LCSCmd) you will also need to know the names of the OCS SIP Service and OCS Component Service accounts.  These are AD user accounts that are being used to run the various OCS Server services.  If this will be the first OCS Server in the domain, you will need to pre-create these user accounts. 

  • OCS SIP Service Account (default: RTCService)
  • OCS Component Service Account (default: RTCComponentService)

Delegation Wizard Inputs

The delegation wizard must be run by a user who is a member of the Domain Admins group in the domain where we are installing the OCS Servers.

The wizard requires 5 input variables:

  1. TrusteeGroup:  The name of the OCS Installer Group, e.g., OCSInstallersGroup
  2. TrusteeDomain:  The domain where the group exists, e.g., europe.yourcompany.com
  3. SIPServiceAccount:   The name of the OCS SIP Service account, e.g, RTCService
  4. ComponentServiceAccount:  The name of the OCS Component Service Account, e.g., RTCComponentService
  5. ComputerOU:  The DN of the OU where the OCS Servers are located, e.g., OU=OCS2007,OU=Servers,DC=europe,DC=yourcompany,DC=com

Delegation Wizard Outputs

The wizard performs the following tasks:

1.  The TrusteeGroup is added to the Following Groups:

  • RTCUniversalGlobalWriteGroup – Members have write access to RTC global settings
  • RTCUniversalGlobalReadOnlyGroup – Members have read access to RTC global settings

(The OCS Global Settings are AD objects typically stored in the configuration partition at: CN=Global Settings,CN=RTC Service,CN=Services,CN=Configuration,DC=yourcompany,DC=com.   In some cases, the Global Settings may be stored in the Root Domain Partition instead.)

2.  The TrusteeGroup is granted Read and Write permissions* to the ComputerOU (the OU containing the OCS Servers).

3. The TrusteeGroup is granted Read/Write Service Principal Name (SPN) permissions* on the OCS SIP Service Account object

4.  The TrusteeGroup is granted Read/Write Service Principal Name (SPN) permissions* on the OCS Component Service Account object.

*  If you would like to see a list of the specific Access Control Entries (ACEs) that are applied in Steps 2 – 4, we’ve documented them here.

Analysis

Our findings were pretty much what we expected.  The person installing OCS needs to be able to create the Pool and Server objects in the Global Settings and they need to be able to register new Service Principal Names in AD (Use a utility like SetSPN.exe to see what these are).  

We were happy with this… and more importantly, our client was happy with this. 

John Lamb, Modality Systems

Technorati Tags: , ,

3 Comments »

  1. Good tips here John. A couple of additional points worth noting.

    - An RTC Guest service account is also required to authorise meeting presentation downloads.

    - In my case I had to go through a delegated setup and fell into a GPO restriction whereby my credentials did not have rights to enumerate and stop the Windows Firewall service (SharedAccess). Although we don’t use this service, it is disabled, but my delegated account did not have the rights to stop the service.

    Comment by Mike P — 27 January, 2009 @ 3:09 pm

  2. Nice work John. The devil is always in the details!

    Thanks,
    Rhys

    Comment by Rhys — 9 March, 2009 @ 10:26 pm

  3. [...] Prep) or be a member of a group that has had these effective permissions delegated to it (see John’s post for more [...]

    Pingback by The Modality Systems Blog » A Closer Look at an OCS 2007 R2 Enterprise Pool Deployment — 20 April, 2010 @ 9:22 pm

RSS feed for comments on this post. TrackBack URI

Leave a comment

© 2007–2008 Modality Systems Limited