Error: "Access is denied HRESULT: 0x80070005 (E_ACCESSDENIED)" when connecting to remote server from IIS 7.

May 13, 2014 at 2:21 PM

I am trying to retrieve scheduled tasks from our remote server, but i'm getting an "Access is denied" exception.
I am trying to access the tasks from a website on IIS 7 on Windows Server 2008.

I have tried the following:
1) Plain
var ts = new TaskService("RemoteServerName");
2) Use impersonation
var identity = HttpContext.Current.Request.LogonUserIdentity;
WindowsImpersonationContext impersonation = identity.Impersonate();

var ts = new TaskService("RemoteServerName");

  • The exception occurs when trying to initialize a new TaskService.
  • When trying to access the scheduled tasks on the local server (the server where the website is hosted) I get no errors, but can only retrieve all tasks if I use impersonation.
  • If I test the same code in the Visual Studio (and IIS Express), it works fine (even without impersonation).
I tried to monitor the Event viewer -> Windows Logs -> Security on the RemoteServer when executing the code. I noticed that the accountname is "ANONYMOUS LOGON" when executing from IIS7 (even when using impersonation).

Why is impersonation ignored?
May 13, 2014 at 4:40 PM
I'm not sure why impersonation isn't working, but do know that the underlying library has separate methods for connecting as the current user versus connecting as another identity. Try using the other parameters to the TaskService constructor that allow you to specify a username, domain and password.
Marked as answer by dahall on 8/1/2014 at 8:09 AM
May 13, 2014 at 5:47 PM
Hi dahall

Thanks for your answer!

If I use the other constructor, it works in all cases.
var ts = new TaskService("RemoteServerName", "User", "Domain", "Password");
But since the user is already logged in on Windows 7, it is not very user friendly to ask for a password again each time the scheduled tasks are manipulated. It should be possible to use impersonation, right?

I have located the error as comming from the call:
 v2TaskService.Connect(targetServer, userName, userDomain, userPassword);
on line 523 in the source code.

I tried to mess a bit with the source code and put the impersonation before the call to Connect, but it didn't work.

Any clues?
May 14, 2014 at 12:01 AM
Yes, that line (523) is where the wrapper calls the native library. I'm not sure why it is failing. The Microsoft documentation says that if the username is not provided, "the current token is used." Is the user that is being impersonated a domain user with rights on remote machine?
May 14, 2014 at 12:24 PM
Hi dahall

The user which is impersonated is indeed a domain user and even has admin rights on the server.

I now tried to setup the same website on my Windows 7 machine on IIS 7.5 (not express). By default it uses the IIS APPPOOL[SiteName] dynamic account, when executing the application code.
If I don't use impersonation, the same exception on line 523 occurs, but when I use impersonation it works!

It seems to be an issue with IIS7 on Windows Server 2008, in which the auth-token is not send correctly to the remote server.

Could that really be the case?
May 14, 2014 at 3:49 PM
It could be, but that seems unlikely. I would check to see if there is an IIS setting, group policy or firewall rule that may be causing the problem.
Jul 30, 2014 at 6:27 PM
Hi dahall

I found out that delegation was disabled on the server making the request. For this reason, the impersonated user was not carried on to the other server when making the request (since this is what delegation does).
Marked as answer by dahall on 8/1/2014 at 8:09 AM