Root password cannot start with curly braces such as "{something}password" because it will be incorrectly interpreted as encryption scheme. Steps to reproduce: 1. Create an .inf file with the following line: RootDNPwd={something}password 2. Use the .inf file with setup-ds.pl to create DS instance. Actual results: The resulting dse.ldif will contain an empty nsslapd-rootpw attribute. Expected results: The tool should not try to interpret the curly braces in the password and generate the correct hash value in nsslapd-rootpw.
The problem also happens when the curly braces is located in the middle of the password: "password{something}password".
Correction to the actual results: Password that contains matching curly braces in any location will be stored as is in the nsslapd-rootpw. Based on the existing code and discussion with Rich, the expected behavior should be: - If the password begins with matching curly braces it indicates that the password is already encrypted and should be stored as is in the nsslapd-rootpw. - If the password does not begin with matching curly braces (it may contain curly braces in other location) it indicates that it is a clear text password and should be encrypted before storing in the nsslapd-rootpw.
Created attachment 398976 [details] 0001-Bug-570542-Root-password-cannot-contain-matching-cur.patch Proposed patch.
This behavior should be documented properly to avoid confusions.
To ssh://git.fedorahosted.org/git/389/ds.git 7701c56..be17b93 master -> master commit be17b937b06eeb0822189951a6f63cfb87749e32 Author: Endi S. Dewata <edewata> Date: Tue Mar 9 15:58:40 2010 -0600
Hi Rich, Did we document the expected behaviour mentioned in comment#3 somewhere? If not, should I go ahead and open a doc bug? ================================================================================ And I got this while giving {amita}sharma as password for cn=Directory Manager : ============================================================================== The interactive phase is complete. The script will now set up your servers. Enter No or go Back if you want to change something. Are you ready to set up your servers? [yes]: yes Creating directory server . . . Could not import LDIF file '/tmp/ldifF_eQ7o.ldif'. Error: 256. Output: importing data ... [27/Jul/2011:19:01:29 +051800] dse - The entry cn=config in file /etc/dirsrv/slapd-amsharma1/dse.ldif is invalid, error code -9 (Bad parameter to an ldap routine) - nsslapd-rootpw: password scheme mismatch (passwd scheme is SSHA; password is clear text) [27/Jul/2011:19:01:29 +051800] dse - Could not load config file [dse.ldif] [27/Jul/2011:19:01:29 +051800] dse - Please edit the file to correct the reported problems and then restart the server. Error: Could not create directory server instance 'amsharma1'. Exiting . . . ================================================================================ sharma{amita}sharma as password for cn=Directory Manager is working fine. ================================================================================ Please guide.
This is the correct behavior. I do not know if we document this behavior. The documentation should read something like this: "When entering the Directory Manager password in setup-ds.pl or setup-ds-admin.pl, if you specify a string like this: {something}something that is, if you specify an open curly brace, followed by some text, followed by a close curly brace, followed by some text, the setup program will interpret this as a pre-hashed password, with the password hashing scheme enclosed in the curly braces. If this is not a valid hashing scheme, or the password is not correctly hashed, the server will generate errors upon startup, or you will not be able to bind to the directory server as the directory manager."
ok, thanks Rich. I have checked the docs and did not find this information, So I have opened a new doc bug - https://bugzilla.redhat.com/show_bug.cgi?id=726302 I am marking this bug as VERIFIED based on comment#8.
This fix was included long ago in 389-ds-base-1.2.6. Closing this out.