Have You Checked Your Service Accounts?
When you set up SQL Server, you also set up services that support various features. From Analysis Services to Reporting Services to SQL Agent and other features and functionality, these features get established with accounts that they use to login to the server.
It’s important to review those accounts after you’ve brought up your SQL Server and had some time to settle in with it a bit – especially if SQL Server isn’t your full-time gig. It’s not that the service accounts are tied to your experience with SQL Server, it’s that many times when setting up SQL Server, these accounts are set up with more access than needed to make things a bit easier during installation. Just a couple of things to consider:
1. Make sure the service accounts are NOT user accounts. The reasoning for this is two-fold. First, you don’t want to have the processes have too much access to your systems. Typical access for a "real" user login often provides far more access than is needed for these services, giving a back-door login (if someone knows the service login, they get more access than they should). Second, many times the service accounts need more low-level access to directories and files than is typically allocated to a user account. This means that if the service logs in with the user account, that user account will have too liberal access to possibly key system files. In short, break them apart, allocate privileges as needed, and *only* as needed to both the user account and the service account.
2. If you associate a different service account with each service (rather than a single account for all services), you can add an additional level of security. If someone gets in on one account, they won’t automatically get the access associated with the other user accounts. Limited access on "proper" use, limited access on improper use is a good approach.
Take a few minutes and look over the accounts associated with your systems. Make sure you have things as closely defined as possible.
More information: http://support.microsoft.com/kb/283811
Featured Article(s)
Undocumented SQL Server 2008 Full-Text Search Stored Procedures
In this article, Alexander Chigrik looks at three undocumented full-text search stored procedures that shipped with SQL Server 2008.
Last Call –
Can You Help? We’re Considering Some SSWUG Features…
…but need to know if you think they would help in your work with SQL Server. These would be open-access features.
I’d like to add the ability to start tracking trend-type items on your servers. We’d provide you with a quick script to run that would return a few bits of information. We’d provide you with a place to log the stats (things like CPU utilization, disk space, other performance and growth type things) and then provide you with some online tools to forecast out in the future based on your actual values entered. Over time, the trends would be evident, and we could help with articles, resources, scripts, video how-to and such – all the stuff on SSWUG – that relates to the growth of your systems, or just plan ongoing support of your systems.
You end up with some nice trending and support tools – available online. You’d also end up with related materials – articles, scripts and so-on – that would pertain to the things that are happening on your system.
Would this be interesting? Would you potentially use it?
It’s the start of online utilities (I’ll have a lot more on this going forward) based on the site so you have access to them anywhere, anytime and with backup resources to explain and explore what’s happening on your systems.
But I need to know what you think. If you could, could you drop me an email and let me know your thoughts?
Email me at swynk@sswug.org and let me know what you think.