[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId attribute - TrackingID
From: Joseph Sutton via cifs-protocol <cifs-protocol () lists ! samba ! org>
Date: 2023-12-18 21:17:52
Message-ID: ddfb9df5-e78f-4a9f-991f-8bc44b8f7217 () samba ! org
[Download RAW message or body]
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@samba.org>
> *Sent:* Monday, December 18, 2023 2:08 AM
> *To:* Sreekanth Nadendla <srenaden@microsoft.com>
> *Cc:* cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>
> *Subject:* Re: [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId
> attribute - TrackingID#2311210040001007
> [You don't often get email from jsutton@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-21 \
> > 0625-errata.pdf&data=05%7C02%7Csrenaden%40microsoft.com%7Cacecbdd7a1994f36e85308db \
> > ff982643%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@samba.org>
> > *Sent:* Monday, December 11, 2023 11:40 PM
> > *To:* Sreekanth Nadendla <srenaden@microsoft.com>
> > *Cc:* cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>
> > *Subject:* Re: [EXTERNAL] [MS-ADTS] Format of the msDS-ManagedPasswordId
> > attribute - TrackingID#2311210040001007
> > [You don't often get email from jsutton@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-69 \
> > 54fb3e58f7&data=05%7C02%7Csrenaden%40microsoft.com%7Cacecbdd7a1994f36e85308dbff982 \
> > 643%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638384801618617742%7CUnknown%7CTW \
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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-6 \
> > 954fb3e58f7&data=05%7C02%7Csrenaden%40microsoft.com%7Cacecbdd7a1994f36e85308dbff98 \
> > 2643%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638384801618624174%7CUnknown%7CT \
> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%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@samba.org>
> > > *Sent:* Monday, November 20, 2023 7:05 PM
> > > *To:* cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>;
> > > Interoperability Documentation Help <dochelp@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
_______________________________________________
cifs-protocol mailing list
cifs-protocol@lists.samba.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic