Results 1 to 4 of 4

Thread: Migrating Accounts from LDAP with Encrypted Passwords

Hybrid View

  1. #1
    Join Date
    Oct 2005
    Location
    Harrisburg, Pennsylvania
    Posts
    155
    Rep Power
    10

    Default Migrating Accounts from LDAP with Encrypted Passwords

    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:

    http://www.zimbra.com/forums/showthr...highlight=ldap

    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

  2. #2
    Join Date
    Aug 2005
    Posts
    228
    Rep Power
    10

    Default

    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

  3. #3
    Join Date
    Oct 2005
    Location
    Harrisburg, Pennsylvania
    Posts
    155
    Rep Power
    10

    Default

    Quote 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 :-)

    Quote 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

  4. #4
    Join Date
    Aug 2005
    Posts
    228
    Rep Power
    10

    Default

    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

Similar Threads

  1. Zimbra Install Problem - getDirectContext
    By bsimzer in forum Installation
    Replies: 27
    Last Post: 07-19-2007, 11:12 AM
  2. 3 testing: LDAP: 389 Failed when restore zimbra
    By victorLeong in forum Administrators
    Replies: 15
    Last Post: 05-24-2007, 07:45 AM
  3. Mac OSX install: Java errors & LDAP CA error
    By jefbear in forum Installation
    Replies: 9
    Last Post: 12-16-2006, 03:39 PM
  4. Replies: 4
    Last Post: 11-15-2006, 12:16 PM
  5. Migrating Accounts from LDAP with {crypt} Passwords
    By shanson in forum Administrators
    Replies: 3
    Last Post: 03-11-2006, 04:09 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •