Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Separate Accounts


Separate Accounts

Author
Message
Steve Jones
Steve Jones
SSC-Forever
SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)SSC-Forever (40K reputation)

Group: Administrators
Points: 40639 Visits: 18851
Comments posted to this topic are about the item Separate Accounts

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
AVX
AVX
SSC-Enthusiastic
SSC-Enthusiastic (159 reputation)SSC-Enthusiastic (159 reputation)SSC-Enthusiastic (159 reputation)SSC-Enthusiastic (159 reputation)SSC-Enthusiastic (159 reputation)SSC-Enthusiastic (159 reputation)SSC-Enthusiastic (159 reputation)SSC-Enthusiastic (159 reputation)

Group: General Forum Members
Points: 159 Visits: 291
Hi, It is nice to know that "you are not alone".
I too believe in the separate service account per instance, although you're "do not store the password and change it when needed" seems to be a bit extreme.
ddriver
ddriver
SSC Rookie
SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)SSC Rookie (37 reputation)

Group: General Forum Members
Points: 37 Visits: 250
I really like that idea and I will pass it on to our DBA's and admins.
Mike Palecek
Mike Palecek
SSC Eights!
SSC Eights! (856 reputation)SSC Eights! (856 reputation)SSC Eights! (856 reputation)SSC Eights! (856 reputation)SSC Eights! (856 reputation)SSC Eights! (856 reputation)SSC Eights! (856 reputation)SSC Eights! (856 reputation)

Group: General Forum Members
Points: 856 Visits: 818
I will admit that I do not have very many instances under my control, but I very much agree with separate accounts and not storing the password. The administrative time spent on password resets, etc. I do not think is too much. The administrative time spent on resting user's forgotten passwords is acceptable so why wouldn't this be?
Grant Bradley
Grant Bradley
Grasshopper
Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)Grasshopper (17 reputation)

Group: General Forum Members
Points: 17 Visits: 193
I think at the least should be separate account for SQL, there by separating the sql db from system admin.
If separate instanances managed by different people then should also have separate accounts for each.
Markus
Markus
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1830 Visits: 3730
We have the same account to run SQL Server for all production and a seperate ID for non production. I was going to have a new account created and used for SQL2012 and continue that with a new account for each new version of SQL Server....



chrisfradenburg
chrisfradenburg
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1768 Visits: 2060
When I started here the same account was used for all servers and services. All new servers get new accounts created though and we're working on changing the account on old servers. We do use the same account for all services on a box.

The only reason it's a pain to do it this way is the IS Security team is so far behind that it can take a couple weeks to get a new service account created. But it's worth it knowing that if one account gets compromised or locked out that it's not going to affect over 150 servers in our hospital system.
rrcottin
rrcottin
Forum Newbie
Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)Forum Newbie (1 reputation)

Group: General Forum Members
Points: 1 Visits: 51
The whole strategy makes implementing Kerberos in your environment a little tougher.
thadeushuck
thadeushuck
SSC-Enthusiastic
SSC-Enthusiastic (177 reputation)SSC-Enthusiastic (177 reputation)SSC-Enthusiastic (177 reputation)SSC-Enthusiastic (177 reputation)SSC-Enthusiastic (177 reputation)SSC-Enthusiastic (177 reputation)SSC-Enthusiastic (177 reputation)SSC-Enthusiastic (177 reputation)

Group: General Forum Members
Points: 177 Visits: 164
If the password of a SQL service account is THAT important to your companies defense of it's data then you are already inside a hurt locker if you ask me but I do know we'd have to change our SOX/SAS/PCI/GSA account documentation to even think about doing this and it would result in god only knows how many issues since we have automated the security model around a 90 day change of service accounts, instance spawning automation and self serivice account management for our clients... I guess for a small shop with under 100 servers this might be a no brainer, but with VM the days of counting servers on two hands are gone...
Tillymint
Tillymint
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 493
We used to have one service account for all instances, but decided a while ago that was a risky strategy. We are now moving to one account per instance, or per pair of instances where we are mirroring databases.
Our Windows Ops team have given us management of an AD group to create these accounts in to.
We do store the passwords for these service accounts, but that's more out of habit than for any specific reason.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search