Home » Orchestrator » Remote work with the Runbook Designer console and security roles in Orchestrator

Remote work with the Runbook Designer console and security roles in Orchestrator

In this post I will show you what you need to configure to allow engineers connect remote to the Orchestrator environment without Orchestrator administrator permissions. After Orchestrator installation we have one security group, the Orchestrator User Group. If your Orchestrator environment is in an Active Directory domain you should use an Active Directory security group as the Orchestrator User Group. The Orchestrator User Group has full access to the Orchestrator environment. If you enabled remote connection during installation, members of the Orchestrator User Group can also remote connect to the Orchestrator environment, for example run the Runbook Designer console from a workstation. A common scenario is that other engineers and experts need access to the Orchestrator environment too, for example the Service Manager team wants to author some runbooks. At the same time the Service Manager engineers should not have access to every runbook, only runbooks created by the Service Manager team. In other Words you cant add the Serivce Manager team to the Orchestrator User Group. To solve this we need to perform the following steps

  • Assign general Orchestrator permissions to a “Orchestrator Remote Users” security group. There are a number of general permissions that everyone that will work with Orchestrator remote needs. We will assign these permissions to a Orchestrator Remote Users group. By using one general group for this kind of permissions the administration gets a bit easier. In this example my group is named SKYNET\grp-sco-remoteusers.
  • Assign specific Service Manager team permissions to a “Service Manager Team” security group. We will most likely have more teams then the Service Manager team working with runbooks. Each team will need specific permissions, which will result in one specific security group for each team. In this example my Service Manager team group is named SKYNET\grp-sco-scsmteam.

We will start by assign the Orchestrator Remote Users Group suitable DCOM permissions

  1. On the Orchestrator Management Server, start Component Services from the start menu
  2. In the Component Services console, expand Component Services, expand Computers and expand DCOM Config
  3. In the list of DCOM applications scroll down and select omanagement. Right-click the omanagement DCOM application and select properties from the context meny
  4. In the omanagement Properties window, click the Security tab
  5. Click Edit in the Launch and Activation Permissions area, click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Launch and Remote Activiation permissions. Click OK
  6. Click Edit in the Access Permissions area, click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Access and Local Access permissions. Click OK
  7. In the Component Services console, right-click My Computer and select properties from the context menu
  8. In the My Computer Properties box, select the COM Security tab
  9. Click Edit Limits… in the Access Permissions area. Click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Access permissions. Click OK
  10. Click Edit Limits… in the Launch and Activation Permissions area. Click Add and add the grp-sco-remoteusers security group from Active Directory. Assign the grp-sco-remoteusers security group Remote Launch and Remote Activation permissions. Click OK
  11. Close the Component Services console 12. After all permissions are configured, on the Orchestrator Management server, start the Services console and restart the Orchestrator Management Service (ManagementService.exe ). If a user dont have correct DCOM permissions to access Orchestrator you will see a error message in the Runbook Designer console, like the one below

and on the Orchestrator management server you will see a event like this

All users that will work with the Orchestrator Runbook Designer console needs read permissions to the top level of the Runbooks folder navigation tree. To assign the grp-sco-remoteusers security group permissions to the root level follow these steps

  1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
  2. Right-click the Runbooks folder and select Permissions from the context menu
  3. In the Permissions for Runbooks dialog box, click Add.. and add the grp-sco-remoteusers security group from Active Directory
  4. In the Permissions for Runbooks dialog box, un-selected everything except Read as permissions for the grp-sco-remoteusers group
  5. In the Permissions for Runbooks dialog box, click Advanced
  6. In the Advanced Security Settings for Runbooks dialog box, select the grp-sco-remoteusers security group and click Edit…
  7. In the Permissions Entry for Runbooks dialog box, change the Apply To drop-down menu to This object only
  8. In the Permissions Entry for Runbooks dialog box, click OK
  9. In the Advanced Security Settings for Runbooks dialog box, click OK
  10. In the Permissions for Runbooks dialog box, click OK

Depending on your environment the different teams need different access to runbook servers. To assign the grp-sco-remoteusers access to all Runbook Servers follows these steps:

  1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
  2. Right-click the Runbook Servers folder and select Permissions from the context menu
  3. In the Permissions for Runbook Servers dialog box, click Add and add the grp-sco-remoteusers security group from Active Directory. Click OK
  4. In the Permissions for Runbook Servers dialog box, un-select all permissions for the grp-sco-remoteusers group except Read. Click Ok

Your different teams will also need access to Global Settings. To give the grp-sco-remoteusers security group permissions to list Global Settings follow these steps:

  1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
  2. Expand Global Settings, one by one, right-click Counters, Variables and Schedules. Select Permissions from the context menu
  3. In the Permissions dialog box, click Add, add the grp-sco-remoteusers security group from Active Directory. Click OK
  4. In the Permissions dialog box, select the grp-sco-remoteusers group and click Advanced
  5. In the Advanced Security Settings dialog box, select the grp-sco-remoteusers security group and click Edit
  6. In the Permission Entry dialog box, change Apply To to This object only, and select only List Contents and Read Properties permissions. Click OK
  7. In the Advanced Security Settings dialog box, click OK 8. In the Permissions dialog box, click OK

You have now configured the grp-sco-remoteusers security group with general permissions to remote connect to the Orchestrator management server with the Orchestrator Runbook Designer console. The security group doesn’t have access to anything in the Orchestrator Runbook Designer console (except Runbook Servers), when a user in this group click for example Variables an error like the own below will show.

The next step is to configure permissions for the different teams, in this example the Service Manager team, group grp-sco-scsmteam. We will create a new Runbook folder where the Service Manager team can work with Runbooks.

  1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator
  2. Right-click the Runbooks folder and select new folder
  3. Name the folder Service Manager Team
  4. Right-click the Service Manager Team folder and select Permissions from the context menu
  5. In the Permissions for Service Manager Team dialog box, click Add and add the grp-sco-scsmteam security group from Active Directory. Click OK

The Service Manager team need access to global settings too

  1. Start the Orchestrator Runbook Designer console as an Orchestrator administrator. Navigate to Global Settings
  2. Under Counters, Variables and Schedules create a folder and name it Service Manager Team
  3. Right-click each new folder and select permissions from the context menu. Click Add and add the grp-sco-scsmteam security group from Active Directory. Click OK

 We have now created a runbook folder for the Service Manager team runbooks and then created one folder for each kind of global setting. The Service Manager team can now work with their own runbooks but cant see or modify any other runbooks or settings.

One thing to think about, that could result in multiple Orchestrator environments, is that the settings that are under the Options menu will be shared with everyone running the Runbook Designer console. There is no easy way to limit access to for example the Active Directory connection or the Virtual Machine Manager connection. This is something to think about when doing the security design for Orchestrator.


6 Comments

  1. Everything is very open with a clear clarification of the challenges.

    It was definitely informative. Your site is very useful.
    Thank you for sharing!

  2. Hi,
    Yes that is possible, right click the object and look at the permissions option. Just remember that the person also need at least READ permissions on any objects above in the stucture.

  3. Hi,
    A user without any Orchestrator permissions should see the web based Orchestrator console by default, but nothing in it. Review your IIS permissions to make sure your users have permissions to connect to the web server.

  4. Hi Andres,
    I have added all the permissions to Dcom as you suggested. But If I try to open the Webconsole from a remote Workstation I get always Access denied after the popup where i have to type in the user credentials with password. The runbookserver is already added to the intranet zone in IE of the remote workstation.
    Any Idea what this can be?

    Thanks
    Markus

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.