This bug is created as a clone of upstream ticket:
krbExtraData is apparently NOT being modified but the ldap server believes it is which triggers an ldap mod & replication event because of it.
ssh logins should not trigger a modification that is replicated to FreeIPA replica servers due to storm concerns.
The issue is that a ssh login triggers the krbExtraData attribute to be modified. This modification is in the list of attributes to be replicated so a simple login to one host triggers a replication event.
Multiply the number of users logging into the number of hosts by the number of replicas and that is the storm he is talking about.
He says that reproduction is simply create a master and replica and log into one or the other. You should see a replication event as a result of a kerberized ssh login.
One of the approaches would be to create a configuration that would specify for which of the attributes the time stamp should not be updated if the attribute value is touched but not changed (updated with the same value). I would actually argue that in 80% cases that would be a preference so the default might be not to update time stamp in this case but have a configuration option to define an exception to this rule.
Replaced https://fedorahosted.org/freeipa/ticket/2220 with https://fedorahosted.org/freeipa/ticket/2354
Bug 842441 is associated with this bug. It should be verified at the same time.
Marking this bug as verified since mmrepl/accept tests are passing 100%. Also, the associated bug #842441 is also marked verified.
############## Result for backend test : mmrepl mmraccept run
mmrepl mmraccept run elapse time : 00:12:12
mmrepl mmraccept run Tests PASS : 100% (28/28)
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.