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. Please let us know if you have further questions regarding this issue. 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-05A82B88383E&start=1&interval=10&SortCol=DatePosted -----Original Message----- From: Andrew Bartlett [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2008 7:01 PM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Secret 'last set times' doc incorrect in 2008 In MS-LSAD 3.1.4.6.3 LsarSetSecret it states that: The server MUST also maintain "time stamp" values for current and old values of the secret object. The following table lists the rules by which the time stamps are computed. Value Effect on old time Effect on new time Old secret value NULL Old value of "new secret time" Not applicable Old secret value Non-NULL Current server time Not applicable New secret value NULL Not applicable Current server time New secret value Non-NULL Not applicable Current server time 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' Please update the docs, Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
