Article ID: 243437 - Last Review: December 5, 2007 - Revision: 1.3

PRB: Identity Different in MTS and COM+ Library Package by Default

View products that this article applies to.

System TipThis article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.

This article was previously published under Q243437

Expand all | Collapse all

SYMPTOMS

Microsoft Transaction Server library packages that run fine on Microsoft Windows NT 4.0 may give authentication failure error in some cases on Microsoft Windows 2000 and Microsoft Windows XP.

Back to the top

CAUSE

This is because of the changes in the security model of Windows 2000 and Windows XP.

Back to the top

RESOLUTION

Check the security in Windows 2000 and Windows XP and change the security scheme in the application. -or-
Use the COM call CoInitializeSecurity to change this behavior.

Back to the top

STATUS

This behavior is by design.

Back to the top

In Windows NT 4.0, when you run components as library or as server, the security context is always that of the package. When resources are accessed by Microsoft Transaction Server objects, the identity of the process hosting the object is used to access resources, not the identity of the caller.

In the case of the server package, it is the account listed in the Identity tab, and in a library package it is IWAM_MachineName. So when the component in the Microsoft Transaction Server library calls out to another process, the outer process checks for the authentication of the IWAM_Machinename in Windows NT 4.0.

When the same code is put onto Windows 2000 and Windows XP, with the same exact configuration, it fails to get access due to an authentication failure. This is because server and library packages operate differently in Windows 2000 and Windows XP than in Windows NT 4.0.

In Windows 2000 and Windows XP, there is the concept of "cloaking," which decides whether to look at the thread token of the initial caller or not. With cloaking enabled, the original user's identity flows to the server. COM+ applications by default are configured to use dynamic cloaking. When dynamic cloaking is set, on each call the current thread token is used to determine the client's identity. If there is no thread token, the process token is used.

If you are running a package as a library application, even though the identity of the package is set for some other user, the security token of the initial caller's thread is used to impersonate the calling thread, and this may result in authentication failure if the initial caller does not have access permission.

Back to the top