Two PC development environment

[Gal Steinitz]

What is the correct way to set up a two PC development environment where one
PC (the main PC) runs IIS and Visual Studio 2005, and the 2nd PC runs SQL
Server 2000 ?

We ran into significant problems with security trying to set up this kind of
infrastructure.

We gave the ASPNET user an implicit password, and specified this password in
machine.config:

<processModel autoConfig="true" userName="aspnet" password="---" />

this user has administrative access on the main PC and access to the debug
group.

There is also this setting in web.config:

<identity impersonate="true" userName="aspnet" password="---">

and additionally there is the user that IIS uses for anonymous connections.

The ASPNET user was created as a local user on both PC's with the same
password.

Using this setup, works for local access, but does not allow access to the
PC via a browser from other PC's.

What is the correct configuration for such a setup, and which of the above
is required and which is not?

Thanks.

[Steven Cheng[MSFT]]

Hi Gal,

Thank you for posting.

As for the ASP.NET application deploying in two machines scenario, here are
some of my understanding and suggestion:

1. For IIS 5.X , the ASP.NET worker process is aspnet_wp.exe and the
default process identity is machine\aspnet account and the password is
controled by machine. also, we do not recommend that user manualy change
the account's password. Actually we can create a separate custom ASP.NET
process account, see the below msdn article:

http://msdn.microsoft.com/library/en...9.asp?frame=tr
ue

http://msdn.microsoft.com/library/en...01.asp?frame=t
rue

2. For SQL Server, since it is always be accessed remotly from ASP.NET
application, so if the ASP.NET application is not using impersonate, it
should always use the worker prcess account to access the remote sqlserver,
no matter the client user visit the page from local or remote client
machine. is your ASP.NET applicaiton using windows authentication and
impersonate?

Anyway, I suggest you turn on the SQL Profiler on the sqlserver machine to
check what's the account used to access the sqlserver and get denied...

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)