Being late into the discussion, and not really having time to write a
lot, quick comments:
>> The problem is that Unix users are used to that concept. Even if I
>assume
>> that
>
>The problem is that not enough Windows users are used to that concept.
>Not too long ago, there were a whole slew of NT servers that
>were rooted
>because the admins left the default SA password unchanged on a SQL
>server that was running on the SYSTEM account.
Not too long ago? Happens *every day*. And it's one of the (if not
*the*) most common ways to attack a windows network from the internet.
>As Microsoft (finally) is starting to become more security conscious
>(please no flames), you should probably start to see more of
>this in the
>future from other products both by Microsoft and 3rd parties.
From what I hear there is plenty of discussion inside MS of perhaps
forbidding both local system and any admin privilege account from
running SQL Server 2005 by release time. No decisions, but serious
discussions. So they learn some things from us :-)
They're also pushing fairly hard for not using the new "Network Service"
account in Windows 2003. For the simple reason that *other use it*. The
best practice is not only to run a low-priv acocun, but to run on it's
own low priv account. Not likely they will (or can) prevent this, but
it's definitly in the docs.
> As for
>workstation development, it really only takes about 2 minutes to set up
>an account and install the server to that account. Plus, most of the
>grunt work can be handled (at some point) by the installer.
If we actually want the installer to set up the account. I'd rather have
the admin set up the account, and have the installer give it "log on as
service" if required. But sure, it can be done.
As someone else said, we could also investigate possibly shipping our
own "runas thingie" that will only make it run lower priv. But this is
not easy. It requires some security privileges that you are *NOT*
granted even as an administrator by default. The RunAs program manages
this by connecting to the RunAs *service*, which run as local system,
and telling that one to do the logon. And since this service deoesn't
exist on NT4, we'd be back where we started...
I ran into this same problem with doing the installer - it needs to call
initdb, and the installer runs as high-priv account... Haven't quite
figured out how to handle that now - the snapshot I'm working off at
home only does initdb on 2000/XP/2003 for the moment. If someone has any
good ideas on this, please let me know.
//Magnus
