April 2, 2012 at 9:48 pm
What are the best practices of service account in production, test, dev environments for mssqlservice, agent service , browser service ...
please specify
Sagar Sonawane
** Every DBA has his day!!:cool:
April 3, 2012 at 12:42 am
Its the same for all, a domain accout with the minimum privlages, the account needs to be able to run as a service if you apply restricted group policies accross your domain
April 3, 2012 at 5:42 am
Depending on what you're trying to do, you may want to use a different account for production and non-production environments in order to prevent any chance of a non-production environment accessing production inappropriately. Other than that, I'd follow the advice of the previous post.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 4, 2012 at 9:41 am
In addition to that, only change the service accounts using SQL Server Confiduration Manager. If you change it through the services.msc window, you will create problems.
Jared
CE - Microsoft
April 4, 2012 at 10:37 am
The following goes into some detail...
http://msdn.microsoft.com/en-us/library/ms143504%28v=sql.105%29.aspx
April 4, 2012 at 11:08 pm
Replies are appreciable..... Thank you guys...
Sagar Sonawane
** Every DBA has his day!!:cool:
February 25, 2014 at 9:27 am
Hopefully this post isn't too old to continue the discussion. I've read that it's best practice that every SQL Server service account on every server have its own domain account. No explanation as to WHY, however. This method in a DEV, TEST, PROD environment could result in a great number of accounts.
The earlier comment about DEV and TEST services having different accounts than PROD makes sense. But should each production server have its own domain account sets? I'm curious how people are handling this. I don't want to ask for a lot of accounts that may not be needed. I don't want to mindlessly follow a "best practice" without understanding why it's a best practice. On the other hand, if there's a good reason, I don't want to be responsible for something that would have been prevented by following the best practice.
What are people doing in their shops? Thanks,
February 25, 2014 at 9:48 am
RonKyle (2/25/2014)
Hopefully this post isn't too old to continue the discussion. I've read that it's best practice that every SQL Server service account on every server have its own domain account. No explanation as to WHY, however. This method in a DEV, TEST, PROD environment could result in a great number of accounts.The earlier comment about DEV and TEST services having different accounts than PROD makes sense. But should each production server have its own domain account sets? I'm curious how people are handling this. I don't want to ask for a lot of accounts that may not be needed. I don't want to mindlessly follow a "best practice" without understanding why it's a best practice. On the other hand, if there's a good reason, I don't want to be responsible for something that would have been prevented by following the best practice.
What are people doing in their shops? Thanks,
It's almost a two year old thread. The only people likely to see your follow-up are the ones who have already posted. If you really want to get more information, I'd suggest opening your own thread.
However, not to leave you hanging, no, I wouldn't suggest a different login for every production box, no. But... if you're really, really concerned with security, it is more secure. It's also a heck of a lot more to manage. We didn't do this at my previous organization where we had hundreds of production servers. There were some different logins to wall off certain servers, but other than that, most ran under a common login (by the way, I didn't have access to that login. It was reserved to the security people. We never knew what the password was or anything).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 25, 2014 at 9:55 am
It's almost a two year old thread.
Probaby shouldn't admit I looked at a last logged in date rather than the posted date. Thanks for the response. I will start a new thread.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply