Thanks Kevin. I got the "low priv'" for my scom action account as per the
http://technet.microsoft.com/en-us/library/dd767431.aspx website. I am just
expecting the monitoring the sql servers excluding the tasks actions.
Just imply monitoring.
The company security policies are not accepting to provide to admin right to
the scom action account, because it makes every SQL Server instance less secure
on every server. Need clarity on the below points
1. Low privilege for SQL Server Mirroring is not supported.
------> which privileges
required to monitor mirroring except SQL Admin rights
2. Low-privilege configuration is only supported for non-clustered SQL
Server environments. ------> which privileges required to monitor Clustered
SQL Server environments(except sQL Admin rights)
3. Clustered SQL Server instance monitoring under the Low-Privilege is
supported only for SQL Server 2012 monitored from System Center Operations
Manager 2012. It is not guaranteed to work for previously-released management
packs.
------------------------------------------------------------------------------->
I am using scom 2007 R2 . For scom 2007 R2 which privileges are required to
monitor(except SQL admin rights)
I am just expecting to monitor the sql infra. And not expecting any tasks to
run on the sql part from scom.
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of Kevin Holman
Sent: Friday, 10 January 2014 10:43 AM
To: [email protected]
Subject: [msmom] RE: Sql server monitoring permissions for scom account.
Public will absolutely not be enough to fully monitor SQL.
Technically speaking, to FULLY make use of all workflows in the SQL MP, you
need to provide the runas account for monitoring SQL to have local admin over
the OS, and SQL "sysadmin" role over the SQL instance. OR - read the MP guide
and provide a "low priv" runas account all the very specific and granular
rights to the OS, the instance, and the individual databases. The guide is
quite clear on the what, and the how.
You have two choices using "low priv" model:
1. Set up all the security and rights exactly as the guide calls for.
Ensure a process is put in place to apply these permissions to new databases as
they are created.
2. "Throw a stake in the ground" Just say "my run as account can only
have these specific rights, PERIOD". That might be local admin to the OS, but
only "public" role to the SQL instance. In this case, SOME monitoring
workflows will work fine, and SOME just won't. Mostly script based monitoring
solutions which require advanced rights. Then you'd have to find out which
workflows are now failing, and just disable them, since they won't work.
I'd question why an audit is requiring removal of rights that are necessary for
an application monitoring solution. Lots of people and service accounts have
these rights. I'd expect the audit to focus on "how are the credentials
managed, how are they stored, are they encrypted... etc.
From: [email protected] [mailto:[email protected]] On
Behalf Of David Biot
Sent: Friday, January 10, 2014 9:06 AM
To: [email protected]
Subject: [msmom] RE: Sql server monitoring permissions for scom account.
Dear Naren,
On technet you will find the theory, on Kevin's blog you'll find a practical
example:
http://blogs.technet.com/b/kevinholman/archive/2010/09/08/configuring-run-as-accounts-and-profiles-in-r2-a-sql-management-pack-example.aspx
I hope this helps.
Many regards,
David Biot
Technical Project Leader
[email protected]<mailto:[email protected]>
Direct +32 2 801 41 52
[X]<http://www.realdolmen.com/>
This e-mail message and any attachment are intended for the sole use of the
recipient(s) named above and may contain information which is confidential
and/or protected by intellectual property rights. Any use of the information
contained herein (including, but not limited to, total or partial reproduction,
communication or distribution in any form) by other persons than the designated
recipient(s) is prohibited. If you have received this e-mail in error, please
notify the sender either by telephone (+32 2 801 55 55) or by e-mail and delete
the material from any computer. Please note that neither RealDolmen nor the
sender accept any responsibility for viruses and it is your responsibility to
scan or otherwise check this email and any attachments. RealDolmen is nor
responsible for the correct and complete transfer of the contents of the sent
e-mail, neither for the receipt on due time.
[Think Green]
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Narendra Bathula
Sent: vrijdag 10 januari 2014 15:59
To: '[email protected]'
Subject: [msmom] Sql server monitoring permissions for scom account.
low priviliges(access level) for SCOM account to monitor the SQL servers. have
to provide the solution to client on this. still now we are using sql admin
account. now we have to remove this account because audit people are not
accepting to give full permissions to monitoring. they have provided the access
level "public" for scom monitoring account.
checked the below link form microsoft
http://technet.microsoft.com/en-us/library/dd767431.aspx
Got a doubt about all these permissions are fall under "public"(server roles in
sql server) or anything needs to be add. please suggest me on permission level.
Sql Server Roles:
1. bulk admin
2. dbcreator
3. diskadmin
4. processadmin
5. public
6. security admin
7. setupadmin
8. sysadmin
Regards,
Naren
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction,
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and
other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
