I have a user who had her desktop replaced. We migrated her from XP to 7. She can no longer open her database, which is on her network drive. KeePass is also run from the network drive and a master password and Windows authentication is required by policy. I am aware of the article here: http://keepass.info/help/base/keys.html#winuser, which warns about the user account being deleted; however, her account is the same. It has not been reset in any way. What could be the issue?
I don't have any experience with this, but since no one else has replied, I will give it a go.
Is this a local user account or a domain account? Either way, you probably need to read up on some of the links from the article that you referenced.
Or, if you still have access to the old desktop, you could export the data or synchronize it with a new database that has a master password only, then on the new desktop, create a new database and import or synchronize to get the data into the new database.
Changing domain computers will not transfer the Windows keys - it may do if you use roaming profiles. Returning to the original computer will allow you to open the database and change the key.
Thanks for the replies, gentlemen.
Paul, I was careful to read the documentation when I put this together. The documentation clearly implies that as long as the account isn't deleted, then access to the database should be possible. I think it should be updated to clarify that in a domain environment, this is not the case. The domain account hasn't changed a bit, but if I am understanding you correctly, there is a machine dependency. Is this correct?
The keys are created under the local user file structure and this is usually machine specific.
The summary on this page has "known issues" that may be useful.
In your case you can use the old computer if the user account still exists, regardless of domain.
Thank you. I understand the technical parts behind this.
The issue is that the documentation leads one to believe that only the user account is a factor in accessing the database. I am now finding out that this is not correct. When I deployed this tool in my company, I was clear to think about and test the failure scenarios. We changed and reset user account passwords, and transferred the database to a non-domain (home computer). All of these tests passed. But we did not test accessing the database by the same user on another domain system, due to the information provided in the documentation. It would be nice to see this corrected so that no one else has to lose access to their database unnecessarily.
The documentation is clear about the requirement for the user's DPAPI keys and warns against relying on this mechanism.
"KeePass can make the database dependent on the current Windows user account. If you enable this option, you can only open the database when you are logged in as the same Windows user when creating the database."
Check. She was logged in as the same user.
"Be very careful with using this option. If your Windows user account gets deleted, you won't be able to open your KeePass database anymore. Also, when using this option at home and your computer breaks (hard disk damaged), it is not enough to just create a new Windows account on the new installation with the same name and password; you need to copy the complete account (i.e. SID, ...). This is not a simple task, so if you don't know how to do this, it is highly recommended that you don't enable this option. Instructions on how to restore a backed up account can be found in a Microsoft TechNet article: How to recover a Vault corrupted by lost DPAPI keys."
The account was not deleted. It's the same account and the same SID.
The documentation is decidedly NOT clear that using the same account within a domain is not sufficient and that there is a machine dependency.
I have reported the issue and it is here for others to stumble across when they lose access to their databases. It's unfortunate that the documentation will not be updated to correct this. I see no reason to keep this discussion going. Thanks for taking the time to respond.