I don't think you gain any special advantages by encrypting (or not) in a slapd.conf context versus any other encryption application. Like most password encryption, it largely boils down to speed bumps in the face of a preexisting access vector.
Keep in mind that you can run slapd(8) entirely without a rootdn/rootpw, either by initializing your directory with slapadd(8) offline or by setting a rootpw for some short period of time and then removing it once a sufficiently populated DIT is present to allow the desired access rules. In this case the only thing you lose is the ability to override ACLs. Many sites do not want such an ability, and purposefully keep off rootdn toward that goal.
On Tue, 13 Nov 2007, Peter Clark wrote:
Heh, thanks for the warning about the rootpw. I used an example of one from the internet. :)
If you cannot supply an encrypted password in the credentials= field and you have both the rootpw= and credentials= visible in the slapd.conf does it serve any purpose for encrypting the rootpw in the slapd.conf? Or is there another purpose to encrypting it other than to stop someone from parsing the file and getting it?
I hope that makes sense.
Thanks again, Peter Clark