Here’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.
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.
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.
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:
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.
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:
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/
Great ! Thank's
So Very Close.
This workaround could be mitigated with a shifting of the groups.
OrchestratorSystemGroup > OrchestratorServiceGroup
OrchestratorUsersGroup > OrchestratorAdminsGroup
- Contains default service Orchestrator Management Service Runs under
- Members of this group can Administer local management server instance and client permissions
- Provides permissions to connect from remote client/access web console at root level
- Permissions beyond root level access must be granted by instance admins
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.