Migrating accounts/users from passwd/shadow file?

[dealt]

Greetings! How can i migrate user accounts from passwd/shadow file? Thanks

[KevinH]

You'd need to write a script that call our zmprov commnad line tool. We don't provide automatic migration of /etc/passwd today.

[dealt]

Yep. A perl script that parses passwd file is easy. Im troubled with how zmprov accepts password. I tried executing zmprov with:

zmprov ca joe@mydomain.com crypt{<crypted_text_from_shadow_file>}

but it seems that it doesnt understand 'crypt'-ing my entered password

Please enlighten me with this. Thanks

[schemers]

The password you pass into zmprov is itself turned into a salted-SHA password {SSHA}.

We can do what you want, but it is tricky today:

(1) you'd have to create the accounts first, with a random password

(2) you'd have to then modify all the LDAP zimbraAccount entries and change the userPassword attribute to be the "{crypt}...." form.

(3) you'd have to configure the domain to use external LDAP authentication, and point it back at the LDAP server. The reason being when we auth internally against our openldap, we don't bind, we already have the userPassword attr value, so we compute the SSHA of the cleartext password and compare.

There are other issues, like when you change passwords we would "upgrade" the password to SSHA, etc.

We can file a feature request to be more flexible to allow existing password encodings to be migrated into the Zimbra system.

roland

[schemers]

I've just fixed this (bug 7691). If the password in OpenLDAP isn't in SSHA format, we'll fallback to binding to our OpenLDAP server as the user trying to login, so all the passwords that OpenLDAP supports should work (CRYPT, MD5, etc).

When passwords are changed via the web (you can mark a password as "must change" in the admin console, and the useer must change it at next login) they will get promoted to SSHA.

[claros]

I've just fixed this (bug 7691). If the password in OpenLDAP isn't in SSHA format, we'll fallback to binding to our OpenLDAP server as the user trying to login, so all the passwords that OpenLDAP supports should work (CRYPT, MD5, etc).

When passwords are changed via the web (you can mark a password as "must change" in the admin console, and the useer must change it at next login) they will get promoted to SSHA.

Ciao Roland,

Simply I've not understand what to do to import an RH9 /etc/shadow file into zimbra ldap password: using zmprov and viewing the ldap db, it seem tha stored password are an SSHA hash of the CRYPT pwd.
I'm using the last release build, 3.1.4 June 27, 2006.

Thanks,
Claudio

[KevinH]

Ciao Roland,

Simply I've not understand what to do to import an RH9 /etc/shadow file into zimbra ldap password: using zmprov and viewing the ldap db, it seem tha stored password are an SSHA hash of the CRYPT pwd.
I'm using the last release build, 3.1.4 June 27, 2006.

Thanks,
Claudio

See the 3rd comment. Just copy the text into a zmprov command.

[schemers]

Doing what is suggested in comment #3 doesn't work, since the server takes that value as the cleartext password and runs it through SSHA.

The best option is to create the accounts with "" as the password (it actually gives them no password), and then use ldapmodify to explicitely set the "userPassword" attr to be the crypt'd version.

[dijichi2]

#2 would be great, but zmprov says userPassword is immutable

its much easier to write single line: ma <email> userPassword <hash>, than write multi line ldapmodify files where you also have to determine the each dn.

will zmprov ca not accept password hash if prefixed with {crypt} or is there some way of making userPassword, err.., mutable?

being able to do this is a nice feature, as it means that passwords can be migrated over from many other installs from wide variety of email systems.

[bewley]

This seems to work now in my 4.5.3 NE. Copy the hash out of the shadow file and prefix it with '{crypt}'.

zmprov ma user@domain userPassword '{crypt}$1$dblahblahstuff....'