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.
----------------------------------------------------------------------------------------------------------------------------------------------------





Reply via email to