ADSI / IIS management and ASP.NET impersonation

Question

I'm in the process of writing a small web app that would allow me to manage several IIS installations on different servers on our network. We have no domain controller.

I have written a small impersonation controller that uses the win32 api and its LogonUser method. I then use System.DirectoryServices and the IIS ADSI provider to create a new site.

I have the following routine (exchanged some values with clear-text strings for better readability):

            if (impersonationSvc.ImpersonateValidUser("Administrator@SRV6", String.Empty, "PASSWORD))
            {


            string metabasePath = "IIS://" + server.ComputerName + "/W3SVC";
            DirectoryEntry w3svc = new DirectoryEntry(metabasePath, "Administrator", "PASSWORD");

            string serverBindings = ":80:" + site.HostName;
            string homeDirectory = server.WWWRootNetworkPath + "\\" + site.FolderName;


            object[] newsite = new object[] { site.Name, new object[] { serverBindings }, homeDirectory };

            object websiteId = (object)w3svc.Invoke("CreateNewSite", newsite);
            int id = (int)websiteId;

            impersonationSvc.UndoImpersonation();
        }

This routine works when I use the server the web app is hosted on (SRV6). A new site is created.

If I use SRV5 for instance, another Server on our network (with no domain), ImpersonateValidUser works, the DirectoryEntry is created, but w3svc.Invoke fails with the following error:

[COMException (0x80070005): Access denied]

System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) +377678
System.DirectoryServices.DirectoryEntry.Bind() +36
System.DirectoryServices.DirectoryEntry.get_NativeObject() +31
System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args) +53

...

Anyone knows how I could solve this?

Answer 1

I would look into the eventlog of SRV5 to check what privileges are used when you connect to that server. You may need to change your group policies to log failures in the security log.

It sounds easier to setup webservices on your servers, preferably protected by logins and/or ip restrictions, that does these kind of operations.

Answer 2

You cannot use impersonation in this situation. The account you are impersonating needs login priveleges on the local machine.

If your web servers are not part of a domain, I think Tant102's idea of web services is your only way to go.