COM

hResult = CoInitializeSecurity (NULL, -1, NULL, NULL,
    RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_IDENTIFY,
    NULL, EOAC_NONE, NULL);

//-----------------------------------------------------------------------------
//
// @func Remove all security
//
// @parm IUnknown * | pUnk | Interface to remove security
//
// @rdesc Routine results
//
//-----------------------------------------------------------------------------

inline HRESULT DtRemoveSecurity (IUnknown *pUnk)
{
	HRESULT hResult;

	//
	// Get the real IUnknown interface
	//

	CComPtr <IUnknown> pRealUnk;
	hResult = pUnk ->QueryInterface (IID_IUnknown, (void **) &pRealUnk);
	if (SUCCEEDED (hResult) && pRealUnk != pUnk)
	{
		hResult = CoSetProxyBlanket (pRealUnk, RPC_C_AUTHN_NONE,
			RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_NONE, 
			RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);
	}

	//
	// Set the original unknown
	//

	hResult = CoSetProxyBlanket (pUnk, RPC_C_AUTHN_NONE, 
		RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_NONE, 
		RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);
	return hResult;
}

CComPtr <IUnknown> p;
HRESULT hResult = pUnkSink ->QueryInterface (*_piid, (void **) &p);
if (FAILED (hResult))
{
    DtRemoveSecurity (pUnkSink);
    hResult = pUnkSink ->QueryInterface (*_piid, (void **) &p);
    if (FAILED (hResult))
        return CONNECT_E_CANNOTCONNECT;
}

One of the errors that newbies often experience when they first
begin tinkering with DCOM occurs when they fail to give a remote 
server process permission to perform callbacks to a client. 
Suppose a client on machine A launches a COM server on machine B 
and receives an interface pointer in return. Then that client 
passes an interface pointer of its own to the server so the 
server can perform callbacks. 

What's wrong with this picture? Nothing, except for the fact 
that callbacks will only be permitted if the server process is 
granted access permission to the client process. If the server 
process is assigned the identity Mister Server, then Mister 
Server must be granted access permission to the client process. 
One way to grant that access permission is to have the client 
process call CoInitializeSecurity. Another way is to include 
Mister Server (or Everyone) in the client machine's 
DefaultAccessPermission ACL. 


What makes this error especially difficult to diagnose is that 
if connection points are involved, the failure typically doesn't 
occur when the server attempts its first callback; it occurs 
when the client passes its interface pointer to the server using 
IConnectionPoint::Advise. Most implementations of Advise, 
including ATL's, call QueryInterface on the client. But if the 
server process lacks access permissions in the client process, 
QueryInterface will fail. When Advise sees QueryInterface fail,
Advise will fail, too. 

The moral: If you're using connection points to facilitate 
callbacks from remote servers and IConnectionPoint::Advise 
returns E_ACCESSDENIED or E_OUTOFMEMORY, check the access 
permissions on the client. Chances are the security principal
whose identity the server process has been assigned does not 
have permission to call into the client process.