asked on

COM security on workstations

I'm noticing vastly different COM behavior on the same machines when they are on a network with a domain and when they are on a network without a domain. They remain configured as workstations and are not explicitly joined to the domain at any point, but COM seems to behave much nicer when they're on the network with the domain.

I initialize my remote servers in the following way:

USES_CONVERSION;
COAUTHINFO cai={RPC_C_AUTHN_NONE,RPC_C_AUTHZ_NONE,NULL,RPC_C_AUTHN_LEVEL_NONE,RPC_C_IMP_LEVEL_IMPERSONATE,NULL,EOAC_NONE};
COSERVERINFO csi={0,T2W((_TCHAR*)m_masterIpAddress),&cai,0};
MULTI_QI qi={&IID_IPeerCommunications,NULL,S_OK};
if(FAILED(hr=CoCreateInstanceEx(CLSID_AudioDistributionSrvObj, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, &qi)))
{
_stprintf(logMsg,_T("Failed to create Master server instance %s error %d"),(_TCHAR*)m_masterHostName, hr);
Log(logMsg);
break;
}
qi.pItf->AddRef();
m_spMasterPeerCom.Attach(static_cast<IPeerCommunications*>(qi.pItf));

This code has always been rock solid when used on computers connected to a network with a domain hierarchy. What's going wrong when they're all connected to their own hub as workstations without a domain?

_ys_

I'll assume that you've already checked the obvious:
You are able to ping the server using it's ip address from a non-networked client.

What is the nature of the COM server - is it in-proc/out-of-process? is it permanently loaded (via an NT service or other construct)?

newcomguy

ASKER

I most certainly have checked the obvious. :) Never hurts to confirm that, though.

It's an out-of-process server that is permanently loaded as a service.

MattWare

Have you tried changing your domain in an SEC_WINNT_AUTH_IDENTITY_W structure and then using CoInitializeSecurity?

newcomguy

ASKER

How can I use CoInitializeSecurity to trick the hosts into thinking they're running on a network with a domain?

Is that even my problem?

ASKER CERTIFIED SOLUTION

YuriPutivsky

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

_ys_

>It's an out-of-process server that is permanently loaded as a service.
Problem lies here.

Specifying RPC_C_AUTHN_LEVEL_NONE is all and good for server objects activated by clients themselves. But yours is a permanently loaded service. So, even though you specify RPC_C_AUTHN_LEVEL_NONE, the server is using RPC_C_AUTHN_LEVEL_CONNECT for all method calls [call security] - the default minimum threshold.

Call CoInitializeSecurity, specifying RPC_C_AUTHN_LEVEL_NONE, from within the _server_ - as early as possible (immediately after CoInitializeEx( ) is as good a place as any). Don't forget that CoInitializeEx and CoInitializeSecurity will have to be called on every thread within the server.

If you're creating multiple objects you may want to call CoInitializeSecurity within the client threads as well, rather then passing the COAUTHINFO structure - either or.

newcomguy

ASKER

Alright, who gets the points? Yuri told me what to call and _ys_ told me where to call it.

_ys_

We'll assume that everything is working then.

There is an option to split points - but I've never asked a question so I don't know how.