Microsoft hardening DCOM, forcing packet integrity on March 14, 2023

[Randy Berry]

DCOM = Distributed Com Object Model

Update Release Behavior Change
June 8, 2021 Hardening changes disabled by default, but with ability to enable them using a register key.
June 14, 2022 Hardening changes enabled by default, but with ability to disable them using a register key.
March 14, 2023 Hardening changes enabled by default, with no ability to disable them.
By this point, you must resolve any compatibility issues with the hardening changes and applications in your environment.

Microsoft is saying that applications must leverage "Packet Integrity" or higher for COM + communications.
Packet Integrity = Authenticates credentials and verifies that no call data has been modified in transit.
Packet Privacy = Authenticates credentials and encrypts the packet, including the data and the sender's identity and signature.

I am using VB6 with my DataEnvironment.Dsr connecting as follows:
Data Link Connection: Provider=SQLNCLI.1;Persist Security Info=False;Extended Properties="Server=MyServer;Database=MyDataBase;Uid=MyUserID;"

My registry setting that is turned off for Packet Integrity is: Computer>HKEY_LOCAL_MACHINE>SOFTWARE>Microsoft>Ole>AppCompat
Registry Name = RequireIntegrityActivationAuthenticationLevel
Registry Value = 0x00000000 (Base Hexadecimal) (disabling Packet Integrity)

When I change the registry value to 0x00000001 (Base Hexadecimal) (enabling Packet Integrity) to test what will happen March 14, 2023, my apps no longer work.

Microsoft SQL Server Login

Connection failed:
SQL State: '08001'
SQL Server Error: 10061
TCP Provider: No connection could be made because the target machine actively refused it.

Connection failed:
SQL State: '08001'
SQL Server Error: 10061

Connection failed:
SQL State: 'HYT00'
SQL Server Error: 0


Does anyone know what addition to the connection string is needed to be able to run with Packet Integrity?

[Schmidt]

This thread should be moved to the main-VB-forum IMO...

Though - when MS states, that only COM+ interactions are affected -
(x-process/x-machine exchanges between COM-Objects) ...
I cannot see (at the moment) - how that relates to:
- "establishing a Client-ADO-Connection to MS-SQLServer"
... (since that communication happens via the TSQL-protocol over normal sockets or pipes usually).

The only thing I can think of, which might be related to "COM+ interactions"
(in the phase of building an ADO-connection) - is the ADO-Connection-Caching-mechanism.

I've never disabled this explicitely (in my Connection-strings to MS-SQLServer) and don't have "any flags handy" here -
but that (disabling the connection-cache) might be a thing you could google and try in your tests...

Olaf

[wqweto]

Data Link Connection: Provider=SQLNCLI.1;Persist Security Info=False;Extended Properties="Server=MyServer;Database=MyDataBase;Uid=MyUserID;"

One of the most weird ADO connection string I've seen recently. SQLNCLI is SQL Server Native Client 9.0 OLEDB provider for MSSQL 2005 and here are some sample strings i.e. very logically using Server, Database, etc. properties (e.g. Provider=SQLNCLI;Server=myServerAddress;Database=myDataBase;Uid=myUsername;Pwd=myPassword)

On the other hand the presence Extended Properties suggests using ODBC shim i.e. OLEDB Provider for ODBC. This I didn't realize might happen if provider name is not found (SQLNCLI.1 in this case) then ADO to default to the ODBC provider (i.e. MSDASQL) which is unexpected to happen automatically.

cheers,
</wqw>

[ahenry]

I don't see events 10036, 10037, or 10038 in my System event log, so I guess this doesn't affect regular ActiveX exes that haven't been configured for DCOM.