Bug 782975 - krbExtraData is being null modified and replicated on each ssh login
Summary: krbExtraData is being null modified and replicated on each ssh login
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
Depends On:
TreeView+ depends on / blocked
Reported: 2012-01-19 00:28 UTC by Dmitri Pal
Modified: 2013-02-21 08:16 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Enhancement
Doc Text:
Feature: replication Reason: certain binds would cause only modifiersname/modifystimestamp to be updated, and this would lead to unneccessary replication traffic. Result: less replicatin traffic caused by binds.
Clone Of:
Last Closed: 2013-02-21 08:16:58 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0503 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 08:18:44 UTC

Description Dmitri Pal 2012-01-19 00:28:40 UTC
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.

Comment 1 Rob Crittenden 2012-02-01 18:44:03 UTC
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.

Comment 2 Dmitri Pal 2012-03-07 19:01:39 UTC
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.

Comment 3 Nathan Kinder 2012-03-14 21:28:53 UTC
Upstream ticket:

Comment 5 Nathan Kinder 2012-07-23 21:08:10 UTC
Bug 842441 is associated with this bug.  It should be verified at the same time.

Comment 7 Sankar Ramalingam 2013-01-29 18:17:54 UTC
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)

Comment 9 errata-xmlrpc 2013-02-21 08:16:58 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.