October 14, 2009 at 5:04 pm
Kia ora,
When SQL 2k08 is insalled it creates some local windows accounts eg. for the runtime account:
"SQLServerMSSQLUser$<DB SERVER name>$MSSQLSERVER"
SQL 2005 did this aswell but added the above as a login (and others) with sysadmin rights...GAPING SECURITY HOLE. 2008 doesn't create them (*Yuss!) WIN for 2008 :-D.
I did blow all of these logins away as part of securing SQL 2005 servers I built, but anyways...on to my question.
My question is around the local windows groups (that were in SQL 2005 linked to these devil logins).
These provide access/control to SQL owned/required local resources on the os that are outside of SQL. I know this because when you delete the local windows groups: all types of weird s**t starts happening (well actually more like NOT happening).
My concern with leaving them there is that any system administrator can add himself/herself to this local windows group...so:
- what sort of things does that allow them to do at a SQL level?
- is this considered an inherant security risk, if so what can be done about it?
- is there a way you can remove them and still make SQL behave normally (short of making the runtime account an local admin....haaaah I can't belive I said that *laughs* )
Don't get me wrong a rogue system administrator can uninstall SQL if he/she really wants to but other than that and well stop the service, but can they compromise any SQL conponents/configurations by adding themselves to this group.
Rant Adjourned
Cheers,
Carlton..
January 4, 2010 at 6:46 am
not sure I can fully answer your question as I'm going through a similar review on a new sql 2008 cluster. I never allow builtin admins a login so that will clear out the risk of a local admin.
I make sure no local account on the server has a sysadmin account on the sql server. By only allowing ad accounts that should give a measure of protection. As to all the accounts that are created on sql server by the install I'm attempting to remove them. NT AUTHORITY\SYSTEM is required for SMS and auto update to apply updates to sql server - but if you don't use these I can't see you need the account. I'm attempting to remove all the others ( against some heavy opposition ) - I have them only as public rights so they don't seem to have anything to do as sysadmin.
As I say if there are no local accounts defined as sysadmin then a box admin isn't going to get to sql server.
Hope this helps?
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
January 5, 2010 at 3:34 am
As far as I know there is no documented procedure from Microsoft for removing these groups. Therefore if you do remove the groups you may put yourself outside of Microsoft support if you have a problem.
They are unlikely to walk away completely, but could well insist you reproduce your problem on a supported system before they will help you further - you need to decide if you want to be in this situation if you have a severity 1 problem. Personally, I always leave these groups in place.
If you are worried about local admins granting themself access to SQL Server this can only really be resolved via site standards and disiplinary processes. You need to get your management to issue a clear policy over who can have sysadmin rights in SQL Server, just as they (hopefully) already have over who can be a local or domain admin. If someone with local admin rights then makes themself a SQL sysadmin without authority you report this to your management to take whatever action they think appropriate. If your management are not fussed over who has sysadmin rights in SQL, then you have to accept their decision, because taking our own action to prevent this will put you outside of site policies.
Also, if SQL Server is properly configured there is no need for any SQL Service account to have local admin access. Likewise, if the DBA accounts are given the relevant Windows rights there is no need for a DBA account to have local admin access.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply