Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

Separate Accounts Expand / Collapse
Author
Message
Posted Thursday, August 9, 2012 9:44 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 5:59 PM
Points: 31,082, Visits: 15,529
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
Post #1343121
Posted Friday, August 10, 2012 2:28 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, September 5, 2014 2:51 AM
Points: 112, Visits: 210
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.
Post #1343195
Posted Friday, August 10, 2012 5:49 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 8:29 AM
Points: 28, Visits: 220
I really like that idea and I will pass it on to our DBA's and admins.
Post #1343317
Posted Friday, August 10, 2012 6:12 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, September 26, 2014 6:37 AM
Points: 845, Visits: 735
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?
Post #1343334
Posted Friday, August 10, 2012 6:40 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Yesterday @ 3:22 PM
Points: 17, Visits: 154
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.
Post #1343349
Posted Friday, August 10, 2012 6:49 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 9:18 AM
Points: 1,285, Visits: 2,829
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....


Post #1343355
Posted Friday, August 10, 2012 6:59 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Monday, August 4, 2014 8:10 AM
Points: 1,635, Visits: 1,972
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.
Post #1343363
Posted Friday, August 10, 2012 7:10 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: 2 days ago @ 4:57 PM
Points: 1, Visits: 44
The whole strategy makes implementing Kerberos in your environment a little tougher.
Post #1343372
Posted Friday, August 10, 2012 7:18 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, November 1, 2013 1:47 PM
Points: 167, 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...
Post #1343379
Posted Friday, August 10, 2012 7:40 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, July 15, 2014 4:49 AM
Points: 5, Visits: 440
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.
Post #1343395
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse