7 Appendix B: Product Behavior
The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.
The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.
Windows Client
Windows NT Workstation operating system
Windows 2000 Professional operating system
Windows XP operating system
Windows Vista operating system
Windows 7 operating system
Windows 8 operating system
Windows 8.1 operating system
Windows 10 operating system
Windows 11 operating system
Windows Server
Windows NT Server operating system
Windows 2000 Server operating system
Windows Server 2003 operating system
Windows Server 2008 operating system
Windows Server 2008 R2 operating system
Windows Server 2012 operating system
Windows Server 2012 R2 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows Server 2025 operating system
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.
Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.
<1> Section 1.8: Windows only uses the values in [MS-ERREF] section 2.2.
<2> Section 1.9: Windows object resolver services always use the well-known endpoints specified in [MS-RPCE] section 2.1, and will never register their interfaces with the RPC endpoint mapper. On Windows, DCOM clients correctly interoperate with a server whose object resolver service registers its interfaces with the RPC endpoint mapper.
<3> Section 2.1: On Windows, DCOM servers register all the security providers supported by the server.
<4> Section 2.2.11: The DCOM versions supported by different platforms are:
|
Operating System |
DCOM version |
|---|---|
|
Windows NT operating system |
5.4 |
|
Windows 95 operating system |
5.4 |
|
Windows 98 operating system |
5.4 |
|
Windows 2000 operating system |
5.6 |
|
Windows XP and later |
5.7 |
|
Windows Server 2003 and later |
5.7 |
<5> Section 2.2.11: Windows uses version 5.7, not to indicate any change in DCOM, but rather in the marshaling of the UDT type specified in [MS-OAUT] section 2.2.28.1.
<6> Section 2.2.13.1: This specification defines two formats for the ORPC_EXTENT structure. See section 2.2.21.
<7> Section 2.2.18.2: Windows will not perform garbage collection pinging for objects unmarshaled with SORF_NOPING.
<8> Section 2.2.18.6: Windows treats this field as the CLSID for an object that both implements the IMarshal interface and is capable of unmarshaling the pObjectData field. For more information, see [MSDN-IMarshal].
<9> Section 2.2.19.1: Windows does not order the STRINGBINDING structures in the decreasing order of preference. They are passed in an arbitrary order.
<10> Section 2.2.19.3: Windows supports a subset of the constants. For details, see section 3.1.2.3.
<11> Section 2.2.19.3: Applicable Windows Server releases accept other forms of the IPv4 address that are accepted by inet_addr as specified in [RFC3493] section 6.3.
<12> Section 2.2.20: Windows uses IID_IContext as the IID of an interface with the local IDL attribute.
<13> Section 2.2.20: Windows uses IID_IContext as the IID of an interface with the local IDL attribute.
<14> Section 2.2.20: On Windows, DCOM clients set this field to a value from the MSHLFLAGS enumeration. For more information, see [MSDN-MSHLFLAGS].
<15> Section 2.2.21.1: On Windows, DCOM clients and servers process the OBJREF supplied in the data field of this ORPC extension as a reference to an object that supports the IErrorInfo interface. For more information, see [MSDN-IERRORINFO].
<16> Section 2.2.21.2: Optionally specifies the index for a help topic in the help file specified by the HelpFile field.
<17> Section 2.2.21.2: Optionally specifies a human-readable string containing the name of the component returning the error.
<18> Section 2.2.21.2: Optionally specifies a human-readable string containing a description of the error.
<19> Section 2.2.21.2: Optionally specifies a path to a Windows Help file containing a Help topic that provides further information for the error.
<20> Section 2.2.21.4: On Windows, DCOM clients set this value to the size (in bytes) of the body of the RPC PDU containing this structure.
<21> Section 2.2.21.4: This field is used by applications or higher-layer protocols. On Windows, DCOM clients and servers ignore this field.
<22> Section 2.2.22.1: On Windows, DCOM clients set this field to MSHCTX_DIFFERENTMACHINE (0x00000002), which is a value from the MSHCTX enumeration. For more information, see [MSDN-MSHCTX].
<23> Section 2.2.22.2.1: On Windows, DCOM clients set this field to one or more values from the CLSCTX enumeration. For more information, see [MSDN-CLSCTX].
<24> Section 2.2.22.2.2: On Windows, DCOM clients set this field to TRUE if the client was impersonating when the activation request was originated, and to FALSE otherwise. On Windows, DCOM servers ignore this field. For more information, see [MSDN-CI].
<25> Section 2.2.22.2.2: On Windows, DCOM clients set this field to FALSE (0x00000000) if guidPartition is not set, and to TRUE (0x00000001) otherwise. On Windows, DCOM servers use the guidPartition field if fPartitionIDPresent is set to TRUE.
<26> Section 2.2.22.2.2: On Windows, DCOM clients set this field to an RPC authentication constant (see [MS-RPCE] section 2.2.1.1.8).
<27> Section 2.2.22.2.2: The value contains a GUID used by applications or higher-layer protocols.
<28> Section 2.2.22.2.2: On Windows, DCOM clients set this field to the unmodified CLSCTX value specified by the client when the activation request was originated. For more information, see [MSDN-CLSCTX].
<29> Section 2.2.22.2.2: Windows 2000, Windows XP and Windows Server 2003 use SpecialPropertiesData_Alternate.
<30> Section 2.2.22.2.3: On Windows, DCOM clients set this to a file name passed to the CoGetInstanceFromFile API. For more information, see [MSDN-CoGetInstanceFromFile].
<31> Section 2.2.22.2.3: On Windows, DCOM clients set this field to the unmodified STGM constant. For more information, see [MSDN-STGMC].
<32> Section 2.2.22.2.3: On Windows, DCOM clients set this to the IStorage reference passed to the CoGetInstanceFromIStorage API. For more information, see [MSDN-CoGetInstanceFromIStorage].
<33> Section 2.2.22.2.4.1: On Windows, DCOM clients set this field to the value 2.
<34> Section 2.2.22.2.7: On Windows, DCOM clients include this structure; On Windows, DCOM servers ignore it.
<35> Section 2.2.22.2.7: On Windows, DCOM clients send a COSERVERINFO structure in this field as specified. On Windows, DCOM servers ignore this field.
<36> Section 2.2.22.2.7.1: On Windows, DCOM clients set pwszName to the remote server name specified by the client when requesting the activation. On Windows, DCOM servers ignore this field.
<37> Section 2.2.22.2.8.1: On Windows, DCOM servers return an RPC authentication level that denotes the minimum authentication level at which the object exporter can be called. On Windows, DCOM clients make calls to object exporters at an authentication level that is at least as high as the authnHint value returned from the object server, or the RPC_C_AUTHN_LEVEL_PKT_INTEGRITY level, whichever is greater. Including the RPC_C_AUTHN_LEVEL_PKT_INTEGRITY authentication level in this evaluation is supported by the operating systems specified in [MSFT-CVE-2022-37978], each with its related KB article download installed.
<38> Section 3: On Windows, all implementations support both roles simultaneously.
<39> Section 3.1.1.5.1: On Windows, servers will set the SORF_NOPING flag if the application specifies the MSHLFLAGS_NOPING flag in the mshlflags parameter to the CoMarshalInterface API. For more information, see [MSDN-CoMarshalInterface].
<40> Section 3.1.1.5.4: Windows XP operating system Service Pack 2 (SP2), Windows Server 2003 operating system with Service Pack 1 (SP1), Windows Vista and later, and Windows Server 2008 and later DCOM servers return E_ACCESSDENIED if the ORPC invocation is for the IRemUnknown (section 3.1.1.5.6) interface or the IRemUnknown2 (section 3.1.1.5.7) interface. They return ERROR_ACCESS_DENIED for all other interfaces. On Windows NT 4.0 operating system, Windows 2000, Windows XP, Windows XP operating system Service Pack 1 (SP1), and Windows Server 2003, DCOM servers return E_ACCESSDENIED for all interfaces.
<41> Section 3.1.1.5.4: On Windows, DCOM servers use the LegacyAuthenticationLevel value (see [MSDN-LegAuthLevel] for more information) as the object exporter's default authentication level setting.
<42> Section 3.1.1.5.4: On Windows XP SP2, Windows Server 2003 with SP1, Windows Vista and later, and Windows Server 2008 and later, DCOM servers return E_ACCESSDENIED if the ORPC invocation is for the IRemUnknown (section 3.1.1.5.6) interface or the IRemUnknown2 (section 3.1.1.5.7) interface and if the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) allows anonymous clients. They return ERROR_ACCESS_DENIED for all other interfaces or if the MachineAccessRestriction does not allow anonymous clients. On Windows NT 4.0, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003, DCOM servers return E_ACCESSDENIED for all interfaces.
<43> Section 3.1.1.5.4: On Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003, DCOM servers use the DefaultAccessPermission (see [MSDN-DefAccPerms] for more information) or the AccessPermission of the object exporter (see [MSDN-AccPerms] for more information) as the default value of the permissions.
On Windows XP SP2, Windows Server 2003 with SP1, Windows Vista and later, and Windows Server 2008 and later the default value of the permissions for DCOM servers consists of both:
The MachineAccessRestriction (see [MSDN-MachAccRstr] for more information).
The DefaultAccessPermission (see [MSDN-DefAccPerms] for more information) or the AccessPermission that is specific to the object exporter (see [MSDN-AccPerms] for more information).
<44> Section 3.1.1.5.4: Windows object exporters use an application-specified message filter. For more information, see [MSDN-IMessageFilter].
<45> Section 3.1.1.5.4: On Windows, DCOM server object exporters supply the well-known ORPC extensions (see section 2.2.21), if present, to applications and higher-layer protocols.
<46> Section 3.1.1.5.4: On Windows, DCOM server object exporters return the extensions field supplied by the well-known ORPC extensions (see section 2.2.21), if present.
<47> Section 3.1.1.5.4: On Windows 2000, Windows XP, Windows XP SP1, Windows XP SP2, Windows Server 2003, and Windows Server 2003 with SP1, DCOM servers optionally append extra data to the end of an ORPC response. This is due to a coding error and the extra data, if present, has no meaning and is ignored by Windows recipients. Whether the data is sent or not does not affect interoperability, and the protocol functions correctly. On Windows XP operating system Service Pack 3 (SP3), Windows Server 2003 operating system with Service Pack 2 (SP2), Windows Vista and later, and Windows Server 2008 and later, DCOM servers do not have this coding error and do not append extra data.
<48> Section 3.1.1.5.6.1.2: On Windows, DCOM server object exporters require security on a RemAddRef call that specifies private reference counts. They will associate the private reference counts with the security identity of the client that makes the RemAddRef call.
<49> Section 3.1.1.5.6.1.3: On Windows, DCOM server object exporters require security on a RemRelease call that specifies private reference counts. They will verify that the security identity of the client that makes the RemRelease call has previously allocated at least that many private reference counts in the IPID entry.
<50> Section 3.1.1.5.8: Opnums reserved for local use apply to Windows as follows.
|
opnum |
Description |
|---|---|
|
0-2 |
Not used by Windows. Returns a failure if called. |
Windows clients internally map the three IUnknown interface methods to the three methods of the IRemUnknown interface.
<51> Section 3.1.2.3: By default, Windows object resolvers listen by way of the following RPC protocols.
|
ncacn_ip_tcp |
ncacn_spx |
ncacn_nb_nb |
ncacn_nb_ipx |
ncadg_ip_udp |
ncadg_ipx |
|
|---|---|---|---|---|---|---|
|
Windows NT |
X |
X |
X |
X |
X |
X |
|
Windows 2000 |
X |
X |
X |
X |
|
|
|
Windows XP |
X |
X |
X |
X |
|
|
|
Windows Server 2003 and later |
X |
|
|
|
|
|
|
Windows Vista and later |
X |
|
|
|
|
|
<52> Section 3.1.2.5.1.1: On Windows, DCOM servers return the minimum accepted authentication level of the object exporter in this field. On Windows, DCOM clients by default make calls to the object exporter, at least at this level of authentication.
<53> Section 3.1.2.5.1.1: On Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003, DCOM servers do not check permissions when processing this call.
On Windows XP SP2, Windows Server 2003 with SP1, Windows Vista and later, and Windows Server 2008 and later, DCOM servers check permissions when processing this call. They use the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) as the default value of the permissions.
<54> Section 3.1.2.5.1.2: On Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003, DCOM servers do not check permissions when processing this call.
On Windows XP SP2, Windows Server 2003 with SP1, Windows Vista and later, and Windows Server 2008 and later, DCOM servers check permissions when processing this call. They use the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) as the default value of the permissions.
<55> Section 3.1.2.5.1.3: On Windows, DCOM servers return a PingBackoffFactor of zero; On Windows, DCOM clients ignore any value returned by the server.
<56> Section 3.1.2.5.1.3: On Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003, DCOM servers do not check permissions when processing this call.
On Windows XP SP2, Windows Server 2003 with SP1, Windows Vista and later, and Windows Server 2008 and later, DCOM servers check permissions when processing this call. They use the MachineAccessRestriction (see [MSDN-MachAccRstr] for more information) as the default value of the permissions.
<57> Section 3.1.2.5.1.5: On Windows, DCOM servers return the minimum accepted authentication level of the object exporter in this field. On Windows, DCOM clients by default make calls to the object exporter, at least at this level of authentication.
<58> Section 3.1.2.5.1.7: Windows object resolvers wait for up to 14 minutes before removing the OID entry from the OID table.
<59> Section 3.1.2.5.2.2: Opnums reserved for local use apply to Windows as follows.
|
opnum |
Description |
|---|---|
|
0-2 |
Not used by Windows. Returns a failure if called. |
<60> Section 3.1.2.5.2.3: All server versions of the DCOM protocol for Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003 use the DefaultLaunchPermission (see [MSDN-DefLnchPerms] for more information) or the LaunchPermission that is specific to the object exporter (see [MSDN-LaunchPerms] for more information) as the default value of the permissions.
For Windows XP SP2, Windows Server 2003 with SP1, Windows Vista and later, and Windows Server 2008 and later versions of the DCOM protocol, the default value of the permissions consists of the following:
The MachineAccessRestriction (see [MSDN-MachAccRstr] for more information).
The MachineLaunchRestriction (see [MSDN-MachLnchRstr] for more information).
The DefaultLaunchPermission (see [MSDN-DefLnchPerms] for more information) or the LaunchPermission that is specific to the object exporter (see [MSDN-LaunchPerms] for more information).
<61> Section 3.1.2.5.2.3: On Windows XP SP2, Windows Server 2003 with SP1, Windows Vista and later, and Windows Server 2008 later, DCOM servers return ERROR_ACCESS_DENIED if the MachineLaunchRestriction or the MachineAccessRestriction does not allow access to the client's credentials.
On Windows NT 4.0, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003, DCOM servers return E_ACCESSDENIED if the DefaultLaunchPermission or the LaunchPermission that is specific to the object exporter does not allow access to the client's credentials.
<62> Section 3.1.2.5.2.3: Windows 2000 object resolvers ignore the SPD_FLAG_USE_CONSOLE_SESSION flag and create the object exporter in the logon session specified in the dwSessionID field, if it is not 0xFFFFFFFF. If the dwSessionID field contains 0xFFFFFFFF, then object resolvers create the object exporter in any logon session.
<63> Section 3.1.2.5.2.3: Windows 2000 object resolvers ignore the SPD_FLAG_USE_CONSOLE_SESSION flag and create the object exporter in the logon session specified in the dwSessionID field, if it is not 0xFFFFFFFF. If the dwSessionID field contains 0xFFFFFFFF, then object resolvers create the object exporter in any logon session.
<64> Section 3.1.2.5.2.3: Windows object resolvers determine the configuration of the identity of the object exporter as described in [MSDN-RunAs].
<65> Section 3.1.2.5.2.3: Windows 2000 and Windows XP object resolvers ignore the ACTVFLAGS_ACTIVATE_32_BIT_SERVER and the ACTVFLAGS_ACTIVATE_64_BIT_SERVER flags and create the object exporter in the 32-bit address space.
<66> Section 3.1.2.5.2.3: Windows 2000 and Windows XP object resolvers ignore the ACTVFLAGS_ACTIVATE_32_BIT_SERVER and the ACTVFLAGS_ACTIVATE_64_BIT_SERVER flags and create the object exporter in the 32-bit address space.
<67> Section 3.1.2.5.2.3: Windows 2000, Windows XP, and Windows Server 2003 object resolvers ignore the ACTVFLAGS_NO_FAILURE_LOG flag and log errors during activation. Windows Vista and later and Windows Server 2008 and later object resolvers log only permission failure errors when the ACTVFLAGS_NO_FAILURE_LOG flag is set and do not log any other errors.
<68> Section 3.1.2.5.2.3.1: On Windows, DCOM clients set this to a file name passed to the CoGetInstanceFromFile API. For more information, see [MSDN-CoGetInstanceFromFile].
<69> Section 3.1.2.5.2.3.1: On Windows, DCOM clients set this to the IStorage reference passed to the CoGetInstanceFromIStorage API. For more information, see [MSDN-CoGetInstanceFromIStorage].
<70> Section 3.1.2.5.2.3.1: On Windows, DCOM clients set this field to the value 2.
<71> Section 3.1.2.5.2.3.1: If the DCOM application passes a file name to the CoGetInstanceFromFile API. For more information, see [MSDN-CoGetInstanceFromFile].
<72> Section 3.1.2.5.2.3.1: On Windows, DCOM servers return the minimum accepted authentication level of the object exporter in this field. On Windows, DCOM clients by default make calls to the object exporter at least at this level of authentication.
<73> Section 3.1.2.5.2.3.2: Windows uses IID_IActivationPropertiesIn as the IID of an interface with the local IDL attribute.
<74> Section 3.1.2.5.2.3.2: On Windows, DCOM clients send all the properties (including optional properties) listed in the following table, except InstanceInfoData. InstanceInfoData is sent only when the DCOM application makes a persistent activation request.
|
Property Name |
Section |
Required or Optional |
|---|---|---|
|
InstantiationInfoData |
Required |
|
|
ScmRequestInfoData |
Required |
|
|
LocationInfoData |
Required |
|
|
SecurityInfoData |
Optional |
|
|
ActivationContextInfoData |
Optional |
|
|
InstanceInfoData |
Optional |
|
|
SpecialPropertiesData |
Optional |
<75> Section 3.1.2.5.2.3.2: Windows uses IID_IActivationPropertiesOut as the IID of an interface with the local IDL attribute.
<76> Section 3.1.2.5.2.3.3: Windows uses IID_IActivationPropertiesIn as the IID of an interface with the local IDL attribute.
<77> Section 3.1.2.5.2.3.3: On Windows, DCOM clients send all the properties (including Optional properties) listed in the following table, except InstanceInfoData. InstanceInfoData is sent only when the DCOM application makes a persistent activation request.
|
Property name |
Section |
Required or optional |
|---|---|---|
|
InstantiationInfoData |
2.2.22.2.1 |
Required |
|
ScmRequestInfoData |
2.2.22.2.4 |
Required |
|
LocationInfoData |
2.2.22.2.6 |
Required |
|
SecurityInfoData |
2.2.22.2.7 |
Optional |
|
ActivationContextInfoData |
2.2.22.2.5 |
Optional |
|
InstanceInfoData |
2.2.22.2.3 |
Optional |
|
SpecialPropertiesData |
2.2.22.2.2 |
Optional |
<78> Section 3.1.2.5.2.3.3: Windows uses IID_IActivationPropertiesOut as the IID of an interface with the local IDL attribute.
<79> Section 3.2: For details on which versions of Windows support which version of the DCOM Remote Protocol, see section 2.2.11.
<80> Section 3.2.4.1.1.2: On Windows, the authentication level requested by the application is raised to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY ([MS-RPCE] section 2.2.1.1.8), if it is less than that. This behavior is supported in the following operating systems with its related KB article download installed: Windows 7 operating system with Service Pack 1 (SP1) and later and Windows Server 2008 operating system with Service Pack 2 (SP2) and later.
<81> Section 3.2.4.1.1.2: On Windows NT, Windows 2000, Windows XP, Windows XP SP1, and Windows Server 2003, DCOM clients specify RPC_C_AUTHN_LEVEL_CONNECT ([MS-RPCE] section 2.2.1.1.8) as the default authentication level value for the call.
On Windows XP SP2 and Windows Server 2003 with SP1, DCOM clients specify the higher of the LegacyAuthenticationLevel value ([MSDN-LegAuthLevel]) or RPC_C_AUTHN_LEVEL_CONNECT as the default authentication level value for the call.
On Windows Vista and later and Windows Server 2008 and later, DCOM clients specify the higher of the LegacyAuthenticationLevel value or RPC_C_AUTHN_LEVEL_PKT_INTEGRITY ([MS-RPCE] section 2.2.1.1.8) as the default authentication level value for the call.
The default activation authentication level is raised to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY level on client side for Windows 7 SP1 and later and the required activation authentication level needs to be at least at RPC_C_AUTHN_LEVEL_PKT_INTEGRITY level for authenticated activation on the server side for Windows Server 2008 R2 Service Pack 1 (SP1) and later to which this change has been backported.
<82> Section 3.2.4.1.1.2: On Windows, DCOM clients specify RPC_C_IMPL_LEVEL_IMPERSONATE (see [MS-RPCE] section 2.2.1.1.9) as the default impersonation level value for the call.
<83> Section 3.2.4.1.2: On Windows, clients will acquire an object reference for the IID specified by the application.
<84> Section 3.2.4.1.2.2: On Windows, DCOM clients specify RPC_C_AUTHN_LEVEL_PKT_INTEGRITY (see [MS-RPCE] section 2.2.1.1.8) as the authentication level for the call.
<85> Section 3.2.4.1.2.2: On Windows, DCOM clients specify RPC_C_IMPL_LEVEL_IDENTIFY (see [MS-RPCE] section 2.2.1.1.9) as the impersonation level for the call.
<86> Section 3.2.4.2: On Windows, DCOM clients use the LegacyAuthenticationLevel value (see [MSDN-LegAuthLevel] for more information) as the client's authentication level value.
<87> Section 3.2.4.2: On Windows, DCOM clients use the LegacyImpersonationLevel value (see [MSDN-LegIMPERSLVL] for more information) as the default impersonation level value.
<88> Section 3.2.4.2: On Windows, DCOM clients specify the extensions field if well-known ORPC Extensions (section 2.2.21) are supplied by the application.
<89> Section 3.2.4.2: On Windows XP SP3, Windows Server 2003 SP2, Windows Vista and later, and Windows Server 2008 and later, DCOM clients do not have this coding error and do not append extra data.
<90> Section 3.2.4.2: On Windows, DCOM clients return the extensions field to the application if well-known ORPC Extensions are present in the ORPCTHAT structure.
<91> Section 3.2.4.4.1: On Windows, DCOM clients use private references when the secure reference counting feature is enabled in the DCOM application using the EOAC_SECURE_REFS capability. For more information, see [MSDN-EOLE_AUTHENTICATION_CAPABILITIES]).
<92> Section 3.2.4.4.2: On Windows, DCOM clients use private reference counts when the secure reference counting feature is enabled using the EOAC_SECURE_REFS capability. For more information, see [MSDN-EOLE_AUTHENTICATION_CAPABILITIES]).
<93> Section 3.2.6.1: On Windows, DCOM clients specify RPC_C_AUTHN_LEVEL_PKT_INTEGRITY (see [MS-RPCE] section 2.2.1.1.8) as the authentication level for the call.
<94> Section 3.2.6.1: On Windows, DCOM clients specify RPC_C_IMPL_LEVEL_IDENTIFY (see [MS-RPCE] section 2.2.1.1.9) as the impersonation level for the call.
<95> Section 5.1: If the application enables the EOAC_SECURE_REFS capability. For more information, see [MSDN-EOLE_AUTHENTICATION_CAPABILITIES]. The default Windows security configuration requires the client to specify security on the activation requests and ORPC requests.