[389-users] DSA unwilling to process update / Viewing contents of replication updates

[Chris Phillips]

On Tue, Jun 9, 2009 at 4:06 PM, Rich Megginson <rmeggins at redhat.com> wrote:

> Chris Phillips wrote:
>
>> Hi,
>>
>> I've a cluster of boxes with replication form two multimasters to 6 read
>> only replicas. There appears to be a problem in the replication in that the
>> error logs state that the DSA is unwilling to process updates for a specific
>> user account, so the replication status in the idm just stays at saying it
>> started rather than completed. I could just delete the account and recreate
>> it, but as it's unfortunately *my* account (and is in this state *possibly*
>> because I was messing with the resetpasswordretrytime field (or something
>> very similarly named) which I get the impression is treated differently to
>> other fields) I'd like to avoid deleting the account.
>>
>> To this end I'm hoping a suitable solution is to remove whatever the
>> change is that is trying to be pushed across, but I can't see any way with
>> SSL replication to see what the actual attributes it doesn't like are. Any
>> way to pull this straight out with ldapsearch or something? Any tips for
>> elegantly troubleshooting this in a heavily locked down environment would be
>> appreciated.
>>
>
> Yes, it probably has to do with one of those password related operational
> attributes.  There are a couple of ways to handle this
> 1) change your replication agreement to exclude the attributes
> passwordRetryCount, retryCountResetTime, and accountUnlockTime - you do this
> by adding these attributes to be excluded in fractional replication - you
> should be able to modify your existing replication agreements to exclude
> these
> 2) add the attribute passwordIsGlobalPolicy in cn=config to "on" on your
> servers - this will allow those attributes to be replicated


This seems to fit in exactly, thanks. If I set this value on a read only
replica, what will happen if it is locked out on that replica? Presumably
despite this setting that can't get replicated back up to the multimasters?

As an alternative to changing the policy, can I manually undo these changes?
TBH I'm not too clued up on what triggers an attribute like this to be
chosen to be replicated in the first place, if it's a hidden timestamp or
such.

Thanks

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20090609/bad18a83/attachment.html>