You could be encountering this problem if:
· You are using an application calling the API “DTCGetTransactionManagerExW” from a thread impersonating a different user to that which the process is running as;
The “DTCGetTransactionManagerEx” API called from a ‘client process’ is being run from a thread that is impersonating the ‘Thread User’. The thread subsequently created which is making the request to the MSDTC service is still running as ‘Process User’. This request is then sent across to the MSDTC service encrypted by a ticket for the ‘Process User’.
When the ‘MSDTC process’ is then sending the message back to ‘client process’, it is assuming it can encrypt it using the same ticket, however the thread on which the ‘client process’ actually receives the call is different to the outgoing call’s thread and running as the ‘Thread User’.
Since this ‘Thread User’ does not match the ‘Process User’, it is not permitted to decrypt the message and therefore is failing.
The problem is caused because the incoming and outgoing requests should both be run from threads in the same user context and currently they are not. This is a problem within the MSDTC Proxy code.
To workaround the issue you can use one of the following options:
1) Set the MSDTC security setting for the communication manager authentication to “no authentication required”.
2) To recreate the MSDTC cluster group with a network name that does not have “Enable Kerberos Authentication” set.
3) Do not call the DTCGetTransactionManagerEx API from an impersonated thread.
Currently there is no fix for the problem in Windows 2003 however the problem is fixed in Windows 2008 and above.