[cifs-protocol] RE: Secret 'last set times' doc incorrect in 2008 - 601488

[Richard Guthrie]

Andrew,

We have completed our investigation into the differences in behavior between Windows 2003 and 2008 with respect to LsarSetSecret/LsarQuerySecret.  It was found there is a change in Windows Server 2008 domain controllers to the response given by LsarQuerySecret for secrets stored in Active Directory.  If Windows Server 2000 and Windows Server 2003 process a global secret with a value that has its Length field equal to 0, these methods will fill in the CipherCurrentValue with following values before encryption.

       Length = 0
       MaximumLength = 0

Windows Server 2008 sets the value of CipherCurrentValue to NULL which is why you see the difference in behavior.  We will be updating the documentation to reflect this behavior in an upcoming version of MS-LSAD.

Please let us know if you have any further 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


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Wednesday, September 03, 2008 5:31 PM
To: Richard Guthrie
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: RE: Secret 'last set times' doc incorrect in 2008 - 600578

On Wed, 2008-09-03 at 12:38 -0700, Richard Guthrie wrote:
> Andrew,
>
> I have completed my research on LsarSetSecret.  The documentation
> provides information when you have an exception case such as when one
> updates EncryptedCurrentValue.  I have included a scenario that might
> help clarify the behavior:
>
> Scenario:
> I have a secret object with old and new secret values set and both
> have timestamps indicating when the values were last updated/set.  I
> then make a call to LsarSetSecret passing in null for new secret value
> and a value I choose for old secret value.
>
> This will null out the new secret value and update the old secret
> value.  I should also observe that the timestamps for both old/new
> secret values would be set to current server time.  The table you
> reference shows this to be the behavior.

Indeed it does.  Did this table change from it's original description?
As it stands, the format is confusing because of the way the operations are linked but also independent.

A table with headings
New value | Old Value | Effect on old time | effect on new time would be more clear, or as they are (almost) independent operations, describe them as such.

> However, tests against Window 2008 show that setting the old value
> (but not the new) removes the new value, and sets the time to 'current
> server time'

Perhaps however you should note the change in behaviour since windows 2003?  Perhaps run RPC-LSA from our GIT tree to see the changes.

(It seems the NULL behaviour changed from 'don't change' to 'remove' in some cases).

Thanks,

Andrew Bartlett

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