Your summary is correct. BTW, the same rules apply when using the local
SYSTEM account in terms of the credentials it uses on the network. The
great advantage of Network Service is that to the local machine, it has very
few privileges and can do much less damage locally on the server if
compromised. That's why it was invented. Local Service is like Network
Service, but it doesn't have any network credentials at all, so you can't
use it in services that access the network in any reasonable way.

When you implement a trusted subsytem security architecture, which is what
you are doing when you use a fixed account to access your backend data
resources, there are many debates over whether to use a fixed service
account vs Network Service. Generally, I think it is best to use Network
Service when possible as it gives you one less password to manage, it has a
lot of useful ACLs and group memberships out of the box as well as a bunch
of useful local security policy privilege assignments such as "run as a
service" and "generate security audits". Also, the machine account will
generally (but not always) get the correct Kerberos servicePrincipalNames
set for various services that are installed on the machine, which allows you
to do Kerberos auth more easily. This is a good thing.

You can do all of those things manually with a fixed service account, but
there is more effort.

In some cases, you really do need to use a fixed service account do to
something you are doing with load balancing or something where you need two
instances of a service on two different boxes to have the same Kerberos

You can solve the SQL permissioning issue either way by creating an
additional abstraction of a group to delegate permissions to. Then you can
add whatever accounts you need to that group and it ends up not matter much
to SQL.

So, in summary, it depends. :) It is good to know your options and what
the affects might be of pulling one lever vs. another.

Joe K.

Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
"Craig Wagner" <MSDNNospam207@xxxxxxxxxxxxx> wrote in message
It was as you suspected. I wasn't seeing the forest for the trees. I could
have sworn I double-checked all the settings in every location, but I
the web.config where the database connection string was. At home it was
hitting a SQL Server on the same machine as the web app. I changed it to
other database server and then I saw the domain\machine$ being used to

So to summarize and confirm what I've discovered...

If you have an application configured to run as Network Service:

- domain\machine$ is the credentials that are exposed outside of the
on which the app is running

- NT AUTHORITY\NETWORK SERVICE is the credentials exposed when accessing
resources on the same machine on which the app is running

- when setting up the SQL login (using SQL Management Studio), I cannot
browse for domain\machine$ in Active Directory, I must know the name and
manually type it into the New Login dialog

One more question regarding Best Practices.

If I'm setting up my app on a web farm I have two choices:

1. Run the app as Network Service on each web server and grant each web
server's machine account access to the SQL Server.

2. Create a custom domain account and run the app as that identity on each
web server. Then I only have to create a single login on the SQL Server.

From an on-going operations perspective, it seems like option (2) is the
better way to go, as I don't have to add/remove logins from the SQL Server
when I add/remove machines from the web farm. But I don't know what
I may create or conveniences I may lose by going that route.

As always, if you know of a source just point me in the right direction.
I've not been able to find definitive, plain English answers to these

"Joe Kaplan" wrote:

Are you sure the web app is trying to hit SQL on the network? The
service account is supposed to use the credentials of the machine account
when it accesses the network to use a remote resource. What you are
at work is what I'd expect and what you are seeing at home is a bit
to me. Any other environmental differences?


Relevant Pages

  • Re: How do you wintrolls...
    ... the system will automatically log in with those credentials from then on. ... account credentials, exactly what files do you think he wants to access? ... When Vista asks you if a newly discovered network is 'Public' or 'Private', this is one of the things it is doing. ... I have not found any necessary functionality in the menu bar; as far as I can see the only the functions that are in the menu bar are the greybeard switch for the old-style status bar and, oddly, the 'Invert Selection' command- which strictly speaking can always by done manually. ...
  • Re: Accessing security information from an authentication provider
    ... In the meantime it occured to me how to transmit the token to the ... If you only need a machine local account and no network credentials, ...
  • Re: backing up to network share issue.
    ... I guess I was confused by your later text where I read it as if you stated that it would be the Agent account ... Tibor Karaszi, SQL Server MVP ... >> impersonation when it accesses the backup file on behalf of the SQL Server ... >>> As Tibor stated, this is not an SQL Server issue, it is a network ...
  • Re: Unable to Backup on Network
    ... service accoutn from the 'Local System' account to a specific account. ... I like to log in to the SQL server console as the service account to test ... > The operating system on which my SQL Server 2000 is there is Windows 2000> Server while i want to take the backup on another computer on network which> also has same operating system. ...
  • Re: Login via Anonymous Authentication via IIS
    ... "Dan Guzman" wrote: ... the network). ... given the login failed message references that account;-) ... SQL Server MVP ...