Hello Isaac, we will update the spec to indicate that in the RBCD scenario, Kdc reply will set the cname and crealm using the impersonated client principal name constructed from the PAC.
Regards, Sreekanth Nadendla Microsoft Windows Open Specifications From: Sreekanth Nadendla Sent: Tuesday, January 28, 2020 4:07 PM To: Isaac Boukris <[email protected]> Cc: support <[email protected]>; Greg Hudson <[email protected]>; [email protected] Subject: RE: [120012821001754][MS-SFU]Clarification request on cross-realm RBCD in MS-SFU 3.2.5.2.2 Hello Isaac, I’m researching this issue for you. I will provide you with an update as soon as I have some details to share with you. Regards, Sreekanth Nadendla Microsoft Windows Open Specifications From: Hung-Chun Yu <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 28, 2020 11:22 AM To: Isaac Boukris <[email protected]<mailto:[email protected]>> Cc: support <[email protected]<mailto:[email protected]>>; Greg Hudson <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [120012821001754][MS-SFU]Clarification request on cross-realm RBCD in MS-SFU 3.2.5.2.2 +support [cc] -dochelp [bcc] Hi Isaac Thank you for your question. We created SR 120012821001754 and please leave this info in the subject line to track your issue. An engineer will contact you soon. Hung-Chun Yu Microsoft Protocols Support ________________________________ From: Isaac Boukris <[email protected]<mailto:[email protected]>> Sent: Tuesday, January 28, 2020 5:30 AM To: Interoperability Documentation Help <[email protected]<mailto:[email protected]>>; Greg Hudson <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] Re: Clarification request on cross-realm RBCD in MS-SFU 3.2.5.2.2 Hi again, On Sun, Jan 26, 2020 at 1:57 PM Isaac Boukris <[email protected]<mailto:[email protected]>> wrote: > > When a KDC replies with Service Ticket (MS-SFU 3.2.5.2.2), how does it > determine the reply cname and crealm. > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sfu%2Fce6bbf34-0f11-40d6-93d1-165a3afa0223&data=02%7C01%7CHungChun.Yu%40microsoft.com%7C3a83b03cfab04f57ca3a08d7a3f680de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158151428246386&sdata=MjRHU0UvvE9zuzJqoQGt%2FeQECFo8xwNs9KU9DvuYNuQ%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sfu%2Fce6bbf34-0f11-40d6-93d1-165a3afa0223&data=02%7C01%7Csrenaden%40microsoft.com%7C85935b52f45841af7f0608d7a4278fd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158362130403984&sdata=nKrdFdaAXXCP8x4zrZth4PVd8YQ6nJ8%2BalPZXd2pw6U%3D&reserved=0> > > Per the above doc, it sounds like it should be the cname and crealm > from the additional-ticket, however in RBCD, when the > additional-ticket is a cross-tgt the cname and cream are of service-1 > and not of the impersonated client. > > In contrast, I've observed that Windows KDC constructs the > impersonated client's principal name from the PAC, and set the reply > cname and crealm to that principal's. However, I can't find any clear > document that reflects it. I've sent this over the weekend, and perhaps got lost. In short, I think MS-SFU 3.2.5.2.2 section was not updated for cross-realm RBCD, as other parts of the document. Please review and assign :)
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
