|
If admin is allowed to to read the password, why shouldn't s/he be allowed to dump them? If passwords are stored as hash value (DIREVE-286), it is at least not that easy to guess them. For a disaster recovery scenario, complete db content has more value.
We have to be really aware of how ldap could be use : for instance, as the centralized user/password authentication system on unix, as a replacement of the classic user/password based on /etc/passwd. You can read an encrypted version of a password, but you won't be able to 'know' this password. This is what I meant by my comment, which was not really clear.
So, dumping the password in a ldif file might be an option, but I just wanted to point out the fact that we may have critical informations in it, that we would not want to expose. In a disaster recovery scenario, obvously, a backup is better. At least, if we use a ldif file, we could just skip the password, because users could always create a new one (this is a critical information, but we can loose it ;) So I really think that this tool is usefull, but I also think we should avoid to dump clear passwords. For encrypted ones, that's another question. wdyt ? A rough dump tool was committed in revision 369946 here. The tool stinks as is and will dump a simple ldif of the partition contents. It needs some work but this can be done any time here's what I'd like to see done to/for it:
* Let's refactor it as a POJO and have a main to run it. * Make main use some commandline option processing toolkit. * Add usage message. * Add option to filter out some attributes (operational ones for example) * IMPORTANT: Add fault tolerance so it does not fail fast. Right now it bombs on an exception. If an entry cannot be extracted then we can note this. We need to handle failures and continue to dump. Here's that commit ... again this just a code drop of how to build a tool someone really needs to write this thing properly. For now it works minimally and satisfies this request.
http://svn.apache.org/viewcvs.cgi?rev=369946&view=rev Oh more TODOs: * logging * should use the updn index to pull from master table instead since this index is simpler and can tell us if an entry cannot be found in the master table * update tool to do more and change its name. some possibilities are: - rebuild indices - scrub partition for deleted entries - compact it (defrag) Emmanuel note that if we add options to filter certain attributes when dumping the LDIF then the administrator can make the call and not us. Give the admiin full power I say and provide the optional switches to filter for convenience.
|
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Critical
Need a dump tool to extract LDIF from JDBM database
What about passwords? I think we should not dump them...