News in SCSM12 (Beta) #8 – Permissions for triggering System Center Orchestrator runbooks

This question comes up a lot: “What permissions are needed to trigger runbooks in System Center Orchestrator?” Sure, you can give all service accounts administrative permissions on all components and that would work somehow, but this is not really what you want to do because you lose control of your environment. Because this information is not available in any docs, me and one of our SCSM TAP customers put together all the permissions that need to be configured to make this thing running smoothly by using the minimum privileges. I hope this will make it to the next version of the SCSM docs somehow …

****************************************************
The complete SCSM SM12 (Beta) Series:
#1 – Service Level Objectives (SLO)
#2 – Service Requests
#3 – Automation of Service Requests
#4 – Enable Self-Service for Service Requests
#5 – Parent/Child Incidents
#6 – Release Management
#7 – Connectors
#8 – Permissions for triggering System Center Orchestrator runbooks
****************************************************

The SCO connector allows you to synchronize runbooks th SCSM and use them in Service Requests (or other requests). If you have no idea what I’m talking about, read this blog post. It describes the process of automating Service Requests by using SCO runbooks. That means that you need permissions to synchronize runbooks to SCSM and later permissions to trigger them as soon as the appropriate runbook automation activities become active. Also, the SCO Administrator has to take care that only runbooks can be synchronized to SCSM that are really needed.

Big Picture – Processes for this scenario

The first table shows the processes involved in runbook triggering.

Tasks Details Account and Permissions
Runbook Synchronization Synchronization of runbooks from SCO to SCSM using the SCO web service Account: SCO connection account

  • This is the RunAs account used on the SCO connector in SCSM
Runbook Triggering Triggering of runbooks that are part of a service request (or other request) using the SCO web service Account: SCO connection account

  • This is the RunAs account used on the SCO connector in SCSM
Workflow Management The business process workflow eninge in SCSM is responsible to check for new work items and to change their status as needed. In case of runbook automation activities the corresponding runbooks are triggered. Account: SCSM Workflow Account

  • This is the workflow account used in SCSM

Permissions in SCSM

The following permissions need to be configured in SCSM.

Group/Role Details Members
Domain Group:
SCSM Admins
ADDS domain
  • This is the group that was used during SCSM setup to define who the SCSM admins are
  • Domain users: Different accounts (persons that are SCSM admins)
  • No service accounts
Local Group:
Administrators
SCSM management server
  • Domain group: SCSM admins (if SCSM admins should also get local admin permissions)
  • Domain user: SCSM service account
  • Domain user: SCSM workflow account
    • Must be manually added. Workflow fails if SCSM workflow account is not a local admin on the SCSM server*
SCSM User Role:
Administrators
SCSM management group
  • Domain group: SCSM admins
  • Domain user: SCSM service account

* This seems to be a problem with SCSM Beta and should be fixed in SCSM RC. Based on an information i got from Microsoft, it should be possible to only give this account read/write permissions on %windir%\temp. But I did not test this myself.

Permissions in SCO

The following permissions need to be configured in SCO.

Group/Role Details Members
Domain Group:
SCO Admins
ADDS domain
  • This is the group that was used during SCO setup to define who the SCO admins are
  • Domain users: Different accounts (persons that are SCO admins)
  • No service accounts
Local Group:
Administrators
SCO management/runbook/web service server
SCO Connection Account Account used to synchronize and trigger runbooks
  • For Runbook synchronization: read and list permissions on top level folder („Runbooks“) and all child objects in SCO runbook designer. Either use SCO runbook connection account or a domain group that this account is a member of
  • For Runbook triggering: publish permissions (advanced security settings) on top level folder („Runbooks“) and all child objects in SCO runbook designer. Either use SCO runbook connection account or a domain group that this account is a member of
Important notice 1

If the SCO connector in SCSM does not synchronize the complete runbook folder structure but only one or multiple sub folders, you must still give read and listpermissions on the top level folder (“Runbooks”) to make sure that the connector can traverse the folder structure.

Important notice 2

You can protect folders and/or runbooks by removing the list and read permissions. When configuring the SCO connector, these folders will be hidden and the containing runbooks will not be visible in SCSM nor synchronized. If needed you can create ADDS groups for all runbook folders and use them for giving permissions to the runbooks (the same way as in file system permissions). This way SCO admins can control which runbooks can be synchronized by SCSM.

Important notice 3

You can give publishpermissions only on those runbooks that SCSM needs to trigger. This way SCO admins can control which runbooks can be triggered by SCSM.

Important notice 4

When a runbook contains one or more child runbooks, you only have to give publishpermissions to the parent runbook (the one that is triggered by SCSM). Publish permissions for the child runbooks are not needed because they are triggered within SCO.

SCO Connector Configuration

This table describes the values for the SCO connector in SCSM.

Area Details
SCO Web Service URL http://servername:81/orchestrator2012/orchestrator.svc
SCO Orchestration Console URL http://servername:82
Connection Account SCO connection account (RunAs Account)
Runbook Path Select as needed

That’s it. With all that information you should be able to configure runbook triggering in SCSM correctly without loosing control and security of your runbooks by giving too much permissions. Have fun trying out!

regards
Marcel

This entry was posted in SCORCH, SCSM and tagged , , , , , , , , . Bookmark the permalink.

7 Responses to News in SCSM12 (Beta) #8 – Permissions for triggering System Center Orchestrator runbooks

  1. Pingback: News in SCSM12 (Beta) #6 – Release Management | SCSMfaq.ch

  2. Pingback: News in SCSM12 (Beta) #1 – Service Level Objectives (SLO) | SCSMfaq.ch

  3. John says:

    How can I test this , I have tried many way but still can’t get SCSM to trigger the runbook , I can run the runbook ok,from the brower with scconnector account , is thier a log I can see..

  4. Daniel Donda says:

    Thank you Zehner !!

  5. Pingback: MicrosoftTouch

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s