I get 'The system cannot find the file specified' when trying to call LsaRetrievePrivateData to retrieve a DCOM user password. Calling LsaStorePrivateData for a DCOM user creates a second entry in LSA rather than updating the current entry. Primarily I want this functionality to automate the setting of DCOM passwords.
ActivePython 2.5.2.2 (ActiveState Software Inc.) based on
Python 2.5.2 (r252:60911, Mar 27 2008, 17:57:18) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import win32security
>>> handle= win32security.LsaOpenPolicy(None, win32security.POLICY_GET_PRIVATE_INFORMATION)
>>> win32security.LsaRetrievePrivateData(handle, 'SCM:{73FDDC80-AEA9-101A-98A7-00AA00374959}')
File "<stdin>", line 1, in <module>
pywintypes.error: (2, 'LsaRetrievePrivateData', 'The system cannot find the file specified.')
Where {73FDDC80-AEA9-101A-98A7-00AA00374959} is a valid AppId which does have a RunAs password set. If I use the SrvcMgmt.cpp sample Microsoft mention in the KB article below, I can successfully read the password. If I modify win32security and recompile, I can successfully read the password.
This appears to be a Microsoft shortcoming: http://support.microsoft.com/kb/259615 whereby the NULL terminator must be included when calculating the length of the keyname - the behaviour seems inconsistent.
Reading the KB arcticle, it sounds like this only applies to LsaRetrievePrivateData / LsaStorePrivateData, whereas win32security uses the function PyWinObject_AsLSA_UNICODE_STRING which is used more widely.
More confusing still, trying to retrieve $MACHINE.ACC from LSA works if length doesn't include the NULL terminator (the way win32security currently does it), but fails if length does include the NULL - so the behaviour is different depending on which passwords you are trying to access.
Manually adding a null to the end of the key seems to work for me, ie use
'SCM:{73FDDC80-AEA9-101A-98A7-00AA00374959}\0'