[cifs-protocol] [EXTERNAL] Re: [REG:120042221001608] MS-KILE | Handling of more than one AD-IF-RELEVANT in Windows
Obaid Farooqi
obaidf at microsoft.com
Wed May 6 21:40:52 UTC 2020
Hi Isaac:
Browsing the code suggest that Windows does entertain the idea of multiple AD-IF-RELEVNET's but your experience is different. That's why we asked for traces to get to the bottom of this but unfortunately, the traces you sent do not load in debugger. This almost never happens.
Would you please collect a fresh set of traces and upload to the workspace? This time, please use the tool that I uploaded in file New_PartnerTTDRecorder_x86_x64.zip on the workspace.
Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft
-----Original Message-----
From: Isaac Boukris <iboukris at gmail.com>
Sent: Wednesday, April 29, 2020 7:57 AM
To: Jeff McCashland <jeffm at microsoft.com>
Cc: Greg Hudson <ghudson at mit.edu>; Stefan Metzmacher <metze at samba.org>; Andrew Bartlett <abartlet at samba.org>; cifs-protocol at lists.samba.org; Obaid Farooqi <obaidf at microsoft.com>; support <support at mail.support.microsoft.com>
Subject: [EXTERNAL] Re: [REG:120042221001608] MS-KILE | Handling of more than one AD-IF-RELEVANT in Windows
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:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> rt.microsoft.com%2Fglobalenglish&data=02%7C01%7Cobaidf%40microsoft
> .com%7C59116fc922634b4f993c08d7ec3cccc7%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C637237618190615726&sdata=eMyU1QiVQnhcFVA%2FBQ1mXYBX
> uc%2BmvUeUIZSoLvZoP08%3D&reserved=0 | 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp
> ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUz
> I1NiJ9.eyJ3c2lkIjoiNDRiNjQwMzctOTRkMS00ZjU2LTg3Y2ItN2ViMDljM2JlYWFlIiw
> ic3IiOiIxMjAwNDIyMjEwMDE2MDgiLCJhcHBpZCI6ImU2ZWU0M2ViLTBmYmMtNDU0Ni1iY
> zUyLTRjMTYxZmNkZjRjNCIsInN2IjoidjEiLCJycyI6IkV4dGVybmFsIiwid3RpZCI6Ijk
> 5MGZiMDdjLWE4Y2UtNDExZS04ZTgyLWNlNWY4MmZiOTUwNyIsImlzcyI6Imh0dHBzOi8vY
> XBpLmR0bW5lYnVsYS5taWNyb3NvZnQuY29tIiwiYXVkIjoiaHR0cDovL3NtYyIsImV4cCI
> 6MTU5NTQyOTYxMSwibmJmIjoxNTg3NjUzNjExfQ.axEbJMAR8BgxMEnRXsHQm7TU9-BzYD
> dyIv1ZAONfIHg9CWy2qK8xtNWsHdCG8rTFbO-aJ25wpiCNcc7PGVgZzwNVJAGfmG5CHsOU
> U9Pdqd_O7jFnOluLZkSVij0RazFmc30DLoSOnFtNFO9NGXLPQX4QSqt7EhXGgp0kmCyEDz
> cShHQLdXlL_tfo8sPX8HGxlAF3tByp9nhVB8mjDOK51gHqM5c8TRdmm92U2Uz6oeWvkfjg
> c714EO8iuPtBd1_QesziWIsrgRj065Gy-ACmxTjSkJPi4U9ZwPEZK75TuMsV2fCXmkXEjB
> k6kLRHemm1C7XMGq33xC19DHPvdTo1_g%26wid%3D44b64037-94d1-4f56-87cb-7eb09
> c3beaae&data=02%7C01%7Cobaidf%40microsoft.com%7C59116fc922634b4f99
> 3c08d7ec3cccc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372376181
> 90615726&sdata=ztX3TSespQl2niWcFwJSCDX7fsGcNxl7nv4FoXhepf8%3D&
> reserved=0
>
> 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:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> rt.microsoft.com%2Fglobalenglish&data=02%7C01%7Cobaidf%40microsoft
> .com%7C59116fc922634b4f993c08d7ec3cccc7%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C637237618190625724&sdata=J8dX5jXsPJCRXKUM3LW3xSRuge
> jDEWJ%2FOK8yOuyGPs0%3D&reserved=0 | 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:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> rt.microsoft.com%2Fglobalenglish&data=02%7C01%7Cobaidf%40microsoft
> .com%7C59116fc922634b4f993c08d7ec3cccc7%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C637237618190625724&sdata=J8dX5jXsPJCRXKUM3LW3xSRuge
> jDEWJ%2FOK8yOuyGPs0%3D&reserved=0 | 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!
>
More information about the cifs-protocol
mailing list