1. Home
  2. ⧑ Industrial Control Group
  3. How to set up DCOM properly to connect server and client remotely

How to set up DCOM properly to connect server and client remotely

Hi all,

I need to know how to set up DCOM properly so the OPC server and client can connect to each other.

Details:

server and client on separate pcs. pcs not in any domain. pcs installed with windows XP SP2. both server and client are .exe files. both are assigned same local user accounts

What I have done so far:

server side: Gave exception to server.exe, DCOM port 135 in Windows firewall. in dcomcnfg, I found the server's id, and changed the properties as well as for "my computer" . I have set default authentication level to connect, impersonation level to identify. For both access and launch permissions, I have set the limits and defaults to include administrators, users, anonymous logon, system and local user (the user assigned specially for the server)

client side: Gave exception to client.exe, DCOM port 135 in Windows firewall. in dcomcnfg, is also the same as the above. Only difference is that the properties are set for "my computer".

Btw, when I edit say, access permissions and I want to add the assigned user account used for the client, when I click on the location button, I can only find the pc's own local user acct. It will show as pc1_name/username. Similarly for the server side, I can only add pc2_name/username. The server and the client will only deal with the username and NOT the pc's name when trying to connect right?

So where have I gone wrong? Btw, in my client, I have the following code (some snippets): I have set the coAuthIdentity to only have the local user acct and not the domain(since my pcs are not in any domain).

CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_CONNECT, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL);

COAUTHINFO coAuthInfo; COSERVERINFO remoteServerInfo; COAUTHIDENTITY coAuthIdentity; HKEY remoteRegHandle; HKEY keyHandle; char classIdString[100]; CLSID clsid; MULTI_QI reqInterface; CString keyName = "SOFTWARE\\Classes\\" + serverName + "\\Clsid";

result = RegConnectRegistry(hostName, HKEY_LOCAL_MACHINE, &remoteRegHandle);

if (SUCCEEDED(result)){ result = RegOpenKeyEx(remoteRegHandle, keyName, 0, KEY_READ, &keyHandle); if (SUCCEEDED(result)){ DWORD entryType;

unsigned bufferSize = 100; result = RegQueryValueEx(keyHandle, NULL, 0, &entryType, (LPBYTE)&classIdString, (LPDWORD)&bufferSize); if (FAILED(result)){ printf("here"); }else{ USES_CONVERSION; LPOLESTR classId = A2W(classIdString); if (CLSIDFromString(classId,&clsid) != S_OK){ printf("Failed"); } } } }

ZeroMemory(&coAuthIdentity, sizeof(coAuthIdentity)); coAuthIdentity.Flags = SEC_WINNT_AUTH_IDENTITY_UNICODE; coAuthIdentity.User = (USHORT*)L"user"; coAuthIdentity.UserLength = wcslen(L"user"); coAuthIdentity.Password = (USHORT*)L"password"; coAuthIdentity.PasswordLength = wcslen(L"password");

ZeroMemory(&coAuthInfo, sizeof(COAUTHINFO)); coAuthInfo.dwAuthnLevel = RPC_C_AUTHN_LEVEL_CONNECT; coAuthInfo.dwAuthnSvc = RPC_C_AUTHN_WINNT; coAuthInfo.dwAuthzSvc = RPC_C_AUTHZ_NONE; coAuthInfo.dwCapabilities = EOAC_NONE; coAuthInfo.dwImpersonationLevel = RPC_C_IMP_LEVEL_IMPERSONATE; coAuthInfo.pAuthIdentityData = &coAuthIdentity; coAuthInfo.pwszServerPrincName = NULL;

When client is runned, the "Failed" message will appear. Which I think means the client does not have permission to access the server.

I need help in this area, hope someone can help me, thanks.

Atiz

Reply to
Atiz
Loading thread data ...

Run "dcomcnfg"

In the applications tab, select the OPC server and click properties. Now select Identity tab. Select "Interactive user"

Hope it helps. srinivas

Reply to
srinivas

Hi Srinivas,

thanks for your suggestion, but I only want to cater to specific users, that's why under Identity, I chose to put this user :) I'm currently trying out now with domain and without firewall, it works! Apparently the firewall is causing me problems, I'll update again when I find out what went wrong. Subsequently, I hope to make it work for pcs without domain.

Huifang

sr> Run "dcomcnfg"

Reply to
Atiz

Hi Atiz,

I think that with/without a domain might be a problem here. I never really established any rhyme or reason to it, but a year back whenI was playing with DCOM, I found I could open up the permissions and allow Everyone to perform any action in the permissions and this would would between any pair of machines. The moment that I needed to lock down the permissions to particular users, I neeed a domain.

I guess that part of the problem is that without a domain, how do the two machines now in different security realms establish a trust with each other to validate the user on one machine accessing resources on another?

So in all the DCOM applications I've done recently (Rockwell RSView, RSLinx, National Instruments LabView), I've used a domain and occasionaly when the interoperability problems are too great (like during the usual confusion about which version of RSLinx is offering what service to what level and the licensing doesn't behave itself), I've used a proxy-tunneller like Matrikon's OPC Tunneller:

formatting link
The upside of using the Tunneller is that the firewall configuration is easy - just open the few documented and changeable ports between the machines. The DCOM configuration is easy too - there isn't any DCOM - COM requests are made locally and then tunnelled out in UDP packets to the "real" requester.

The downside is cost. But then how expensive are the hours spent trying to fix those Microsoft bits that are not so much broken, but just don't quite work the way that we think they are meant to?

David.

Reply to
Dave Slee

Hi Dave,

thx for replying :) I tried with both pcs in a domain, works fine when both firewalls are down, so I think there shd be no problems regarding the DCOM settings. The thing is the firewall. Right now, the firewall is down on the client side and firewall up on server side.

Even though I've added the DCOM port 135, the Citect32.exe to the exception list, my client cannot connect to the Citect server. Later, I tried switching off the firewall just only for connection and it works. I suspect that some ports are not being added to the exception list that's why the client cannot connect to Citect server.

Atiz

Dave Slee wrote:

Reply to
Atiz

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.