DCOM Security in QuickOPC
Date: October 1, 2014



Overview
========
QuickOPC uses following steps, regarding COM/DCOM security:
1. Process-wide security is initialized (only in QuickOPC-COM, see InitComSecurity below).
2. OPC objects are created using CoCreateInstance or CoCreateInstanceEx, see COM Object Creation below.
3. All interfaces obtained from OPC-related objects are first configured for proper security - see SetProxyBlanket below.

The objects and functions described here are internal to the C++ code of QuickOPC, and not directly as exposed to the QuickOPC developer as such.

They are named here because they allow to describe the implementation in a convenient way.



The CComSupport object
======================
This object contains COM-related properties, which are also exposed through public API of QuickOPC.
Properties are divided into two groups.

"COM support parameters" (used either as process-wide settings, or on a per-interface level):
- UseCustomSecurity (default: true)
- TurnOffCallSecurity (default: false; only significant when UseCustomSecurity == true)

"COM Instantiation parameters" (they are used only at the moment of COM object creation):
- ClsCtx
- TurnOffActivationSecurity (default: false)

Note that there are TWO independent sets of these settings:
1. First set is used with the OPCEnum objects (for OPC server browsing). In QuickOPC.NET, those are the ones in EasyXXClient.SharedParameters.Machine.
2. The second set is used with the actual OPCServer objects, and other objects provided by the OPC Servers. In QuickOPC.NET, those are the ones in EasyXXClient.SharedParameters.Client.



HRESULT CComSupport::InitComSecurity()
======================================
The purpose of this function it to initialize process-wide security.

In QuickOPC-COM, this function is called as part of module preparation (i.e. globally, once).
In QuickOPC.NET, this function is not called at all, because the CLR and/or the hosting process is responsible for it, and a subsequent call would return an error. The description of this function is therefore irrelevant for QuickOPC.NET and is included for completeness only.

If UseCustomSecurity == false, does nothing.

If UseCustomSecurity == true, determines the parameters and then calls CoInitializeSecurity (msdn.microsoft.com/en-us/library/windows/desktop/ms693736(v=vs.85).aspx, msdn.microsoft.com/en-us/library/windows/desktop/ms679760(v=vs.85).aspx).

The relevant parameters for CoInitializeSecurity are determined as follows:
- Security descriptor: NULL if TurnOffCallSecurity == true. Otherwise, the security descriptor is initialized from the thread token (see e.g. msdn.microsoft.com/en-us/library/aa277685(v=vs.60).aspx ).
- Count of authentication services = -1 (tells COM to choose).
- Authentication services: NULL.
- Authentication level: If TurnOffCallSecurity == True, it is RPC_C_AUTHN_LEVEL_NONE (see msdn.microsoft.com/en-us/library/windows/desktop/ms687216(v=vs.85).aspx ). Otherwise, it is RPC_C_AUTHN_LEVEL_CONNECT.
- Impersonation level: RPC_C_IMP_LEVEL_IMPERSONATE.



HRESULT CComSupport::SetProxyBlanket(IUnknown* pUnknown)
========================================================
This function is called as first on every interface that we obtain, on every OPC-related COM object that we work with.
In QuickOPC.NET, this is the only way to gain control over the security settings, because the process-wide security cannot be generally influenced by QuickOPC code.

If UseCustomSecurity == false, does nothing.

If UseCustomSecurity == true, determines the parameters and then calls CoSetProxyBlanket (msdn.microsoft.com/en-us/library/windows/desktop/ms692692(v=vs.85).aspx ) on the pUnknown interface. The other relevant parameters for CoSetProxyBlanket are determined

as follows:
- Authentication level: as with CComSupport::InitComSecurity.
- Impersonation level: as with CComSupport::InitComSecurity.



COM Object Creation
===================
If the (target) machine name is an empty string, the CoCreateInstance function (msdn.microsoft.com/en-us/library/windows/desktop/ms686615(v=vs.85).aspx ) is used; this function takes no direct security-related parameters.
Otherwise (i.e. normally for remote machines), the CoCreateInstanceEx function (msdn.microsoft.com/en-us/library/windows/desktop/ms680701(v=vs.85).aspx ) is used; this function takes a COSERVERINFO input parameter that we fill in as needed, and of interest is the pAuthoInfo member of COAUTHINFO type. How the COAUTHINFO is determined is explained further below.

The COM object creation is followed by obtaining initial interfaces from it, and calling SetProxyBlanket on them (See above).
For connections to OPCEnum, there is an additional "trick", aimed at making it work in more cases than it would normally: After the object is created, we try the SetProxyBlanket with the CComSupport object (for OPCEnum) as specified by the developer, and query for the interface we need.

If the query returns E_ACCESSDENIED for all of them, and the CComSupport settings are different from those that we deem as "recommended", we make one more attempt, now with the "recommended" settings. If this second attempt succeeds, we use the working set of parameters instead, for the
remaining calls on that OPEnum object. The recommended settings are: UseCustomSecurity == true, TurnOffCallSecurity == true. Note that currently these "recommended" settings differ from the parameter defaults, therefore unless the developer changes the parameter values, both combinations will be attempted in case of E_ACCESSDENIED errors on OPCEnum.



Determining COAUTHINFO for CoCreateInstanceEx
=============================================
If TurnOffActivationSecurity == false, the resulting COAUTHINFO is NULL.
If TurnOffActivationSecurity == true (see msdn.microsoft.com/en-us/library/ms680560(VS.85).aspx ), the resulting COAUTHINFO has following settings:
dwAuthnSvc = RPC_C_AUTHN_NONE;
dwAuthzSvc = RPC_C_AUTHZ_NONE;
pwszServerPrincName = NULL;
dwAuthnLevel = RPC_C_AUTHN_LEVEL_NONE;
dwImpersonationLevel = RPC_C_IMP_LEVEL_IMPERSONATE;
pAuthIdentityData = NULL;
dwCapabilities = EOAC_NONE;



DCOMCNFG, and unclear parts
===========================
In QuickOPC.NET, we do not know whether and how precisely the CLR or the hosting environment initializes the process-wide security, and it is also subject to change without a notice (from Microsoft). There may be some fixed settings (in which case the DCOMCNFG security settings for the client computer or the application will have no influence except for "Limits"), or it may not be initlaized at all (in which case the DCOM security settings for the client computer or application will apply). That's what we try to resolve with UseCustomSecurity == true AND using SetProxyBlanket, which should lead to a behavior that is at least independent of the CLR/host implementation. With UseCustomSecurity == true, the DCOMCNFG *security* settings (but not *all* settings) for the client computer or the application should have no influence (except for the "Limits", which, in my understanding, are always enforced). With UseCustomSecurity == false, we really do not work with security at all, except for providing the COAUTHINFO at object instantiation time, for remote objects. What DCOM security settings will be used in this case depends on the CLR/host (and, in turn, may or may not depend on security values in DCOMCNFG).



Summary
=======
In QuickOPC.NET, besides the common issues with DCOM and OPC, additional problems arise form the fact that the environment is managed "for us", including the process-wide security settings. In QuickOPC.NET, with UseCustomSecurity == true, we try to resolve this issue by properly calling SetProxyBlanket on every OPC interface.



Note: When this document refers to QuickOPC-COM, it generally means the "Local Server" or "Service" incarnation of the EasyOPC objects. For the less-commonly "In-process" option, the situation is in fact, quite similar or identical to QuickOPC.NET, i.e. the hosting process is responsible for the process-wide security settings.



***

Here are the results with the different options, summarized:

#	UseCustomSecurity	TurnOffActivationSecurity	TurnOffCallSecurity	Test Outcome
1	true	true	true	UnauthorizedAccessException
2	true	false	true	UnauthorizedAccessException
3	true	true	false	UnauthorizedAccessException
4	true	false	false	UnauthorizedAccessException
5	false	true	true	UnauthorizedAccessException
6	false	true	false	UnauthorizedAccessException
7	false	false	true	"Cannot connect topic..."
8	false	false	false	"Cannot connect Data Access client..."

From: A.
Sent: Monday, September 29, 2014 4:58 PM
To: ...
Subject: RE: OPC Analyzer version

Thank Zbynek!

C. and I have been going over this case and we just have a few questions to clarify. We really appreciate any feedback.

[...]

In the attached text file There are 8 different combinations of security code combinations involving the UseCustomSecurity, TurnOffActivationSecurity, and TurnOffCallSecurity commands.

[...]

We also had a question about how the default DCOM permissions are generated by .NET for data client applications. Can you give us some clarity on this?

Thanks,
A. & C.