Security Features for MSDTC

Melissa Amanna                                              19th January 2012


I have worked on a few MSDTC cases and found that customers are not aware about the Security Features in MSDTC and how to use the same. Also I did not find any documentation that clearly speaks about the same. Hence I attempt to lessen the pain and explain it in this blog.


Starting from Windows 2003 there are new features that have been added to DTC. By default, the Network Enable Access is not checked and we have to manually enable the same. The kb speaks about the new features.

If you go to the Security tab in Windows 2008 or in the Security Configuration in Windows 2003, we see 3 Different Authentication:

  1. No Authentication
  2. Incoming caller Authentication
  3. Mutual Authentication

No Authentication – No Authentication will be done.

Incoming Caller Authentication - Only the remote transactions will be authenticated.

Mutual Authentication – Here Authentication will be done via impersonation.


Windows 2000:

In Windows 2000, there were no security features available in MSDTC service and it used to run under the high privilege Local System account provided. And hence when the Server is a Windows 2003 or a 2008 machine and the client a Windows 2000 machine, we check the “No Authentication” checkbox for the transaction to occur correctly.

Windows 2003:

If both the servers are Windows 2003 standalone machines, we can either use the Mutual Authentication, Incoming caller Authentication or No Authentication.

In a Clustered Environment, you must the Incoming Caller Authentication.


Windows 2008:

If both the machines are 2008 boxes in a standalone environment, we can use the either the Mutual Authentication, Incoming caller Authentication or No Authentication.

Starting from Windows 2003, the account name changed from Local System Account to NT Authority\NetworkService account. Starting from Windows 2008 cluster environment, when we enable the Mutual Authentication, it internally does a Kerberos Authentication. If the Kerberos is not configured correctly then authentication will fail and hence we will see errors. If we really really have to use Mutual Authentication then we have to check the Kerberos Security, making sure that we have the Service Principal names for these machines registered correctly. Please take a look at this document that talks about setting Kerberos.

No Authentication works in a clustered environment. But in scenarios where Mutual Authentication fails for cluster, we may have to do some Kerberos troubleshooting and enable Kerberos audit failure logging to get into the root cause of the failure.

Comments (2)

  1. Nickil Somanna -MSFT says:

    A very informational post,Thanks !

  2. Akshay Shaha says:

    Thanks for this information…. really helped me a lot… 🙂

Skip to main content