[cifs-protocol] [120012821001754][MS-SFU]Clarification request on cross-realm RBCD in MS-SFU 3.2.5.2.2

[Hung-Chun Yu]

+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 <iboukris at gmail.com>
Sent: Tuesday, January 28, 2020 5:30 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>; Greg Hudson <ghudson at mit.edu>; cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
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 <iboukris at gmail.com> 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
>
> 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20200128/4d38618f/attachment-0001.htm>