471,853 Members | 821 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,853 software developers and data experts.

Risks of single MSSQL domain account for mult servers?

Greetings:

I am trying to conceive what risks might be created by running
multiple SQL servers within a domain under a single domain account, as
opposed to 1) running under the local service account or 2) multiple
domain service accounts.

In this case, all the SQL servers are SQL2000 running on Win2003. The
service account is assigned only to the "Domain Users" group.

We do use linked server calls, and I have played and suceeded getting
Kereberos up to avoid double hop issues when using Windows Auth. In
fact, this is one of the reasons that sparked the question in my mind
-- in all the MS Kerebos SQL<->SQL examples, the SQL servers run under
a unique service account.
As an aside, most of the servers are "line of business" servers, but
HR runs under a unique server with more sensitive information. I don't
really think that merits a seperate service account, but again, I
could well be missing something.
I mostly looking for food for thought, but concrete examples of
gotchas would be appreciated.

Thanks all.

d.
Jul 20 '05 #1
2 2779
D (or should I call you d?),

One drawback of using a single service account is that a breach of security
on that account means a breach on all of your SQL Servers.

(Yes, it is easier to only have one account to manage. Also, once upon a
time (a long time ago) it made replication easier.)

Russell Fields
"D Barry" <go****@dcbarry.com> wrote in message
news:6d**************************@posting.google.c om...
Greetings:

I am trying to conceive what risks might be created by running
multiple SQL servers within a domain under a single domain account, as
opposed to 1) running under the local service account or 2) multiple
domain service accounts.

In this case, all the SQL servers are SQL2000 running on Win2003. The
service account is assigned only to the "Domain Users" group.

We do use linked server calls, and I have played and suceeded getting
Kereberos up to avoid double hop issues when using Windows Auth. In
fact, this is one of the reasons that sparked the question in my mind
-- in all the MS Kerebos SQL<->SQL examples, the SQL servers run under
a unique service account.
As an aside, most of the servers are "line of business" servers, but
HR runs under a unique server with more sensitive information. I don't
really think that merits a seperate service account, but again, I
could well be missing something.
I mostly looking for food for thought, but concrete examples of
gotchas would be appreciated.

Thanks all.

d.

Jul 20 '05 #2
Russell:

It's "d.". "D." is just too pompous... ;-)

I should have stated the breach against one is a breach of all
arugument. (We do use nice long complex passwords.) I'm looking for
other

"Russell Fields" <Ru***********@NoMailPlease.Com> wrote in message news:<ub**************@TK2MSFTNGP10.phx.gbl>...
D (or should I call you d?),

One drawback of using a single service account is that a breach of security
on that account means a breach on all of your SQL Servers.

(Yes, it is easier to only have one account to manage. Also, once upon a
time (a long time ago) it made replication easier.)

Russell Fields
"D Barry" <go****@dcbarry.com> wrote in message
news:6d**************************@posting.google.c om...
Greetings:

I am trying to conceive what risks might be created by running
multiple SQL servers within a domain under a single domain account, as
opposed to 1) running under the local service account or 2) multiple
domain service accounts.
<snip>
Thanks all.

d.

Jul 20 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Philip Nelson | last post: by
9 posts views Thread by Phillip B Oldham | last post: by
NeoPa
reply views Thread by NeoPa | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.