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:
- Have already drawn up a design for your System Center 2012 Infrastructure with considerations to components, layout, performance sizing etc...
- You already have all your base VM's and SQL installs done.
- All Pre-reqs are installed.
- You know how to install the System Center 2012 Components.
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 2 - Service Accounts & Permissions
Part 4 - Partner Solutions & Extensions
No comments:
Post a Comment