Archive

Archive for the ‘Security’ Category

Security Risk of Enabling Agent proxy

March 29, 2010 Leave a comment

This was a great post by Dan Rogers on the potential security risks of enabling Agent Proxy:

Dan Rogers:
If someone can get you to import a management pack, and that management pack discovers classes and assigns them to another server, then the potiential exists that you have been duped into running a managment pack rule that you thought was safe.

It’s a subtle internal social engineering attack – so there is a warning on the enable proxy box and we took steps to make it not easy to skip that warning.

That said, nearly every management pack that is coming in the future will not function adequately or at all if proxy isn’t enabled. This is because management packs are becoming sophisticated in the way they project health states in products that inherently have multiple server roles. When a management pack creates a roll-up tree in a diagram view, it typically will need proxy enabled.

The decision to enable proxy comes with a great responsibility – that is to always be sure you TRUST with absolute certainty, the source you got that management pack from. Since the proxy-enabled attack is most likely to come from inside your company, you may want to put a process in place (like we have at MSFT) to design-check every management pack before it is ready to be used in production environments.

Advertisements

OpsMgr database security requirements

August 11, 2009 Leave a comment

OpsMgr MS Action Account:

Server Role – Public

OperationsManager database:
Ø Db_datareader
Ø Db_datawriter
Ø Db_ddladmin
Ø Db_module_users
Ø Public

OpsMgr SDK \ Config

Server Role – Public

OperationsManager database:
Ø Db_datareader
Ø Db_datawriter
Ø Db_ddladmin
Ø Configsvc_user
Ø Dwsynch_users
Ø Sdk_Users
Ø Public

OperationsManagerDW:
Ø Db_datareader
Ø OpsMgrReader
Ø Public

OpsMgr Data Reader

Server Role – Public

Master:
Ø Public
Ø RSExecRole

MSDB:
Ø Public
Ø RSExecRole
Ø SQLAgentOperatorRole
Ø SQLAgentReaderRole
Ø SQLAgentUserRole

Operations ManagerDW:
Ø Db_datareader
Ø OpsMgrReader
Ø Public

Report Server:
Ø Db_owner
Ø Public
Ø RSExecRole

ReportServerTempDB:
Ø Db_owner
Ø Public
Ø RSExecRole

Ops Mgr Data Writer:
OperationsManager database:
Ø Db_datareader
Ø Dwsynch_users
Ø public

OperationsManagerDW:
Ø Db_owner
Ø OpsMgrWriter
Ø Public

Categories: Security

Run As Accounts and Tasks

July 27, 2009 Leave a comment

This discussion came up on the technet forums recently and Steve Halsey from Microsoft came up with a great explanation:

“By default a task will use the default action account on an agent, that is if nothing else is specified in one of two places. The first place is when you run the task in the console, and you have change the account the task is run as, basically selecting a different account than the predefined run as account. If credentials are specified when the task is run they will override any other account settings.

The second place is inside the MP itself the author could have set the task to use a different Run As Profile. If the task has been set to use a different account profile, then this account rather than the default action account will be used. I can’t recall currently if you can set this run as profile when you are creating a task through the UI or not, but the xml of the Management Pack can use a Run As profile, the RunAs property just needs to be set in the WriteAction of the task”

WriteAction ID=”WA” RunAs=”MyLocalMachineAdministrator” TypeID=”System!System.CommandExecuter”

Categories: Runs As Accounts, Tasks

RunAs Profile or Low Privileged Account

July 9, 2009 Leave a comment

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

Categories: Run As Profiles, Security