Migrating Accounts from LDAP with Encrypted Passwords

[andreychek]

Howdy,

I see from this following post what one might do to migrate to Zimbra, if one has data in LDAP that includes plaintext passwords:

Import users from other LDAP directory?

I'm not so lucky though, my LDAP passwords are in 'crypt' format. If I fire up my LDAP browser, and look at the passwords, they look like one of:

userPassword: {crypt}PR4rUd/wJ9a4
userPassword: {crypt}$1$28HtH18x$S.YXvaGjIBVnZYNEjRA481d

(just because someone is bound to wonder... I copied those password strings in directly, but changed a few characters around :-)

Now, since that's what shows up in my LDAP browser, I figured I could pass them into zmprov:

zmprov SetPassword myuser@zimbra.mydomain.com '{crypt}PR4rUd/wJ9a4'

But no, while it accepts the string, I can't log in with the password I'd expect. Of course, after running SetPassword with a plaintext password, I can log in just fine.

So, any hints on how one might migrate accounts from an LDAP setup where the passwords are not stored in plaintext?

Thanks!
-Eric

[schemers]

zmprov setPassword (or create account, for that matter) is just going to take that string and use it as the actual password, which obviously isn't what you want.

There is a way to do what you want, but it isn't all that pretty

You could:

1. create all the users Zimbra (random passwords are fine)
2. using LDAP utils (ldapmodify, etc) replace the userPassword attribute with your crypt version
3. Configure Zimbra to use an external LDAP server for authentication, but then point it back to itself. This will cause it to do an LDAP bind on authentication, which will then work with the crypt'd password. If you don't configure to this way, we skip the bind step and just do the SSHA compare internally (as an optimization).

If anyone changes their password from within Zimbra, the {crypt} version will be replaced with {SSHA} version, which may or may not be what you want.

Another option if you go this route is to require people to change their passwords on first login (fixed in next release), which will upgrade everyone to SSHA eventually, at which point you can just use internal auth again.

roland

[andreychek]

Originally Posted by schemers

There is a way to do what you want, but it isn't all that pretty

Well, yeah, that's not too pretty, but I do think it'll work :-)

Originally Posted by schemers

Another option if you go this route is to require people to change their passwords on first login (fixed in next release), which will upgrade everyone to SSHA eventually, at which point you can just use internal auth again.

Okay, here's a question --

I'd say around 75% of our users aren't going to be using the web interface, they'll just be checking their email from work using Outlook.

Assuming, for the moment, that we are not using the Zimbra Outlook Connector, just Outlook via POP or IMAP... how would Outlook handle this if Zimbra forced it to change the password?

Is Outlook smart enough to just prompt the user for a new email password? And if so, do you recall if they have to know their existing password when they enter a new one?

I know this sounds silly, but the users don't know their existing email passwords. Remember, 75% of them just open Outlook and expect their email to show up :-) So, the goal would be to find a way to change them all without anyone knowing the old password (except for Outlook, of course, who has the password stored).

Barring that, we could just keep doing the LDAP bind. Is the bind performed purely for authentication? I guess I'm wondering how much a performance hit that'll be.

Thanks for your insight,
-Eric

[schemers]

yeah, I don't think the outlook connector handles "must change" password errors at login. I'll ask around.

It really shouldn't be a performance issue to bind on logins. We just didn't have to internally since we already did the read to get the LDAP entry and we have the userPassword attr sitting there. If we supported {crypt} we could avoid the bind as well. Should be fairly trivial to do.

roland