Change password in AD still allows login (ZCS 4.0.5 GA 518)

[jameztcc]

Hi,

I setup a domain to use external AD auth. It seemed that whenever I change the password of an AD user (using AD to change and not Zimbra), I can login using the NEW and the PREVIOUS password. Is this a bug and how can I workaround it?

1.0 Expected behaviour:
.1 Should only allow the latest changed password to login.

2.0 Steps to reproduce:
.1 Create user = tester in AD
.2 Assign e.g. password = abc123
.3 Login via Zimbra Web UI as tester, abc123

.4 Change password ==> cde456 (Do this using AD).
.5 Login via Zimbra Web UI as tester, abc123 [Able to log in!]
.6 Login via Zimbra Web UI as tester, cde456 [Able to log in - expected behaviour]

.7 Change password ==> fgh789 (Do this using AD).
.8 Login via Zimbra Web UI as tester, abc123 [Cannot log in - expected behaviour]
.9 Login via Zimbra Web UI as tester, cde456 [Able to log in!]
.10 Login via Zimbra Web UI as tester, fgh789[Able to log in - expected behaviour]


3.0 Configurations:
.1 zcs 4.0.5 GA 518 (x86)
.2 rhel es 4



thanks for any reply.
James

[Rich Graves]

phoenix, he's not asking about syncing passwords; he is authenticating to AD "live" via LDAP. His problem is that a bind to AD returns success for an old password.

Believe it or not, this is actually the intended behavior of Active Directory. See Windows Server 2003 Service Pack 1 modifies NTLM network authentication behavior and NTLM Authentication: Old Password Usable After Password Changed - CA Security Advisor Research Blog - CA

Microsoft Windows Server 2003 Service Pack 1 (SP1) modifies NTLM network authentication behavior. After you install Windows Server 2003 SP1, domain users can use their old password to access the network for one hour after the password is changed.

[mmorse]

I think he's trying to say the opposite, that the last 2 passwords are caching somewhere in AD for a short amount of time - have you checked to see if there's an AD setting for this?
BTW it's time to update zimbra to 4.5.10

[mmorse]

There we go, what Rich said ^ wait more than an hour and then test.

[mmorse]

Just curious is there a reason that you're still on 4.0.5? Like a platform no longer supported or something? From this thread back in september you asked if you should upgrade to 4.5.7 to fix the large log file issue... logswatch.out and zmlogger.out BIG!
(which has definitely proven fixed in 4.5.7 > [SOLVED] running a version 4.5.6 or prior? Prevent Large Log File)
Be sure to make a good backup!