Hi Andreas, Thank you for the summaries and suggestions. I will follow up on these with our SAMR team.
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: Andreas Schneider <a...@samba.org> Sent: Friday, July 15, 2022 12:18 AM To: Jeff McCashland (He/him) <je...@microsoft.com> Cc: cifs-protocol@lists.samba.org; Jeff McCashland <je...@microsoftsupport.com> Subject: [EXTERNAL] Re: [MS-SAMR] 3.2.2.5 Deriving an Encryption Key fr... - TrackingID#2207140040006706 On Friday, July 15, 2022 1:43:47 AM CEST Jeff McCashland (He/him) wrote: > Hi Andreas, Hi Jeff, > Actually, I think you are correct that dkLen is 16, as the result when > the server calls the PBKDF2 function is 16 bytes. The failure occurs > because your AuthData doesn't match what we calculate. > > I'm assuming P is the hash of the old password. Here are byte dumps of > the inputs and outputs to the PBKDF2 function from your trace: > > P: f8 48 54 de b8 36 10 33-ca ea 5c 95 96 66 99 38 > S: d5 be 4f d7 b6 85 d1 ea-fd 3b f4 29 83 ce 10 44 > c: 0x5bed > > Derived Key: f1 e6 b2 6a 78 28 63 05-77 38 c9 71 d2 05 88 58 thank you very much for confirming this. I created a unit test with the values and it worked. I just had two passwords swapped and after fixing it I got it working :-) $ ./bin/rpcclient ncacn_np:earth.milkyway.site -U'bob%Pa$$w0rd@3' -c 'chgpasswd4 bob Pa$$w0rd@3 Pa$$w0rd@8' -d10 [..] rpc_api_pipe: host earth.milkyway.site returned 4 bytes. samr_ChangePasswordUser4: struct samr_ChangePasswordUser4 out: struct samr_ChangePasswordUser4 result : NT_STATUS_OK Summary: 3.2.2.5 Deriving an Encryption Key from a Plaintext Password The client MUST derive the CEK in the following manner: CEK :: = (PBKDF2(NT HASH of "OldPassword", Salt, IterationCount, 512)) This need to be clarified that 512 means that the PBKDF2 functions should use SHA512 internally. It should also state the the CEK length should be 16! 3.1.5.10.4 SamrUnicodeChangePasswordUser4 (Opnum 73) 7. If Stored-NT-Hash is not NULL and EncryptedPassword.PBKDF2Iterations is valid, the server will decrypt EncryptedPassword as follows: [..] This has details which are missing in 3.2.2.5. It also misses some details (like SHA512). I would suggest you put all relevant information in 3.2.2.5 and point there. Thanks for your help! Best regards Andreas > From which we calculate the mac_key: > 95 40 fc 6d bb 63 16 46-73 ea 0c ab 26 ea 00 5a > 68 b2 d2 20 60 34 12 31-7a 4f d7 d0 9b 38 d4 e6 > d1 f6 cb 6c f3 71 99 9f-b4 0c d5 46 e8 d4 f5 7a > 3c e4 49 8b eb d6 16 31-36 da b4 15 e0 78 d0 e1 > > That is then used generate AuthData: > ce bf 34 2e cf 5a a4 e7-09 f0 8e a5 41 16 c7 5f > e2 56 59 7c 26 ed 23 28-3f 79 23 29 9e ae 86 d2 > ef ea 32 f8 5c d3 69 dd-48 7b de 63 6f 8e d3 61 > 0e 61 1c 1d 1a 77 23 e9-d5 7f 52 33 0c c4 2d c5 > > Which doesn't match what you sent: > 92 1c bd b5 90 a5 28 23 e9 0a f0 bc f3 74 f5 ba > c3 13 34 c4 8b 11 3d a6 ea 28 55 41 9b 80 f0 d7 > 8e 2a 66 5b b7 c1 12 f0 3f 18 a4 fc 5d dd c4 b3 > 37 71 5b 1b b6 71 10 86 78 f5 04 db 34 b4 0a 4d > > Best regards, > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol > Open Specifications Team > > -----Original Message----- > From: Jeff McCashland (He/him) > Sent: Thursday, July 14, 2022 3:03 PM > To: Andreas Schneider <a...@samba.org> > Cc: cifs-protocol@lists.samba.org; Jeff McCashland > <je...@microsoftsupport.com> Subject: RE: [MS-SAMR] 3.2.2.5 Deriving an > Encryption Key fr... - TrackingID#2207140040006706 > > Hi Andreas, > > You referenced the PBKDF2 profile from the RFC: > PBKDF2 (P, S, c, dkLen) > > And where it's used in [MS-SAMR] section 3.2.2.5: > CEK :: = (PBKDF2(NT HASH of "OldPassword", Salt, IterationCount, 512)) > > P = NT HASH of "OldPassword" > S = Salt > c = IterationCount > dkLen = 512 > > I think the 512 is actually the dkLen, rather than a reference to SHA512. > Let me know if you still get an error using 512 as dkLen. > > 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%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZS7bZUfy3%2BAbmfB2sHArgrB%2F2GMoYCWvQTNwZWFiVeY%3D&reserved=0 > | Extension > 1138300 > > -----Original Message----- > From: Jeff McCashland (He/him) > Sent: Thursday, July 14, 2022 10:53 AM > To: Andreas Schneider <a...@samba.org> > Cc: cifs-protocol@lists.samba.org; Jeff McCashland > <je...@microsoftsupport.com> Subject: RE: [MS-SAMR] 3.2.2.5 Deriving an > Encryption Key fr... - TrackingID#2207140040006706 > > [HC to BCC] > > Hi Andreas, > > I will assist you with this issue. I have the traces you uploaded to the > workspace for our previous case. In general, it's best to wait for a new > workspace link before uploading traces, so the traces are connected to the > correct issue. > > Below I've included credentials and a workspace link for this specific > issue/case. The reason I've been setting up separate workspaces is that any > time you update/fix your implementation, we consider subsequent concerns as > new issues even if the operation and error are the same. > > I'll analyze the traces and let you know what I find. > > Credentials for any additional files related to this issue: > Log in as: 2207140040006706_andr...@dtmxfer.onmicrosoft.com > 1-time: 75M1vMQ] > > Workspace link: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSU&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cGW24ePuV6vixdM%2BkaDphEaMDJJZc4cwu%2BHiVVJ4mts%3D&reserved=0 > zI1NiJ9.eyJ3c2lkIjoiOTQwYTI3MmYtNTA3ZC00MWRiLTg1YTUtZWJmMmRlNTIxMzJhIiwic3Ii > OiIyMjA3MTQwMDQwMDA2NzA2IiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNi > ZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI0NGQ3MTRmYy00NTRk > LTRhOTgtOWFjNi0xNzcwOTJmNjcyNTgiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWlj > cm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NjU1OTcwNzksIm5iZiI6MTY1 > NzgyMTA3OX0.TGwaNQYExmasfoHGEEd1ZeXoXkqMc0_3-vdRo02F2qIMVEL0QDNZPCjSotF_eK-2 > uCPI-uZHrqQ5nYuXKxJaQ4GFTPic0ncYkbiFdhbVPTJgwKpjyddv9AM11lV1M8_5wgtMPCQjeEeh > KaevPB6ioCMXTMsX5cJAJ92ZGnIwCAwDuqGKILmLWltKtyQl5oYOOKRbi8zsPHFt7SKQqc3yP4YG > b0NemT1e2tllZ_rewpEChdlqqrg9BC9-EL-UOUhnqcJRaJ5R_PzDPA4hKywK8o-5NJ3bZku7bAdg > P1LLhMwhfFe0vMetd5o7EUMpTACriiD-UqiQTUKdyEMHQlVBbw&wid=940a272f-507d-41db-85 > a5-ebf2de52132a > > 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%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZS7bZUfy3%2BAbmfB2sHArgrB%2F2GMoYCWvQTNwZWFiVeY%3D&reserved=0 > | Extension > 1138300 > > -----Original Message----- > From: Hung-Chun Yu <hungchun...@microsoft.com> > Sent: Thursday, July 14, 2022 10:20 AM > To: Andreas Schneider <a...@samba.org> > Cc: cifs-protocol@lists.samba.org > Subject: [MS-SAMR] 3.2.2.5 Deriving an Encryption Key fr... - > TrackingID#2207140040006706 > > [BCC] dochelp > > HI Andreas > > Thank you for contacting Microsoft Open Specifications Support. We created > SR Case - TrackingID#2207140040006706 to track this issue. Do leave this > tag in the subject line for future reference. One of our engineers will be > contacting you shortly. > > Hung-Chun Yu > Escalation Engineer > Microsoft Open Specifications > > -----Original Message----- > From: Andreas Schneider <a...@samba.org> > Sent: Thursday, July 14, 2022 1:03 AM > To: Interoperability Documentation Help <doch...@microsoft.com> > Cc: cifs-protocol@lists.samba.org > Subject: [EXTERNAL] [MS-SAMR] 3.2.2.5 Deriving an Encryption Key from a > Plaintext Password > > Dear Dochelp Team, > > I need your help again :-) > > I'm trying to implement SamrUnicodeChangePasswordUser4. However when I try > to run my implementation against Windows. I always get > STATUS_WRONG_PASSWORD returned. > > For the SamrUnicodeChangePasswordUser4 method (section 3.1.5.10.4), the > shared secret is the plaintext old password and the CEK is generated as > specified in section 3.2.2.5. > > 3.2.2.5 Deriving an Encryption Key from a Plaintext Password > > The client MUST derive the CEK in the following manner: > CEK :: = (PBKDF2(NT HASH of "OldPassword", Salt, IterationCount, 512)) > > > > Looking at the RFC 8018 section 5.2: > > PBKDF2 (P, S, c, dkLen) > > Options: PRF underlying pseudorandom function (hLen > denotes the length in octets of the > pseudorandom function output) > > Input: P password, an octet string > S salt, an octet string > c iteration count, a positive integer > dkLen intended length in octets of the derived > key, a positive integer, at most > (2^32 - 1) * hLen > > Output: DK derived key, a dkLen-octet string > > > The MS-SAMR document doesn't say a word about the dkLen. Which would be how > many bytes the pbkdf2 function should return for the CEK. > > I've used 16 bytes (same as the session key) as dkLen. However I get > STATUS_WRONG_PASSWORD > > > ./bin/rpcclient ncacn_np:earth.milkyway.site -U'bob%Pa$$w0rd@3' -c > 'chgpasswd4 bob Pa$$w0rd@3 Pa$$w0rd@6' [...] > rpc_api_pipe: host earth.milkyway.site returned 4 bytes. > samr_ChangePasswordUser4: struct samr_ChangePasswordUser4 > out: struct samr_ChangePasswordUser4 > result : NT_STATUS_WRONG_PASSWORD > > > I've uploaded traces to: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.mi%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652653073%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h1eengbZVRm1%2FnWRG3tacNgThY%2FGKk5rG6Rk1ixpXhM%3D&reserved=0 > crosoft.com%2Ffiles&data=05%7C01%7Cjeffm%40microsoft.com%7C2e7351441cdb4 > 696179208da65bd0dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63793415990 > 7789590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 > Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZnF7vMBiUpxR5NHinHK%2B0ID8g > Xvuo%2FgzJ%2FWcXlDBojU%3D&reserved=0? > workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiNTY5YjBlMTItMzYy > NS00NjhlLWIwNjgtOTBiZDYyZDk2MTllIiwic3IiOiIyMjA3MTEwMDQwMDA4ODMyIiwiYXBwaWQi > OiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJF > eHRlcm5hbCIsInd0aWQiOiJhYzUxMDFlOS1mMTExLTQ5MGUtOGVlYS04NWMxNGMyNzMyNmIiLCJp > c3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9z > bWMiLCJleHAiOjE2NjU0MTQxMzEsIm5iZiI6MTY1NzYzODEzMX0.Oe0Nrl4WiClzTrLHTGeFVX6S > - oHNH4LjSGoiVF9eXNo9wN9w- > NyabVRaEUpWVvKheXcqukAuNYvxDGCnoj2ZbpPsE1JY4EByZfqC2l--8i6N0smD8Rtccd_YLg_hx > 9SqGO- Dgr6Y5zLo6FMBUnfF6xQ8jhqB5a7ZJf4- > TfMnCgXDsltrLzB_JU1rLDsVGI5ZzZfN9BEOJeKxS9PJEB3azUy8lFvcMsyq8ZL5LOzyQyhg7H2C > glwDjzNeGmg2Wov8vdVdh3Ahk0AZ08Otf7i-7tpggx0F9FsH13oS2j6IOzEni23z2G6AqNL4j7ss > _23sCp5njIL70rvGv3LliynERA&wid=569b0e12-3625-468e- b068-90bd62d9619e > > > Help here would be much appreciated. Thanks you dochelp team. > > > Best regards > > > Andreas > > -- > Andreas Schneider a...@samba.org > Samba Team > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.samba%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652809308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UDF1dJMf73j6gMQZ7eNnzjw01uUvW7SAFmibWjaUU9g%3D&reserved=0. > org%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C2e7351441cdb4696179208da65 > bd0dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934159907789590%7CUnk > nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=g%2BBw0bw7eD7Mit%2FCPz%2FBAPYvOS65NyD%2B > q24mqS%2F4Cl0%3D&reserved=0 GPG-ID: > 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D -- Andreas Schneider a...@samba.org Samba Team https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.samba.org%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cb3fc80a152bf4259a70c08da66321b5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934662652809308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S17HGunzIfD4VaCTpS1DG6J8RJEPLjF2sQj3gFOhT%2FU%3D&reserved=0 GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D _______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
