[cifs-protocol] format of password attributes in AD

Fri Sep 12 20:40:51 GMT 2008

Metze/Andrew,

  We  completed the investigation for two issues listed in the e-mail below.

  For the first issue,  we finally determined where the extra bytes come from.  There are two issues contributing to the extra bytes.

   (1) The cause of these bytes is an "off by one" calculation error when allocating the buffer for the credentials structure.  The KERB_STORED_CREDENTIAL  and  KERB_STORED_CREDENTIAL_NEW  structures contain space for  KERB_KEY_DATA and KERB_KEY_DATA_NEW structures respectively which are not accounted for correctly in the Windows implementation.  The calculation for the count of these structures should have been based on CredentialCount - 1.  This adjustment is not performed in the code and therefore exactly sizeof(KERB_KEY_DATA) and sizeof(KERB_KEY_DATA) extra bytes of 0 are present after the last real key data.   The benign presence of these bytes with value of 0 are not referenced by any offset and the salt value following them is referenced correctly,  therefore it should not affect interoperability.

   (2) The storage of a dummy key that is included in the supplemental credentials when the current domain functional level is DS_BEHAVIOR_WIN2003 or less.  For this issue we will make the following change to 2.2.10.8 [MS-SAMR].

        "2.2.10.8 Kerberos Encryption Algorithm Identifiers

        The following table identifies the various algorithms that can be used in the KERB_KEY_DATA and KERB_KEY_DATA_NEW structures.<24>

      <Windows Behavior>

        <24> Section 2.2.10.8: When the current domain functional level is DS_BEHAVIOR_WIN2003 or less, a Windows Server 2008 DC includes a key entry of        type -140 in each of KERB_STORED_CREDENTIAL and KERB_STORED_CREDENTIAL_NEW, which is not needed and can be ignored; it is a dummy type in the   supplemental credentials that is not present when the domain functional level is raised to DS_BEHAVIOR_WIN2008 or greater. The key data is the NT       hash of the password."

  For the second issue with regard to the extra byte at the end we need additional information on how to reproduce the problem , as Richard indicated in his mail below.

Thanks

----------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis at microsoft.com
Tel:  469-7757027 x 57027
-----------------------------------------------------------

-----Original Message-----

Stefan/Andrew,

I wanted to give you an update on this issue.  I was able to parse the NDR dump you gave us and have identified the two issues you point out.  Here is info on our findings to date.

Both Primary:Kerberos-Newer-Keys - KERB_STORED_CREDENTIAL_NEW and Primary:Kerberos - KERB_STORED_CREDENTIAL show extra bytes between the last credential structure and the salt value.  However, the offset for DefaultSaltOffset is correct so you should be able to correctly parse the structure.  We are working to determine exactly where the bytes are coming from.  I hope to have that information shortly.

I also see the extra byte (value 0x66) at the end of the NDR dump however, we are unable to reproduce that behavior currently.  Can you provide a detailed set of steps that can be used to reproduce this behavior?  Also, is it possible there is an issue in your parsing at a lower level?  I am not saying there is I just want to try and attack the issue from multiple angles.  I am also working on the reserved fields and hope to send an update shortly as well.

Please let us know if you have any additional questions.

Richard Guthrie
Open Protocols Support Team
Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM
Tel: +1 (469) 775-7794
E-mail: rguthrie at microsoft.com
We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383E&start=1&interval=10&SortCol=DatePosted

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze at samba.org]
Sent: Tuesday, August 19, 2008 1:12 AM
To: Andrew Bartlett
Cc: Richard Guthrie; Nick Meier
Subject: Re: 600300 RE: [cifs-protocol] format of password attributes in AD

Andrew Bartlett schrieb:
> On Mon, 2008-08-18 at 14:43 -0700, Richard Guthrie wrote:
>> Stefan,
>>
>> I reviewed your IDL and need to see if I can get some additional information from you in order to correctly interpret what you sent.  I see your supplementalCredentialsBlob structure in your IDL.  The way I read your mail you are seeing an extra byte at the end of the structure for which you do not have an understanding.  That value is marked as [value(0)] uint8 unknown3 In your IDL.
>>
>> Can you send me a dump of the structure in memory (not sure how your
>> environment is setup but a memory dump would be great)?  This looks
>> very similar to the USER_PROPERTIES structure btw, any chance it is
>> part of the PropertySignature or PropertyCount?
>>
>> With regard to package_PrimaryKerberosCtr3, I see the 20 bytes you
>> have marked in the structure.  I wanted to confirm that I am matching
>> up structures between the documentation and your IDL.  Please verify
>> my understanding
>>
>> *       Package_PrimaryKerberosKey4 - this lines up with the
>> KERB_KEY_DATA_NEW structure (section 2.2.10.7).
>> *       package_PrimaryKerberosCtr4 I think is supposed to line up
>> with Primary:Kerberos-Newer-Keys - KERB_STORED_CREDENTIAL_NEW
>> (section
>> 2.2.10.6) It looks like you drop the revision and flags values, is
>> that correct?
>> *       package_PrimaryKerberosKey3 looks like it lines up with
>> KERB_KEY_DATA 2.2.10.5.  This looks to line up correctly.
>> *       package_PrimaryKerberosCtr3 - This looks to line up correctly
>> with exception of the 20 bytes you have marked as padding 1-5.  Again
>> it looks like you drop the revision and flags fields.  Is it possible
>> that 20 bytes is part of the salt or key values structures?  Can you
>> give me a memory dump of the full structure that shows this (I have
>> attached a file Andrew sent on a previous issue that shows what I
>> mean by memory dump, hope that helps).
>>
>> Thanks for the feedback and I look forward to hearing from you.
>
> I don't see an attachment, but I presume you mean the ndrdump output
> (this is the parsed text format I'll included, along with a binary
> blob, in the past).

I'll send ndrdump with '--dump-data' output later today, that should have everything that's needed.

metze