[cifs-protocol] [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId attribute - TrackingID#2311210040001007

Sreekanth Nadendla srenaden at microsoft.com
Fri Dec 15 18:58:03 UTC 2023


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://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 ]

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%7C9462dc0f331646a88de508dbfacc75cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638379528294828193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aoIS%2B0N5mL52uY6DjYIFM0a6lkaMsWniSRSPaUmOcRk%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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20231215/dda868f7/attachment.htm>


More information about the cifs-protocol mailing list