locked
Run as profile vs Low Priviledge account RRS feed

  • Question

  • Hi all,

     

    What is the best approach, using Low privilege account or configuring Run As profile in SCOM?

     

    I am trying to get my head around the difference but can’t make any headway.

     

    TIA

     

    Regards

    • Edited by SakkieJ Thursday, July 9, 2009 2:47 AM
    Thursday, July 9, 2009 2:25 AM

Answers

  • Hi

    In general I would say it is easier (administratively) to use local system as the agent action account and use run as profiles to elevate permissions when needed (e.g. for SQL Server \ possibly AD replication). It is impossible to give a full answer as it varies by management pack and security requirements of different enterprises so there is no "correct" answer here.

    When you install the agent you specify the action account. This is by default local system but you can specify a low privileged account - a windows account with "minimal" permissions. Just be aware that many management packs do not support the use of low privileged accouts and even when they do, low privilege is actually very misleading. For instance with SQL Server, low privilege requires local windows administrator and SQL sysadmin if you want all the functionality of the MP to work. Not exactley low privilege. Likewise for AD client monitoring - the "client" side of the check needs local windows admin. You don't gain anything by using a low privilege account in many situations. So in general I would leave the agent action account as local system. If you have a secure environment where permissions need to be tied down then you can look to use a low privilege account for those servers but be careful what it is you are monitoring on the box.

    With the agent running as local system you might find SQL discovery \ monitoring fails as does AD monitoring \ replication monitoring. Again, it depends on how your environment is setup. If the login to SQL for built-in administrators and local system has been removed then running the agent action account as local system won't work. So then you need to use a run as profile configured as follows on R2:

     Go to Administration, Run As Configuration, Profiles
     SQL Server Discovery Account.
     Double Click SQL Server Discovery Account
     Click Next on the General Properties window
     Click Save on the Run As Accounts Window
     On the Completion Window, there will be a yellow warning triangle under “More Secure Run As Accounts”. Click on the hyperlink that states “SQL Monitoring Account”
     Next to Selected Computers, click ADD and add in the new SQL Server
     Click Save and Close

    If your company has a SQL DBA AD group that has local windows rights to the SQL Servers and SQL Sysadmin rights then I generally create the SQL Run As Account \ assign it to the Profile and make this account a member of that AD group. But as I've mentioned this depeneds on the environment.

    On domain controllers you might need to run HSLockdown to allow local system to run scripts ... or you might want to configure a seperate run as profile. It all depends ...

    Perhaps these 2 links will help:
    http://technet.microsoft.com/en-us/library/bb735423.aspx
    http://technet.microsoft.com/en-us/library/bb735419.aspx

    Cheers

    Graham
    • Marked as answer by StuartR Wednesday, August 26, 2009 4:22 PM
    Thursday, July 9, 2009 7:10 AM

All replies

  • Hi

    In general I would say it is easier (administratively) to use local system as the agent action account and use run as profiles to elevate permissions when needed (e.g. for SQL Server \ possibly AD replication). It is impossible to give a full answer as it varies by management pack and security requirements of different enterprises so there is no "correct" answer here.

    When you install the agent you specify the action account. This is by default local system but you can specify a low privileged account - a windows account with "minimal" permissions. Just be aware that many management packs do not support the use of low privileged accouts and even when they do, low privilege is actually very misleading. For instance with SQL Server, low privilege requires local windows administrator and SQL sysadmin if you want all the functionality of the MP to work. Not exactley low privilege. Likewise for AD client monitoring - the "client" side of the check needs local windows admin. You don't gain anything by using a low privilege account in many situations. So in general I would leave the agent action account as local system. If you have a secure environment where permissions need to be tied down then you can look to use a low privilege account for those servers but be careful what it is you are monitoring on the box.

    With the agent running as local system you might find SQL discovery \ monitoring fails as does AD monitoring \ replication monitoring. Again, it depends on how your environment is setup. If the login to SQL for built-in administrators and local system has been removed then running the agent action account as local system won't work. So then you need to use a run as profile configured as follows on R2:

     Go to Administration, Run As Configuration, Profiles
     SQL Server Discovery Account.
     Double Click SQL Server Discovery Account
     Click Next on the General Properties window
     Click Save on the Run As Accounts Window
     On the Completion Window, there will be a yellow warning triangle under “More Secure Run As Accounts”. Click on the hyperlink that states “SQL Monitoring Account”
     Next to Selected Computers, click ADD and add in the new SQL Server
     Click Save and Close

    If your company has a SQL DBA AD group that has local windows rights to the SQL Servers and SQL Sysadmin rights then I generally create the SQL Run As Account \ assign it to the Profile and make this account a member of that AD group. But as I've mentioned this depeneds on the environment.

    On domain controllers you might need to run HSLockdown to allow local system to run scripts ... or you might want to configure a seperate run as profile. It all depends ...

    Perhaps these 2 links will help:
    http://technet.microsoft.com/en-us/library/bb735423.aspx
    http://technet.microsoft.com/en-us/library/bb735419.aspx

    Cheers

    Graham
    • Marked as answer by StuartR Wednesday, August 26, 2009 4:22 PM
    Thursday, July 9, 2009 7:10 AM
  • Thanks Graham,

     

    Sorry for my ignorance; so just to put this in a scenario.

     

    Create a low Privilege account (Action Account)

    Add to the following groups

                    Local Users, Performance Monitor Group, “allow log on locally” GPO.

    Add the same account to the run as profiles that is created when importing a MP. (I know that some MP needs more configurations and group memberships, but this is a simple example)

    Friday, July 10, 2009 1:19 AM
  • Hi

    No need to apologise - the whole point of the forum is to help!

    So .... assumming you have configured your default action account as specified above, then you wouldn't necessarily need to configure the Run As Profile at all. The agent will function like this. It is only when the agent needs extra permissions that you'd need to configure a Run As Account and Profile. But when you do configure a Run As Account \ Profile you wouldn't use this account because it doesn't have the elevated rights. You'd still need to create a specific account for the Run As Account \ Profile.

    Reason (blatantly plagiarised from technet) - Rules, tasks, monitors, and discoveries defined in a management pack require credentials to run on a targeted computer and by default, rules, tasks, monitors, and discoveries run using the default action account for the agent or server.

    And

    Run As accounts and Run As profiles allow you to run different rules, tasks, monitors, or discoveries under different accounts on different computers. Management packs no longer share the same identity and therefore allow you to use a low privilege account as your action account.

    The reason to configure a Run As Account \ Profile would be for management packs that require elevated rights above those that the "low privileged account" has.

    So if we use SQL as an example. You'd have your default action account running as a low privileged account. But this isn't enough for the SQL MP. So you'd need to:
    - create a windows account that is a local windows admin and a SQL Sysadmin on the SQL Server (typically I add this to a SQL DBAs security group if one exists as this group would tend to have these permissions already granted to it).
    - assign this to to the SQL Discovery \ Monitoringg Account Profile (as mentioned in my previous post)

    So the windows MP would use your default action account and the SQL MP would use the Run As Account \ Profile specified. 

    Hope that makes sense - let me know if it is as clear as mud ;-)

    Graham

     

    Friday, July 10, 2009 9:09 AM
  • Thanks alot Graham,

    Now, I have a better understanding....

    Tuesday, July 14, 2009 1:17 AM