[cifs-protocol] [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId attribute - TrackingID#2311210040001007
Joseph Sutton
jsutton at samba.org
Mon Dec 18 21:17:52 UTC 2023
Thank you. I believe that tells me what I needed to know.
Regards,
Joseph
On 19/12/23 6:49 am, Sreekanth Nadendla wrote:
> Hello Joseph, the 'Data' portion of the msDS-ManagedPasswordId is as
> shown below. The length field is the total length of the buffer
> containing 'Data'.
>
> DWORD version;
> DWORD magic;
> DWORD dwFlags;
> DWORD dwL0KeyID;
> DWORD dwL1KeyID;
> DWORD dwL2KeyID;
> GUID rootKeyID;
>
> DWORD cbAdditionalInfo; //Ephemeral public key or
> random number used in derive symmetric key
> DWORD cbSourceDomainName;
> DWORD cbSourceForestName;
> // Public key blob of the Ephemeral used in secret agreement or
> random number used in derive symmetric key
> // DNS style name of the domain which generated the key
> // DNS name of the forest
>
> But if you want to retrieve other details like KDF algorithm name etc..
> They can be retrieved by calling GetKey as mentioned in my previous email.
>
> Data returned from GetKey is shown below ( ppbOut parameter will have this )
>
> DWORD version;
> DWORD magic;
> DWORD dwFlags;
> DWORD dwL0KeyID;
> DWORD dwL1KeyID;
> DWORD dwL2KeyID;
> GUID rootKeyID;
>
> DWORD cbKDFAlgorithmName; //length of the KDF algorithm name.
> DWORD cbKDFParameters; //length of the KDF
> parameters.
> DWORD cbSecAgrAlgorithmName; //length of secret
> agreement algorithm name
> DWORD cbSecAgrAlgorithmParam;//length of the secret
> agreement algorithm param
> DWORD cbPrivateKeyLen; //length of the secret
> agreement private key
> DWORD cbPublicKeyLen; //length of the secret
> agreement public key
> DWORD cbL1KeyLen; //Length of L1 key
> DWORD cbL2KeyLen; //Length of L2 Key (public
> key blob or private key material)
> DWORD cbSourceDomainName; //length of domain DNS name
> DWORD cbSourceForestName; //length of forest DNS name
> // KDF algorithm Name
> // KDF parameters
> // Secret agreement algorithm name
> // Secret agreement parameters
> // DNS name of the domain which generated the key
> // DNS name of the forest
> // SID L1 key data
> // SID L2 key data
>
> Regards,
>
> Sreekanth Nadendla
>
> Microsoft Windows Open Specifications
>
>
> ------------------------------------------------------------------------
> *From:* Joseph Sutton <jsutton at samba.org>
> *Sent:* Monday, December 18, 2023 2:08 AM
> *To:* Sreekanth Nadendla <srenaden at microsoft.com>
> *Cc:* cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
> *Subject:* Re: [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId
> attribute - TrackingID#2311210040001007
> [You don't often get email from jsutton at samba.org. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification
> <https://aka.ms/LearnAboutSenderIdentification> ]
>
> Thank you. So, if I understand correctly, the msDS-ManagedPasswordId
> attribute comprises this SID_KEY_ID_HEADER, a DWORD parameter containing
> the length (?) of an ephemeral public key or a random number, and
> finally the DNS names of the domain and forest, preceded by their
> respective lengths?
>
> Regards,
> Joseph
>
> On 16/12/23 7:58 am, Sreekanth Nadendla wrote:
>> Hello Joseph, Section 3.1.4.1 GetKey (Opnum 0) from MS-GKDI specifies
>>
>> HRESULT GetKey( [in] handle_t hBinding, [in] ULONG cbTargetSD, [in]
>> [size_is(cbTargetSD)] [ref] char* pbTargetSD, [in] [unique] GUID*
>> pRootKeyID, [in] LONG L0KeyID, [in] LONG L1KeyID, [in] LONG L2KeyID,
>> [out] unsigned long* pcbOut, [out] [size_is(, *pcbOut)] byte** ppbOut);
>>
>> Call this function and use ppbOut to access SID_KEY_HEADER which has the
>> algorithm info (see below)
>>
>> struct _SID_KEY_HEADER
>> {
>> SID_KEY_ID_HEADER sidKeyID;
>> DWORD cbKDFAlgorithmName; //length of the KDF
>> algorithm name.
>> DWORD cbKDFParameters; //length of the KDF
>> parameters.
>> DWORD cbSecAgrAlgorithmName; //length of secret
>> agreement algorithm name
>> DWORD cbSecAgrAlgorithmParam;//length of the secret
>> agreement algorithm param
>> DWORD cbPrivateKeyLen; //length of the secret
>> agreement private key
>> DWORD cbPublicKeyLen; //length of the secret
>> agreement public key
>> DWORD cbL1KeyLen; //Length of L1 key
>> DWORD cbL2KeyLen; //Length of L2 Key (public
>> key blob or private key material)
>> DWORD cbSourceDomainName; //length of domain DNS name
>> DWORD cbSourceForestName; //length of forest DNS name
>> // KDF algorithm Name
>> // KDF parameters
>> // Secret agreement algorithm name
>> // Secret agreement parameters
>> // DNS name of the domain which generated the key
>> // DNS name of the forest
>> // SID L1 key data
>> // SID L2 key data
>> } SID_KEY_HEADER;
>>
>>
>> The 'unknown' field you've mentioned is the Ephemeral public key or
>> random number used in derive symmetric key.
>>
>> Most importantly, there is an errata published for MS-GKDI. It can be
>> found here
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwinprotocoldoc.blob.core.windows.net%2Fproductionwindowsarchives%2FMS-GKDI%2F%255bMS-GKDI%255d-210625-errata.pdf&data=05%7C02%7Csrenaden%40microsoft.com%7Cacecbdd7a1994f36e85308dbff982643%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638384801618609376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HCPOXQgXla2nSiX3uOPSAcqEGrz3F28FvEHUi8wKC%2B0%3D&reserved=0 <https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-GKDI/%5bMS-GKDI%5d-210625-errata.pdf>>
>>
>> "dwFlags (4 bytes): A 32-bit unsigned integer. Bit 31 (LSB) MUST be set
>> to 1 when this structure is being used to transport a public key, and
>> otherwise set to 0. Bit 30, when set to 1, indicates that this key can
>> be used for encrypting new data. This field is encoded using
>> little-endian format."
>>
>> This explains why you are seeing value 2 for dwFlags i.e. flags (as it
>> was defined previously in the older version of the specification). We
>> will work with our documentation team to get these updated in the
>> specification. Just wanted to share these with you to unblock your
>> development asap. Plus, you may still notice other ambiguous portions
>> and let us know. Let us know your thoughts.
>>
>>
>> Regards,
>>
>> Sreekanth Nadendla
>>
>> Microsoft Windows Open Specifications
>>
>> ------------------------------------------------------------------------
>> *From:* Joseph Sutton <jsutton at samba.org>
>> *Sent:* Monday, December 11, 2023 11:40 PM
>> *To:* Sreekanth Nadendla <srenaden at microsoft.com>
>> *Cc:* cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>
>> *Subject:* Re: [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId
>> attribute - TrackingID#2311210040001007
>> [You don't often get email from jsutton at samba.org. Learn why this is
>> important at https://aka.ms/LearnAboutSenderIdentification
> <https://aka.ms/LearnAboutSenderIdentification>
>> <https://aka.ms/LearnAboutSenderIdentification
> <https://aka.ms/LearnAboutSenderIdentification>> ]
>>
>> Hi,
>>
>> Here’s what I see in the msDS-ManagedPasswordId attribute of a Group
>> Managed Service Account created on Windows:
>>
>> version : 0x00000001 (1)
>> magic : 0x4b53444b (1263748171)
>> flags : 0x00000002 (2)
>> 0: ENVELOPE_FLAG_TRANSPORTING_PUBLIC_KEY
>> 1: ENVELOPE_FLAG_KEY_MAY_ENCRYPT_NEW_DATA
>> l0_index : 0x0000016a (362)
>> l1_index : 0x00000001 (1)
>> l2_index : 0x0000000e (14)
>> root_key_id : 9d922231-af27-b73b-1056-aeb18eeca71a
>> unknown : 0x00000000 (0)
>> domain_name_len : 0x00000018 (24)
>> forest_name_len : 0x00000018 (24)
>> domain_name : 'example.com'
>> forest_name : 'example.com'
>>
>> This data is structured similarly to Group Key Envelope, which is
>> described here:
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-gkdi%2F192c061c-e740-4aa0-ab1d-6954fb3e58f7&data=05%7C02%7Csrenaden%40microsoft.com%7Cacecbdd7a1994f36e85308dbff982643%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638384801618617742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5DZ0%2BWx7fKzzner19n3HctEVgZuuj2MwK5PXrWIFOjg%3D&reserved=0 <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/192c061c-e740-4aa0-ab1d-6954fb3e58f7> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-gkdi%2F192c061c-e740-4aa0-ab1d-6954fb3e58f7&data=05%7C02%7Csrenaden%40microsoft.com%7Cacecbdd7a1994f36e85308dbff982643%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638384801618624174%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZcGfE4JkuHhlGqS2sqLwINfkmk2p61454PRzXkQra7I%3D&reserved=0 <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-gkdi/192c061c-e740-4aa0-ab1d-6954fb3e58f7>>
>>
>> However, the two structures evidently are not the same. Some of the
>> fields present in Group Key Envelope are missing from
>> msDS-ManagedPasswordId (notably the ones relating to algorithms and
>> keys). And immediately following the root key identifier in
>> msDS-ManagedPasswordId is a 32‐bit field the purpose of which I have not
>> been able to determine.
>>
>> Regards,
>> Joseph
>>
>> On 9/12/23 9:40 am, Sreekanth Nadendla wrote:
>>>
>>> Hello Joseph, the attribute msDS-ManagedPasswordId is expected to
>>> contain two fields 'Size' and 'Data'. Representing a byte array along
>>> with its size. The Size member indicates the length of the byte array,
>>> and the Data member is a pointer to the actual array of bytes.
>>>
>>> Data field holds the pointer to GmsaKeyId buffer while Size is set to
>>> total number of bytes of the GmsaKeyId buffer.
>>>
>>> Are you saying that the contents inside the Data field don't appear to
>>> be GmsaKey related ?
>>>
>>> Regards,
>>>
>>> Sreekanth Nadendla
>>>
>>> Microsoft Windows Open Specifications
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Joseph Sutton <jsutton at samba.org>
>>> *Sent:* Monday, November 20, 2023 7:05 PM
>>> *To:* cifs-protocol at lists.samba.org <cifs-protocol at lists.samba.org>;
>>> Interoperability Documentation Help <dochelp at microsoft.com>
>>> *Subject:* [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId
>>> attribute
>>> Hi dochelp,
>>>
>>> [MS-ADTS] 3.1.1.4.5.39, “msDS-ManagedPassword”, makes reference to the
>>> attribute ‘msDS-ManagedPasswordId’, which (it states) contains a key ID
>>> that is involved in the computation of the managed password. I’m trying
>>> to work out the format of this attribute.
>>>
>>> A couple of times that document mentions that the key ID identifies a
>>> Group Key Envelope data structure, defined in section 2.2.4 of
>>> [MS-GKDI]. Now I have obtained some samples of ‘msDS-ManagedPasswordId’
>>> attributes from Group Managed Service Accounts created by Windows. While
>>> these samples appear to be superficially similar to Group Key Envelope
>>> format, they have a few notable differences: the fields from
>>> ‘cbKDFAlgorithm’ to ‘cbL2Key’ are missing, replaced by a single 32‐bit
>>> field containing I don’t know what; and the fields from ‘KDF Algorithm’
>>> to ‘Secret Agreement Parameters’, and both ‘L1 Key’ and ‘L2 Key’, are
>>> similarly missing.
>>>
>>> Also mysterious is the field ‘isPublicKey’, which according to [MS-GKDI]
>>> must contain either 0 or 1, but in my samples has the value 2 !
>>>
>>> Can you provide me with some details on the format of the
>>> ‘msDS-ManagedPasswordId’ attribute, and on how it resembles or differs
>>> from the Group Key Envelope structure?
>>>
>>> Regards,
>>> Joseph
More information about the cifs-protocol
mailing list