Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

OpsMgr security account rights mapping - what accounts need what privileges?

OpsMgr security account rights mapping - what accounts need what privileges?

  • Comments 22
  • Likes

 

Do you ever wish you had a list of the rights needed to install OpsMgr on each server role?  Or what each service account needs for steady state?  Or how about ongoing support... for your Admin group - to have enough rights in SQL to support OpsMgr?

I have created a spreadsheet of the typical security accounts, and what rights they need on each server role, or database. 

 

Attachment is below:

 

 

Attachment: OpsMgr 2007 SP1 Security account Matrix v1.0.xls
Comments
  • Thanks for the effort of putting the permissions account document together, I mentioned before to C.Fox that his doc is lacking these details.

    I just wanted to add my 2 cents here:

    You should probably include in the doc account's system permissions.

    For example:

    Data reader account on the reporting server needs:

    Logon as a Batch Job and Logon as a Service privileges.

    SDK account requires the same priveleges on the RMS server.

    Data Writer Logon as a Service on the reporting.

    Don't quote me on these. Just verify the roles exactly, I am not sure regarding whether data wareshouse account provileges needed on the reporting db server or on the server where SSRS installed if separate. (in my environment these  roles isntalled on the same server, so I can' t really clarify)...

    PaVel

  • This is exactly what DBA's have been asking for.  Thanks man!

    -Jess

  • Excellent, thank you very much, highly appreciated!

    Is it possible to include Pavel's recommendations in version 2.0 of your Matrix?

  • Kevin,

    It's about time.. Jesus.  Can you be any slower? ;-)

    Hugs and kisses,

    Blakey poo

  • There has always been a bit of confusion on when to run the DBCreateWizard.exe tool, or when to just

  • Outstanding work on the spreadsheet - its a shame that its so difficult to implement good practices like separating databases from applications.  I've been fighting this for a few weeks and I really appreciate why they suggest to take the shortcut and just install it all on one box.  Good on ya Kevin!

  • Great 10x,

    A good addition to the document would be to add the Permissions required for popular MPs like the ADMP and the Exchange ones...

  • What about R2? I was reading the "SDK and config" account is now called the Data Access Service account. Can I safely replace "SDK and config" with Data Access Service account on the spreadsheet to be complient with R2?

    Thanks,

    Stephen

  • Yes - as far as I know - no security schema changes were made.

  • Great stuff Kevin!

    I do have a couple of questions however:

    Q1 - Microsoft KB article 936220, entitled "How to change the credentials for the OpsMgr SDK Service and for the OpsMgr Config Service in Microsoft System Center Operations Manager 2007", makes no mention of adding either of the following accounts in the RMS & MS local Administrators group:

    - OpsMgr SDK Service account

    - OpsMgr Config Service

    The "Operations Manager 2007 R2 Quick Start Guide" clearly states the following however:

    "SDK and Config Service accounts. They can use the same account. It must have administrative privileges on the management server and system administrator privileges on the instance of SQL Server that will host the Operations Manager 2007 R2 database."

    I'm leaning towards putting them in the local Administrators group, as our current installation is generating a plethora of error logs (Event ID:26319; Source: OpsMgr SDK Service - The user <Domain>\SVC-MOMSDK does not have sufficient permission to perform the operation.) on our RMS.

    What are your thoughts on this?

    Q2 - In my sandbox environment*:

    - the 'public' database role for the OperationsManager database is empty, whereas the spreadsheet indicates that the following should appear:

    - SDK and Config account

    - MS Action account

    - Report Data Writer account

    - Domain Global Group associated with the Operations Manager Administrators user role

    - the 'db_datareader' database role for the OperationsManager database does not include the Domain Global Group associated with the Operations Manager Administrators user role.

    - the 'db_datareader' database role for the OperationsManagerDW database does not include the Domain Global Group associated with the Operations Manager Administrators user role.

    - the 'OpsMgrReader' database role for the OperationsManagerDW database does not include the Domain Global Group associated with the Operations Manager Administrators user role.

    - the 'public' database role for the OperationsManager database is empty, whereas the spreadsheet indicates that the following should appear:

    - SDK and Config account

    - Report Data Reader account

    - Report Data Writer account

    - Domain Global Group associated with the Operations Manager Administrators user role

    Should I make these additions manually and, if so, why didn't the installer take care of this?

    Thanks,

    Larry

    * sandbox is 3 VM servers:

    - 1 AD Server

    - 1 RMS Server (OpsMgr 2007 R2)

    - 1 SQL Server (2005)

  • Thanks Kevin,

    Shouldn't all these permissions be expected to populate during the installation?  For example, all the needed permissions for the SDK account on the OpsMgrDB and the OpsMgrDW, shouldn't these auto populate during the installation?

    Thanks,

    Tom

  • Hi Tom -

    Yes - these should all be published and configured during install - and should not require ANY manual intervention.

    My document is published for three reasons:  

    1.  To clarify the user account and rights required to perform an install/upgrade/hotfix

    2.  To document the security for customers - so their SQL DBA teams can better understand our requirements go beyond "just give my service account DBO to the database"

    3.  To document the default configuration for support professionals, so they have a reference to compare against when something isnt working and they suspect permissions have been modified.

  • Does the SCOM action account need to be in Enterprise Admin group if AD monitoring is being done? How do we overcome the security issue if Domain controllers are to be monitored using the same SCOM infrastructure which monitors member servers.

  • @ Adhokd -

    Q:  Does the SCOM action account need to be in Enterprise Admin group if AD monitoring is being done?

    A:  No - never.  Read the ADMP guide.  You only need elevated rights for an account if the action account is low priv.

    Q:  How do we overcome the security issue if Domain controllers are to be monitored using the same SCOM infrastructure which monitors member servers.

    A:  There is no issue.  Use Local System as the default agent action account.

  • Is there also an R2 version of this sheet?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs