This is a migrated thread and some comments may be shown as answers.

ToDataSourceResultAsync(...) and impersonation

2 Answers 249 Views

General Discussions

This is a migrated thread and some comments may be shown as answers.

Heiko asked on 29 Aug 2018, 02:45 PM

Hi,

in my MVC-App I use <authentication mode="Windows" /> and <identity impersonate="true"/> inside web.config which means the current WindowsIdentity is delivered through IIS to SQL-Server. Normally I use the async/await pattern in my code and thus use ToDataSourceResultAsync(...) to get my filtered/sorted/paged results async. When doing so I run into an error. The call from App -> IIS -> SQL-Server is now under the normal "IIS APPPOOL\DefaultAppPool" account which is not a valid SQL-Server user and so the connection is refused. When using the normal ToDataSourceResult(...) call everything works perfect.

The reason for this is the usage of "Task.Factory.StartNew(...)" inside QueryableExtensions.cs. Whenever you use "Task.Factory.StartNew(...)" the impersonation is reset to the default value and is NOT using the identity used inside the MVC-App. Here is a little example (just place the code inside a normal Controller Action):

1.Debug.WriteLine("App is running as: {0}", WindowsIdentity.GetCurrent().Name);

2.await Task.Factory.StartNew(

3. () =>

4. Debug.WriteLine("New Task is running as: {0}", WindowsIdentity.GetCurrent().Name),

5. CancellationToken.None,

6. TaskCreationOptions.None,

7. TaskScheduler.Default);

As a result you get:
Line 1: "App is running as: myDomain\myUser"
Line 4: "New Task is running as: IIS APPPOOL\DefaultAppPool"

At least you should warn in your documentation that this could happen or think about a better solution for implementing "ToDataSourceResultAsync(...)". In my opinion my scenario is not so seldom in the enterprise world so giving a warning should be a good idea.

Regards
Heiko

2 Answers, 1 is accepted

Accepted