On 7/7/05, Rich Megginson <rmeggins at redhat.com> wrote: > Sam Tran wrote: > On 7/7/05, Sam Tran <stlist at gmail.com> wrote: > > > On 7/7/05, Rich Megginson <rmeggins at redhat.com> wrote: > > > Sam Tran wrote: > On 7/7/05, Rich Megginson <rmeggins at redhat.com> wrote: > > > Sam Tran wrote: > > > > Hi all, > > I compiled FDS from the latest sources. > > I migrated a user entry from OpenLDAP to FDS as a test. For that user > entry I tried different password hash schemes for the userPassword > attribute and checked if it was successfully migrated to FDS. Here are > the results: > > > > Did you run this script first - > http://www.directory.fedora.redhat.com/download/openLDAP2Fedora.pl > - to > migrate the data that used MD5 passwords? > > > > {CRYPT} --> OK > (MD5} --> FAILED > {SMD5} --> FAILED > {MD5CRYPT} --> OK > {SHA} --> OK > {SSHA} --> OK > > I thought that FDS supported MD5 password hash. Did I miss something? > > > > Not sure. I would have expected {MD5} to work but not {MD5CRYPT}. See > above. > > > > Thanks in advance. > > Sam > > > You should not need to run this script to do the migration. This > script just Base64 decodes the userPassword attribute and puts it in > the form {HASH}xxxxxxxx. FDS apparently understands the Base64 encoded > version of the password. > > For SHA, SSHA, CRYPT and MD5CRYPT I didn't use this script and the > migration was successful. For MD5 I tried without and with the script: > it was unsuccessful in both cases. > > This is really bizarre, because MD5CRYPT should not work at all - it is not > supported by FDS. The only thing I can think is that it is interpreting the > value as clear text. > > How did you verify that the migration was successful? > > Sam > > > I simply did a ldapsearch with a binddn: > ./ldapsearch -h localhost -b "dc=example,dc=com" -D > "uid=joesmith,ou=people,dc=example,dc=com" -w - > "objectclass=*" > > I create a new user in FDS with a password I generated using this python > module: > http://www.sabren.net/code/python/crypt/index.php3 > > The hash is MD5CRYPT. And it worked. > > Try for yourself. > > Don't forget to prepend {CRYPT} to the generated password. > > Ah hah. That's why it works. But in FDS, {CRYPT} is not the same as MD5 > crypt - FDS crypt uses the old unix crypt that used to be the standard for > Solaris /etc/passwd and /etc/shadow (and other OSes). > > dirving, any clues as to why {MD5} doesn't work? > Rich, I believe that {CRYPT} in FDS or OpenLDAP use the system crypt(3) function. Please read this pages: http://www.openldap.org/faq/data/cache/344.html http://www.openldap.org/faq/data/cache/1041.html The second page says: "Newer Unix systems also support other password hash algorithms including MD5 and DES-based hashing with longer than 8 significant password characters." When I do a "man crypt" on my Debian box I have the following: [snip] GNU EXTENSION The glibc2 version of this function has the following additional features. If salt is a character string starting with the three characters "$1$" followed by at most eight characters, and optionally terminated by "$", then instead of using the DES machine, the glibc crypt function uses an MD5-based algorithm, and outputs up to 34 bytes, namely "$1$<string>$", where "<string>" stands for the up to 8 characters following "$1$" in the salt, followed by 22 bytes chosen from the set [a-zA-Z0-9./]. The entire key is significant here (instead of only the first 8 bytes). [snip] The bottom line is that if your system crypt() function supports MD5-based algorithm, your FDS should support MD5CRYPT. In the userPassword attribute, you would see {CRYPT}$1<string> for a "MD5CRYPT" hashed password. I am sorry if I confused you with the {MD5CRYPT} naming; it is actually a particular type of {CRYPT} hashing scheme. Still don't know what {MD5} does not work ... Thanks. Sam
