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

[Richard Guthrie]

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:

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.

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.

ntPwdHistory and lmPwdHistory are both Arrays of 16 byte hash values.  I am still doing some research into how these values are laid out.

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.

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.

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.

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: 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: Richard Guthrie
Sent: Monday, June 09, 2008 1:36 PM
To: Andrew Bartlett; Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: [cifs-protocol] format of password attributes in AD

Andrew,

I have been tasked with working on this issue and will be sending you another mail shortly with a summary of the questions I think you are asking.  Is this issue a blocking issue for you or are you able to work around it?

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: rguthrie at microsoft.com


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Monday, June 09, 2008 1:40 AM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: Re: [cifs-protocol] format of password attributes in AD

On Mon, 2008-06-09 at 16:23 +1000, Andrew Bartlett wrote:
> 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).

Actually, to make this complete, I need the format for all the attributes listed in the table at MS-ADTS 3.1.1.4.4, in particular those marked 'access is never granted'.

> Can you please describe to me (and the list) the format of this and
> the other password attributes?

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.