SQL Server Performance

  • Home
  • Articles
  • Forums
  • Tips
  • Training
  • FAQ's
  • Blogs
  • Software
  • Books
  • About Us
RSS Feeds
Sign in | Join


FAQ Topics

All FAQ's
General DBA
General Developer
DBA Performance Tuning
Developer Performance Tuning
Clustering
Error Messages

USEFUL SITES :

ASP.NET Tutorials
Windows and SQL Azure Tutorials
Cloud Hosting Magazine
SharePoint Tutorials
Windows Server Help

Write for Us

Share your SQL Server knowledge with others and raise your profile in the community More...
Latest Articles

A High Level Comparison Between Oracle and SQL Server - Part ...
A High Level Comparison Between Oracle and SQL Server - Part ...
A High Level Comparison Between Oracle and SQL Server - Part ...
A High Level Comparison Between Oracle and SQL Server

More     
 
Latest FAQ's

Add Node to A SQL Server failover Cluster failed with invalid ...
SQL Server Destination remote server error
Setting Up Data And Log Files For SQL Server
Will Check Constraints Improve Database Performance?

More     
   
Latest Software Reviews

dbForge Review
Spotlight on ApexSQL Diff - Server-based database comparison tool ...
Spotlight on ApexSQL Data Diff - Server-based database comparison tool ...
Spotlight on ApexSQL Doc 2008

More     

For optimum security, is it recommended to use a single domain account the SQL Server instances in a network?



Question

Our team supports 150+ SQL Server 2000/2005 instances company-wide. In order to make it easier to manage the services accounts, we use the same domain account for all the SQL Services. This domain account has been granted both local machine and SA privileges.

Recently, somebody raised a question about the wisdom of using the same domain account for all SQL Servers, suggesting that it might be a poor security practice. In our case, what is the best security practice?

Answer

In a perfect world, assuming we want as perfect as security as we can attain, then we would want to assign a separate domain user account for each active SQL Server service, and for each individual instance. Of course, this is not practical.

The next best option, considering real world realities, would be to assign a different domain account for each of the services, but use the same domain accounts for all SQL Server instances. This is a more practical approach.

One of the things to keep in mind about service accounts is that they should not be members of the Domain Administrators Active Directory global group. In addition, service accounts should not be members of the local administrators local group of each individual SQL Server. In most cases, SQL Server services will work fine with no special rights and permissions. But not all cases. In some cases, SQL Server service accounts need more than basic rights and permissions, which is discussed in the following article. While this article covers SQL Server 2000, it also applies to SQL Server 2005.

https://www.microsoft.com/sql/prodinfo/previousversions/securingsqlserver.mspx

So my suggestion is to use separate domain accounts for each service, but use these same domain accounts for all of your instances. In addition, ensure that these domain accounts don't have more rights and permissions that they need to properly function. Following this suggestion, along other SQL Server best security practices, will minimize security risks to your environment.








C# Help and Tutorials | PHP MySQL Tutorial | Sharepoint Tutorial | Azure Tutorial | Cloud Hosting Magazine | ASP.NET Tutorials | Windows Server Help | Windows Phone Pro | Silverlight Ace | Visual Studio Tutorials | Home | Peformance Articles | Audit Articles | Business Intelligence Articles | Clustering Articles | Developer Articles | Reporting Services Articles | DBA Articles | ASP.NET / ADO.NET Articles | SQL Server Training Videos | DBA FAQ's | Developer Peformance FAQ's | DBA Peformance FAQ's | Developer FAQ's | Clustering FAQ's | Error Messages | Audit Tool Reviews | Backup Tool Reviews | Coding Tool Reviews | Compare Tool Reviews | Documentation Tool Reviews | Design Tool Reviews | Monitoring Tool Reviews | Log Tool Reviews | Reporting Tool Reviews | Clustering Tool Reviews | Security Tool Reviews | Change Management Tool Reviews | Remote Access Tool Reviews | Book Reviews | Security Tool Reviews | ADO.NET / ASP.NET | Administration | Analysis/OLAP Services | Application Development | Configuration | Components | ETL | Hardware | High Availability | Hints | Index | Misc | Operating Systems | Performance Tuning | Replication | T-SQL | Views


              © 2010 Jude O'Kelly. All rights reserved