389-ds-base

#182 Pwd retry counters replication not enabled by default, and enabling it could lead to undesired results
Closed: wontfix Opened by rmeggins.

Closed: wontfix
Reopen Issue

https://bugzilla.redhat.com/show_bug.cgi?id=740528

Description of problem:
Error counters don't replicate by default and it's needed to activate an
special option to have them replicated. Also, the multimaster
replication of this counters can produce undesired behaviours.
RHDS / 389 DS still uses old method of counting errors by using a
counter in the "passwordretrycount" attribute. This attribute doesn't
replicate by default, so one could fail 3 times against a replica and
then other 3 times against another different replica, and so on, before
replication occurs and it wouldn't let try it anymore.
There is a parameter to activate the replication of these attributes
(passwordIsGlobalPolicy) that was also used in other LDAP like Sun DS
5.2 (same codebase as RHDS). In this case, multimaster replication of
these counters could lead to errors if the user tries against several
replicas, due to replication delays and collisions.
In Sun DS 6 this was solved using same scheme as other directories (as
Crtitical or IBM) did , where instead of a counter each failure has a
timestamp.
This is an RFE for this error counters replication feature.
Version-Release number of selected component (if applicable):
All current releases
How reproducible:
Always, depending on replication delay
Steps to Reproduce:
1. Define maximum number of login re-tries to 3, and let it replicate across
all MMR
2. Enable replication of error counters with attribute "passwordIsGlobalPolicy"
3. Try to login with wrong password in one replica 3 times
4. Before replication actually occurs, try to login with wrong password in
another replica another 3 times (it might take more than one test loop to
reproduce)
Actual results:
User can try to login on each replica until maximum number of tries has been
reached,  although it has been reached already against another previous
replica.
Expected results:
User cannot retry login in second replica.
User cannot retry login more times than maximum specified in configuration,
across all replicas.
Additional info:
Customer is looking for detailed SunDS 6 implementation description. Do you
have it at hand?

batch move to milestone 1.3

SunDS still has this exact problem. Although it used timestamps, it was a multivalued attribute, and it just counted the attributes to determine the count. The timestamp was used for reset times, etc. Prioritized replication helped send these pwd policy updates out "faster", but it is still at the mercy of replication latency. The Sun solution was/is to use an "all master" replication environment, and use a ldap router (e.g. DPS) to point all the binds to a single master.

set default ticket origin to Community

Added initial screened field value.

Since prioritized replication is the only approach that will help this kind of issue, I'm marking this as a duplicate of ticket:

https://fedorahosted.org/389/ticket/194

Metadata Update from @nkinder:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.2 - 07/13 (July)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/182

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Duplicate)
Metadata
None
None
None
Normal
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.