DCOM Hardening - Autentication level for calls

Question

MS is changing the minimum security level for DCOM. The setting "Authentication level for calls", a setting for the COM+ application, will be set to minimum "Packet integrity" and this will be mandatory by March 2023.

According to Microsoft, the correct way to handle this is to make this change in you application through programming rather then changing the setting of the com+ app under Computer services>COM+ applications. Is there anybody who got experience from this, how it is done? Me and my team are struggling a bit with this. We use Delphi RAD Studio but that is not important I would guess, the principles are likely the same regardless.

We have looked at the possibilities to change this setting by programming it but does not seem possible without a total rewrite of Delphi core functions. When the com+ object is created by a Delphi core-function, there is property for authentication level which is not set, it is left "blank". We interpret this as it will apply the Authentication level of the COM+ object under COM+ applications.

There is also a function CoInitializeSecurity that actually seem as a more plausible alternative but it is still unclear. Anyone?

Answer 1

We just resolve this problem in our Delphi application with CoInitializeSecurity function and it works.

We made two types:

type
  TAuthenticationLevel = (
    alMclDefault,
    alMclNone,
    alMclConnect,
    alMclCall,
    alMcllPacket,
    alMclPacketIntegrity,
    alMclPacketPrivacy
  );
  TImpersonationLevel = (
    ilMclNone,  // dummy
    ilMclAnonymous,
    ilMclIdentify,
    ilMclImpersonate,
    ilMclDelegate
  );

and on the end of mainform.pas, initialization call:

initialization
  OleCheck(CoInitializeSecurity(nil, -1, nil, nil, ord(alMclPacketIntegrity), ord(ilMclIdentify), nil, 0, nil));
end.

Answer 2

Trying to figure out the same for an old VB6 app using Activex.exes via DCOM, and I'm not convinced it's feasible.

VB6 hides the ability to change the security settings other than with the DCOM configuration tool, and attempting to match the settings there doesn't allow the client to connect at all.

The client does call CoInitialize, using None & Anonymous as default, but changing to PKT_Integrity in that call, along with changing gloabal DCOM permissions to Packet integrity doesn't allow the connection to complete.