[cifs-protocol] format of password attributes in AD
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] We're hiring http://members.microsoft.com/careers/search/details.aspx?JobID=A976CE32-B0B9-41E3-AF57-05A82B88383Estart=1interval=10SortCol=DatePosted -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] 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
Re: 600300 RE: [cifs-protocol] format of password attributes in AD
On Fri, 2008-07-11 at 12:36 -0700, Richard Guthrie wrote: Andrew, Regarding your question on the Extended Access Checks table in the MS-ADTS documentation section 3.1.1.4.4, as you know there are 13 attributes in which the documentation cites Access is never granted with respect to query via LDAP. With respect to replication we are working to update the documentation but I wanted to provide you with a progress update. I would like to do this by taking each of the attributes and reviewing either the proposed change or result of my investigation. Here are the results: Thanks! pekList msDS-ExecuteScriptPassword These two attributes are not replicated by Directory Replication Services (DRS). You can determine this by checking the systemFlags property (look for FLAG_ATTR_NOT_REPLICATED) of these attributes in the MS-ADA# documents. So, would it be correct to say there is no way to obtain these values (in the form stored in the directory) from a windows server? unicodePwd dBCSPwd ntPwdHistory lmPwdHistory All four of these are 16 byte values that contain a hash of various types. unicodePwd - is a 16 byte password hash that is constructed using NT One way function (NT OWF) which is defined in the MS-NLMP documentation in section 4.2. I would also encourage you to read section 3.1.1.3.1.5 in the MS-ADTS documentation for information about password modify operations and how this attribute is updated/affected in the various flavors of Windows OS with regard to LDAP. For information on how this value is constructed using NTOWF see MS-NLMP section 4.2 for NTLM v1 and v2 specific details. dBCSPwd - is a 16 byte hash value containing the accounts Lan Manager Password as defined in MS-ADA1 section 2.141. This value is constructed using Lan Manager OWF (LMOWF). Details on LMOWF v1 and v2 are described in the MS-NLMP documentation section 4.2. Thanks. ntPwdHistory and lmPwdHistory are both Arrays of 16 byte hash values. I am still doing some research into how these values are laid out. We are pretty sure it's just an end-to-end array (not multiple elements). trustAuthIncoming trustAuthOutgoing These values are documented in sections 7.1.6.7.10 trustAuthIncoming, 7.1.6.7.11 trustAuthOutgoing, and 7.1.6.8.1 trustAuthInfo Attributes. The last section 7.1.6.8.1 has information on layout. initialAuthIncoming initialAuthOutgoing I am currently in discussion with the development team, these attributes are not in use by Windows. They are most likely something that was considered for Windows pre-Windows 2000 but were never implemented. As a Microsoft policy attributes are never removed from the schema once they have been added and these fall into that category. priorValue currentValue The value stored in this attribute is application specific. We are currently working with the various teams to have these documented. Is there a specific application for which you need the format of these attributes? If so please let me know and I can work to get you that format. Otherwise, these will be released with the protocols that use them as those docs get updated. I think these have been used to store the secrets for NT4 trusts in the past. I suspect a link here to the work you are doing for me on MS-LSAD will be part of the end result. This leaves supplementalCredentials. We are working to get this documented as quickly as possible. I have two options for moving forward. We can send you an interim documentation update or we can wait till the final document is completed. Whichever you prefer is fine. If you want the interim update, I just have to let you know that any information in that update is subject to change. Let me know how you want to proceed there. The interim documentation would be useful. Was the IDL I sent in any help? I want to pass along a Thank you from the development team as this exposed an area of the documentation that needed quite a bit of work to make it correct. Hope this gives you an update on progress and some information from which to go on. Please send me your comments and we will continue to work as quickly as possible to get this resolved. Great. A big help with this area would be better links in the documentation, particularly from the schema doc the detailed format descriptions (or put them in the schema doc). (Samba and the other AD server implementation I know of are both LDAP-oriented, so we tend to work up from entries and attributes stored in the LDAP database, and replicated in that form). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [cifs-protocol] format of password attributes in AD
Andrew, We are working to get you and answer for the entire table as you requested. At this time I don't have an ETA for completion but I will update you by the end of the week, regardless of whether I have a complete answer or not. I did want to ask you if this link to the MS-SAMR document gives you the information you need with regard to the supplementalCredentials attribute http://msdn.microsoft.com/en-us/library/cc245499.aspx? Richard Guthrie Open Protocols Support Team Support Escalation Engineer, US-CSS DSC PROTOCOL TEAM 7100 N Hwy 161, Irving, TX - 75039 Las Colinas - LC2 Tel: +1 469 775 7794 E-mail: [EMAIL PROTECTED] -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Sunday, June 22, 2008 10:44 PM To: Richard Guthrie Cc: Interoperability Documentation Help; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [cifs-protocol] format of password attributes in AD On Sat, 2008-06-14 at 22:55 +1000, Andrew Bartlett wrote: On Thu, 2008-06-12 at 08:38 -0700, Richard Guthrie wrote: Andrew, I wanted to ensure I understand your question so please validate the following: The MS-ADTS document, section 3.1.1.4.4 Extended Access checks is missing information that describes the format of the attributes listed in the table. Your question relates to syncing these attributes via Directory Replication as described in MS-DRSR. The table indicates Access is never granted. What is the format of these attributes when synced via DRS? The MS-ADTS document, section 3.1.1.4.4 Extended Access checks lists attributes over which Access is never granted.. Naturally this makes them harder to inspect to determine their format. What is the format of these attributes when synced via DRS (which does permit their access)? I'm picking on this table because almost all these attributes listed here as 'access is never granted' are in some way complex in their representation (because they deal with passwords and similar information), but most (all?) are described simply as 'octect string' in the documentation. Is this a correct interpretation of your question? No, see my revised attempt. Has there been any progress in documenting the format of these attributes? Thanks, -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
[cifs-protocol] format of password attributes in AD
As a PFIF subcontractor, I am requesting correction assistance: MS-ADS3 lists supplementaryCredentials as: .286 Attribute supplementalCredentials This attribute specifies stored credentials for use in authenticating; the encrypted version of the user's password. This attribute is neither readable nor writable. However, it does not describe the format of the attribute (when read over DRS replication, as it is not available in LDAP). We have some idea of the format, but need to know how it is expanded for new key types (for example, we wish to enable AES in our KDC). Similarly the other password attributes not not fully described (ntPwdHistory and lmPwdHistory are un-described, and unicodePwd could be better described). Can you please describe to me (and the list) the format of this and the other password attributes? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
