KB: "Access Denied" in Runbook Designer when connecting to the System Center Orchestrator Management Server

KB: "Access Denied" in Runbook Designer when connecting to the System Center Orchestrator Management Server

  • Comments 2
  • Likes

imageHere’s a new Knowledge Base article we published. This one talks about an issue where you get an "Access Denied" in Runbook Designer when connecting to the Orchestrator Management Server.

=====

Symptoms

When attempting to connect to your System Center 2012 Orchestrator Management Server using the Runbook Designer application, the following error is returned:

Connection Error

Access Denied. If you are using the local administrators group to manage permissions, you might need to start the Runbook Designer with Run as Administrator.

Cause

This can occur if the user account launching the Runbook Designer application does not have sufficient permissions to access, launch and activate the omanagement Distributed COM (DCOM) Server on the Management Server computer from a remote computer.

Resolution

Allowing users to connect to the System Center Orchestrator Management Server using the Runbook Designer application consists of two layers of authorization. The first layer, where this error occurs, is the ability to access, then launch and activate the DCOM Server called omanagement. During installation a group referred to as the Orchestrator Users Group is either selected or created and granted the permissions to be able to connect to the omanagement DCOM Server remotely without requiring membership to the local administrators group on the Management Server.

In order to allow additional users the same authorization to access, launch and activate the omanagement DCOM Server remotely, we must add those users either directly or indirectly via group membership into the DCOM security structure. It is recommended to add an Active Directory based security group rather than direct users so that the DCOM Service does not need to be restarted each time a user is desired to be added or removed from authorization.

To add additional users and/or security groups to be authorized for remote access, launch and activation of the omanagement DCOM Server, follow the instructions below:

  1. On the System Center Orchestrator Management Server, launch dcomcnfg to open up the Component Services applet.
  2. Expand Component Services, then Computers, then My Computer.
  3. Right-click My Computer, then click Properties.
  4. Click the COM Security tab.
  5. Under Access Permissions, click Edit Limits.
  6. Click Add then enter details of the desired local or Active Directory based security group and click OK.
  7. Click the new entry and then select the Allow checkbox for each permission then click OK.
  8. Under Launch and Activation Permissions, click Edit Limits.
  9. Click Add then enter details of the desired local or Active Directory based security group and click OK.
  10. Click the new entry and then select the Allow checkbox for each permission then click OK.
  11. Click OK to close the My Computer Properties dialog.
  12. Expand My Computer, then click DCOM Config.
  13. Locate omanagement, then right-click and choose Properties.
  14. Click the Security tab.
  15. Under Launch and Activation Permissions, click Edit.
  16. Click Add then enter details of the desired local or Active Directory based security group and click OK.
  17. Click the new entry and then select the Allow checkbox for each permission then click OK.
  18. Under Access Permissions, click Edit.
  19. Click Add then enter details of the desired local or Active Directory based security group and click OK.
  20. Click the new entry and then select the Allow checkbox for each permission then click OK.
  21. Click OK to save the changes.
  22. Close the Component Services applet.
  23. Open a Command Prompt.
  24. Type sc stop omanagement and press Enter.
  25. Type sc start omanagement and press Enter.

Once the Orchestrator Management Service (omanagement) is restarted, direct users and members of security groups that were added will now be able to successfully connect to the System Center Orchestrator Management Server using the Runbook Designer.

More Information

In addition to DCOM Server authorization, the user account must have direct or indirect permissions granted inside the Runbook Designer to the various components. If the user does not have at least read permissions to the Runbooks node in the Runbook Designer's navigation pane, they will receive a different error message that could be misinterpreted as this problem as this is the default node that the Runbook Designer takes the user to upon successful connection to the Management Server. That error message appears as below:

General Error
A general error has occurred. The error returned was:
Access is denied. (80070005)

=====

For the most current version of this article please see the following:

2779526 - "Access Denied" in Runbook Designer when connecting to the System Center Orchestrator Management Server

J.C. Hornbeck | Knowledge Engineer | Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Great ! Thank's

  • So Very Close.

    This workaround could be mitigated with a shifting of the groups.

    OrchestratorSystemGroup > OrchestratorServiceGroup

    OrchestratorUsersGroup > OrchestratorAdminsGroup

    New Hiearchy:

    OrchestratorServiceGroup

     - Contains default service Orchestrator Management Service Runs under

    OrchestratorAdminsGroup

     - Members of this group can Administer local management server instance and client permissions

    OrchestratorUsersGroup

     - Provides permissions to connect from remote client/access web console at root level

     - Permissions beyond root level access must be granted by instance admins

    Why?

    The power one can give to an Organizational Automation Tool should be directly proportional to the security that can be implemented to limit any single users use of that tool.

    The current OrchestratorUsersGroup allows unilateral (admin) access to the client and the full power of the default domain service it runs under.  As it stands, only system admins should be added to the OrchestratorUsersGroup and additional Security Groups provided access via the steps above with specific permissions set through the client.