Job / Database Owners
-
Tuesday, April 24, 2012 12:07 PM
I have a question regarding database and job owners. For a while I've noticed that when I create jobs and databases my network login is listed as the owner of the database. For example if I right click a database and choose properties it lists my login as the owner. This doesn't really bother me, except I was wondering if it's best practice. I'm concerned if I leave the organization it will cause things to break if my network account was deactivated.
I've done some research and the security best practices document for 2008 R2 states
Have distinct owners for databases; not all databases should be owned by sa.
However, I've also noticed several posts in forums, blogs, etc that state sa should be used for database owners/jobs. They've noted that if you use a network account it could be deactivated at some point and cause problems. And, using sa isn't really a security issue because if someone had the sa login they'd be able to control the server anyway.
Just wondering what the best way to set up jobs and databases on my servers is. Thanks in advance!
All Replies
-
Tuesday, April 24, 2012 12:25 PM
Hello,
If your network account owns a database, or even objects inside of that database and your login is disabled, deleted, or otherwise gone the database will still function and the objecst will still exist. This is different for job owners - if the login no longer exists or is disabled, the jobs will fail and point to the login not being valid.
Where the database owner issue comes into play is if a service account is used for an application/process and is the owner of said database. As the owner there are certain security privs that it has (it can do pretty much anything to the database it owns) which may be needed for the application/process to run correctly. If this account is disabled I would assume the application or process to fail or have incorrect rights.
You'll find many different opinions on who should own certain resources. For jobs, my personal preference is whichever application or person needs the job is who owns it. All of my jobs (other than certain system ones I write) have an owner that is tied to its business function or process. The same goes for the database, if needed as there are extra rights the owner has which may be too much. Most 3rd party vendors I deal with make you, by either checking for ownership or not knowing rights needed, have the login they use own the database.
-Sean
-
Tuesday, April 24, 2012 12:31 PMModerator
I have a question regarding database and job owners. For a while I've noticed that when I create jobs and databases my network login is listed as the owner of the database. For example if I right click a database and choose properties it lists my login as the owner. This doesn't really bother me, except I was wondering if it's best practice. I'm concerned if I leave the organization it will cause things to break if my network account was deactivated.
This is why it's best to change the database owner after creation and avoid using an individual's AD account as an owner. See http://weblogs.sqlteam.com/dang/archive/2008/01/13/Database-Owner-Troubles.aspx.
If only sysadmin role members can create objects, I think 'sa' is acceptable unless you have other requirements. Alternatively, you can use a specialized AD account (or managed service account) or a SQL login (perhaps disabled) for databaswe ownership purposes.
Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/
- Marked As Answer by Nate31112 Tuesday, April 24, 2012 12:44 PM
-
Tuesday, April 24, 2012 12:44 PM
Thanks Sean, Dan!
Dan, great article! In our environment only sysadmins can create object so it looks like going to sa is going to be ok.
-
Tuesday, April 24, 2012 5:03 PMI prefer these things owned by sa. Regarding jobs, watch out for this: http://sqlblog.com/blogs/tibor_karaszi/archive/2011/10/06/who-owns-your-jobs.aspx

