ASPNET permissions woe - even when writing to a local drive that is mapped

[jimmyfishbean]

Hi,

My client has the following network structure:

2 Windows 2003 servers :
Server 1 - Web server running IIS, ftp import and export folder,
ASP.NET SOAP web service and asp code on here.
Server 2 - SQL server with database on. Want to store images on here
accessed via a share.

Standalone servers, no active directory, so users need to be set up on
both servers.

Situation:
I have installed an ASP.NET SOAP web service tool on server 1. This
uses ASPNET account which is only a local account. Therefore, if I
want this process to write to the local machine, great it all works.
If I want to write to server 2, then I need to set up a domain account
for the ASPNET process to use. I have accomplished this in the past
and know it works (when the network structure uses active
directory/domain accounts).

The problem is that my client does not have domain accounts, so I
cannot get the ASPNET process to write to another PC. Worse still, I
can only get the ASPNET to write to the local server if the location is
on a physical drive (i.e. C:\ or D:\). If I map a drive letter (i.e.
G:\) to point to C:\Images, then the ASPNET process is unable to write
- despite the fact that C:\Images and G:\ are pointing to the local
server.

This is the same when I try to write to a local location when using UNC
path (i.e. \\localPC\Images)

It seems as if mapped drives and UNC paths force ASPNET to be
validated/authenticated against domain accounts.

How can I get around this problem when the client does not have domain
accounts and active directory?

Many thanks.

Jimmy

 

[S. Justin Gengo]

Jimmy,

This may point you in the right direction:

http://www.netomatix.com/ImpersonateUser.aspx

--
Sincerely,

S. Justin Gengo, MCP
Web Developer / Programmer

www.aboutfortunate.com

"Out of chaos comes order."
Nietzsche

 

[jimmyfishbean]

Thanks for this Justin. I was wondering whether there is another way
to get around this problem. I do not want to amend my code (unless
there is no other option but to do so) as I have currently a solution
that works for all of my clients except one. Cheers,

Jimmy

 

[Paul Clement]

On 9 Sep 2005 05:50:00 -0700, (e-mail address removed) wrote:

¤ Hi,
¤
¤ My client has the following network structure:
¤
¤ 2 Windows 2003 servers :
¤ Server 1 - Web server running IIS, ftp import and export folder,
¤ ASP.NET SOAP web service and asp code on here.
¤ Server 2 - SQL server with database on. Want to store images on here
¤ accessed via a share.
¤
¤ Standalone servers, no active directory, so users need to be set up on
¤ both servers.
¤
¤ Situation:
¤ I have installed an ASP.NET SOAP web service tool on server 1. This
¤ uses ASPNET account which is only a local account. Therefore, if I
¤ want this process to write to the local machine, great it all works.
¤ If I want to write to server 2, then I need to set up a domain account
¤ for the ASPNET process to use. I have accomplished this in the past
¤ and know it works (when the network structure uses active
¤ directory/domain accounts).
¤
¤ The problem is that my client does not have domain accounts, so I
¤ cannot get the ASPNET process to write to another PC. Worse still, I
¤ can only get the ASPNET to write to the local server if the location is
¤ on a physical drive (i.e. C:\ or D:\). If I map a drive letter (i.e.
¤ G:\) to point to C:\Images, then the ASPNET process is unable to write
¤ - despite the fact that C:\Images and G:\ are pointing to the local
¤ server.
¤
¤ This is the same when I try to write to a local location when using UNC
¤ path (i.e. \\localPC\Images)
¤
¤ It seems as if mapped drives and UNC paths force ASPNET to be
¤ validated/authenticated against domain accounts.
¤
¤ How can I get around this problem when the client does not have domain
¤ accounts and active directory?
¤

The only way I can think of that this would possibly work is to have a local account on both
machines (the web server and remote resource) that have the same credentials (user ID and password).
You would need to run your ASP.NET application process under this local account (instead of ASPNET).


Paul
~~~~
Microsoft MVP (Visual Basic)