600300 RE: [cifs-protocol] format of password attributes in AD

[Andrew Bartlett]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080712/1f4ac456/attachment.bin