System Center 2012 Service Accounts & Permissions

Following on from my first post which set the scene for what I was trying to achieve with my new test environment (Dubbed the Customer Experience Center within Trustmarque!) I promised a post capturing some of the information you might find yourself needing when setting up an environment.

In this post I thought I would provide some information around the requirements for some of the accounts System Center 2012 requires when installing and some of the immediate accounts for the base configuration.

I think that all this information is already out there, but this post helps to pull it all into one central location and hopefully easier to digest.

All this information is of course assuming that you:

1. Have already drawn up a design for your System Center 2012 Infrastructure with considerations to components, layout, performance sizing etc...
2. You already have all your base VM's and SQL installs done.
3. All Pre-reqs are installed.
4. You know how to install the System Center 2012 Components. 

If you need more information on points 3 & 4 then a further post is coming listing lots of install guides and powershell scripts to install the pre-requisites.

Couple of tips first though:

Tip # 1 - Ensure the account used during install has rights to create databases on the SQL instance(s)/server(s) you specify during installation and can add security rights etc. Easiest option is to give the account SQL SysAdmin privileges and then look to revoke later.

Tip #2 - While using the Local System or Network Service option for the accounts is the easiest, I would personally only recommend this for lab/test environments.

Tip #3 - Again, using the same account over and over is easiest, but from a security and also risk mitigation perspective, separate accounts is what I recommend.  For example, using one account for all services possibly across multiple products would mean more than one system would fail if this account became locked out.

Tip #4 - If using (and it's recommended) domain accounts for the SQL services, don't forget to ensure the SPN's are registered for them.

Tip #5 - Staying on SPN's, ensure the data access service accounts get their SPN's registered

Tip #6 - Rule of least privileges.  It's always tempting just to drop the accounts into either the local admins group, sysadmin or heaven forbid the domain admins group.  Hopefully this information will help with only assigning the accounts the least amount of privileges they require which will always be best practise.

Below are a series of tables with example account names, their purpose and the permissions they require.
I've used the domain of TrustLab in this example so all accounts are in the format of <DomainName>\<AccountName>
Like I say, these are examples only, use your own naming conventions for service accounts.




Virtual Machine Manager Accounts
http://technet.microsoft.com/en-us/library/gg697600.aspx

Account Examples	Purpose	Permissions
TrustLab\SCVMMSA	SCVMM Service Account	Local Admin rights on VMM Server
TrustLab\SCVMMHVHost	Adding Hyper-V hosts to VMM	Local Admin rights on target Hyper-V server.
TrustLab\SCVMMOMCon	SCVMM to SCOM connector account	SCOM Administrator Role SCVMM Administrator Role
TrustLab\DomJoin	Domain Joining Account used in templates for VM Deployment	Do not grant the account interactive logon rights. Use Delegate Control in AD: Computer Objects - Reset Password Validated write to DNS host name Validated write to service principal name Read/Write Account Restrictions This object and all descendant objects - Create/Delete Computer Objects

Configuration Manager Accounts
http://technet.microsoft.com/en-us/library/hh427337

Account Examples	Purpose	Permissions
TrustLab\SCCMNA	SCCM Network Access Account	Requires "Access this computer from the network" right on the Distribution Points. Minimum rights to access content on the Distribution Points.
TrustLab\DomJoin	Domain Joining Account used within task sequences to join the OS to the domain.	Do not grant the account interactive logon rights. Use Delegate Control in AD: Computer Objects - Reset Password Validated write to DNS host name Validated write to service principal name Read/Write Account Restrictions This object and all descendant objects - Create/Delete Computer Objects
TrustLab\SCCMCP	SCCM Client Push Account	Do not grant the account interactive logon rights. Must be local admin on the target devices you push clients to.
TrustLab\SCCMRA	SCCM Reporting Service Point Account	Account is granted rights if chosen as a new account during Reporting Point creation from the console.

N.B. There are FAR too many accounts to realistically list for ConfigMgr, please refer to the link above for a full breakdown.  Listed are the most common ones needed for the base install.


Operations Manager Service Accounts
http://technet.microsoft.com/en-us/library/hh298609.aspx

Account Examples	Purpose	Permissions
TrustLab\SCOMAA	SCOM Action Account	Local Admin (NOT Domain Admin)
TrustLab\SCOMDA	SCOM Data Access Account	Local Admin
TrustLab\SCOMDR	SCOM Data Warehouse Read Account	Setup assigns Read to DW DB. Best Practice to ensure account has SQL Logon rights before installation
TrustLab\SCOMDW	SCOM Data Warehouse Write Account	Setup assigns Read to Operational DB, Write to DW DB. Best Practice to ensure account has SQL Logon rights before installation

N.B. Always use the same Action Account & Data Access Account for each Management Server you deploy.
N.B. This list does not cover RunAs accounts for management packs such as the SQL or AD MP's.  Please refer to the applicable guide for the management pack for details/requirements.


Service Manager Service Accounts
http://technet.microsoft.com/en-US/library/hh495662.aspx

Account Examples	Purpose	Permissions
TrustLab\SCSM Admins (This is a group not an account)	Management group administrators	Account used to run setup must be able to add users to this group as it will try to auto add the user to it.
TrustLab\SCSMSA	SCSM Service Account	Local Admin on SCSM Server(s) Must be same account for DW & MS Servers.
TrustLab\SCSMRA	SCSM Reporting Account	Nothing specific, will be granted rights in SQL during install.
TrustLab\SCSMAS	SCSM Analysis Services Account	Nothing specific, will be granted rights in SQL during install.
TrustLab\SCSMWF	SCSM Workflow Account	Normal User permissions, but must have mailbox and send permissions for notifications. Manually add account to Service Manager Administrators after install if not present.

N.B. I haven't listed the accounts here that are used for setting up SharePoint which will be needed when installing SharePoint dedicated for the Self Service Portal as I am not a SharePoint expert and would recommend seeking dedicated SharePoint best practise advice for that.



Service Manager Connector Accounts

Account Examples	Purpose	Permissions
TrustLab\ SCSMADCON	Active Directory Connector Account	AD Read Advanced Operator in Service Manager
TrustLab\SCSMOMCICON	SCOM CI Connector Account	Operations Manager - Operator Privileges Service Manager -Advanced Operator
TrustLab\SCSMOMALCON	SCOM Alert Connector Account	Operations Manager - Administrator Service Manager -Advanced Operator
TrustLab\SCSMCMCON	SCCM Connector Account	SCCM SQL DB -smsdbrole_extract & db_datareader roles Service Manager -Advanced Operator
TrustLab\SCSMSCOCON	SCORCH Connector Account	Read Properties, List Contents and Publish permissions to the root Runbook folder and all child objects. Grant via the Runbook Designer.
TrustLab\SCSMVMMCON	SCVMM Connector Account	SCVMM Administrator Local Admin on VMM Server Service Manager -Advanced Operator

Orchestrator Service Accounts
http://technet.microsoft.com/en-us/library/hh912319.aspx

Account Examples	Purpose	Permission
TrustLab\SCORCHSA	Orchestrator Management Service	Recommended to be a domain account. No special permissions required other those that the installer assigns during installation.
TrustLab\SCORCHSA	Orchestrator Runbook Service	Recommended to be a domain account so that if Runbooks require access to remote resources, rights can be granted to this account.
TrustLab\SCORCHSA	Orchestrator Runbook Server Monitor service	Same account used as Orchestrator Management Service and same rights required.

N.B. As is common with most deployments of Orchestrator, if you install the Management Server and Runbook Server components at the same time on the same server they will both use the same service account.
N.B. To deploy an IP to Runbook Designer, ensure the account running the Deployment Manager has local admin rights on the target otherwise you will get Access Denied.

Part 1 - Building the TESG Private Cloud Customer Experience Centre

Part 2 - Service Accounts & Permissions

Part 3 - Installation Guide Links
Part 4 - Partner Solutions & Extensions