Thank you Nathan! [Nathan to BCC]
Hi David,
I would like to look into these questions. Could you send net traces for the
two scenarios (sparse vs. non-sparse) you describe?
I created a DTM Workspace for uploading files to this case. You will receive a
separate email from "CTS Automated Diagnos
Hi David,
We have made the following spec changes for the next doc release:
In section 2.1.5.9.4 FSCTL_DUPLICATE_EXTENTS_TO_FILE behavior notes have been
added to the following paragraphs.
Before:
§ The object store MUST check for byte range lock conflicts on Open.Stream
using the algorithm de
Thanks Will! [Will to BCC, casemail on CC]
Hi Andreas,
I will research your SMB2 ECHO questions and let you know what I find.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
Hi Andreas,
You are correct, Windows and SMB2 allow SessionId to be 0 for ECHO, but do not
require it. It is necessary to establish a Session, but the ID does not need to
be passed with the ECHO request. Non-zero MessageId is also needed, but neither
a Tree Connection nor TID are necessary for
Hi Andreas,
Normally, this type of information would go into the processing rules for the
Client (Section 3.2). However, the gist of what I explained below is that SMB2
doesn't have any rules for the client to process the ECHO command. The client
is free to use and process ECHO as needed, as lo
Hi Andreas,
My suggestion below was rejected as inappropriate for section 2, since it isn't
a MUST rule. In fact, it is felt that the documentation covers the issue as the
server processing rules for every SMB2 command (except NEGOTIATE and
SESSION_SETUP) specify verifying the SessionId with th
[-casemail]
Hi Andreas,
Here is what we came up with for the next release of the document:
In section 3.3.5.17 Receiving an SMB2 ECHO Request the following has been added:
The server MUST verify the session, as specified in section 3.3.5.2.9, if any
of the following conditions is TRUE:
§ SMB2_F
[DocHelp to BCC, casemail on CC, SR ID on Subject]
Hi Andreas,
Thank you for your protocols question. We have created SR 117102016529426 to
track this issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specificati
Thank you for the update, Jeremy!
From: Jeremy Allison
Sent: Friday, October 20, 2017 2:10:12 PM
To: Andreas Schneider
Cc: Interoperability Documentation Help; cifs-protocol@lists.samba.org
Subject: Re: [cifs-protocol] SMB2 File Rename
On Fri, Oct 20, 2017 at 0
Thanks, Tom! [Tom to BCC]
Hi Garming,
I will be assisting you with this issue. Let me do some research on the INF
syntax, and I will let you know what I find.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38
Hi Garming,
I've verified that the general syntax description does not cover the three
sub-sections exactly as you say. Thank you for reporting this issue. I will
file a change request to update our documentation.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol O
[-casemail]
Hi Garming,
We have updated [MS-GPSB] for the next release with the following changes:
MS Response 6/25/2018
TDI 8624 has been addressed in MS-GPSB. These changes are available in the
daily build of 6/25/2018.
Section 2.2 Message Syntax
Revised syntax from:
InfFile = UnicodePre
[DocHelp to BCC, casemail on CC, SR ID on Subject]
Hello Aurélien,
Thank you for your question. We have created SR 118100419158690 to track this
issue. One of our engineers will respond soon to assist you.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Spe
[DocHelp to BCC, casemail on CC, SR ID on Subject]
Hello Alexander,
Thank you for your question. We have created SR 118100419160002 to track this
issue. One of our engineers will respond soon to assist you.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
S
DocHelp on BCC this time...
-Original Message-
From: Jeff McCashland
Sent: Thursday, October 4, 2018 8:09 AM
To: Alexander Bokovoy ; Interoperability Documentation Help
Cc: cifs-protocol@lists.samba.org; MSSolve Case Email
Subject: [REG:118100419160002] joining readonly domain controll
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Issac,
Thank you for your question. on Kerberos. We have created SR ID 119051523001903
to track this issue. One of our protocols engineers will respond soon.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Ope
[Bryan to BCC]
Hi Ralph,
I will research your question, and also touch bases with Sreekanth regarding
related SR 119101121001349.
I will let you know what I find.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-830
+Sreekanth for collaboration
-Original Message-
From: Jeff McCashland
Sent: Monday, October 14, 2019 11:05 AM
To: Ralph Boehme
Cc: cifs-protocol@lists.samba.org; support
Subject: RE: [REG:119101421001093] MS-SMB2/FSA: File.LastModificationTime,
update "lost" against Windows 2019
[Brya
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi slow,
Thank you for your file sharing question. We have created SR 119102121001551 to
track this issue. One of our engineers will respond soon to assist.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
S
Hi slow,
I have filed an update request on [MS-FSA].
Please keep sending anything you find to our DocHelp alias.
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)
Hi slow,
Thank you for reporting this gap. I will research the issue and let you know
what I find.
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 (
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Andrew,
Thank you for your Active Directory question. We have created SR
11910242115 to track this issue. One of our engineers will respond soon to
assist.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi slow,
Thank you for sending in your question and trace. We have created SR
120030321000983 to track this issue. I will review your trace and follow up.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Spec
Hi slow,
I love the trace you sent, it's beautiful. I've verified that Frame 139
unexpectedly does not break lease.
I thought it was interesting that READ_EA access also breaks the lease, but I'm
not certain why.
Thank you for pointing this out and providing the trace. I will file a request
Hi Ralph,
Presumably the change would be to add READ_CONTROL to the list in the section
you referenced. I'll let you know when and if the document is updated.
However, note that legacy Oplocks do break on READ_CONTROL. If I understand our
source code correctly, Leases never broke on READ_CONTR
Hi slow,
Thank you for the trace!
That's not my call and will be verified when the change request is worked on.
However, commentary in the code from Win7 days suggests it is by design.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Ph
[-support]
Hi Ralph,
We've updated [MS-FSA] section 2.1.4.12 "Algorithm to Check for an Oplock
Break" for the next release accordingly:
2.1.4.12 Algorithm to Check for an Oplock Break
The algorithm uses the following local variables:
§ OPERATION_MASK – a constant that MUST contain the following
[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
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 wil
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
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Jeremy,
Thank you for your question. We have created SR 12005092138 to track this
issue. I will research the question and let you know what I find.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Spe
Hi Jeremy,
[MS-FSA] describes the operation of the underlying file store, roughly how NTFS
works. NTFS will accept negative Offset writes and treat them as documented in
[MS-FSA]. However, SMB2 will return STATUS_INVALID_PARAMETER if SMB2_READ or
SMB2_WRITE Offset are < 0. SMB2 will not send a
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Aurélien,
Thank you for your question. We have created SR 120060621000848 to track this
issue. I will research the question and let you know what I find.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
S
Hi Aurélien,
It appears this section of pseudocode was added as part of an update to
document handling when input data > 64kb. The algorithm takes two passes over
the data for each 64k block in succession, first to do LZ77 compression, then
another pass to do Huffman encoding. When both passes
Hi Aurélien,
I will investigate further and let you know what I find.
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 p
[Obaid to BCC]
Hi Volker,
I will look into the question and I'll let you know what I discover.
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 a
Hi Volker,
You found some interesting code that I did not find documentation for. However,
it is necessary to violate the spec in order to hit it, so it isn't something
we would document.
Please note:
[FSCC]
2.1.5 Pathname
2.1.5.1 Dot Directory Names
Except where explicitly permitted, a pathna
Hi Volker,
I will be raising the issue with the content team to consider documenting the
behavior.
Please let me know if you have further concerns.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hour
Hi Aurélien,
As you know, it's a complex routine. I'll see if we can provide some feedback
on it soon.
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 Ti
Hi Aurélien,
We have some explanation of the pseudocode in question:
A negative HuffmanSymbol indicates that the size of the value exceeds the value
of the table (is > 64k). The location for the actual value is based of the
decoded value:
Each 16-bit entry in the table/tree follows this
Are there any specific parts that are particularly confusing? How far do you
get with it?
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 Can
Apologies! I see that now.
-Original Message-
From: Aurélien Aptel
Sent: Tuesday, June 23, 2020 2:16 AM
To: Jeff McCashland ; cifs-protocol@lists.samba.org
Cc: support
Subject: RE: [EXTERNAL] RE: [REG:120060621000848] [MS-XCA] L77+Huffman negative
huffman symbol update
Hi Jeff,
Jeff
Hi Aurélien,
We're still working on this. In the meantime, have you considered the code
changes since the published version which are covered by the Errata document?
An additional paragraph has been added right before the compression pseudocode:
"During the beginning of processing each block for
Hi Aurélien,
We have investigated further, and determined that the section you're asking
about (the addition of the If HuffmanSymbol >= 0 block) is
implementation-specific code that was inadvertently added, and is not necessary
for Huffman compression or for >64k input buffers. Please ignore th
Glad I could help!
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
-Original Message-
From: Aurélien Aptel
Sent: Monday, July 6, 2020 1:45 AM
To: Jeff McCashland ; cifs-protocol@lists.samba.org
Cc: support
Subject: RE: [EXTERNA
[Hung-Chun to BCC]
Hi Ronnie,
Thank you for reporting this issue. I will investigate and let you know what I
find.
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
Hi Ronnie,
It appears you are correct.
By any chance do you have a net trace showing the TRANS2_SET_PATH_INFORMATION
call succeeding for level SMB_SET_FILE_BASIC_INFO?
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703
[-support]
Hi Aurélien,
We have updated the documentation for the next release:
[MS-XCA] 2.2.4 Processing (Second block of pseudocode)
Loop until a decompression terminating condition
Build the decoding table
CurrentPosition = 256 // start at the
[-Support]
Hi Volker,
We have updated section 3.3.5.9 of [MS-SMB2] for the next release:
If the file name in the Buffer field of the request fails to resolve the
pathname components as specified in [MS-FSCC] section 2.1.5.1, the server
SHOULD<262> fail the request with STATUS_INVALID_PARAMETER
[DocHelp to BCC, support on CC, SR ID on Subject]
Hello Stefan,
Thank you for sending in your question. While we normally only document
out-of-box behavior, we'll investigate to see if a product behavior note is
needed. We have created SR 120082121001591 to track this issue.
I'll research the
Hi Stefan,
I have filed a request to update the document. I'll follow up with the content
team.
Let us know if you find anything else.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm |
Hi Douglas,
Could you let us know more about what problem your trying to address?
- All of our protocols are documented here:
https://docs.microsoft.com/en-us/openspecs/windows_protocols
- Web Services Management is documented in [MS-WSMV]:
https://docs.microsoft.com/en-us/openspecs/windows_
[DocHelp to BCC, Tracking ID on Subject]
Hi Samuel,
Thank you for your question. We have created SR 2012220050006398 to track this
issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Andrew,
Thank you for engaging us. We have created SR 2104270040006933 to track this
issue. One of our engineers will respond soon to assist.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specification
[Sree to BCC, support alias on CC, SR ID on Subject]
Hi Douglas,
I will research your list, and follow up.
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)
Pacif
[Sree to BCC, support alias on CC, SR ID on Subject]
Hi Douglas,
I will research your questions about StartScavenging, and let you know what I
find.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hour
Hi Douglas,
I have been able to confirm that EntombedTime is actually (and always) in
100-nanosecond increments. Also, "Time Zone Secured" is tracked in full seconds
as documented.
The comparison in section 3.1.1.1.1 should perhaps read: "...and an
EntombedTime (section 2.2.2.2.4.23) value >>
[Tom to BCC, support alias on CC]
Hi Douglas,
Are you able to provide a network trace showing the behavior in question? What
are the Server and Client OS versions? Does this repro in a Windows-to-Windows
scenario?
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol
I see you said at the top the server is WS 2012 R2. What tool and steps are you
using to repro the issue?
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
-Original Message-
From: Jeff McCashland
Sent: Monday, June 7, 2021 9:55
Thank you Douglas!
-Original Message-
From: Douglas Bagnall
Sent: Monday, June 7, 2021 3:22 PM
To: Jeff McCashland ; cifs-protocol
Cc: Jeff McCashland
Subject: Re: [cifs-protocol] [EXTERNAL] [MS-DNSP] sticky static dns updates -
TrackingID#2106070040005009
On 8/06/21 10:11 am, Dougl
Hi Douglas,
Based on my read of the code, the 'scavenging process' is a combination of a)
and b). Initially, resource records that have expired are added to a list of
required updates. When a sufficient number of records are expired, then they
are removed (deleted) from the database. Also, the
Hi Douglas,
I'll take a closer look at DsTombstoneInterval and make sure I understand the
relationship.
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 T
Hi Douglas,
I added the Keytab file on the Wireshark Preferences page under Protocols ->
KRB5, and checked 'Try to decrypt Kerberos blobs', then reloaded the trace.
The LDAP frames still aren't decrypted. Did I miss a step?
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsof
Hi Douglas,
Could you confirm that you received the email below? I'm getting warnings that
lists.samba.org is rejecting my email as spam.
A co-worker pointed out an article that could be useful, if you haven't already
seen it.
How DNS Aging and Scavenging Works
https://social.technet.microsof
Hi Douglas,
In my email this morning for the StartScavenging case, I mentioned the article:
How DNS Aging and Scavenging Works
https://social.technet.microsoft.com/wiki/contents/articles/21724.how-dns-aging-and-scavenging-works.aspx
This article has a link to a related article:
How to Convert a D
Thanks for the confirmation. I'm open to any suggestions for avoiding the spam
filter.
Original Message-
From: Douglas Bagnall
Sent: Tuesday, June 15, 2021 2:18 PM
To: Jeff McCashland ; cifs-protocol@lists.samba.org
Cc: Jeff McCashland
Subject: Re: [EXTERNAL] Re: [MS-DNSP] StartScaven
Resending to get into the list.
-Original Message-
From: Jeff McCashland
Sent: Wednesday, June 9, 2021 11:48 AM
To: Douglas Bagnall ;
cifs-protocol@lists.samba.org
Cc: Jeff McCashland
Subject: RE: [EXTERNAL] Re: [MS-DNSP] StartScavenging RPC call -
TrackingID#210601004444
Hi Doug
Hi Douglas,
I've been reviewing the documentation and source code where we perform
operations on the dnsNode. I realize now that scavenging/aging is specific to
the resource records, while Tombstoning happens to the dnsNode when connected
to AD server. From our source code, it appears the only
Hi Douglas,
Just to put a wrap on this issue...
Aging and scavenging applies to individual resource records, and the scavenging
process is to delete the record. This triggers a timer on the dnsNode to kick
off the tombstoning process. Tombstoned nodes are kept around for a period of
time to al
[Mike to BCC]
Hi Isaac,
I altered the Subject line to branch this to a separate email thread for your
notes on [MS-CSSP] Windows Behavior Note <22> for section 2.2.1.2.3.1 (SR
2106210040004026). I will not be addressing the point about the ServiceTicket
in this case/thread, just the supplement
Hi Isacc,
I have created a workspace for uploading files related to this case
(credentials below). Can you provide a decrypted network trace showing the
structure and flags as you have reported seeing on the wire?
Log in as: 2106210040004026_is...@dtmxfer.onmicrosoft.com
1-time: (19GrM9h
Work
Hi Isaac,
Could you upload the file as a .zip? I don't think we have a site license for
WinZip.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
-Original Message-
From: Isaac Boukris
Sent: Monday, June 21, 2021 11:29 AM
To: J
Hi Isaac,
Thank you for the fast responses and trace file. I have been able to confirm
the field order and flags as you indicated.
I will file a request to update [MS-CSSP] and follow up.
Thank you for bringing this to our attention. Please continue to send any
protocol issues you find to o
Hi Douglas,
I've been able to confirm that when a static record is added to a dnsNode, new
records are added as static. This is done so that when a record is manually
marked as static by an admin, refreshes don't over-ride the static state. This
is tied to whether aging is turned on or off in t
Hi Douglas,
I forgot to mention that I have filed a request to document these behaviors in
[MS_DNSP], which I will follow up on.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone
[DocHelp to BCC, support on CC, SR ID on Subject]
Hello Isaac,
Thank you for submitting your question. We have created SR 2107090040004014 to
track this issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specific
Hi Douglas,
Our Active Directory Family Test Suites do not have test cases for [MS-DNSP].
I'm not aware of a public test tool.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
Hi Isaac,
I have gotten some clarification on the comment "When this protection if
enabled, it unifies the logic for Resource-Based Constrained Delegation (RBCD)
with the original constrained delegation.".
RBCD was recently updated to ensure that everyone honors the ticket issuer's
request to
[-support alias]
Hi Douglas,
We have updated [MS-DNSP] for the next release of the document:
3.1.1.1.1 DNS Server Integer Properties
DsTombstoneInterval:
Every day at 2:00 AM local time the DNS server MUST conduct a search of all
zones stored in the directory server for nodes which have the dns
Hi Isaac,
Thank you for the additional observations and information. I will continue
working with our CVE team to get verification and clarification.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hour
Hi Isaac,
You are correct about the NonForwardableDelegation enabled behavior:
If the evidence ticket is not forwardable, the KDC immediately returns
KDC_ERR_BADOPTION with the status code STATUS_ACCOUNT_RESTRICTION.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protoco
[New case and SR ID]
Hi Douglas,
Our DNS team would like to verify the second issue where all RR's get their
timestamp updated.
Could you please collect and upload TTT traces of that scenario along with a
concurrent network trace? I have created a File Transfer workspace for
exchanging files
Hi Douglas,
Do you have any questions about why we're requesting the traces below or how to
collect them?
When do you think you may be able to upload traces?
Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38
Hi Douglas,
We not certain that the resolution of the sibling update issue is accurate,
which is why we need traces.
Alternatively, if you can tell me steps to trigger the scenario, I may be able
to collect the traces myself.
Best regards,
Jeff McCashland | Senior Escalation Engineer | Micros
[-support]
Hi Isaac,
We have updated [MS-SFU] for the next release of the document:
1.2.2 Informative References
[MSFT-RBCD-ProtectedUserChanges] Microsoft Corporation, "Managing deployment of
RBCD/Protected User changes for CVE-2020-16996",
https://support.microsoft.com/en-us/topic/managing-d
I look forward to hearing from you!
-Original Message-
From: Isaac Boukris
Sent: Monday, September 13, 2021 2:37 AM
To: Jeff McCashland
Cc: cifs-protocol@lists.samba.org; Greg Hudson
Subject: Re: [EXTERNAL] [MS-SFU] Clarify the new NonForwardableDelegation flag
- TrackingID#2107090040
[Kristian to BCC]
Hi Alexander and Metze,
I will look into this 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)
87 matches
Mail list logo
