SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Separate Accounts


Separate Accounts

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)SSC Guru (224K reputation)

Group: Administrators
Points: 224084 Visits: 19634
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 Veteran
SSC Veteran (232 reputation)SSC Veteran (232 reputation)SSC Veteran (232 reputation)SSC Veteran (232 reputation)SSC Veteran (232 reputation)SSC Veteran (232 reputation)SSC Veteran (232 reputation)SSC Veteran (232 reputation)

Group: General Forum Members
Points: 232 Visits: 304
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-Enthusiastic
SSC-Enthusiastic (107 reputation)SSC-Enthusiastic (107 reputation)SSC-Enthusiastic (107 reputation)SSC-Enthusiastic (107 reputation)SSC-Enthusiastic (107 reputation)SSC-Enthusiastic (107 reputation)SSC-Enthusiastic (107 reputation)SSC-Enthusiastic (107 reputation)

Group: General Forum Members
Points: 107 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! (998 reputation)SSC Eights! (998 reputation)SSC Eights! (998 reputation)SSC Eights! (998 reputation)SSC Eights! (998 reputation)SSC Eights! (998 reputation)SSC Eights! (998 reputation)SSC Eights! (998 reputation)

Group: General Forum Members
Points: 998 Visits: 823
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
Valued Member
Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)Valued Member (65 reputation)

Group: General Forum Members
Points: 65 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.
Summer90
Summer90
SSChampion
SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)SSChampion (11K reputation)

Group: General Forum Members
Points: 11604 Visits: 3863
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
SSCarpal Tunnel
SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)SSCarpal Tunnel (4.1K reputation)

Group: General Forum Members
Points: 4070 Visits: 2080
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
Grasshopper
Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)Grasshopper (11 reputation)

Group: General Forum Members
Points: 11 Visits: 51
The whole strategy makes implementing Kerberos in your environment a little tougher.
thadeushuck
thadeushuck
Mr or Mrs. 500
Mr or Mrs. 500 (571 reputation)Mr or Mrs. 500 (571 reputation)Mr or Mrs. 500 (571 reputation)Mr or Mrs. 500 (571 reputation)Mr or Mrs. 500 (571 reputation)Mr or Mrs. 500 (571 reputation)Mr or Mrs. 500 (571 reputation)Mr or Mrs. 500 (571 reputation)

Group: General Forum Members
Points: 571 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
Grasshopper
Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)

Group: General Forum Members
Points: 21 Visits: 526
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