Considerations around the Forgot Password feature.

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
Post Reply
User avatar
gabrieles
Outstanding Member
Outstanding Member
Posts: 233
Joined: Tue Feb 14, 2017 9:40 am

Considerations around the Forgot Password feature.

Post by gabrieles »

Hi all, here some considerations around the new Forgot Password feature.

Based on the docs (https://zdocs.github.io/curie/fp.html), the feature shoud be available for the domain "@mydomain.com" under these conditions:
-domain mydomain.com has zimbraFeatureResetPasswordStatus attribute = enabled
-domain mydomain.com has zimbraAuthMech = local

First of all shoud be specified a third condition:
-domain mydomain.com has a zimbraVirtualHostname, e.g. webmail.mydomain.com (...OR mydomain.com is the default domain)
Ok if you have a single server, single domain installation. But if you have two domains on the same server, one with reset password enabled, and another disabled you must have a way to discriminate them, and this is done via virtual hostname. It works, and well, but the docs don't mention it.

Then the bad thing, the zimbraAuthMech == local does not work, even in the docs is said:
"This forgot password link will be disabled if external authentication is used. If the recovery email is not set, the user will get an error message to contact the Administrator."

Using zimbraAuthMech = ldap for mydomain.com and pointing the authentication on another test machine with ldap on it, the feature has not been disabled.
When the user asks for a password recovery, the security code will be shipped to the safe email and the user could select if continue with session or change the password.
The first case (continue with session) is less dangerous and only in case of MITM, so let's ignore it.
In the second case (change password) obviously the pwd will not be changed on the remote ldap/AD, but will be changed LOCALLY. This is dangerous if the domain has zimbraAuthFallbackToLocal = true, because actually the same user can log in with two passwords, the old one, and the new set up password.

Test conducted on ZCS 8.8.9 and 8.8.10

Any thoughts?
User avatar
L. Mark Stone
Ambassador
Ambassador
Posts: 2796
Joined: Wed Oct 09, 2013 11:35 am
Location: Portland, Maine, US
ZCS/ZD Version: 10.0.6 Network Edition
Contact:

Re: Considerations around the Forgot Password feature.

Post by L. Mark Stone »

I agree the documentation around virtual hostnames needs improving; it's leftover from when installing proxy was prohibited on single-server installations.

zimbraAuthMech to my understanding is never set just on its own. Two additional domain attributes are required for the external mechanism: zimbraAuthLdapURL and zimbraAuthLdapBindDn. You don't say explicitly that you set those two variables (may that's what you did when you say "...pointing the authentication on another test machine with ldap on it").

May I suggest using the Admin Console to configure domain authentication on your test system, and if you get the same results, then open a Support Case with Zimbra. The Wizard includes a "TEST" button, so you can make sure Zimbra can actually talk to the third-party authentication system with a specific user to auth.

If you set all three variables by hand but set zimbraAuthLdapURL and zimbraAuthLdapBindDn incorrectly (or the third-party LDAP isn't available), and zimbraAuthFallbackToLocal = true, then it is correct that the user should be able to use and change their Zimbra LDAP password, else how would they be able to log in otherwise.

If you had set zimbraAuthFallbackToLocal = false, third-party LDAP wasn't available (or didn't auth the user), then the user should not be able to change nor use the Zimbra password stored in Zimbra's LDAP.

FWIW, for a Zimbra domain that is converting to AD auth, I often set zimbraAuthFallbackToLocal = true for a while to ensure that everyone in all the branch offices can log in OK if there is a problem with a branch communicating with the domain controllers. Once we are satisfied the VPNs and other network connectivity is reliable enough, then we change zimbraAuthFallbackToLocal = false to force everyone to use AD auth only.

Hope that helps,
Mark
___________________________________
L. Mark Stone
Mission Critical Email - Zimbra VAR/BSP/Training Partner https://www.missioncriticalemail.com/
AWS Certified Solutions Architect-Associate
User avatar
gabrieles
Outstanding Member
Outstanding Member
Posts: 233
Joined: Tue Feb 14, 2017 9:40 am

Re: Considerations around the Forgot Password feature.

Post by gabrieles »

Were just some considerations..
zimbraAuthLdapURL and zimbraAuthLdapBindDn. You don't say explicitly that you set those two variables.
Yes, actually set a complete, tested and working external ldap authentication against another zimbra server. I did'nt want to write a poem.
May I suggest using the Admin Console [...] The Wizard includes a "TEST" button, so you can make sure Zimbra can actually talk
In a first step I set up a fake connection, but I had the same doubt and then set a real external auth. The TEST was successful, and the user authentication too.
Tests have been done several times via CLI and via Admin Console, results are the same.
User avatar
L. Mark Stone
Ambassador
Ambassador
Posts: 2796
Joined: Wed Oct 09, 2013 11:35 am
Location: Portland, Maine, US
ZCS/ZD Version: 10.0.6 Network Edition
Contact:

Re: Considerations around the Forgot Password feature.

Post by L. Mark Stone »

gabrieles wrote:Were just some considerations..
zimbraAuthLdapURL and zimbraAuthLdapBindDn. You don't say explicitly that you set those two variables.
Yes, actually set a complete, tested and working external ldap authentication against another zimbra server. I did'nt want to write a poem.
May I suggest using the Admin Console [...] The Wizard includes a "TEST" button, so you can make sure Zimbra can actually talk
In a first step I set up a fake connection, but I had the same doubt and then set a real external auth. The TEST was successful, and the user authentication too.
Tests have been done several times via CLI and via Admin Console, results are the same.
So do you still have your concern that something is broken with Zimbra for which you should open a Support Case?

Because it seems to me that the fallback auth is working as intended, and you have the capability to turn it off if you wish. (Just trying to bring closure to this thread...)

All the best,
Mark
___________________________________
L. Mark Stone
Mission Critical Email - Zimbra VAR/BSP/Training Partner https://www.missioncriticalemail.com/
AWS Certified Solutions Architect-Associate
Post Reply