Wednesday, 30 May 2012

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 ExamplesPurposePermissions
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 ExamplesPurposePermissions
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 ExamplesPurposePermissions
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 ExamplesPurposePermissions
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 ExamplesPurposePermissions
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 PurposePermission
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 2 - Service Accounts & Permissions

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

7 comments:

accounts receivable factoring company  said...

Hey thanks for this tips. It really a big for me.

Anonymous said...

I noticed this post was done in May - any chance there is a more updated version??
-Jon @ human services software

Marcova said...

Thanks for sharing such valuable information.. I am very lucky to get this tips from you.
Accounting Services

Anonymous said...

Great stuff. Very helpful. I only found that the Service Manager accounts are named *SCOM* instead of *SCSM*.

Steve Beaumont said...

Whoops! You're right, I'll change that now, good spot ;)

Philippe LOUISE said...

Thanks for your very helpful post but for SCSM 2012 you do not speak about the account requested for exchange connector and its rights?
Do you know that they are ?

我本将心向明月 said...

too many account need to create,the minimum is?