Parallel.ForEach () cambia el contexto de suplantación

Hoy implementamos nuestra aplicación ASP.NET recién creada en el servidor y pronto nos dimos cuenta de que había un extraño problema relacionado con la seguridad que causaba el bloqueo de la aplicación. Esta es una aplicación interna y usamos suplantación para administrar cómo los usuarios acceden a los recursos. Sin embargo, la aplicación genera una excepción de "Acceso denegado" cuando el usuario intenta acceder a una carpeta sobre la cual tiene control total.

La excepción fue de hecho unAggregateException y estaba siendo arrojado en un método que usaParallel.ForEach para enumerar sobre una lista y dentro del cuerpo, intenta acceder a la carpeta, pero en este punto se cambia el Contexto de suplantación y el subproceso de trabajo se ejecuta como la identidad del grupo de aplicaciones, que no tiene acceso a la carpeta, por lo tanto, la excepción.

Para confirmar esto, miré la identidad del proceso antes y dentro del cuerpo deParallel.ForEach:

string before = WindowsIdentity.GetCurrent().Name;
Debug.WriteLine("Before Loop: {0}", before);

Parallel.ForEach(myList, currentItem =>
{
    string inside = WindowsIdentity.GetCurrent().Name;
    Debug.WriteLine("Inside Loop: {0} (Worker Thread {1})", inside, Thread.CurrentThread.ManagedThreadId);
});

Cuando ejecuto la aplicación, esto es lo que se imprime:

Before Loop: MyDomain\ImpersonatedUser

Inside Loop: NT AUTHORITY\SYSTEM (Worker Thread 8)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 6)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 7)
Inside Loop: NT AUTHORITY\SYSTEM (Worker Thread 9)
Inside Loop: NT AUTHORITY\SYSTEM (Worker Thread 10)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 7)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 6)
Inside Loop: MyDomain\ImpersonatedUser (Worker Thread 7)

Como puede ver, algunos subprocesos se ejecutan como la identidad suplantada y otros como el grupo de aplicaciones (en este caso,LocalSystem) y no parece haber un patrón. El cuadro anterior en elCall Stack ventana también va a los no gestionadoskernel32.dll, lo que me hace pensar que CLR no está validando el contexto antes de delegarlo al sistema operativo.

¿Alguna idea de por qué está sucediendo esto? ¿Es ese un problema / error conocido?

Respuestas a la pregunta(2)

Su respuesta a la pregunta