Service acounts for SQL Server

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2008 » SQL Server 2008 - General » Service acounts for SQL Server

Service acounts for SQL Server

Rate Topic

Display Mode

Topic Options

Author

Message

SQListic

Posted Tuesday, August 07, 2012 4:37 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, May 14, 2013 2:42 PM
Points: 193, Visits: 773

Hi Experts,

I got a request for creating 5 service accounts for sql servre

Question 1) these accounts shoulb be AD accounts,am i right?
Question 2) Creating Service accounts is job of DBA? I think it should be done by systems/network team(plz clarify)
Question 3) These same 5 accounts will be used in dev and future prod box, condition is that service accounts password should be different in DEV and QA, how can i fulfill this?

Post #1341599

MyDoggieJessie

Posted Tuesday, August 07, 2012 10:50 PM

SSCrazy

Group: General Forum Members
Last Login: Today @ 2:19 PM
Points: 2,037, Visits: 3,761

Sqlism (8/7/2012)
Question 1) these accounts shoulb be AD accounts,am i right?
Question 2) Creating Service accounts is job of DBA? I think it should be done by systems/network team(plz clarify)
Question 3) These same 5 accounts will be used in dev and future prod box, condition is that service accounts password should be different in DEV and QA, how can i fulfill this?

#1 - It depends on how things are set up at your company, but I would recommend AD accounts, configured as ones that cannot be locked out. Another note, these accounts should not be granted logon to the server/workstation.

#2 - The DBA/team can request the creation of AD accounts, but in my experience it's the System/Network team. However if the system/network team is going to allow you to do it and grant you access to do so, I'd be tickled...

#3 - ??? How can you fulfill it? Can't you just ask them to make the account passwords different ???

______________________________________________________________________________
"Never argue with an idiot; They'll drag you down to their level and beat you with experience" Wink

Post #1341670

SQListic

Posted Wednesday, August 08, 2012 2:52 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, May 14, 2013 2:42 PM
Points: 193, Visits: 773

Thank you so much for the help!

Post #1342235

MyDoggieJessie

Posted Wednesday, August 08, 2012 2:57 PM

SSCrazy

Group: General Forum Members
Last Login: Today @ 2:19 PM
Points: 2,037, Visits: 3,761

You're very welcome, best of luck with it Hehe

______________________________________________________________________________
"Never argue with an idiot; They'll drag you down to their level and beat you with experience" Wink

Post #1342247

Nadrek

Posted Thursday, August 09, 2012 2:05 PM

Say Hey Kid

Group: General Forum Members
Last Login: 2 days ago @ 12:28 PM
Points: 675, Visits: 2,031

Don't forget to make sure to set Group Policy up for these accounts as you see fit, and if need be, set up Proxy accounts also.

Personally, I tend to make sure they're on the lists for:
Act as part of the operating system
Adjust memory quotas for a process
Bypass traverse checking
Lock pages in memory
Log on as a service
Perform volume maintenance tasks
Replace a process level token

Some of the above were from working with proxy users, as well, and may not be required for you. I understand there is some debate about Lock pages in memory, as well.

Note that one account gets one and only one password - use a different account username for Prod than you do for QA as you do for Dev.

For passwords, they're service accounts, set and forget, so make them insanely long, complex and random, then copy/paste them in.

I disagree about disabling account lockout - I'd rather have the security in case some tries a dictionary, hybrid rules based dictionary, or even pure brute force attack. If you can manage to keep the username/passwords secret, and only use one per machine/environment, then you shouldn't have much to worry about them being locked out by other employees.

As mentioned above turn off the "log on as a user" right, and definitely don't make them domain admins or local admins, so they're not as useful to a hacker, and not as tempting to other employees to use as shortcuts.

Post #1342996

MyDoggieJessie

Posted Thursday, August 09, 2012 2:24 PM

SSCrazy

Group: General Forum Members
Last Login: Today @ 2:19 PM
Points: 2,037, Visits: 3,761

+1 Nadrek

______________________________________________________________________________
"Never argue with an idiot; They'll drag you down to their level and beat you with experience" Wink

Post #1343020

« Prev Topic | Next Topic »

Permissions