Hi metze, The registry entry to restore the default behavior is: [HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]EnableWeakCryptography = 0x1
Note that the plan is at some point this will go away, as will the ability to restore the default behavior. I have created a DTM workspace for exchanging files related to this issue (credentials and link below). Please find on the workspace 'PartnerTTDRecorder_x86_x64.zip' available for download. These tools can be staged on the Windows client for collecting traces. The instructions below assume they were staged to C:\TDD. These traces are highly compressible, please add them to a .zip archive for transferring. To collect the needed traces: 1. From a PowerShell prompt, execute: C:\TTD\tttracer.exe -Attach ([int](Get-Process -NAME lsass | Format-Wide -Property ID).formatEntryInfo.formatPropertyField.propertyValue) 2. Wait for a little window to pop up in top left corner of your screen, titled "lsass01.run" 3. start a network trace using netsh or WireShark, etc. 4. Repro the attempted operation 5. Stop the network trace and save it 6. CAREFULLY: uncheck the checkbox next to "Tracing" in the small "lsass01.run" window. Do not close or exit the small window or you will need to reboot. 7. The TTTracer.exe process will generate a trace file, then print out the name and location of the file. Compress the *.run file into a .zip archive before uploading with the matching network trace. It is a good idea to reboot the machine at the next opportunity to restart the lsass process. Workspace credentials and link: Log in as: [email protected] 1-time: M7_h@91f Link: https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiZjY5NGMxMTItN2Y4OS00MzNmLWIwYmYtYjhiNjk3ZThmZjlhIiwic3IiOiIyMjA3MjAwMDQwMDA1NDgyIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI4ZjhmOTk0NS01ZDE4LTRkYWQtOThhMS01ZWY3MjI0ODU5ZWYiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NjYyOTI0MTksIm5iZiI6MTY1ODUxNjQxOX0.p_X_ajVstNCxah482jUaWEp-gWBwVEpjlEsKdU2CwM7M5-fOms77Z34KslF76XVzv8uiSEmUWAC7tMGNjsv7WvPe8aiE_Ufp1OJZZOjFccnnoiMx4NVP32J1_CD-vSxV6GCzkbo1iF9VMysXd3cUnjgQ6Gk-x41l9HJFZ8AAHFac4aQ5JhXZOgPwr23GwB-H-OYVp91h1UsWQgpYj286biL1_HXktGgudBAJnUr1cpbB150BGCOGorEjV4N3eOdWdoVyjhcc25d1UGhR4JwpgF8PplV7VV6wXqznBrnO8-AbA7huIScacfkwH3ijxnJoz4RWNlKPwoXBDQtlcuzFPQ&wid=f694c112-7f89-433f-b0bf-b8b697e8ff9a Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=02%7C01%7Cjeffm%40microsoft.com%7C92c4c7bb8c6d4412e78108d80d79f45f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637274164726698458&sdata=KtEL7V58Q7rscYvr9cPik%2FmYKZIv0rh3E3kBdGywwwI%3D&reserved=0> | Extension 1138300 -----Original Message----- From: Stefan Metzmacher [email protected]<mailto:[email protected]> Sent: Wednesday, July 20, 2022 5:55 AM To: Interoperability Documentation Help [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: [EXTERNAL] MSFT-CVE-2022-21925 MS-BKRP 3.2.4.1 Performing Client-Side Wrapping of Secrets Hi Dochelp, I'm currently debugging a problem where client seem to have problems with our MS-BKRP implementation. I found the following: <18> Section 3.2.4.1: The process of falling back to server-side wrapping using the BACKUPKEY_BACKUP_GUID when retrieval of the server's public key fails using the BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID is no longer available by default for the operating systems specified in [MSFT-CVE-2022-21925]. However, the fall back to server-side wrapping can be enabled by adding a registry key designed for this purpose. In addition, as noted earlier, Windows clients always retry failing operations once. The resulting process is as follows: The client first tries the BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID operation, and if it fails, the client performs DC (2) rediscovery and retries the same operation. If the retry fails, the client tries a BACKUPKEY_BACKUP_GUID operation. If this fails, the client performs DC rediscovery again and retries the BACKUPKEY_BACKUP_GUID operation. If this also fails, an error is returned to the caller. I have two questions: 1. what is the name and value is for the registry key in order to allow the fallback to server-side wrapping to be activated again. 2. Is your tracing tool also able to debug client side powershell scripts? My customer is able to trigger the problem with ConvertFrom-SecureString/ConvertTo-SecureString Thanks! metze
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
