February 4, 2009 at 4:50 am
MOM and HP SIM are quite intensive databases to operate, especially MOM. I would recommend a high level of disk separation for your MOM database files for IO performance.
--
Andrew Hatfield
February 4, 2009 at 5:04 am
Thank you Andrew, I know it, and alerady configured 3 separate RAIDs - for OS and programs, for database data files, and for database logs. Everything's ready, except for unresolved question about accounts for SS services.
February 4, 2009 at 8:54 am
VEB (1/29/2009)
Hello,I run SQL Server 2005 instances under local service accounts for Servers, Agents, and Browser services in order to follow less privilege account practice. I have no problem so far. However, Best Practice Analyzer says "we recommend using domain service accounts". What conditions would require using domain accounts instead of local ones?
Thank you.
to your original question above the answer is simple. If you have a domain and sql is part of that domain use domain service accounts. If you dont have a domain use local acounts (as you have no domain).
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 4, 2009 at 9:33 am
Thank you, Perry Whittle.
The answer is simple for those pros who knows it. 🙂
If a newbie would just follow the answer, he/she will always be newbie. To become a pro, he/she has to understand, =why= the answer is so.
Why can't I use local accounts for SS services in a domain environment? What are the exact conditions for =each= of Server, Agent, Browser services, when running under a local account is unappropriate?
For example:
1. Server service account must be a domain account in the following scenarios/conditions:
1.1
1.2
In all other scenarios, the Server service account can be local.
2. Agent service account ...
3. Browser service account ...
I deeply appreciate you help.
February 4, 2009 at 10:10 am
VEB (2/4/2009)
Why can't I use local accounts for SS services in a domain environment?
why build a windows domain in the first place?
its not that you cant use local accounts, if that's what you want to do then fine. If you have gone to all the trouble of implementing an Active Directory domain then you would want to use this to manage all accounts even service accounts. As someone has already pointed out, if the sql server needs to access resources in the domain then a domain account is useful. It merely removes the need for maintaining accounts in multiple locations
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 4, 2009 at 1:38 pm
If a domain account is compromised, the domain is affected; if a local account is compromised, only a single machine is affected. Moreover, if the account is used only by a certain service, not a bunch of services, only that single service on a single machine would be affected. On the other hand, if a certain functionality needs domain account context, it will surely be given that; but only if it really needs.
That is target approach. Task's conditions, if you will. I'm seeking for the resolution of the task with the given conditions, but not for changing the conditions.
Any idea?
February 4, 2009 at 2:34 pm
Security is the best way to "un"-compromise an account. Regardless of the application, you should ALWAYS be aware of the rights granted and what those rights are going to mean once the service is logged in. Never, ever, ASSMUE that all will be OK. Be sure that you're going to be OK with the rights granted. Why take chances??? Who OWNS the data?
-- You can't be late until you show up.
February 4, 2009 at 2:57 pm
One thing you might need a domain account for is the ability to backup a database to a remote file share or to restore from a backup on a remote file share.
February 4, 2009 at 3:28 pm
If your SQL Server and users are in the same security zone (ie, internal production network) then there is no argument for or benefit to using local machine service accounts. all it does is increase management overhead and complexity.
another point that hasn't been mentioned is that if you are running local service accounts you can't take advantage of Kerberos as that is a domain provided service.
Rules of thumb
- if you're not in a domain - you can only use local service accounts
- if you are in a domain
+ and your sql server and users are in the same security zone - use domain accounts
+ if your sql server and users are in different security zones (ie sql server in a DMZ) then consider local service accounts unless you have deployed separate forests with relevant trusts
the above is a simplified ruleset, but should get you started.
--
Andrew Hatfield
February 4, 2009 at 3:41 pm
Thank you for the very certain answers.
This is what I'm asking for.
Michael Valentine Jones, do you mean account for Agent service, right?
Andrew, do you mean all 3 services (Server, Agent, Browser) should run under domain accounts?
February 4, 2009 at 3:49 pm
VEB (2/4/2009)
If a domain account is compromised, the domain is affected
its a low permissions account so no more a risk than any other domain user. Your windows system admin should be setting precedences there (password complexity, etc)
it would be easier for some one to gain access to a servers local SAM with Lophtcrack and gain logon credentials than bind to a DC and retrieve the AD catalog
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
February 4, 2009 at 4:28 pm
...Michael Valentine Jones, do you mean account for Agent service, right?...
I mean both accounts. Backup and restore commands run under the SQL Server Service account.
February 4, 2009 at 4:44 pm
Andrew, do you mean all 3 services (Server, Agent, Browser) should run under domain accounts?
Each service should run under its own account with only the privileges it requires to run.
SQL DBE, AGT, BRW, FTS, SSIS, Analysis Services
Leave Active Directory Helper as NETWORK SERVICE
--
Andrew Hatfield
February 6, 2009 at 10:33 am
Thank you for your answers.
So far, you enumerate 2 reasons (besides convenience) to use domain accounts instead of local ones:
- backup/restore using remote file share (not my case);
- ability to use Kerberos (not sure).
"...there is no argument for or benefit to using local machine service accounts. all it does is increase management overhead and complexity."
Andrew, if each service has its own account (multiply by number of instances) storing accounts locally or on AD doesn't make difference in terms of management overhead and complexity. Moreover, having bunch of service accounts (that are specific to a single machine) stored in AD (which is "network-wide") will increase management overhead and complexity.
"Each service should run under its own account with only the privileges it requires to run."
No doubt, whether those accounts are local or domain, they will surely be only simple Users, so that SS Setup or SS Config Mgr will grant them only necessary privileges. (Complex passwords are implied.)
Adhering to this least-privilege-practice was the reason of my question - I just don't want to use domain accounts if using the local ones would be sufficient.
February 7, 2009 at 6:23 am
VEB
you really are making more complex than it actually is. The whole point of a domain is to centrally manage obects within the domain. If your SQL server is part of a domain then it makes sense to use AD
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 15 posts - 16 through 30 (of 41 total)
You must be logged in to reply to this topic. Login to reply