[SOLVED] Migrate to Zimbra from iPlanet 5.2

[ple]

Hi,
I'm testing the new Zimbra server (5.0.11_GA_2695.RHEL5_20081117020711). We'd like to migrate over 2000 accounts from iPlanet email sever without resetting their passwords. I've look at imapsync and a few others but still can't figure out the best way NOT to reset their passwords in order to complete the migration. Currently, users authenticate to the Sun LDAP server. I could make Zimbra to authenticate to the same LDAP server but unsure what to do next.
All feedbacks and suggestions are greatly appreciated.
Thanks.
Phil

[fowler]

User Migration - Zimbra :: Wiki

This will fall into the "all feedback" category. Assuming the password must be changed, you could:

1. query the 'userpassword' attribute of the users dn and save it.
2. ldapmodify the user's password with a known one.
3. perform the imapsync.
4. query the 'userpassword' again, in case the EU changed it during migration
5. restore the user's password with a final ldapmodify, using the value from 1 or 4

[ple]

Thanks for responding. Apparently the password is encrypted in the binary (46b) format. How do you change this type of password?
Thanks.

[fowler]

You will need to know what the encrypted/hashed password looks like for comparing, but you will not need to decrypt it.

An ldapmodify can change the password. If clear text is used, it will default to whatever encryption your directory server is set to (see: cn=Password Policy,cn=config). If the default is set to ssha, it might look like this:

ldapmodify -h abc.host.com -D ...
dn: uid=someuser,ou=accounting,dc=host,dc=com
changetype: modify
replace: userpassword
userpassword: migrateme

ldapsearch <<options>> uid=someuser userpassword
userpassword: {SSHA}c7LzEqO7fHIFTCUpkcj8bKmDEZyuNAhI5jxRJA==

If you ldapmodify a password and precede the value with {CRYPT} or {SSHA}, it will not encrypt/hash the value provided.

ldapmodify -h abc.host.com -D ...
dn: uid=someuser,ou=accounting,dc=host,dc=com
changetype: modify
replace: userpassword
userpassword: {SSHA}c7LzEqO7fHIFTCUpkcj8bKmDEZyuNAhI5jxRJA==

good luck.

[ple]

Thanks for taking your time to respond. Can you further explain your previous post? I'm still a bit confused with this (If you ldapmodify a password and precede the value with {CRYPT} or {SSHA}, it will not encrypt/hash the value provided.) part. Also, do you have a script that do ldapmodify for lots of users?
Thanks.
PL

[fowler]

Net::LDAP with imapsync ?
Net::LDAP - Lightweight Directory Access Protocol - search.cpan.org

Another method might involve generating an LDIF file to describe your changes and running ldapmodify against it.
http://tldp.org/HOWTO/LDAP-HOWTO/utilities.html

(If you ldapmodify a password and precede the value with {CRYPT} or {SSHA}, it will not encrypt/hash the value provided.)

If you are comparing passwords, you will need to know what the encrypted/hashed password looks like, for instance:
{CRYPT}103Ld3rC9IOzs == secret123

then you could ldapmodify the password as
dn: uid=someuser....
changetype: modify
replace: userpassword
userpassword: {CRYPT}103Ld3rC9IOzs

When you later search on the directory entry's password, the value returned should look like {CRYPT}103Ld3rC9IOzs

If you did not precede the password with {CRYPT} then the modify would encrypt it again:

dn: uid=someuser....
changetype: modify
replace: userpassword
userpassword: 103Ld3rC9IOzs

Which might end up being:
dn: uid=someuser....
userpassword: {CRYPT}47cA/2SSvmsoo

{CRYPT}47cA/2SSvmsoo == 103Ld3rC9IOzs != secret123

Experiment with ldapmodify to validate your results.

OpenLDAP Faq-O-Matic: Passwords