System.UnauthorizedAccessException

[Peter Afonin]

Hello,

I'm using this code to access a network share from an asp.net page:

Dim dir As DirectoryInfo = New DirectoryInfo("\\10.0.0.150\FormLib\")
Dim files() As FileInfo = dir.GetFiles("*.eps")

When I try to do it, I get this error:

System.UnauthorizedAccessException: Access to the path
"\\10.0.0.150\FormLib\" is denied. at System.IO.__Error.WinIOError(Int32
errorCode, String str) at
System.IO.Directory.InternalGetFileDirectoryNames(String fullPath, String
userPath, Boolean file) at System.IO.Directory.InternalGetFiles(String path,
String userPath, String searchPattern) at
System.IO.DirectoryInfo.GetFiles(String searchPattern) at
Wip7b.WorkInProcess.btnGetEPS_ServerClick(Object sender, EventArgs e)

All permissions to this folder and a file share are set to Everyone.Usually
I don't have this problem. The only thing that is different about this
particular machine that it is not a part of the domain to which all other
PCs in our company belong, so I cannot access any users from our Active
Directory.

This is a Win 2000 SP4 machine.

I would greatly appreciate your help.

Thank you,

 

[Joyjit Mukherjee]

Hi,

you need to impersonate the user under whose behalf the resource is going to
be accessed. Put a <identity> tag in ur Web.Config as follows: -

< identity impersonate = "true" userName = "Domain\username" password =
"password" />

Regards
Joyjit

 

[Peter Afonin]

Thank you very much, Joyjit, it worked.

However, for now I'm using

<identity impersonate="true" />

i.e. impersonating all users. If I impersonate individual users, do I need
to enter the password if I'm using the Windows authentication? I tried and
it didn't work, just want to be sure that I'm doung the right thing.

Thank you,

Peter

Hi,

you need to impersonate the user under whose behalf the resource is going to
be accessed. Put a <identity> tag in ur Web.Config as follows: -

< identity impersonate = "true" userName = "Domain\username" password =
"password" />

Regards
Joyjit

 

[Prodip Saha]

The following article will probably solve the problem. Be sure to pay
attention to the conditions--
How To: Implement Kerberos Delegation for Windows 2000
J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

November 2002

Applies to:
Microsoft® ASP.NET
Microsoft Windows® 2000

See the Landing Page for a starting point and complete overview of Building
Secure ASP.NET Applications.

Summary: Kerberos delegation allows you to flow an authenticated identity
across multiple physical tiers of an application to support downstream
authentication and authorization. This How To shows you the configuration
steps required to make this work. (3 printed pages)

Contents
Notes
Requirements
Summary
References

By default, the Microsoft® Windows® 2000 operating system uses the Kerberos
protocol for authentication. This How To describes how to configure Kerberos
delegation, a powerful feature that allows a server, while impersonating a
client, to access remote resources on behalf of the client.

Important Delegation is a very powerful feature and is unconstrained on
Windows 2000. It should be used with caution. Computers that are configured
to support delegation should be under controlled access to prevent misuse of
this feature.

Windows Server 2003 will support a constrained delegation feature.

When a server impersonates a client, Kerberos authentication generates a
delegate-level token (capable of being used to respond to network
authentication challenges from remote computers) if the following conditions
are met:

1.. The client account that is being impersonated is not marked as
sensitive and cannot be delegated in Microsoft Active Directory® directory
service.
2.. The server process account (the user account under which the server
process is running, or the computer account if the process is running under
the local SYSTEM account) is marked as trusted for delegation in Active
Directory.
Notes
a.. For Kerberos delegation to be successful, all computers (clients and
servers) must be part of a single Active Directory forest.
b.. If you impersonate within serviced components and want to flow the
callers context through an Enterprise Services application, the application
server that hosts Enterprise Services must have Hotfix Rollup 18.1 or
greater.
For more information, see INFO: Availability of Windows 2000 Post-Service
Pack 2 COM+ Hotfix Rollup Package 18.1.

Requirements
The following items describe the recommended hardware, software, network
infrastructure, skills and knowledge and service packs you will need:
Windows 2000 Server with Active Directory.

Summary
This How To includes the following procedures:

1.. Confirm that the Client Account is Configured for Delegation
2.. Confirm that the Server Process Account is Trusted for Delegation
1. Confirm that the Client Account is Configured for Delegation
This procedure ensures that the client account is capable of being
delegated.

To confirm that the client account is configured for delegation

1.. Log onto the domain controller using an administrator account.
2.. On the taskbar, click the Start button, point to Programs, point to
Administrative Tools, and then click Active Directory Users and Computers.
3.. Under your domain, click the Users folder.
4.. Right-click the user account that is to be delegated, and then click
Properties.
5.. Click the Account tab.
6.. Within the Account options list, make sure Account is sensitive and
cannot be delegated is not selected.
7.. Click OK to close the Properties dialog box.
2. Confirm that the Server Process Account is Trusted for Delegation
This procedure ensures that the account used to run the server process (the
process that performs impersonation) is allowed to delegate client accounts.
You must configure the user account under which the server process runs, or
if the process runs under the local SYSTEM account, you must configure the
computer account. Perform the appropriate procedure that follows, depending
on if your server process runs under a Windows account or a local SYSTEM
account.

To confirm that the server process account is trusted for delegation if the
server process runs under a Windows user account

1.. Within the Users folder of Active Directory Users and Computers,
right-click the user account that is used to run the server process that
will impersonate the client, and then click Properties.
2.. Click the Account tab.
3.. Within the Account options list, click Account is trusted for
delegation.
To confirm that the server process account is trusted for delegation if the
server process runs under the local SYSTEM account

1.. Right-click the Computers folder within Active Directory Users and
Computers, and then click Properties.
2.. Right-click the server computer (where the process that impersonates
the client will be running), and then click Properties.
3.. On the General page, click Trust computer for delegation.
References
a.. For a list of the files that are affected by the Windows 2000
Post-Service Pack 2 (SP2) COM+ hotfix package 18.1, see article Q313582,
INFO: Availability of Windows 2000 Post-Service Pack 2 COM+ Hotfix Rollup
Package 18.1, in the Microsoft Knowledge Base.
b.. To see how to configure a complete delegation scenario, involving
ASP.NET, Enterprise Services and SQL Server, see Flowing the Original Caller
to the Database in Chapter 5, "Intranet Security."

Thank you very much, Joyjit, it worked.

However, for now I'm using

<identity impersonate="true" />

i.e. impersonating all users. If I impersonate individual users, do I need
to enter the password if I'm using the Windows authentication? I tried and
it didn't work, just want to be sure that I'm doung the right thing.

Thank you,

Peter

Hi,

you need to impersonate the user under whose behalf the resource is

going

 

[Peter Afonin]

Thank you, Prodip.

It looks like this article applies to Windows 2000 only, and we're using
Windows 2003.

Peter

 

[Peter Afonin]

Hello Joyjit,

It seems that I'm in a dead end. After I impersonated udentity as you
suggested, everything worked on my machine, but when I put the application
to the server - it didn't run. I described it in my post
"Impersonate Identity doesn't work on the server". I fixed this by
impersonating IWAM_SERVERNAME. After this I've lost access to the original
folder again. I don't know what's happening.

Thank you,

Peter

Hi,

you need to impersonate the user under whose behalf the resource is going to
be accessed. Put a <identity> tag in ur Web.Config as follows: -

< identity impersonate = "true" userName = "Domain\username" password =
"password" />

Regards
Joyjit

 

[Peter Afonin]

I fixed it. For some reason
<identity impersonate="true" />
didn't work, but when I changed it to

<identity impersonate = "true" userName = "domain\IWAM_SERVER" password
="password"/> it did.

Thanks,

Peter

Hello Joyjit,

It seems that I'm in a dead end. After I impersonated udentity as you
suggested, everything worked on my machine, but when I put the application
to the server - it didn't run. I described it in my post
"Impersonate Identity doesn't work on the server". I fixed this by
impersonating IWAM_SERVERNAME. After this I've lost access to the original
folder again. I don't know what's happening.

Thank you,

Peter

Hi,

you need to impersonate the user under whose behalf the resource is

going

 

[Frank Mamone]

I notice the IP address is in the private IP range. If the offending
server has a public IP , then it will not work if not properly routed. Check
with your network admin.

To troubleshoot, go on the server and login as the ASPNET account or an
account with the same privileges and try accessing the path manually and see
if it works.

If it doesn't then you have a network access problem. You need to eliminate
that possibility first.

-Frank Mamone

Hello Joyjit,

It seems that I'm in a dead end. After I impersonated udentity as you
suggested, everything worked on my machine, but when I put the application
to the server - it didn't run. I described it in my post
"Impersonate Identity doesn't work on the server". I fixed this by
impersonating IWAM_SERVERNAME. After this I've lost access to the original
folder again. I don't know what's happening.

Thank you,

Peter

Hi,

you need to impersonate the user under whose behalf the resource is

going