[cifs-protocol] Certificate claim missing from PAC - TrackingID#2310210040000144
Jeff McCashland (He/him)
jeffm at microsoft.com
Sat Oct 21 01:18:35 UTC 2023
[Updated Subject w/new SR ID]
Hi Joseph,
We have created SR 2310210040000144 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 your Domain Controller and upload these to the workspace (details below).
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 PartnerTTDRecorder_x86_x64.zip available for download. The x64 tool can be staged onto the DC in any location (instructions below assume C:\TTD).
To collect the needed traces:
1. From a PowerShell prompt, execute:
C:\TTD\tttracer.exe -Attach ([int](Get-Process -NAME lsass | Format-Wide -Property ID).formatEntryInfo.formatPropertyField.propertyValue)
2. Wait for a little window to pop up in top left corner of your screen, titled “lsass01.run”
3. start a network trace using netsh or WireShark, etc.
4. Repro the attempted operation
5. Stop the network trace and save it
6. 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.
7. The TTTracer.exe process will generate a trace file, then print out the name and location of the file.
Compress the *.run file into a .zip archive before uploading with the matching network trace. It is a good idea to reboot the DC at the next opportunity to restart the lsass process.
Workspace credentials:
Log in as: 2310210040000144_joseph at dtmxfer.onmicrosoft.com
1-Time: W7v7(MpU
Workspace link: https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiNjhmMjRjZmYtMjRjMi00YjJmLWJiZTMtZTlmZjU2ZTJhMzFkIiwic3IiOiIyMzEwMjEwMDQwMDAwMTQ0IiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiIyZDc0ZWI3ZC1jOWU1LTQyOWUtYmM1Ni0wYWMyNTMxMDI1OWYiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE3MDU2MjcwNTIsIm5iZiI6MTY5Nzg1MTA1Mn0.sSl9GPxuRxRbz7eIZhOxolHYZdxNsn5Hkz3nKj1qjVaMl8nec7xTHFXqKM67OxJ5WnBpmRLml7n424X4P78ntIaZWX4Mwy7q7QdH3L3FITFOGeH_XQ10WyDz_vxbBLXk_APyqKZ6YYaRdu32kFTz1PdAKWmba4PVOtOYNi3ro0qdZNNGnI-5vUruIoGe2VTNKiw9K1cU5lNVlZbTaj_nxVj3n_HPXqKoO_sUBk77v1cwRoMWjP1fp0ZljyoFR_FfeM43yGpeI7UvCGRIAfpnFsRgFaIkfpKC49PeM-UA8MiExRnmhtWrElEIeNmSFtsqAU2tmktF_DHkPs61E-_W9Q&wid=68f24cff-24c2-4b2f-bbe3-e9ff56e2a31d
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: http://support.microsoft.com/globalenglish | Extension 1138300
-----Original Message-----
From: Joseph Sutton <jsutton at samba.org>
Sent: Thursday, October 19, 2023 5:25 PM
To: Jeff McCashland (He/him) <jeffm at microsoft.com>
Cc: Microsoft Support <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
Subject: Re: [EXTERNAL] Re: [MS-KILE] Certificate strings - but nothing is said as to how these strings are to be derived from the client’s certificate - TrackingID#2308180010001826
Hi,
I’ll try to explain more clearly what my problem is. First, I can create
a new AD claim type like so:
New-AdClaimType -DisplayName "ObjectClass" -SourceAttribute "objectClass"
Having performed a Kerberos AS-REQ exchange with the KDC, I examine the
PAC_CLIENT_CLAIMS_INFO structure in the resulting ticket — the claim is
there, in an array of type CLAIMS_SOURCE_TYPE_AD.
Similarly, I can create a new Certificate claim type:
New-ADClaimType -DisplayName "CertClaim" -SourceOID "1.3.6.1.4.1.311.67.1.1"
This same OID is placed into the Extended Key Usage extension in a
client certificate, as well as into an szOID_APPLICATION_CERT_POLICIES
extension (having OID 1.3.6.1.4.1.311.21.10). Why? Only because a piece
of documentation [0] seemed to suggest it.
Now I perform another Kerberos AS-REQ exchange, this time using PKINIT
to authenticate with the client’s certificate. In the PAC of the
resulting ticket, I find an “ObjectClass” claim, produced from the
aforementioned AD claim type that I created.
I expect also to find, in an array of type
CLAIMS_SOURCE_TYPE_CERTIFICATE, a “CertClaim” claim — but no matter what
combination of SourceOID and certificate extension OID I try, such a
claim is not forthcoming.
So my question is just this: what must I do to get a certificate claim
to appear in the PAC?
Regards,
Joseph
[0]
https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/bitlocker-how-to-enable-network-unlock#create-the-network-unlock-certificate
On 20/10/23 6:45 am, Jeff McCashland (He/him) wrote:
> 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 claim? Here is a link to the syntax page:
> https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adclaimtype?view=windowsserver2022-ps
>
> In the previous output you provided, it showed "ClaimSourceType : Certificate". Is this not the certificate claim you're trying to create? What is it that you're looking for that you are not seeing?
>
> 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: http://support.microsoft.com/globalenglish | Extension 1138300
>
> -----Original Message-----
> From: Joseph Sutton <jsutton at samba.org>
> Sent: Wednesday, October 18, 2023 1:57 AM
> To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> Cc: Microsoft Support <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
> Subject: Re: [EXTERNAL] Re: [MS-KILE] Certificate strings - but nothing is said as to how these strings are to be derived from the client’s certificate - TrackingID#2308180010001826
>
> Hi,
>
> Thank you for that information. I understand that msDS-ClaimSource is assigned no special meaning in Active Directory; but that gets me no further in my quest to generate certificate claims, since I don’t know what (if any) meaning this attribute is given by the KDC, and MS‐KILE gives no clues.
>
> I made one last fruitless attempt using the OID you gave as an example
> (1.3.6.1.4.1.311.67.1) — but still nothing.
>
> Anyway, I’ve no pressing need for further information at the moment — I’m happy to accept that such details may not be deemed in‐scope for MS-KILE protocol documentation — but if there is an answer on how to generate certificate claims, I’m still interested to hear it.
>
> Thank you for your help so far.
>
> Regards,
> Joseph
>
> On 13/10/23 10:46 am, Jeff McCashland (He/him) wrote:
>> 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 existing claims.
>>
>> All claims are stored under container “CN=Claim Types,CN=Claims Configuration,CN=Services,CN=Configuration” in AD. GetCertificateSourcedClaims looks through all the claims under this container, and returns claims that 1. Its msDS-ClaimTypeAppliesToClass attribute value matches the input principalClass parameter and 2. Its msDS-ClaimSource attribute value is in the input pCertificateStringsArray.
>>
>> pCertificateStringsArray would typically contain a set of predefined OIDs, like 1.3.6.1.4.1.311.67.1 for Key Usages for BitLocker Drive Encryption, or other commonly used OID at Application Policy | Microsoft Learn. However, AD does not enforce any format on a claim source value other than it is a string.
>>
>> To create a claim, use cmdlet New-ADClaimType New-ADClaimType
>> (ActiveDirectory) | Microsoft Learn
>>
>> For example, the following command creates a claim object under “CN=Claim Types,CN=Claims Configuration,CN=Services,CN=Configuration”:
>> New-ADClaimType -DisplayName "Client Cert Auth Bogus" -SourceOID "this
>> is a string does not means anything" -Enabled $true
>>
>> The corresponding object created:
>> Expanding base 'CN=ad://ext/ClientCertAuthB:88dbca8a81d91622,CN=Claim Types,CN=Claims Configuration,CN=Services,CN=Configuration,DC=ABOct23,DC=jiajingzLab,DC=com'...
>> Getting 1 entries:
>> Dn: CN=ad://ext/ClientCertAuthB:88dbca8a81d91622,CN=Claim
>> Types,CN=Claims
>> Configuration,CN=Services,CN=Configuration,DC=ABOct23,DC=jiajingzLab,D
>> C=com
>> cn: ad://ext/ClientCertAuthB:88dbca8a81d91622;
>> displayName: Client Cert Auth Bogus;
>> distinguishedName:
>> CN=ad://ext/ClientCertAuthB:88dbca8a81d91622,CN=Claim Types,CN=Claims
>> Configuration,CN=Services,CN=Configuration,DC=ABOct23,DC=jiajingzLab,D
>> C=com;
>> dSCorePropagationData: 0x0 = ( );
>> Enabled: TRUE;
>> instanceType: 0x4 = ( WRITE );
>> msDS-ClaimIsSingleValued: TRUE;
>> msDS-ClaimIsValueSpaceRestricted: FALSE;
>> msDS-ClaimSource: this is a string does not means anything;
>> msDS-ClaimSourceType: Certificate;
>> msDS-ClaimTypeAppliesToClass:
>> CN=User,CN=Schema,CN=Configuration,DC=ABOct23,DC=jiajingzLab,DC=com;
>> msDS-ClaimValueType: 6;
>> name: ad://ext/ClientCertAuthB:88dbca8a81d91622;
>> objectCategory:
>> CN=ms-DS-Claim-Type,CN=Schema,CN=Configuration,DC=ABOct23,DC=jiajingzL
>> ab,DC=com; objectClass (3): top; msDS-ClaimTypePropertyBase;
>> msDS-ClaimType;
>> objectGUID: 5e65562a-546d-4222-88bc-c5048db89991;
>> uSNChanged: 13052;
>> uSNCreated: 13052;
>> whenChanged: 10/11/2023 11:47:23 AM Pacific Daylight Time;
>> whenCreated: 10/11/2023 11:47:23 AM Pacific Daylight Time;
>>
>> Please let us know if you have any further questions.
>>
>> 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:
>> http://suppo/
>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%
>> 7C4b8df534a4af425379e008dbcfb844f1%7C72f988bf86f141af91ab2d7cd011db47%
>> 7C1%7C0%7C638332162604060424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
>> a=%2FoOR9hjEUHyZLAh1rp4%2FCAePhi6k7nG%2FG8kwEp2H72E%3D&reserved=0 |
>> Extension 1138300
>>
>> -----Original Message-----
>> From: Jeff McCashland (He/him)
>> Sent: Thursday, October 12, 2023 12:51 PM
>> To: Joseph Sutton <jsutton at samba.org>; cifs-protocol at lists.samba.org
>> Cc: Microsoft Support <supportmail at microsoft.com>
>> Subject: RE: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>> nothing is said as to how these strings are to be derived from the
>> client’s certificate - TrackingID#2308180010001826
>>
>> 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:
>> http://suppo/
>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%
>> 7C4b8df534a4af425379e008dbcfb844f1%7C72f988bf86f141af91ab2d7cd011db47%
>> 7C1%7C0%7C638332162604068479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
>> a=Ii1oIckSdZhNRtDklUm701N2uIkOKVxqoVQDjj8kfIk%3D&reserved=0 |
>> Extension 1138300
>>
>> -----Original Message-----
>> From: Joseph Sutton <jsutton at samba.org>
>> Sent: Wednesday, October 11, 2023 6:37 PM
>> To: Jeff McCashland (He/him) <jeffm at microsoft.com>;
>> cifs-protocol at lists.samba.org
>> Cc: Microsoft Support <supportmail at microsoft.com>
>> Subject: Re: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>> nothing is said as to how these strings are to be derived from the
>> client’s certificate - TrackingID#2308180010001826
>>
>> Hi,
>>
>> Running the command you provided on a DC, I got the following output:
>>
>> AppliesToClasses :
>> {CN=User,CN=Schema,CN=Configuration,DC=example,DC=com,
>> CN=Computer,CN=Schema,CN=Configuration,DC=example,DC=com}
>> ClaimSourceType : Certificate
>> CompatibleResourceTypes : {}
>> DisplayName :
>> DistinguishedName : CN=cert_claim,CN=Claim Types,CN=Claims
>> Configuration,CN=Services,CN=Configuration,DC=example,DC=com
>> Enabled : True
>> ID : cert_claim
>> IsSingleValued : True
>> Name : cert_claim
>> ObjectClass : msDS-ClaimType
>> ObjectGUID : 4494a616-320b-41a0-adb3-d3519eff446e
>> RestrictValues :
>> SourceAttribute :
>> SourceOID : 1.3.6.1.4.1.311.67.1.1
>> SuggestedValues : {}
>> ValueType : Boolean
>>
>> This is showing a newly‐created claim type, but one that is more or less the same as a previous attempt that I mentioned in an earlier message.
>>
>> Regards,
>> Joseph
>>
>> On 12/10/23 7:36 am, Jeff McCashland (He/him) wrote:
>>> 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 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:
>>> http://supp/
>>> o%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008dbc
>>> fb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6383321626040740
>>> 66%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qm2B%2FEXvSMJz3iKSWBAa
>>> gQEE5RgMsllSCe7mw1OGWaE%3D&reserved=0
>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com
>>> %
>>> 7Cba7ad16420704117fcb308dbcac3caf6%7C72f988bf86f141af91ab2d7cd011db47
>>> %
>>> 7C1%7C0%7C638326714532987062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>>> M
>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda
>>> t
>>> a=uldpKED7R%2Fs%2BS5IeHNV539liv7IQKHbKlU9GkR34XK4%3D&reserved=0 |
>>> Extension 1138300
>>>
>>> -----Original Message-----
>>> From: Jeff McCashland (He/him)
>>> Sent: Wednesday, October 4, 2023 9:45 AM
>>> To: Joseph Sutton <jsutton at samba.org>; cifs-protocol at lists.samba.org
>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>> Subject: RE: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>> nothing is said as to how these strings are to be derived from the
>>> client’s certificate - TrackingID#2308180010001826
>>>
>>> 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:
>>> http://supp/
>>> o%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008dbc
>>> fb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6383321626040782
>>> 32%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7jNJxbgi82XTjBHLkcSa5b
>>> 0joGYcw7ViviaPjy%2BMpqU%3D&reserved=0
>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com
>>> %
>>> 7Cba7ad16420704117fcb308dbcac3caf6%7C72f988bf86f141af91ab2d7cd011db47
>>> %
>>> 7C1%7C0%7C638326714532995336%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>>> M
>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda
>>> t
>>> a=dE2HjRUSI35q7Q22SWwxygfeWU6UW2YvOm%2FfzQEjoS8%3D&reserved=0 |
>>> Extension 1138300
>>>
>>> -----Original Message-----
>>> From: Joseph Sutton <jsutton at samba.org>
>>> Sent: Tuesday, October 3, 2023 1:58 PM
>>> To: Jeff McCashland (He/him) <jeffm at microsoft.com>;
>>> cifs-protocol at lists.samba.org
>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>> Subject: Re: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>> nothing is said as to how these strings are to be derived from the
>>> client’s certificate - TrackingID#2308180010001826
>>>
>>> Hi,
>>>
>>> Yes; I’ve just checked the domain policy, and I have “KDC support for claims, compound authentication and Kerberos armoring” set to “Always provide claims”.
>>>
>>> Besides, I can get Windows to generate AD claims just fine. It’s only with certificate claims that I’m having trouble.
>>>
>>> Regards,
>>> Joseph
>>>
>>> On 4/10/23 9:13 am, Jeff McCashland (He/him) wrote:
>>>> 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://le/
>>>> a%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008db
>>>> cfb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63833216260408
>>>> 2174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wTg5DgONgwU2MIAmrm
>>>> IKRkQ5qCGjGyevejKaC9pTj2o%3D&reserved=0
>>>> r%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cba7ad16420704117fcb308db
>>>> c
>>>> ac3caf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638326714533001
>>>> 1
>>>> 84%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>>>> i
>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2SoNaoV60LCJ2zWLsVoVi
>>>> R
>>>> OT2NL2%2Bll3DkCKJAD1Pqk%3D&reserved=0
>>>> n.microsoft.com%2Fen-us%2Fprevious-versions%2Fwindows%2Fit-pro%2Fwin
>>>> d
>>>> o
>>>> ws-server-2012-R2-and-2012%2Fhh831747&data=05%7C01%7Cjeffm%40microso
>>>> f
>>>> t
>>>> .com%7Cb435b15eb4464891794608dbc4536afd%7C72f988bf86f141af91ab2d7cd0
>>>> 1
>>>> 1
>>>> db47%7C1%7C0%7C638319634817317104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
>>>> 4
>>>> w
>>>> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
>>>> 7
>>>> C
>>>> &sdata=H7%2BjsSrkCJpzQG6AbObq%2Fk1EIESLJeQwGJwx7cFNKIM%3D&reserved=0
>>>> (
>>>> v
>>>> =ws.11)
>>>>
>>>> Compound authentication and AD DS claims in AD FS
>>>> https://le/
>>>> a%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008db
>>>> cfb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63833216260408
>>>> 6102%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AV4nUUw8dELvNph0UP
>>>> kKDZECuBwMwf4VErAXfZ%2FLEOQ%3D&reserved=0
>>>> r%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cba7ad16420704117fcb308db
>>>> c
>>>> ac3caf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638326714533005
>>>> 5
>>>> 43%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>>>> i
>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s0qgAeIiWKAHD7u7%2FUv
>>>> B
>>>> EFXY1VnEKgLur64pq%2FmWvto%3D&reserved=0
>>>> n.microsoft.com%2Fen-us%2Fwindows-server%2Fidentity%2Fad-fs%2Foperat
>>>> i
>>>> o
>>>> ns%2Fad-fs-compound-authentication-and-ad-ds-claims&data=05%7C01%7Cj
>>>> e
>>>> f
>>>> fm%40microsoft.com%7Cb435b15eb4464891794608dbc4536afd%7C72f988bf86f1
>>>> 4
>>>> 1
>>>> af91ab2d7cd011db47%7C1%7C0%7C638319634817317104%7CUnknown%7CTWFpbGZs
>>>> b
>>>> 3
>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>>>> %
>>>> 7
>>>> C3000%7C%7C%7C&sdata=SNyoXVqAVSeLZJ4L%2FO2GGWD0xZBclloDntTxqOAGhsU%3
>>>> D
>>>> &
>>>> reserved=0
>>>>
>>>> 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:
>>>> http://sup/
>>>> p%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008db
>>>> cfb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63833216260408
>>>> 9985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BdMxboO38YXfwcgq
>>>> bn5YT3MrvifPUEWAXNmw3Fchdws%3D&reserved=0
>>>> o%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cba7ad16420704117fcb308db
>>>> c
>>>> ac3caf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638326714533009
>>>> 7
>>>> 36%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>>>> i
>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=idTWkyMPStpskYsRycjFV
>>>> c
>>>> 9IQkxrbhS8LVF3F8P5QRE%3D&reserved=0
>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.co
>>>> m
>>>> %
>>>> 7Cb435b15eb4464891794608dbc4536afd%7C72f988bf86f141af91ab2d7cd011db4
>>>> 7
>>>> %
>>>> 7C1%7C0%7C638319634817317104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
>>>> w
>>>> M
>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sd
>>>> a
>>>> t
>>>> a=KrOgceOx1UPzkwMebpnKU69GqzLFRf3Dojhm88qSGVE%3D&reserved=0 |
>>>> Extension 1138300
>>>>
>>>> -----Original Message-----
>>>> From: Joseph Sutton <jsutton at samba.org>
>>>> Sent: Tuesday, September 26, 2023 3:51 PM
>>>> To: Jeff McCashland (He/him) <jeffm at microsoft.com>;
>>>> cifs-protocol at lists.samba.org
>>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>>> Subject: Re: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>>> nothing is said as to how these strings are to be derived from the
>>>> client’s certificate - TrackingID#2308180010001826
>>>>
>>>> Hi,
>>>>
>>>> Thank you for that information. I don’t think it entirely answers my question, though.
>>>>
>>>> What I’m trying to discover is precisely how this set of OIDs relates to the client’s certificate, and how I can have Windows generate a certificate claim.
>>>>
>>>> From your remark that pCertificateStringsArray is a set of OIDs,
>>>> I found [0] which gives an example of creating a claim type with the
>>>> driveEncryption OID [1]. Searching further, I found an example [2]
>>>> of creating a self‐signed certificate containing that same OID, by
>>>> placing it into two certificate extensions with OIDs
>>>> 1.3.6.1.4.1.311.21.10 and
>>>> 2.5.29.37 respectively.
>>>>
>>>> Based on these two examples, I assumed that if I added to the client’s certificate both extensions containing the driveEncryption OID, and created a claim type with msDS-ClaimSource set to the same OID, I would be able to see a certificate claim generated when I performed a PKINIT request. However, when I did so, I saw no certificate claims in the PAC of the ticket.
>>>>
>>>> What am I doing wrong that Windows is not generating any certificate claims?
>>>>
>>>> Regards,
>>>> Joseph
>>>>
>>>> [0]
>>>> https://le/
>>>> a%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008db
>>>> cfb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63833216260432
>>>> 3779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LEuvXUJ5ex2ik6%2BM
>>>> DkDrtBtIEmTdODKKdf1n4wmG1gM%3D&reserved=0
>>>> r%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cba7ad16420704117fcb308db
>>>> c
>>>> ac3caf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638326714533013
>>>> 8
>>>> 91%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>>>> i
>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7SckFwNw1H9Lal%2BIdfQ
>>>> J
>>>> PWgWHMLWvuX%2B%2BRZwLGK8nls%3D&reserved=0
>>>> n.microsoft.com%2Fen-us%2Fpowershell%2Fmodule%2Factivedirectory%2Fne
>>>> w
>>>> -
>>>> adclaimtype%3Fview%3Dwindowsserver2022-ps%23example-3-create-a-new-d
>>>> e
>>>> v
>>>> ice-claim-type-with-a-display-name-with-the-source-destination&data=
>>>> 0
>>>> 5
>>>> %7C01%7Cjeffm%40microsoft.com%7Cb435b15eb4464891794608dbc4536afd%7C7
>>>> 2
>>>> f
>>>> 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638319634817317104%7CUnknown
>>>> %
>>>> 7
>>>> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>>>> X
>>>> V
>>>> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZHKmtXWAYK6bTa7cVWdK9vzTWlyPUQms58tb
>>>> 1
>>>> G
>>>> T5H6c%3D&reserved=0
>>>>
>>>> [1]
>>>> https://oi/
>>>> d%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008db
>>>> cfb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63833216260432
>>>> 9626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=t%2FnqRlrM6nNki5%2
>>>> B8MS3Ob34GsS%2BuKtDTuBZ9LendS0U%3D&reserved=0
>>>> -
>>>> rep.orange-labs.fr%2Fget%2F1.3.6.1.4.1.311.67.1.1&data=05%7C01%7Cjef
>>>> f
>>>> m
>>>> %40microsoft.com%7Cb435b15eb4464891794608dbc4536afd%7C72f988bf86f141
>>>> a
>>>> f
>>>> 91ab2d7cd011db47%7C1%7C0%7C638319634817317104%7CUnknown%7CTWFpbGZsb3
>>>> d
>>>> 8
>>>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
>>>> C
>>>> 3
>>>> 000%7C%7C%7C&sdata=Gyd1Vy1fv2X%2BRe7xpcF5L9iQra9xK4SuiZlqbpsrZaQ%3D&
>>>> r
>>>> e
>>>> served=0
>>>>
>>>> [2]
>>>> https://le/
>>>> a%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C4b8df534a4af425379e008db
>>>> cfb844f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63833216260433
>>>> 3690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ynjn4SouSGMIaZMDk2
>>>> 6a%2BegekVvMScOxy9FOZB8lieo%3D&reserved=0
>>>> r%2F&data=05%7C01%7Cjeffm%40microsoft.com%7Cba7ad16420704117fcb308db
>>>> c
>>>> ac3caf6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638326714533022
>>>> 2
>>>> 62%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>>>> i
>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FIPXQk0fhSa6vP4lL21
>>>> F
>>>> 0Zz6EeFGszqn2nnXOMiP6%2BQ%3D&reserved=0
>>>> n.microsoft.com%2Fen-us%2Fwindows%2Fsecurity%2Foperating-system-secu
>>>> r
>>>> i
>>>> ty%2Fdata-protection%2Fbitlocker%2Fbitlocker-how-to-enable-network-u
>>>> n
>>>> l
>>>> ock%23create-the-network-unlock-certificate&data=05%7C01%7Cjeffm%40m
>>>> i
>>>> c
>>>> rosoft.com%7Cb435b15eb4464891794608dbc4536afd%7C72f988bf86f141af91ab
>>>> 2
>>>> d
>>>> 7cd011db47%7C1%7C0%7C638319634817317104%7CUnknown%7CTWFpbGZsb3d8eyJW
>>>> I
>>>> j
>>>> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
>>>> 7
>>>> C
>>>> %7C%7C&sdata=uXb9jwwP%2B5E3PlRyTSUGlCOcHogfKLsqSyZrb1SHxOA%3D&reserv
>>>> e
>>>> d
>>>> =0
>>>>
>>>> On 23/09/23 10:17 am, Jeff McCashland (He/him) wrote:
>>>>> 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 CLAIMS_SOURCE_TYPE
>>>>> enumeration specifies the source of the claims.
>>>>> typedef enum _CLAIMS_SOURCE_TYPE
>>>>> {
>>>>> CLAIMS_SOURCE_TYPE_AD = 1,
>>>>> CLAIMS_SOURCE_TYPE_CERTIFICATE
>>>>> } CLAIMS_SOURCE_TYPE;
>>>>> Note No semantics are to be attached to these values other than those specified in section 3.
>>>>>
>>>>> That last note indicates that the format is left undefined other than as a string blob, intended to be implementation-specific.
>>>>>
>>>>> Please let me know if this does not answer your question.
>>>>>
>>>>> 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:
>>>>> http://suppo/
>>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.c
>>>>> o
>>>>> m
>>>>> %
>>>>> 7C7b9468c03f3a474bff9c08dbbee30936%7C72f988bf86f141af91ab2d7cd011db
>>>>> 4
>>>>> 7
>>>>> %
>>>>> 7C1%7C0%7C638313654571083004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>>> A
>>>>> w
>>>>> M
>>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>>>>> d
>>>>> a
>>>>> t
>>>>> a=cxdtvpzePNloyGYNPVM1EfQXt6qRID8baPdxe9zIqVw%3D&reserved=0 |
>>>>> Extension 1138300
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jeff McCashland (He/him)
>>>>> Sent: Tuesday, September 19, 2023 10:15 AM
>>>>> To: Joseph Sutton <jsutton at samba.org>;
>>>>> cifs-protocol at lists.samba.org
>>>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>>>> Subject: RE: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>>>> nothing is said as to how these strings are to be derived from the
>>>>> client’s certificate - TrackingID#2308180010001826
>>>>>
>>>>> 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 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://suppo/
>>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.c
>>>>> o
>>>>> m
>>>>> %
>>>>> 7C7b9468c03f3a474bff9c08dbbee30936%7C72f988bf86f141af91ab2d7cd011db
>>>>> 4
>>>>> 7
>>>>> %
>>>>> 7C1%7C0%7C638313654571083004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>>> A
>>>>> w
>>>>> M
>>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>>>>> d
>>>>> a
>>>>> t
>>>>> a=cxdtvpzePNloyGYNPVM1EfQXt6qRID8baPdxe9zIqVw%3D&reserved=0 |
>>>>> Extension 1138300
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jeff McCashland (He/him)
>>>>> Sent: Wednesday, August 23, 2023 3:52 PM
>>>>> To: Joseph Sutton <jsutton at samba.org>;
>>>>> cifs-protocol at lists.samba.org
>>>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>>>> Subject: RE: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>>>> nothing is said as to how these strings are to be derived from the
>>>>> client’s certificate - TrackingID#2308180010001826
>>>>>
>>>>> Hi Joseph,
>>>>>
>>>>> Thank you for your fast response. I will analyze the traces 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 and Canada) Local country phone number
>>>>> found here:
>>>>> http://suppo/
>>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.c
>>>>> o
>>>>> m
>>>>> %
>>>>> 7C7b9468c03f3a474bff9c08dbbee30936%7C72f988bf86f141af91ab2d7cd011db
>>>>> 4
>>>>> 7
>>>>> %
>>>>> 7C1%7C0%7C638313654571083004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>>>>> A
>>>>> w
>>>>> M
>>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
>>>>> d
>>>>> a
>>>>> t
>>>>> a=cxdtvpzePNloyGYNPVM1EfQXt6qRID8baPdxe9zIqVw%3D&reserved=0 |
>>>>> Extension 1138300
>>>>>
>>>>> -----Original Message-----
>>>>> From: Joseph Sutton <jsutton at samba.org>
>>>>> Sent: Wednesday, August 23, 2023 3:44 PM
>>>>> To: Jeff McCashland (He/him) <jeffm at microsoft.com>;
>>>>> cifs-protocol at lists.samba.org
>>>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>>>> Subject: Re: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>>>> nothing is said as to how these strings are to be derived from the
>>>>> client’s certificate - TrackingID#2308180010001826
>>>>>
>>>>> [You don't often get email from jsutton at samba.org. Learn why this
>>>>> is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have uploaded a TTD trace and a network trace. The PKINIT AS-REQ I’m interested in should be the final AS-REQ that appears in the network trace.
>>>>>
>>>>> Regards,
>>>>> Joseph
>>>>>
>>>>> On 24/08/23 8:53 am, Jeff McCashland (He/him) wrote:
>>>>>> Hi Joseph,
>>>>>>
>>>>>> That configuration is quite complex in Windows. I think it would be best to collect a TTT trace from your attempted repro. This will allow me to debug into where the PAC is being populated so I can determine what is needed in the Unicode string array. Please collect and upload an LSASS TTT trace and concurrent network trace from your Windows Server where the AS Req is processed.
>>>>>>
>>>>>> 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 PartnerTTDRecorder_x86_x64.zip available for download. The x64 tool can be staged onto the Windows server in any location (instructions below assume C:\TTD).
>>>>>>
>>>>>> To collect the needed traces:
>>>>>> 1. From an elevated command prompt, run "tasklist /FI "IMAGENAME eq lsass.exe" and note the PID number
>>>>>> 2. Run the command (using the PID from step 1): "C:\TTD\TTTracer.exe -attach [PID]"
>>>>>> 3. From a PowerShell prompt, execute:
>>>>>> C:\TTD\tttracer.exe -Attach ([int](Get-Process -NAME lsass | Format-Wide -Property ID).formatEntryInfo.formatPropertyField.propertyValue)
>>>>>> 4. Wait for a little window to pop up in top left corner of your screen, titled “lsass01.run”
>>>>>> 5. start a network trace using netsh or WireShark, etc.
>>>>>> 6. Repro the attempted operation
>>>>>> 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.
>>>>>> Compress the *.run file into a .zip archive before uploading with the matching network trace. It is a good idea to reboot the machine at the next opportunity to restart the lsass process.
>>>>>>
>>>>>> Workspace information:
>>>>>> Log in as: 2308180010001826_joseph at dtmxfer.onmicrosoft.com
>>>>>> 1-time: xU1GQ+f1
>>>>>>
>>>>>> Workspace link:
>>>>>> https://sup/
>>>>>> p%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C7b9468c03f3a474bff9c08
>>>>>> d
>>>>>> b
>>>>>> b
>>>>>> ee30936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6383136545710
>>>>>> 8
>>>>>> 3
>>>>>> 0
>>>>>> 04%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>>>> B
>>>>>> T
>>>>>> i
>>>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=65qs2sN8QHmArr%2BHP
>>>>>> A
>>>>>> %
>>>>>> 2
>>>>>> FQlw4Tcq9G3cN5CecSBEa1F5w%3D&reserved=0
>>>>>> ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOi
>>>>>> J
>>>>>> S
>>>>>> U
>>>>>> z
>>>>>> I1NiJ9.eyJ3c2lkIjoiOWY3ZDY3ODMtNjBhOC00OGE0LTk3MTctNDUzYzY2ZDQxYTJ
>>>>>> i
>>>>>> I
>>>>>> i
>>>>>> w
>>>>>> ic3IiOiIyMzA4MTgwMDEwMDAxODI2IiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlN
>>>>>> W
>>>>>> U
>>>>>> t
>>>>>> Y
>>>>>> mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQ
>>>>>> i
>>>>>> O
>>>>>> i
>>>>>> I
>>>>>> xODMyMDRlMi04ZjJkLTRjZTQtOTY0Zi1hYzIyMzVlOThjNzEiLCJpc3MiOiJodHRwc
>>>>>> z
>>>>>> o
>>>>>> v
>>>>>> L
>>>>>> 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJ
>>>>>> l
>>>>>> e
>>>>>> H
>>>>>> A
>>>>>> iOjE3MDA1OTkxODcsIm5iZiI6MTY5MjgyMzE4N30.b4P9cxG8t-JSihx9aIIOuDgjJ
>>>>>> u
>>>>>> n
>>>>>> 4
>>>>>> S
>>>>>> 3Jfi_k6POc8VIUHBGMKelPAUligjBRVVTJ5AeRL3BLfKcbWy43C2gT8oZfH2lchMzn
>>>>>> B
>>>>>> 4
>>>>>> a
>>>>>> z
>>>>>> BN0Rnum5uDBCtk5p3mtWiDiFTMuezuef5yjqx-qP_WTG5JjBrueN8EFM9LFaHqiwK3
>>>>>> 9
>>>>>> K
>>>>>> F
>>>>>> _
>>>>>> ysUGWfuKC4yGn5i_VI9QcRH12zdEifbNG3oHcA0Sdc7ke9Oq0MzHPvTI_jIPRoKmU2
>>>>>> 3
>>>>>> 5
>>>>>> p
>>>>>> t
>>>>>> LHCH9zPznKnri4GigHIDC_-sq-H2czKio2-4CVcRtxIe5MHo8zy7u16lePsMFORGYL
>>>>>> 9
>>>>>> M
>>>>>> v
>>>>>> 7
>>>>>> y4U35QQ-VH6ha6PhgAH9aynO2tmTdCtqg%26wid%3D9f7d6783-60a8-48a4-9717-
>>>>>> 4
>>>>>> 5
>>>>>> 3
>>>>>> c
>>>>>> 66d41a2b&data=05%7C01%7Cjeffm%40microsoft.com%7C0b1be9ac901a4abb3a
>>>>>> e
>>>>>> c
>>>>>> 0
>>>>>> 8
>>>>>> dba42a827f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6382842747
>>>>>> 2
>>>>>> 5
>>>>>> 4
>>>>>> 4
>>>>>> 8580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>>>> C
>>>>>> J
>>>>>> B
>>>>>> T
>>>>>> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c5XPHYjQ4ShzE5Vffp
>>>>>> h
>>>>>> y
>>>>>> 9
>>>>>> k
>>>>>> WkMI2FqECMz125Z9aC8cE%3D&reserved=0
>>>>>>
>>>>>> 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:
>>>>>> http://supp/
>>>>>> o%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C7b9468c03f3a474bff9c08
>>>>>> d
>>>>>> b
>>>>>> b
>>>>>> ee30936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6383136545710
>>>>>> 8
>>>>>> 3
>>>>>> 0
>>>>>> 04%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>>>> B
>>>>>> T
>>>>>> i
>>>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SMyuLekE2QAnrf366jM
>>>>>> e
>>>>>> B
>>>>>> J
>>>>>> GfYbjZKY8TMq70OPWHQko%3D&reserved=0
>>>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
>>>>>> c
>>>>>> o
>>>>>> m
>>>>>> %
>>>>>> 7C0b1be9ac901a4abb3aec08dba42a827f%7C72f988bf86f141af91ab2d7cd011d
>>>>>> b
>>>>>> 4
>>>>>> 7
>>>>>> %
>>>>>> 7C1%7C0%7C638284274725448580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>>>>> j
>>>>>> A
>>>>>> w
>>>>>> M
>>>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>> s
>>>>>> d
>>>>>> a
>>>>>> t
>>>>>> a=jAZ7o8ItUpVZZpFiXlHxEtutPG%2FsdCZK2EoCbsVZAUc%3D&reserved=0 |
>>>>>> Extension 1138300
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jeff McCashland (He/him)
>>>>>> Sent: Tuesday, August 22, 2023 2:25 PM
>>>>>> To: Joseph Sutton <jsutton at samba.org>;
>>>>>> cifs-protocol at lists.samba.org
>>>>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>>>>> Subject: RE: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>>>>> nothing is said as to how these strings are to be derived from the
>>>>>> client’s certificate - TrackingID#2308180010001826
>>>>>>
>>>>>> Hi Joseph,
>>>>>>
>>>>>> Thank you for the information.
>>>>>>
>>>>>> It appears the certificate strings array needs to contain the msDS-ClaimSource that you mentioned, which may have values such as 'AD', 'Certificate', or 'TransformPolicy'.
>>>>>>
>>>>>> I will see what more I can find out.
>>>>>>
>>>>>> 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:
>>>>>> http://supp/
>>>>>> o%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C7b9468c03f3a474bff9c08
>>>>>> d
>>>>>> b
>>>>>> b
>>>>>> ee30936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6383136545710
>>>>>> 8
>>>>>> 3
>>>>>> 0
>>>>>> 04%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>>>>>> B
>>>>>> T
>>>>>> i
>>>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SMyuLekE2QAnrf366jM
>>>>>> e
>>>>>> B
>>>>>> J
>>>>>> GfYbjZKY8TMq70OPWHQko%3D&reserved=0
>>>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
>>>>>> c
>>>>>> o
>>>>>> m
>>>>>> %
>>>>>> 7C0b1be9ac901a4abb3aec08dba42a827f%7C72f988bf86f141af91ab2d7cd011d
>>>>>> b
>>>>>> 4
>>>>>> 7
>>>>>> %
>>>>>> 7C1%7C0%7C638284274725448580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>>>>> j
>>>>>> A
>>>>>> w
>>>>>> M
>>>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>> s
>>>>>> d
>>>>>> a
>>>>>> t
>>>>>> a=jAZ7o8ItUpVZZpFiXlHxEtutPG%2FsdCZK2EoCbsVZAUc%3D&reserved=0 |
>>>>>> Extension 1138300
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Joseph Sutton <jsutton at samba.org>
>>>>>> Sent: Monday, August 21, 2023 11:30 PM
>>>>>> To: Jeff McCashland (He/him) <jeffm at microsoft.com>;
>>>>>> cifs-protocol at lists.samba.org
>>>>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>>>>> Subject: [EXTERNAL] Re: [MS-KILE] Certificate strings - but
>>>>>> nothing is said as to how these strings are to be derived from the
>>>>>> client’s certificate - TrackingID#2308180010001826
>>>>>>
>>>>>> [You don't often get email from jsutton at samba.org. Learn why this
>>>>>> is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have not managed to have Windows generate these certificate strings myself, but I imagine the procedure looks something like the following.
>>>>>>
>>>>>> First, create a claim type like so:
>>>>>>
>>>>>> dn: CN=ExampleClaim,CN=Claim Types,CN=Claims
>>>>>>
>>>>>> Configuration,CN=Services,CN=Configuration,DC=example,DC=com
>>>>>> changetype: add
>>>>>> objectClass: msDS-ClaimType
>>>>>> Enabled: TRUE
>>>>>> msDS-ClaimIsSingleValued: TRUE
>>>>>> msDS-ClaimSource: (what value should this have? — see below.)
>>>>>> msDS-ClaimSourceType: Certificate
>>>>>> msDS-ClaimTypeAppliesToClass:
>>>>>> CN=User,CN=Schema,CN=Configuration,DC=example,DC=com
>>>>>> msDS-ClaimTypeAppliesToClass:
>>>>>> CN=Computer,CN=Schema,CN=Configuration,DC=example,DC=com
>>>>>> msDS-ClaimValueType: 6
>>>>>>
>>>>>> Then, having installed and set up Certificate Services on the Windows server, perform a Kerberos AS-REQ using PKINIT. If the KDC generates the certificate strings as specified in [MS-ADTS], the claim ought now to be in the PAC_CLIENT_CLAIMS_INFO PAC buffer in the TGT. More pertinently (from an end user’s perspective), with the claim in the PAC we should be authorized to access resources requiring possession of said claim.
>>>>>>
>>>>>> I’ve followed these steps as far as making the Kerberos AS-REQ.
>>>>>>
>>>>>> The part of all this that I’m quite uncertain about is how to set
>>>>>> the attribute “msDS-ClaimSource”. According to the documentation
>>>>>> for
>>>>>> GetCertificateSourcedClaims() ([MS-ADTS] section 3.1.1.11.2.3), a certificate-sourced claim will be issued only if this attribute matches one of the certificate strings. But, as of yet, I haven’t been able to discover what value this attribute should hold for that to happen, not knowing how the certificate strings are derived. That’s what I’m ultimately trying to find out.
>>>>>>
>>>>>> Regards,
>>>>>> Joseph
>>>>>>
>>>>>> On 22/08/23 6:23 am, Jeff McCashland (He/him) wrote:
>>>>>>> Hi Joseph,
>>>>>>>
>>>>>>> I think I will need to do some debugging to find the answer to your question. Do you have a use case or scenario that would use this mechanism? Can you suggest a configuration and repro steps I can use to generate the exchange?
>>>>>>>
>>>>>>> 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:
>>>>>>> http://sup/
>>>>>>> p%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C7b9468c03f3a474bff9c0
>>>>>>> 8
>>>>>>> d
>>>>>>> b
>>>>>>> bee30936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63831365457
>>>>>>> 1
>>>>>>> 0
>>>>>>> 8
>>>>>>> 3004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
>>>>>>> L
>>>>>>> C
>>>>>>> J
>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=385Yj9hR%2Fjgnd
>>>>>>> H
>>>>>>> c
>>>>>>> l
>>>>>>> W4w%2F%2FOnYOH32JcqXLWodVLo3%2FHw%3D&reserved=0
>>>>>>> o%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C0b1be9ac901a4abb3aec0
>>>>>>> 8
>>>>>>> d
>>>>>>> b
>>>>>>> a
>>>>>>> 42a827f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638284274725
>>>>>>> 4
>>>>>>> 4
>>>>>>> 8
>>>>>>> 5
>>>>>>> 80%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
>>>>>>> J
>>>>>>> B
>>>>>>> T
>>>>>>> i
>>>>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=r02tETufnbF8nvwGQk
>>>>>>> w
>>>>>>> P
>>>>>>> R
>>>>>>> %
>>>>>>> 2FO1NOlLdYAM1cXgBrnFG58%3D&reserved=0
>>>>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
>>>>>>> c
>>>>>>> o
>>>>>>> m
>>>>>>> %
>>>>>>> 7C5a06ba8e5597421a203a08dba2d94bcd%7C72f988bf86f141af91ab2d7cd011
>>>>>>> d
>>>>>>> b
>>>>>>> 4
>>>>>>> 7
>>>>>>> %
>>>>>>> 7C1%7C0%7C638282826407736325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>>>> L
>>>>>>> j
>>>>>>> A
>>>>>>> w
>>>>>>> M
>>>>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>> &
>>>>>>> s
>>>>>>> d
>>>>>>> a
>>>>>>> t
>>>>>>> a=tVzSZdkLQwee9MFR%2Foz07SNAVeQS%2BWj6r6etmXaLddE%3D&reserved=0 |
>>>>>>> Extension 1138300
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jeff McCashland (He/him)
>>>>>>> Sent: Friday, August 18, 2023 9:52 AM
>>>>>>> To: Joseph Sutton <jsutton at samba.org>;
>>>>>>> cifs-protocol at lists.samba.org
>>>>>>> Cc: Microsoft Support <supportmail at microsoft.com>
>>>>>>> Subject: RE: [MS-KILE] Certificate strings - but nothing is said
>>>>>>> as to how these strings are to be derived from the client’s
>>>>>>> certificate
>>>>>>> -
>>>>>>> TrackingID#2308180010001826
>>>>>>>
>>>>>>> [HC to BCC]
>>>>>>>
>>>>>>> Hi Joseph,
>>>>>>>
>>>>>>> I will research 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 and Canada) Local country phone
>>>>>>> number found here:
>>>>>>> http://sup/
>>>>>>> p%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C7b9468c03f3a474bff9c0
>>>>>>> 8
>>>>>>> d
>>>>>>> b
>>>>>>> bee30936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63831365457
>>>>>>> 1
>>>>>>> 0
>>>>>>> 8
>>>>>>> 3004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
>>>>>>> L
>>>>>>> C
>>>>>>> J
>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=385Yj9hR%2Fjgnd
>>>>>>> H
>>>>>>> c
>>>>>>> l
>>>>>>> W4w%2F%2FOnYOH32JcqXLWodVLo3%2FHw%3D&reserved=0
>>>>>>> o%2F&data=05%7C01%7Cjeffm%40microsoft.com%7C0b1be9ac901a4abb3aec0
>>>>>>> 8
>>>>>>> d
>>>>>>> b
>>>>>>> a
>>>>>>> 42a827f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638284274725
>>>>>>> 4
>>>>>>> 4
>>>>>>> 8
>>>>>>> 5
>>>>>>> 80%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
>>>>>>> J
>>>>>>> B
>>>>>>> T
>>>>>>> i
>>>>>>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=r02tETufnbF8nvwGQk
>>>>>>> w
>>>>>>> P
>>>>>>> R
>>>>>>> %
>>>>>>> 2FO1NOlLdYAM1cXgBrnFG58%3D&reserved=0
>>>>>>> rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
>>>>>>> c
>>>>>>> o
>>>>>>> m
>>>>>>> %
>>>>>>> 7C5a06ba8e5597421a203a08dba2d94bcd%7C72f988bf86f141af91ab2d7cd011
>>>>>>> d
>>>>>>> b
>>>>>>> 4
>>>>>>> 7
>>>>>>> %
>>>>>>> 7C1%7C0%7C638282826407736325%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
>>>>>>> L
>>>>>>> j
>>>>>>> A
>>>>>>> w
>>>>>>> M
>>>>>>> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>> &
>>>>>>> s
>>>>>>> d
>>>>>>> a
>>>>>>> t
>>>>>>> a=tVzSZdkLQwee9MFR%2Foz07SNAVeQS%2BWj6r6etmXaLddE%3D&reserved=0 |
>>>>>>> Extension 1138300
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Hung-Chun Yu <HungChun.Yu at microsoft.com>
>>>>>>> Sent: Thursday, August 17, 2023 9:44 PM
>>>>>>> To: Joseph Sutton <jsutton at samba.org>;
>>>>>>> cifs-protocol at lists.samba.org
>>>>>>> Cc: Microsoft Support <supportmail at microsoft.com>; Hung-Chun Yu
>>>>>>> <HungChun.Yu at microsoft.com>
>>>>>>> Subject: [MS-KILE] Certificate strings - but nothing is said as
>>>>>>> to how these strings are to be derived from the client’s
>>>>>>> certificate
>>>>>>> -
>>>>>>> TrackingID#2308180010001826
>>>>>>>
>>>>>>> [bcc dochelp]
>>>>>>> Hi Joseph
>>>>>>>
>>>>>>> Thank you for contacting Protocol Support. We created SR Case - TrackingID#2308180010001826. Do leave this tag in the subject line for future references.
>>>>>>> One of our engineers will be contacting you shortly.
>>>>>>>
>>>>>>> Hung-Chun Yu
>>>>>>> hunyu at microsoft.com
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Joseph Sutton <jsutton at samba.org>
>>>>>>> Sent: Thursday, August 17, 2023 7:26 PM
>>>>>>> To: cifs-protocol at lists.samba.org; Interoperability Documentation
>>>>>>> Help <dochelp at microsoft.com>
>>>>>>> Subject: [EXTERNAL] [MS-KILE] Certificate strings
>>>>>>>
>>>>>>> [Some people who received this message don't often get email from
>>>>>>> jsutton at samba.org. Learn why this is important at
>>>>>>> https://aka.ms/LearnAboutSenderIdentification ]
>>>>>>>
>>>>>>> Hi dochelp,
>>>>>>>
>>>>>>> [MS-KILE] 3.3.5.6.4.6, “PAC_CLIENT_CLAIMS_INFO Structure”, mentions that the KDC should call GetClaimsForPrincipal() to get the claims blob with which to populate the PAC_CLIENT_CLAIMS_INFO structure. One of the parameters to GetClaimsForPrincipal(), namely “pCertificateStringsArray”, comprises “[a] set of Unicode strings”, but nothing is said as to how these strings are to be derived from the client’s certificate.
>>>>>>>
>>>>>>> Can you outline the procedure by which these strings are formed, and perhaps provide an example of such a string?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Joseph
>>>>>>>
More information about the cifs-protocol
mailing list