Hi metze,

Thanks for letting me know, I'm glad it's working better. Please let us know at 
our DocHelp alias if there's anything we can help with. 

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 | Extension 1138300

-----Original Message-----
From: Stefan Metzmacher <[email protected]> 
Sent: Monday, July 25, 2022 7:56 AM
To: Jeff McCashland (He/him) <[email protected]>
Cc: [email protected]; Microsoft Support <[email protected]>
Subject: [EXTERNAL] Re: MSFT-CVE-2022-21925 MS-BKRP 3.2.4.1 Performing 
Client-Side Wrapping of Secrets - TrackingID#2207200040005482

Hi Jeff,

> The registry entry to restore the default behavior is:
> [HKLM\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-
> 11d1-8c7a-00c04fc297eb]EnableWeakCryptography = 0x1

Thanks!

> Note that the plan is at some point this will go away, as will the ability to 
> restore the default behavior.

Ok, at this point we managed to get it working by removing the 
BCKUPKEY_PREFERRED (symlink), which means a new public key pair with a new 
certificate was generated (with a current samba version).
It seems certificates generated by 10 year old samba versions are not accepted.

I may come back to this later, in order to debug the details, but for now it's 
on hold...

Thanks!
metze

> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp
> ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUz
> I1NiJ9.eyJ3c2lkIjoiZjY5NGMxMTItN2Y4OS00MzNmLWIwYmYtYjhiNjk3ZThmZjlhIiw
> ic3IiOiIyMjA3MjAwMDQwMDA1NDgyIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtY
> mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI
> 4ZjhmOTk0NS01ZDE4LTRkYWQtOThhMS01ZWY3MjI0ODU5ZWYiLCJpc3MiOiJodHRwczovL
> 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHA
> iOjE2NjYyOTI0MTksIm5iZiI6MTY1ODUxNjQxOX0.p_X_ajVstNCxah482jUaWEp-gWBwV
> EpjlEsKdU2CwM7M5-fOms77Z34KslF76XVzv8uiSEmUWAC7tMGNjsv7WvPe8aiE_Ufp1OJ
> ZZOjFccnnoiMx4NVP32J1_CD-vSxV6GCzkbo1iF9VMysXd3cUnjgQ6Gk-x41l9HJFZ8AAH
> Fac4aQ5JhXZOgPwr23GwB-H-OYVp91h1UsWQgpYj286biL1_HXktGgudBAJnUr1cpbB150
> BGCOGorEjV4N3eOdWdoVyjhcc25d1UGhR4JwpgF8PplV7VV6wXqznBrnO8-AbA7huIScac
> fkwH3ijxnJoz4RWNlKPwoXBDQtlcuzFPQ%26wid%3Df694c112-7f89-433f-b0bf-b8b6
> 97e8ff9a&amp;data=05%7C01%7Cjeffm%40microsoft.com%7C49d9b50025cc4bbac7
> f508da6e4dc694%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379435775
> 88349619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=AKccJBRYSadhYk
> fzY0JGcaiGrBrmC0GaLQlV5sQ5DOg%3D&amp;reserved=0
> 
> 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: 
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> rt.microsoft.com%2Fglobalenglish&amp;data=05%7C01%7Cjeffm%40microsoft.
> com%7C49d9b50025cc4bbac7f508da6e4dc694%7C72f988bf86f141af91ab2d7cd011d
> b47%7C1%7C0%7C637943577588349619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> amp;sdata=cxD%2FNuPDcTVg19hLvxmEnVDWyhh10n1xPCiC9HKIOM0%3D&amp;reserve
> d=0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs
> upport.microsoft.com%2Fglobalenglish&amp;data=05%7C01%7Cjeffm%40micros
> oft.com%7C49d9b50025cc4bbac7f508da6e4dc694%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C637943577588349619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&amp;sdata=cxD%2FNuPDcTVg19hLvxmEnVDWyhh10n1xPCiC9HKIOM0%3D&amp;res
> erved=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

Reply via email to