July 26, 2010 at 4:25 pm
Hello,
Can someone suggest what is the best security for SQL Server Agent service account? Or in other words which account would you recommend for running SQL Server jobs? I know SA account is not a good practice as it grants more security than needed. I appreciate your input in this regards.
Thanks.
July 26, 2010 at 4:30 pm
SA can be the owner of the jobs. The jobs will execute as the Agent Service Account - unless otherwise specified (proxy). I typically set my agent service to use a domain account.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 27, 2010 at 10:46 am
I know we can use SA account. But I googled and found that it is not the best thing to do. Can you suggest what is the best account to run SQL Server jobs under?
July 27, 2010 at 11:14 am
You are mixing a few things here. The owner of the job is not necessarily the one that executes a job. SQL Agent Service cannot be set to SA. It is the service account by which jobs are executed. Thus set your service account to a domain account from active directory. Use an account created in AD specifically for the purpose of being a service account for SQL Server.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 27, 2010 at 3:03 pm
Thanks Jason. We used to use a windows domains account specifically created for SQL Server jobs, but our security policies changed. We changed the SQL Server Agent service account to a local .\sqladmin account. I hope this practice is fine. Please let me know if it is not.
July 27, 2010 at 3:10 pm
Using a local account for security can work. It complicates matters a bit when there is a need to deal with other computers on the network. It also complicates management of those accounts (no central management, who is responsible for the account, who can change the passwords, who knows the passwords).
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
July 27, 2010 at 3:27 pm
Thanks for your input. I appreciate it!
Thanks,
Teja
July 27, 2010 at 3:31 pm
You're welcome.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
May 21, 2013 at 9:55 am
Hello,
I have read that a SQL agent startup account should not be a admin on the server as a best practice it is not mentioned why or how vulnerable a SQL server can be if the agent is run under a admin account ?
What can the security issue be if the startup account of the sql server agent is a part of the window admin group.
Thanks all
May 21, 2013 at 10:36 pm
:exclamation: Note, this thread is almost 3 years old. :exclamation:
Maybe start a new thread next time?
http://www.sqlservercentral.com/Forums/Forum1526-1.aspx
-----
Hello,
I have read that a SQL agent startup account should not be a admin on the server as a best practice it is not mentioned why or how vulnerable a SQL server can be if the agent is run under a admin account ?
What can the security issue be if the startup account of the sql server agent is a part of the window admin group.
Thanks all
The recommendation falls under 'rule of least privilege.' You do not want processes running with a higher level of permissions than they need to do the work they are asked to do.
What can happen? Well, say you are in a shop where not all DBAs who are added to the sysadmin Role sp they can do admin tasks are granted access to the file system of the server hosting the SQL Server instance. They could theoretically setup jobs to do work with files they would not normally be able to access. Yes, this would likely constitute a violation of trust but if someone were to commit such an act you would want to them to have the toughest time they possibly could stealing information or otherwise doing damage to your environment. Same goes for the SQL Server service account for the same reasons. Sometimes it's not always a rogue DBA either. Sometimes accounts become compromised because of poor password maintenance, poor configuration management, social hacking, lots of other things.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply