There's a minor discrepancy between Windows and Samba behaviour when pwdHistoryLength has been previously set to zero in the past. If pwdHistoryLength is increased, Windows will reject password changes where the user enters their current password as the new password. Whereas Samba will allow this, for the first password change.

Reproduction:
1. set the domain's pwdHistoryLength to zero.
2. add a user (or just set its password).
3. set the domain's pwdHistoryLength to a non-zero value, e.g. 1, 24, etc.
4. try to change the user's password to the exact same password as in step 2. Windows rejects this, but Samba allows it. 

If you change the user's password to something unique, and then try to set it to the exact same value again, then both Samba and Windows will reject this.

The difference in behaviour seems to be that Samba only updates the user's password history upon password changes. Whereas Windows is somehow tracking the user's current password, even though pwdHistoryLength is zero.

I've added a test-case to demonstrate this behaviour (test_domain_pwd_history_zero in ldap.password_settings - code is still pending delivery).

This seems like an unusual corner-case that users wouldn't really care about. However, it might be a simple 'first bug' for someone new to Samba development.