Description of problem: When a changelog is enabled and a userPassword is modified, both the hash and the cleartext are logged for winsync's benefit: change:: replace: userPassword userPassword: {SSHA}vqtiN2LHdrEUOJUKu+IBVqAVFsAlvFw+11kD/Q== - replace: unhashed#user#password unhashed#user#password: secret12 The change (including the cleartext password) is sent to replicas (where the cleartext password is actually ignored, see #182507). We should probably require that MMR is configured with SSL if passwords are sent in the clear. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Configure two replicas with MMR, M1 and M2. 2.Change a userPassword in M2. Actual results: Expected results: Additional info:
The "unhashed#user#password" value is also stored in plain text in the replication changelog under /opt/fedora-ds/slapd-<instance>/changelogdb/ .
We are working to address this issue in the upcoming RHDS 7.2 release. The fix will also go into the next version of Fedora DS.
Yes, by being changelogged is how it ends up getting replayed to replicas. Rich, without unhashed#user#password it's not possible to write password policy plugins since the userPassword is already hashed when MOD pre-op is called so you're not taking it out I guess. Is the fix to skip it for changelogging?
Yes. I think the fix will involve these things: 1) Do not store unhashed#user#password in the changelog or send it over the wire 2) Disable password syntax checking and password policy for replicated changes Note that if using Digest MD5 for authentication, you must store the clear text password in the database, in the userPassword attribute.
Note that with RHDS 8.0.0-14 and later, you can use fractional replication to exclude that attribute.
revisit in 8.2
Upstream ticket: https://fedorahosted.org/389/ticket/149
This issue had been already treated when bz 182507 was solved.