469,271 Members | 1,113 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

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

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

Nov 19 '05 #1
3 1420
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
<ji***********@yahoo.co.uk> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
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

Nov 19 '05 #2
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

Nov 19 '05 #3
On 9 Sep 2005 05:50:00 -0700, ji***********@yahoo.co.uk 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)
Nov 19 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Stephane | last post: by
2 posts views Thread by Yogesh Pancholi | last post: by
2 posts views Thread by dimstthomas | last post: by
6 posts views Thread by Andrew Chalk | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.