When a thread is impersonated, it is commonly used to flow identity to all resources on the same machine. This is true for SQL Server authentication, and NTFS authentication/authorization. While not ideal, impersonation is a common technique in IIS for overriding the default process identity with the identity of the interactive user, or a fixed identity.
When System.Diagnostics.Process.Start() executes Dtexec.exe, it does not flow the impersonated identity. Instead, the impersonated identity is ignored, and the identity running the process (the Win32 thread) is used instead.
In the case of IIS, the process runs under ASPNET account for Windows 2000 and XP, and NETWORK SERVICE in Windows 2003 Server. These accounts are least privileged and thus, cannot start Dtexec.exe.
There are at least two solutions to this problem:
1. Configure IIS to run as a fixed identity that is able to start dtexec.exe. When running IIS 5, there is no other option than to change the processModel key in machine.config to use a fixed identity. In IIS 6, configuring an application pool with a fixed identity will accomplish the same result.This identity will then flow to dtexec.exe.
I believe that not flowing the impersonated security context is inconsistent with the .NET security model and should be reconsidered or at least published as an issue in a KB.