DirectoryEntry call to remote IIS Metabase ALWAYS connects as ASPNET

[Eric Templin]

I have been developing a web-based application that will manage our FTP servers by creating users, folders, setting NTFS security and creating virtual directories. I have been devloping these pages in ASP.NET using DirectoryServices, and up until this point, I have had no problems. I have been able to create local user accounts, folders and set their security on the remote servers but I have not been able to create virtual directories.

Here is my code...

Dim FTPService As DirectoryEntry
Dim FTPSites As DirectoryEntries
Dim FTPSite As DirectoryEntry

FTPServices = DirectoryEntry("IIS://SERVER/MSFTPSVC")
'FTPServices.UserName = "Domain\UserName"
'FTPServices.Password = "Password"
FTPSites = FTPServices.Children
For Each FTPSite in FTPSites
Response.Write(FTPSite.Properties("ServerComment").Value)
Next

Every time I execute this code against any IIS server other than what is running on my own machine, I get an Access Denied error for any property I attempt to access or change/add.

I have researched this for days, and every answer I find is security related. I have tried all of the following:
1. Configure IIS to run the website under admin credentials
2. Configure the machine.config to impersonate with admin credentials
3. Configure the web.config to impersonate with admin credentials
4. Use code level impersonation with admin credentials

All fail with Access Denied against both W2K/IIS5 and W2K3/IIS6 servers.
The security logs on all of these services shows failures by the ASPNET account on my machine attempting to access the box.

My questions are these...

1. Why can I use DirectoryServices to create and manage local user accounts on a remote server, as well as NTFS folders and their security, but NOT manage IIS on the remote server?
2. Why is my code NOT impersonating as shown by the security logs on the remote servers?

ANY help would be appreciated?

Before you respond, know that I have used accounts that DO have admin rights not only on those servers, but also elsewhere in the domain. I have no intent on using these extremely powerful accounts for the production version of my code, but just for determining the cause of this problem. Also, if there is another way besides DirectoryServices, I would be willing to entertain approaching this from another angle.

From http://www.developmentnow.com/g/14_2004_10_0_0_0/dotnet-framework-aspnet-security.ht

Posted via DevelopmentNow.com Group
http://www.developmentnow.com

 

[Joe Kaplan \(MVP - ADSI\)]

The UserName and Password properties on the DirectoryEntry are not supported
for the IIS provider. You have to impersonate the user you want to use.

It says this somewhere in the documentation for the IIS provider, but it
isn't easy to find.

Joe K.

 

[Eric Templin]

I understand that, which is why the username and password properties of
the DE are commented out. I've tried the impersonation (as my post
states) but the remote server always shows a failed connection by my
machines ASPNET account despite the impersonation.

 

[Joe Kaplan \(MVP - ADSI\)]

Sorry about that. I didn't see the comments on that code (why include it in
the sample?) and didn't read the rest of the post because I thought you were
having the obvious problem.

Impersonation is supposed to work. I have no idea why it would not. It
sounds like the IIS provider isn't using the impersonated identity in the
remote call and will only use the process identity. This might be some kind
of a shortcoming in the IIS provider, although my understanding is that it
should not do this.

You might consider the possibility that is simply works this way and look
for a way to make the process identity be the admin user you want to use for
this. The most straightforward approach would be to move the IIS code into
a COM+ component and have that set to run under your admin user identity.
Then, you would just invoke the COM+ component from your web application.

Joe K.