locked
Error with MSDTC RRS feed

  • Question

  • My web application is using the Windows Principle to authenticate users against IIS (impersonation is true).

    When a user who does not have the same privileges as the Network Services account I get the following error when trying to execute a transaction via TransactionScope.

    I am using an Oracle Db.

    System.Transactions.TransactionAbortedException: The transaction has aborted. ---> System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException (0x8004D01B): The Transaction Manager is not available. (Exception from HRESULT: 0x8004D01B) at System.Transactions.Oletx.IDtcProxyShimFactory.ConnectToProxy(String nodeName, Guid resourceManagerIdentifier, IntPtr managedIdentifier, Boolean& nodeNameMatches, UInt32& whereaboutsSize, CoTaskMemHandle& whereaboutsBuffer, IResourceManagerShim& resourceManagerShim) at System.Transactions.Oletx.DtcTransactionManager.Initialize() --- End of inner exception stack trace --- at System.Transactions.Oletx.OletxTransactionManager.ProxyException(COMException comException) at System.Transactions.Oletx.DtcTransactionManager.Initialize() at System.Transactions.Oletx.DtcTransactionManager.get_ProxyShimFactory() at System.Transactions.Oletx.OletxTransactionManager.CreateTransaction(TransactionOptions properties) at System.Transactions.TransactionStatePromoted.EnterState(InternalTransaction tx) --- End of inner exception stack trace --- at System.Transactions.TransactionStateAborted.CheckForFinishedTransaction(InternalTransaction tx) at System.Transactions.EnlistableStates.Promote(InternalTransaction tx) at System.Transactions.Transaction.Promote() at System.Transactions.TransactionInterop.ConvertToOletxTransaction(Transaction transaction) at System.Transactions.TransactionInterop.GetDtcTransaction(Transaction transaction) at System.Data.OracleClient.OracleInternalConnection.Enlist(String userName, String password, String serverName, Transaction transaction, Boolean manualEnlistment) at System.Data.OracleClient.OracleInternalConnection.Activate(Transaction transaction) at System.Data.ProviderBase.DbConnectionInternal.ActivateConnection(Transaction transaction) at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection) at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory) at System.Data.OracleClient.OracleConnection.Open()

    How do I get around this without trying to grant specific user accounts access to the various COM+ objects?

    Am I missing something? Is this a trust issue?

    Thanks.

    James

     

    Monday, March 19, 2007 3:29 PM

Answers

  • I suspect you are running into a "Mutual Authentication Required" issue ->

     

    http://blogs.msdn.com/florinlazar/archive/2004/06/18/159127.aspx

    Here is a blurb:

    When “Mutual Authentication Required” is selected, the local MSDTC (proxy or service) will communicate with a remote MSDTC service using only encrypted messages and mutual authentication (Windows Domain authentication). If a secure communication cannot be established with the remote system, the communication will be denied. “Incoming Caller Authentication Required” means that if mutual authentication cannot be established, but the incoming caller can be authenticated, then the communication will be allowed. Currently only Windows 2003 Server and XP SP2 support the first two options. “No Authentication Required” means that the MSDTC communication on the network can fallback to a non authenticated and non encrypted communication if the attempts to start a secure communication will fail. The “no authentication required” option is for compat communications with previous OSes (W2K, XP RTM and XP SP1); this setting needs also to be used when the computers involved are located in two untrusted Windows domains or in a Windows workgroup. If your XP SP2 box is talking to a Windows 2003 system that has disabled it’s RPC security for MSDTC (using TurnOffRpcSecurity registry key - see http://blogs.msdn.com/florinlazar/archive/2004/03/02/82916.aspx for more info), then you will need to use this third option on the XP SP2 box to enable network transactions between the two systems.

    Monday, March 19, 2007 8:36 PM

All replies

  • I noticed that MS DTC always needs to be accessed with a NTAuthority\NetworkService account. However, my users are authenticating under a AD account that does not have that permission set available to them.

    I found this link:

    http://msdn2.microsoft.com/en-us/library/ms998355.aspx

    In that link there is section titled: To configure protocol transition for a custom domain account

    Is this the correct route in fixing this issue?

    Thanks,

    James

    Monday, March 19, 2007 4:57 PM
  • I suspect you are running into a "Mutual Authentication Required" issue ->

     

    http://blogs.msdn.com/florinlazar/archive/2004/06/18/159127.aspx

    Here is a blurb:

    When “Mutual Authentication Required” is selected, the local MSDTC (proxy or service) will communicate with a remote MSDTC service using only encrypted messages and mutual authentication (Windows Domain authentication). If a secure communication cannot be established with the remote system, the communication will be denied. “Incoming Caller Authentication Required” means that if mutual authentication cannot be established, but the incoming caller can be authenticated, then the communication will be allowed. Currently only Windows 2003 Server and XP SP2 support the first two options. “No Authentication Required” means that the MSDTC communication on the network can fallback to a non authenticated and non encrypted communication if the attempts to start a secure communication will fail. The “no authentication required” option is for compat communications with previous OSes (W2K, XP RTM and XP SP1); this setting needs also to be used when the computers involved are located in two untrusted Windows domains or in a Windows workgroup. If your XP SP2 box is talking to a Windows 2003 system that has disabled it’s RPC security for MSDTC (using TurnOffRpcSecurity registry key - see http://blogs.msdn.com/florinlazar/archive/2004/03/02/82916.aspx for more info), then you will need to use this third option on the XP SP2 box to enable network transactions between the two systems.

    Monday, March 19, 2007 8:36 PM