Microsoft KB Archive/301451

= INFO: COM+ Components Warning When You Use Role-Based Security at the Interface Level =

Article ID: 301451

Article Last Modified on 2/22/2002

-

APPLIES TO


 * Microsoft COM+ 1.0

-



This article was previously published under Q301451



SUMMARY
If you are passing out a reference to a component (Component2) that is not installed in a COM+ application from a component (Component1) that is installed in a COM+ server application and is using role-based security at the Interface level, you may receive the following warning in the Application Event Log:

A method call to an object in a COM+ application was rejected because the caller is not properly authorized to make this call. The COM+ application is configured to use Application and Component level access checks, and enforcement of these checks is currently enabled. The remainder of this message provides information about the component method that the caller attempted to invoke and the identity of the caller.

Destination of the rejected call:

Application Id: {B7FE210F-1088-4BBD-B549-CF4D8E6675CF}

CLSID: {D4CC349B-063B-4256-9AE7-B14630C6B9A8}

IID: {0193088D-396D-4455-9573-33DCB872B2AE}

Method #: 7

Class: SecClient.SecCl1

Interface: (unknown)

Method: (unknown)

Caller Information:

Svc/Lvl/Imp = 10/6/1, Identity = NORTHAMERICA\useraccount



MORE INFORMATION
The warning is generated when the client makes a method call on the Component2 interface that Component1 returns to it. This occurs because Component2 is created in the same context as Component1. When the client makes a call into Component2, the object context has no information on the destination interface and its security requirements because Component2 is not installed in a COM+ application; thus, the call is rejected.

This behavior is by design in order to provide the greatest protection. Unconditional denial of access to anyone who makes calls on such an interface ensures that a possible administrative or programming error (such as returning an interface reference from Component2) does not create a security hole. This behavior cannot be changed even in cases where it is desirable to permit access because it is not possible to associate configuration information with components that are not installed in COM+ applications.

In the above-mentioned scenario, passing out references to Component2 from Component1 is not good programming practice and should be avoided. You can encounter issues similar to those discussed here.

