[cifs-protocol] [REG:120042221001608] MS-KILE | Handling of more than one AD-IF-RELEVANT in Windows

Wed Apr 29 12:56:44 UTC 2020

Hi Jeff and Obaid,

I've just uploaded the debug file and the capture to the workspace.
The packet capture won't be useful as I'm testing the applicability of
KERB_AP_OPTIONS_CBT which requires the test to run over TLS.

Here is the description of the test; the DC is configured with
LdapEnforceChannelBinding=1 and the client does not send
channel-bindings (that is, 16 zeroes), so the server should only
reject the request if KERB_AP_OPTIONS_CBT is present in the
authenticator.

The client makes the first request (cn=isaac), adding
KERB_AP_OPTIONS_CBT as a separate AD-IF-RELEVANT like below, and does
not get recognized by the server, that is the ldapsearch command
succeeds (incorrectly).

authorization-data: 2 items
    AuthorizationData item
        ad-type: AD-IF-RELEVANT (1)
        ad-data: 3011300fa00402020081a10704053003020112
            AuthorizationData item
                ad-type: AD-GSS-API-ETYPE-NEGOTIATION (129)
                ad-data: 3003020112
                    ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
    AuthorizationData item
        ad-type: AD-IF-RELEVANT (1)
        ad-data: 3010300ea0040202008fa106040400400000
            AuthorizationData item
                ad-type: AD-AP-OPTIONS (143)
                ad-data: 00400000
                    AD-AP-Options: 0x00004000, ChannelBindings
                        .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set

Then the client makes the same request again, only with
KERB_AP_OPTIONS_CBT in a single AD-IF-RELEVANT container and then it
gets recognized by the server and the ldapsearch request fails as
expected.

authorization-data: 1 item
    AuthorizationData item
        ad-type: AD-IF-RELEVANT (1)
        ad-data: 3010300ea0040202008fa106040400400000
            AuthorizationData item
                ad-type: AD-AP-OPTIONS (143)
                ad-data: 00400000
                    AD-AP-Options: 0x00004000, ChannelBindings
                        .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set

ldapsearch -h adc.acme.com -b dc=acme,dc=com cn=isaac -Y GSSAPI -N -ZZ
-O maxssf=0
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind: Invalid credentials (49)
additional info: 80090346: LdapErr: DSID-0C090569, comment:
AcceptSecurityContext error, data 80090346, v4563

I've also tested with other ad-types inside the single AD-IF-RELEVANT
container (not in the debug file), and it works fine as well (that is,
ldapsearch yields same "Invalid credentials (49)").

authorization-data: 1 item
    AuthorizationData item
        ad-type: AD-IF-RELEVANT (1)
        ad-data:
3021300fa00402020081a10704053003020112300ea0040202008fa106040400400000
            AuthorizationData item
                ad-type: AD-GSS-API-ETYPE-NEGOTIATION (129)
                ad-data: 3003020112
                    ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            AuthorizationData item
                ad-type: AD-AP-OPTIONS (143)
                ad-data: 00400000
                    AD-AP-Options: 0x00004000, ChannelBindings
                        .... .... .... .... .1.. .... .... .... =
ChannelBindings: Set

Thank you for looking into it.

On Tue, Apr 28, 2020 at 4:57 PM Jeff McCashland <jeffm at microsoft.com> wrote:
>
> Hi Issac,
>
> I have added Obaid Farooqi to the email, as he will also be assisting with this issue.
>
> Do you have any questions about the information I've requested? When do you think you may be able to collect traces?
>
> Best regards,
> Jeff McCashland | 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
> We value your feedback.  My manager is Jeremy Chapman (jeremyc), +1 (469) 775-2475
>
> -----Original Message-----
> From: Jeff McCashland
> Sent: Thursday, April 23, 2020 8:09 AM
> To: 'Isaac Boukris' <iboukris at gmail.com>; 'Greg Hudson' <ghudson at mit.edu>; 'Stefan Metzmacher' <metze at samba.org>; 'Andrew Bartlett' <abartlet at samba.org>; 'cifs-protocol at lists.samba.org' <cifs-protocol at lists.samba.org>
> Cc: support <support at mail.support.microsoft.com>
> Subject: RE: [REG:120042221001608] MS-KILE | Handling of more than one AD-IF-RELEVANT in Windows
>
> Hi Isaac,
>
> To troubleshoot this issue, I need to collect lsass TTT traces with a matching network trace. I have created a File Transfer workspace for this issue. Please find your credentials and a link to the workspace below. Please let me know if anyone else needs access to the workspace. I will generate credentials for each individual.
>
> If you log into the workspace using the provided credentials, you will find "PartnerTTDRecorder_x86_x64.zip" available for download. Please extract the x64 version of the tool and place it on your AD Server.
>
> To collect the needed traces:
> 1.      From an elevated command prompt, execute: tasklist /FI "IMAGENAME eq lsass.exe"
> 2.      Note the PID of the lsass process from the output of the above command.
> 3.      Execute: C:\TTD\TTTracer.exe -attach PID, where PID is the number from above.
> 4.      Wait for a little window to pop up in top left corner of your screen, titled “lsass01.run”
> 5.      start a network trace on the Server side
> 6.      Repro the attempted AD request
> 7.      Stop the network trace and save it
> 8.      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.
> 9.      The TTTracer.exe process will generate a trace file, then print out the name and location of the file.
>
> Please upload the network trace and TTTracer.exe trace to the File Transfer workspace. It would be helpful if you could let me know which frame of the network trace has the failed AD request of interest.
>
> Credentials for Isaac:
> Log in as: 120042221001608_isaac at dtmxfer.onmicrosoft.com
> 1-time: O1IKG?(@
>
> Workspace URL: https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiNDRiNjQwMzctOTRkMS00ZjU2LTg3Y2ItN2ViMDljM2JlYWFlIiwic3IiOiIxMjAwNDIyMjEwMDE2MDgiLCJhcHBpZCI6ImU2ZWU0M2ViLTBmYmMtNDU0Ni1iYzUyLTRjMTYxZmNkZjRjNCIsInN2IjoidjEiLCJycyI6IkV4dGVybmFsIiwid3RpZCI6Ijk5MGZiMDdjLWE4Y2UtNDExZS04ZTgyLWNlNWY4MmZiOTUwNyIsImlzcyI6Imh0dHBzOi8vYXBpLmR0bW5lYnVsYS5taWNyb3NvZnQuY29tIiwiYXVkIjoiaHR0cDovL3NtYyIsImV4cCI6MTU5NTQyOTYxMSwibmJmIjoxNTg3NjUzNjExfQ.axEbJMAR8BgxMEnRXsHQm7TU9-BzYDdyIv1ZAONfIHg9CWy2qK8xtNWsHdCG8rTFbO-aJ25wpiCNcc7PGVgZzwNVJAGfmG5CHsOUU9Pdqd_O7jFnOluLZkSVij0RazFmc30DLoSOnFtNFO9NGXLPQX4QSqt7EhXGgp0kmCyEDzcShHQLdXlL_tfo8sPX8HGxlAF3tByp9nhVB8mjDOK51gHqM5c8TRdmm92U2Uz6oeWvkfjgc714EO8iuPtBd1_QesziWIsrgRj065Gy-ACmxTjSkJPi4U9ZwPEZK75TuMsV2fCXmkXEjBk6kLRHemm1C7XMGq33xC19DHPvdTo1_g&wid=44b64037-94d1-4f56-87cb-7eb09c3beaae
>
> Best regards,
> Jeff McCashland | 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 We value your feedback.  My manager is Jeremy Chapman (jeremyc), +1 (469) 775-2475
>
> -----Original Message-----
> From: Jeff McCashland
> Sent: Wednesday, April 22, 2020 1:09 PM
> To: Isaac Boukris <iboukris at gmail.com>; Greg Hudson <ghudson at mit.edu>; Stefan Metzmacher <metze at samba.org>; Andrew Bartlett <abartlet at samba.org>; cifs-protocol at lists.samba.org
> Cc: support <support at mail.support.microsoft.com>
> Subject: RE: [REG:120042221001608] MS-KILE | Handling of more than one AD-IF-RELEVANT in Windows
>
> [Bryan to BCC]
>
> Hi Isaac,
>
> I will assist you with this issue. Let me do some research and get back to you.
>
> Best regards,
> Jeff McCashland | 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 We value your feedback.  My manager is Jeremy Chapman (jeremyc), +1 (469) 775-2475
>
> -----Original Message-----
> From: Bryan Burgin <bburgin at microsoft.com>
> Sent: Wednesday, April 22, 2020 9:03 AM
> To: Isaac Boukris <iboukris at gmail.com>; Greg Hudson <ghudson at mit.edu>; Stefan Metzmacher <metze at samba.org>; Andrew Bartlett <abartlet at samba.org>; cifs-protocol at lists.samba.org
> Cc: support <support at mail.support.microsoft.com>
> Subject: [REG:120042221001608] MS-KILE | Handling of more than one AD-IF-RELEVANT in Windows
>
> Hi Isaac,
>
> Thank you for your question.  We created SR 120042221001608 to track this issue.  An engineer will contact you soon.
>
> Bryan
>
> -----Original Message-----
> From: Isaac Boukris <iboukris at gmail.com>
> Sent: Wednesday, April 22, 2020 5:21 AM
> To: Interoperability Documentation Help <dochelp at microsoft.com>; Greg Hudson <ghudson at mit.edu>; Stefan Metzmacher <metze at samba.org>; Andrew Bartlett <abartlet at samba.org>; cifs-protocol at lists.samba.org
> Subject: [EXTERNAL] MS-KILE | Handling of more than one AD-IF-RELEVANT in Windows
>
> Hello dochelp,
>
> From many tests involving MS-PAC authorization data in a ticket, and recently by testing authorization-data in the authenticator (ap-req), it appears as if Windows would only handle the first AD-IF-RELEVANT element (RFC4120), and would ignore additional ones when present.
>
> So if for instance a ticket has more than one AD-IF-RELEVANT element and the PAC is wrapped in the second one, the server fails to handle the request. Same goes for KERB_AP_OPTIONS_CBT in authenticator, I can see that it is not handled when it is wrapped in a second AD-IF-RELEVANT.
>
> I wonder if this understanding is correct, if it is a known issue, if it is documented anywhere, and whether this is planned to be fixed in future versions of Windows.
>
> Thanks!
>