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
[cifs-protocol] RE: Specific sockaddr layout in MS-ADTS 7.3.1.7
Hi, Andrew, We have completed our investigation on Window clients implementation regarding NETLOGON_NT_VERSION_5EX_WITH_IP bit. We confirmed that in all clients of Windows NT 4 or higher, NETLOGON_NT_VERSION_5EX_WITH_IP bit of NtVersion flag is always set for NetBIOS based mailslot ping, but is never set for LDAP ping. We verified in our testing that clients did set this bit when a NetBIOS domain name is used. Please let us know if you have further questions. Thanks ! Hongwei -Original Message- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 5:21 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Specific sockaddr layout in MS-ADTS 7.3.1.7 On Thu, 2008-06-26 at 14:03 -0700, Hongwei Sun wrote: Hi, Andrew, Thanks for your question regarding NETLOGON_NT_VERSION_5EX_WITH_IP flag. In terms of the server, it is not deprecated. That is, current servers still support requests that include this flag and respond appropriately. For a server to be interoperable with Windows clients, it needs to accept the flag in either way whenever it is sent. The documentation explains what server should do if the bit is set in the NtVersion flag and what server should do if it is not set and that it should be prepared to accept a communication that contains this flag at any time. Any actions taken by a Windows client based on this flag do not affect the interoperability of a server implementation. All those words, yet no new information! Can you please answer the question: What windows client will set this flag, and under what circumstances? If no Microsoft clients set this flag, then can the documentation be updated to reflect this. This is an important question for implementers. We could spend all year implementing things that Microsoft servers do, but if we concentrate our efforts on the things that exist the the real world, then we are all much more productive. Perhaps you could escalate this question to someone who is able to find this out? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
