I am using DirectoryServices and the WinNT:// provider to connect to a remote computer. I then check some group membership information and possibly add or remove a domain user from a specified local group.
I have been able to get all of this code working without a hitch using a vb.net console application and when communicating with my local box, or with any box where the account I am logged in under has administrative rights.
Code:
string strUserPath = "WinNT://DomainName/someuser,user";
DirectoryEntry deComputer = new DirectoryEntry("WinNT://" + Computername + ",computer");
deComputer.RefreshCache();
DirectoryEntry deGroup = deComputer.Children.Find("administrators", "group");
IEnumerable members = deGroup.Invoke("members", null);
List<DirectoryEntry> r = new List<DirectoryEntry>();
foreach (object o in members)
{
DirectoryEntry deMember = new DirectoryEntry(o);
r.Add(deMember);
}
deGroup.Invoke("Add", strUserPath);
deGroup.CommitChanges();
deGroup.Invoke("Remove", strUserPath);
deGroup.CommitChanges();
So I moved the code to an ASP.Net web app, which is impersonating a service account through the Impersonate section of web.config. The account I am impersonating does not have admin rights on any of the workstations so I put in a username/password into the constructor for the computer entry like so:
DirectoryEntry deComputer = new DirectoryEntry("WinNT://" + Computername + ",computer", username, password);
The username is that of a domain account which has local admin rights on every workstation. If I look at the Username property of the resulting deComputer object I can see that the username matches what I entered. Also if I enter in an invalid password it throws an error, so it is authenticating in some fashion.
However if I now try and add or remove a user from a remote workstation I get a general access denied error. If I add the service account that ASP.Net is using as a local admin on that workstation it will add and remove no problem.
So next I tried using the LogonAPI (advapi32.dll ->LogonUser call) to login as the user account that is a local admin on all workstations, impersonated the resulting WindowsIdentitiy and tried running just the original deComputer instantiation. When I do this every property, excepty Path, returns an OLE exception...
I'm pretty lost here on what to try next. Any help would be greatly appreciated.
--Workaround--
To work around the issue we created a windows service that runs under the local admin account and thus doesn't have any issues running the code. We push all of our updates to a table in a SQL database and the service picks them up and processes them. BUT, I still really would like to know why this doesn't work, and it would be nice to push updates straight from the web site.