Using the NetworkService account as a trusted login to SQL Server

[Guest]

IIS 6.0 dy default uses the NetworkService account as the process identity
for ASP.NET apps. Does anyone know if it is possible to make a trusted
connection to SQL Server using the NetworkService account.

As far as I know (and I'm no expert on Active Directory) there is an Active
Directory group called something like "Computers in the Domain" that you
could add to a local group on the SQL Server and make the local group a
trusted login.

I am thinking that if the NetworkService account is a member of the
"Computers in the domain" group then when the ASP.NET worker process on IIS6
attempts to connect to the SQL Server it will take on the identity of the
host computer and be granted access to the SQL Server as the SQL Server local
group.

I don't have access to an Active Directory domain infrastructure to test
this out, does anyone have any comments.

Colin

 

[Guest]

Possible? sure!

Wise? Absolutely not.

There are other options. Impersonation works in some instances. If you need
a particular account and do not want to go to mixed mode, you can spawn a
thread with another identity. One of the easiest ways is to involve COM+ and
assign an account to the package. A little perf loss, but no security hole.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

Thanks for the reply.

I appreciate the reply.

Possible? sure!

I guess the real reason for the post was to find out if this does in fact
work (I've never been able to actually test this so I still don't know if it
does in fact work).

Wise? Absolutely not.

Perhaps, but I should have mentioned that the main reason for me asking is
that most of the apps I work on are intranet based and network admins seem to
detest the concept of a non-trusted connection to SQL Server, they also hate
the concept of having to store the userid and password of an account
"somewhere" to allow a trusted connection.

One of the easiest ways is to involve COM+ and assign an account to the package. A little perf loss, but no security hole.

The main problem here is if you are returning datasets from you data tier to
you presentation tier the minute you go cross process you incurr a MASSIVE
perf penalty. This has been discussed many times (ADO.NET 2.0 will solve the
issue but until then....).

I appreciate the time you have taken to answer this post, I guess I should
have mentioned up front that I am quite aware of the security implications of
allowing the ASP.NET process direct trusted access to SQL Server but to be
honest, the problems which arrise from the alternatives raise a different
type of problem which usually involes some wacky scheme to keep the userid
and password secure.