Hi Ralph,
It was pointed out to me that the compounded SetInfo request in your trace
(packet 34} is not an async operation, and that's why it succeeds. The async
flag is not set, so there is no need to document an exception.
Am I missing anything?
Best regards,
Jeff McCashland (He/him) | Seni
Hi Ralph,
We have created SR 2409060040001453 to address the issue of compound responses
getting split:
Details:
[Related to SR 240901004238]
Another presumable undocumented behavior is that in a series of compound CREATE
+ NOTIFY requests, the CREATE response and the PENDING response fo
Hi Ralph,
I'm breaking this out into separate cases to ensure that all of your questions
on these traces are addressed. We created SR 2409060040001408 to address your
second question on the 'failed GetInfo' trace:
Scenario:
when receving a compound related request chain of CREATE + SETINFO(re
[Michael to BCC]
Hi Ralph,
I will dig into the traces you provided, and let you know what I find.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Pacific Time (US and Canada)
Hi Douglas,
We're standing by to assist, but we need more information as requested below.
Can you give me an idea of when you may be able to respond?
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | T
Hi Douglas,
We can confirm that MS-NBFS describes the SOAP protocol, and I see the document
does provide binary representation of the Soap format. Is that what you needed,
or was something more missing for you to decode the traffic?
If so, I'd like to collect a network trace with the traffic yo
[Sreekanth to BCC]
Hi Douglas,
Is there a specific problem you're trying to solve? Is this blocking your
implementation of ADWS?
MS-ADDM is the main documentation for ADWS. MS-NBFS describes the SOAP
protocol. ADWS uses the common SOAP based web service protocol described in
MS-NBFS, but MS
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Jo,
Thank you for your question. We have created SR 2405210040011397 to track this
issue. One of our engineers will response and provide workspace information to
upload your traces.
Best regards,
Jeff McCashland (He/him) | Senior Escalation
Hi Douglas,
Thanks for the update and additional information. Sree is taking point on Q2
and will continue to dig into it.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Paci
Hi Douglas,
I reviewed the Windows source code where SACLs are processed, and I did not see
any indication of a required or preferred order to SACL ACEs. However, I did
notice that when we process SACLs, we process the ACEs in this order: Audit,
Label (including trust label and filtering), Attr
Hi Douglas,
Could you let us know a bit more about how this relates to what you're working
on?
It appears to me that the documentation sufficiently covers your question #3.
We document that inherited ACEs must be kept in the order they are inherited.
Since each parent orders their explicit ACE
Hi Douglas,
I will research your question and let you know what I find.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Pacific Time (US and Canada)
Local country phone number
Hi Douglas,
I will research your question and let you know what I find.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Pacific Time (US and Canada)
Local country phone number
ation changes
related to CVE-2024-26248 and CVE-2024-29056 - TrackingID#240410004280
Am 12.04.24 um 19:59 schrieb Jeff McCashland (He/him) via cifs-protocol:
> Hi Andrew,
>
> Also, our security updates team would like to talk with you about the
> changes. Do you have some availabi
g forward to hearing from your team.
Andrew,
On Wed, 2024-04-10 at 01:20 +, Jeff McCashland (He/him) via cifs-protocol
wrote:
Sending again, as I received an error that the Samba server rejected my message
as spam.
Thank you for your question. We have created SR 240410004280 to track this
E-2024-26248 and CVE-2024-29056 - TrackingID#240410004280
Thanks Jeff, looking forward to hearing from your team.
Andrew,
On Wed, 2024-04-10 at 01:20 +, Jeff McCashland (He/him) via cifs-protocol
wrote:
Sending again, as I received an error that the Samba server rejected my message
as
: [cifs-protocol] [MS-KILE] PAC Validation changes
related to CVE-2024-26248 and CVE-2024-29056 - TrackingID#240410004280
Thanks Jeff, looking forward to hearing from your team.
Andrew,
On Wed, 2024-04-10 at 01:20 +, Jeff McCashland (He/him) via cifs-protocol
wrote:
Sending again, as I
Sending again, as I received an error that the Samba server rejected my message
as spam.
Thank you for your question. We have created SR 240410004280 to track this
issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft
[DocHelp to BCC, support on CC, Updated Subject w/SR ID]
Hi Andrew,
Thank you for your question. We have created SR 240410004280 to track this
issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Speci
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Andrew,
We have created SR 240409004814 to address the question about PAC signature
changes. One of our engineers will respond.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications
[DocHelp to BCC, support on CC, SR ID on Subject]
HI Andrew,
We have created SR 240409004756 to track the question on CVE-2024-20674.
One of our engineers will respond.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Andrew,
Thank you for your questions. I will respond to this email 3 times to create a
separate thread (and SR ID) for each of these questions.
We have created SR 240409004707 to track the question about CVE-2024-21427.
One of our engine
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi David,
Thank you for your email. We have created SR 2404080040009575 to track this
issue. One of our engineers will respond soon to assist.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specif
Hi Stefan,
I haven't seen any response to my last couple of emails. Hopefully you got what
you need and have moved on.
I'll consider these two issues closed (2401050040013471 and 240106004027).
If you need more information on these, please reach out (and include our
DocHelp alias) and we
Hi Stefan,
Could you let me know when you'll have time to respond to my request below?
Best regards,
Jeff McCashland (He/him) | 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 an
Hi Stefan,
I have the same question for this issue as for SR 2401050040013471.
Considering that:
The Windows Client has a 'lazy' efficiency. It tracks the servers it connects
to, and updates their Available or Unavailable status internally when it gets
the notifications. It doesn't act on the
Hi Stefan,
I've been working with repros to understand the behavior around Async
Notifications. What I've observed is that the Windows Client has a 'lazy'
efficiency. It tracks the servers it connects to, and updates their Available
or Unavailable status internally when it gets the notification
Hi Stefan,
We have updated [MS-LSAD] for the next release:
3.1.4.7.10 LsarCreateTrustedDomainEx2 (Opnum 59)
AuthenticationInformation: A structure containing an encrypted
LSAPR_TRUSTED_DOMAIN_AUTH_BLOB (section 2.2.7.16) which specifies the
authentication information for the trusted domain. T
Hi Stefan,
To collect the t.cab traces from the Client, use 't.cmd clion' and 't.cmd
clioff'
Thank you for catching what I missed!
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm
Hi Stefan,
I've been able to determine that clusters can have many names and/or aliases
that can be used more or less interchangeably.
Here is an article on aliasing (a little dated but still relevant):
How to Configure an Alias for a Clustered SMB Share with Windows Server 2012 -
Microsoft Com
Hi Stefan,
Could you let me know when you may have time to collect and upload the event
logs and t.cab traces requested earlier?
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm |
Hi Stefan,
In addition to the traces below, could you also upload any Events from the
appropriate time range? In Event Viewer, navigate to Application and Services
Logs > Microsoft > Windows > SMBWitnessSService (from the cluster), and
SMBWitnessClient from the client.
Best regards,
Jeff McCa
Hi Joseph,
We have updated [MS-ADTS] to address this issue:
3.1.1.4.5.39 msDS-ManagedPassword
Define function GetgMSAPasswordBlob(TO: OBJECT), which returns an
msDS-ManagedPassword BLOB structure (section 2.2.19) as follows using integer
arithmetic where divisions are rounded down without a r
Hi Stefan,
To help troubleshoot this issue, I would like to collect ETL (t.cab) traces as
well as the network capture you offered.
Please find attached t.cmd.txt, which can be renamed to t.cmd and copied to any
folder on your server.
To collect traces:
1. From an elevated command pro
We'll take another look.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
-Original Message-
From: Stefan Metzmacher
Sent: Tuesday, January 9, 2024 11:53 PM
To: Jeff McCashland (He/him) ; Andreas Schneider
; cifs-protoc
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Joseph,
Thank you for your email. We have created SR 240110004760 to track this
issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications
Good catch, we missed that! We'll take care of it.
-Original Message-
From: Andreas Schneider
Sent: Monday, January 8, 2024 11:57 PM
To: cifs-protocol@lists.samba.org; Jeff McCashland (He/him)
Subject: Re: [EXTERNAL] Re: [MS-LSAD] LsarCreateTrustedDomainEx3 requires
cbCipher 520 for Au
[-Support]
Hi Andreas,
We have updated [MS-LSAD] for the next release to address this issue:
2.2.7.29 LSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION_INTERNAL_AES
The LSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION_INTERNAL_AES structure communicates
authentication material. The cleartext password data is in the f
Hi Stefan,
We have created SR 240106004027 to address this question:
By testing I found that a CLIENT_MOVE_NOTIFICATION is ignored if the list of ip
addresses if the also contains the ip address that was given to the
Register[Ex]() call. I have only tested the case where all ip addresses h
Hi Stefan,
We have created SR 2401050040013471 to address this question:
So far I found this in my testing:
A RESOURCE_CHANGE message with WITNESS_RESOURCE_STATE_UNAVAILABLE will trigger
a reconnect, but the RESOURCE_CHANGE.name content is completely ignored,
currently I'm sending the ip addr
Hi Stefan,
We mean FSCTL_QUERY_NETWORK_INTERFACE_INFO, correct.
I am going to reply 2 more times, as we have created new cases for the updated
questions below.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 70
[HC and Kristian to BCC]
Hi Stefan,
I will look into this question and let you know what I find.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Pacific T
[Hung-Chun and Kristian to BCC]
Hi Stefan,
I will dig into this and let you know what I find.
Best regards,
Jeff McCashland (He/him) | 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 Stefan,
We have updated [MS-SMB2] for the next release to address this issue:
3.2.5.2 Receiving an SMB2 NEGOTIATE Response
§ If SMB2_GLOBAL_CAP_PERSISTENT_HANDLES is set in the Capabilities field
of the SMB2 NEGOTIATE Response, the client MUST set
Connection.SupportsPersistentHandles
Hi Stefan,
Could you let me know when you think you'll have time to provide more
information as requested below?
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-
Hi Andreas,
Thank you for the information. I will work with our LSAD team to confirm and
update the spec.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Hi Stefan,
I didn't see a response to my previous request. It's not clear to us what you
are looking for here. Having a single netname for multiple nodes sounds similar
to a SOFS configuration. We use DNS to enumerate the IP addresses.
Windows uses witness for the following:
- If networ
[Updated Subject w/new SR ID]
Hi Andreas,
I was able to confirm in our source code that LsarCreateTrustedDomainEx3
actually marshals the data into LSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION as
documented.
I am still researching why the requirement is there.
Best regards,
Jeff McCashland (He/him) |
Hi Andreas,
Thank you for the suggestion. I will look into that.
Best regards,
Jeff McCashland (He/him) | 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
Hi Andreas,
I found that the cause of the INVALID_PARAMETER error is that cbCipher is too
small in the PLSAPR_TRUSTED_DOMAIN_AUTH_INFORMATION_INTERNAL_AES structure
included in the request.
The value sent is 0xD0 (208), while we were expecting at least 520 (0x208). Is
there some significance t
Hi Andrew,
Thank you for the information. I will let you know what I find.
Best regards,
Jeff McCashland (He/him) | 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)
Loc
Hi Joseph,
We have updated [MS-KILE] for the next release to address this issue:
3.3.5.7 TGS Exchange
[...]
If domainControllerFunctionality returns a value >= 6 ([MS-ADTS] section
3.1.1.3.2.25) and the account is not also the application service account, the
KDC MUST determine whether an Auth
Hi Andreas,
I was not able to find an INVALID_PARAMETER failure in the provided network
trace. Is this the network trace that was collected at the same time as the TTT
trace?
I see the INVALID_PARAMETER error in your smbtorture logs, but I don't know
which packet in the network trace that rela
Hi Joseph,
Thank you for letting us know about this.
I have filed a request to clarify the documentation, and will follow up.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Ti
Hi Andreas,
Hopefully the LSASS TTT will tell us which parameter it is. I will let you know.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Pacific Time (
I will see what we can do to make this more clear.
Best regards,
Jeff McCashland (He/him) | 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
Hi Andreas,
I would like to collect LSASS TTT traces to troubleshoot the failure.
The LSASS traces can be quite large, but are highly compressible, so please add
them to a .zip archive before uploading (file transfer workspace credentials
are below). Please log into the workspace and find
Part
[Michael to BCC]
Hi Andreas,
I will dig into your question and let you know what I find.
Best regards,
Jeff McCashland (He/him) | 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
Hi Joseph,
In studying [MS-ADTS], I believe that initialization and updating of
msDS-ManagedPasswordId is already documented in section 3.1.1.4.5.39
msDS-ManagedPassword, where this algorithm is described:
Define function GetgMSAPasswordBlob(TO: OBJECT), which returns an
msDS-ManagedPassword
Hi Joseph,
That is my understanding, yes.
Best regards,
Jeff McCashland (He/him) | 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 h
Hi Joseph,
It appears that when the passwords are accessed, the interval is checked and
the passwords are then regenerated if they have expired.
Please let me know if this does not answer your question.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol O
Hi Stefan,
I haven't seen a response, so I'm going to consider this issue closed. I'm
guessing you may be on vacation since it's the holiday season. If that's the
case, just send me a response to my query below, and we can pick up where we
left off.
Best regards,
Jeff McCashland (He/him) | Se
Hi Joseph,
I have part of the answer for you. msDS-ManagedPasswordId is initialized
whenever a User account is created in AD. This may also be initialized when a
Kerberos TGT is generated.
I am still looking into when the values are updated.
Best regards,
Jeff McCashland (He/him) | Senior Es
Hi Joseph,
I will continue researching this and get back to you.
Best regards,
Jeff McCashland (He/him) | 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 countr
[-Tom, Updated Subject]
Hi Stefan,
This is in regards to your question #2 concerning:
3.2.5.2 Receiving an SMB2 NEGOTIATE Response
...
If SMB2_GLOBAL_CAP_PERSISTENT_HANDLES is set in the Capabilities field of the
SMB2 NEGOTIATE Response, the client SHOULD invoke the event as specified
Hi Joseph,
I found a couple of online resources that appear to describe how to generate
the msDS-ManagedPasswordId attribute:
Introducing the Golden GMSA Attack
https://securityboulevard.com/2022/03/introducing-the-golden-gmsa-attack/
How to recover from a Golden gMSA attack
https://learn.micro
Hi Stefan,
The Witness protocol is an essential service for highly available shares. Are
there other uses of the SMB2_SHARE_CAP_SCALEOUT capability that you might
expect to see? What else do you think it might be used for?
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | M
Hi Stefan,
This is in regards to your question:
Question 9:
Section 3.2.4.27-3.2.4.29 seems to actions triggered when the client receives
an RESP_ASYNC_NOTIFY, but there's no specification on how the individual
witness registrations handle specific notification events. E.g. based on the
differ
[try again- Kristian to BCC
From: Jeff McCashland (He/him)
Sent: Tuesday, November 28, 2023 8:27 AM
To: Kristian Smith ; Joseph Sutton
; cifs-protocol@lists.samba.org
Cc: Microsoft Support
Subject: RE: [EXTERNAL] [MS-ADTS] Procedure for setting msDS-ManagedPasswordId
attribute - TrackingID#2311
[Kristian to BCC]
Hi Joseph,
I will look into your question and let you know what I find.
Best regards,
Jeff McCashland (He/him) | 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
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Joseph,
Thank you for your question. We have created SR 231123004495 to track this
issue. One of our engineers will respond soon.
Note that due to the U.S. Thanksgiving holiday, the response may be delayed
until Monday at the latest.
Thank you for the clarification.
I will let you know what I find.
Best regards,
Jeff McCashland (He/him) | 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 coun
Hi Stefan,
I'm looking into your question on:
Question 7:
The above section is the only place in the whole documentation that references
SMB2_SHARE_CAP_SCALEOUT, is that really correct?
I have not found other references to this bit. Could you provide more context
on your question? Is there add
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Joseph,
Thank you for your question. We have created SR 2311210040001551 to track this
issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specificatio
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Joseph,
Thank you for your question. We have created SR 2311210040001007 to address
this issue.
Please note the errata for [MS-GKDI] that redefines isPublicKey:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-winerrata/02262
[-support]
Hi Joseph,
In regards to your question on whether the behavior is important for
implementation:
It is important that the RODC PAC is not used to evaluate policy, that may be
dangerous and must not happen.
Your options are to:
1. Fail the request as we do
2. Generate a PAC locally
Hi Joseph,
I was able to debug the time travel trace, and determined the cause of failure.
It appears that an RODC PAC cannot be used for an access check.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300
Hi Joseph,
Not as far as we know. The issuance policy oid is stored on the issued
certificate. It shouldn't matter how it got there.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm
Hi Joseph,
It appears the certificate claims are only returned when the certificate used
for Authentication has an Issuance Policy on it.
Here is more information:
Using Issuance Policies
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc736786(v=ws.10)
Co
Hi Joseph,
Thank you for uploading the traces. I will analyze them and get back to you.
Best regards,
Jeff McCashland (He/him) | 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 Joseph,
Thank you for uploading the traces. I will analyze them and let you know what I
find.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00)
Pacific T
[Updated Subject w/new SR ID]
Hi Joseph,
We have created SR 231021004144 to track this issue. I created a new file
transfer workspace as the previous SR was closed.
To troubleshoot this issue, please collect and upload LSASS TTT logs and a
concurrent network packet trace both taken from yo
I will see what I can find out...
-Original Message-
From: Joseph Sutton
Sent: Thursday, October 19, 2023 5:25 PM
To: Jeff McCashland (He/him)
Cc: Microsoft Support ; cifs-protocol@lists.samba.org
Subject: Re: [EXTERNAL] Re: [MS-KILE] Certificate strings - but nothing is said
as to how
Hi Joseph,
To debug this issue, I need to collect an LSASS TTT trace. I have created a
file transfer workspace for exchanging files related to this issue (link
below).
The LSASS traces can be quite large, but are highly compressible, so please add
them to a .zip archive before uploading (file
Hi Joseph,
As far as we can tell, the only meaning this parameter has is as a lookup value
when calling GetCertificateSourcedClaims. Therefore, whatever string value you
provide, should not prevent you from generating a certificate claim.
Did the New-ADClaimType command not work to create a cl
Hi Joseph,
I will research your issue and get back to you.
Best regards,
Jeff McCashland (He/him) | 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 phon
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Joseph,
Thank you for your email. We have created SR 231019004616 to track this
issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications
[DocHelp to BCC, support on CC, SR ID on Subject]
Hi Douglas,
Thank you for your email. We have created SR 231019004571 to track this
issue. One of our engineers will respond soon.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications
Hi Joseph,
From protocol side regarding the original question: what is
pCertificateStringsArray in GetClaimsForPrincipal? My understanding is,
pCertificateStringsArray is an input parameter from the caller contains a set
of strings, intended to be used to match the msDS-ClaimSource value of ex
Thank you for the output and comments.
Best regards,
Jeff McCashland (He/him) | 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:
Hi Joseph,
Could you provide the output from an elevated PowerShell session on your DC?
Get-ADClaimType -Filter *
Take note in the output of ClaimSourceType.
Our engineering team notes that any value can be entered for ClaimSource, and
that AD has no specific expectations.
Best regards,
Jeff
Understood, thank you for the response.
Best regards,
Jeff McCashland (He/him) | 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:
Hi Joseph,
We working on getting more information for you. In the meantime, I've been
asked to make a quick sanity check.
I'm assuming you already configured the policy to enable claims for Kerberos?
These articles should help if not:
What's new in Kerberos Authentication
https://learn.microsof
[HC to BCC, adding later response]
Hi Metze,
I will file a request to update the documentation and follow up.
Thank you for letting us know.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open
Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hou
n this enum used in Active Directory, in
particular is there any use in conditional ACEs? Section 3 isn't a clear
enough reference sorry!
Thanks,
Andrew Bartlett
On Fri, 2023-09-22 at 22:17 +, Jeff McCashland (He/him) via cifs-protocol
wrote:
Hi Joseph,
Here is further infor
Hi Joseph,
Here is further information: The string in pCertificateStringsArray represents
a certificate based claim source. We could have 2 types of claim source, AD
based source or certificate based source.
Claims source type is defined here:
[MS-ADTS] 2.2.18.3 CLAIMS_SOURCE_TYPE
The CLAIM
umptions as this is a security behaviour we need
to get right, while maintaining service against both patched and unpatched
(Samba is not yet patched on the server side) servers.
Thanks,
Andrew Bartlett
On Wed, 2023-09-20 at 18:37 +, Jeff McCashland (He/him) via cifs-protocol
wrote:
Hi A
2023-09-20 at 18:37 +0000, Jeff McCashland (He/him) via cifs-protocol
wrote:
Hi Andrew,
Just to be clear, are you referring to this behavior note for section
3.5.4.4.10 NetrLogonGetCapabilities (Opnum 21)?:
<197> Section 3.5.4.4.10: Windows RPC layer may retur
details of what to do if the behaviour
in note <197> is triggered. If the correct fault (mapped to an error code) is
received by the client, due to noticing an older unpatched server (or Samba),
what is the secure and correct behaviour?
Andrew Bartlett
On Mon, 2023-09-18 at 15:55 +
Hi Joseph,
What I've been able to determine so far is that pCertificateStringsArray is a
set of OIDs of msDS-ClaimSource attribute. Hopefully this helps.
I'll let you know if I discover more information.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol
1 - 100 of 230 matches
Mail list logo
