[Fedora-directory-users] Account lockout counters not replicating; how to unlock users?
Ulf Weltman
ulf.weltman at hp.com
Wed Feb 8 03:06:44 UTC 2006
Richard Megginson wrote:
> Bliss, Aaron wrote:
>
>> Ulf, Thanks for getting back to me; yep, I understand that the consumer
>> can never replicate information to the supplier (I wasn't very clear
>> before, sorry about that); I set the passwordIsGlobalPolicy to on on
>> both servers, and things are looking better; the passwordRetryCount,
>> retryCountResetTime, accountUnlockTime attributes are now getting
>> replicated properly from supplier to consumer, and deleting
>> passwordRetryCount, retryCountResetTime attributes from the supplier
>> does unlock accounts, however I'm still having a bit of a problem; what
>> I've seen is that if a users account gets locked on the consumer because
>> of bad password attempts, if that same user then attempts to login to a
>> server that is configured to first attempt to bind to the supplier
>> server, the user is allowed to login; What I see happening is that the
>> passwordRetryCount, retryCountResetTime, accountUnlockTime attributes
>> are set on the consumer properly, however these attributes are never set
>> if the bad password attempts occur from a server that attempts to bind
>> to the consumer first. Any ideas? Thanks again.
>>
>>
> Yes, this is a limitation of password policy. What you really want is
> for the consumer to pass the BIND request back to a master and have
> all of the password policy attributes computed on the master to be
> replicated to all other servers. Ulf, were you ever able to get Chain
> On Update to work in this configuration?
> http://directory.fedora.redhat.com/wiki/Howto:ChainOnUpdate
I think using the passthrough plugin to pass the bind back to a central
point was the only solution I came up with but it needs a patch, it
doesn't like getting controls back (Bugzilla #176302).
For ChainOnUpdate I didn't see a way to get it to work for this case.
The internal update that adds the PWP state didn't seem to get chained,
only updates coming from external clients.
>
>> Aaron
>>
>> -----Original Message-----
>> From: fedora-directory-users-bounces at redhat.com
>> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Ulf
>> Weltman
>> Sent: Tuesday, February 07, 2006 6:19 PM
>> To: General discussion list for the Fedora Directory server project.
>> Subject: Re: [Fedora-directory-users] Account lockout counters not
>> replicating;how to unlock users?
>>
>> Hello Aaron. Two separate things:
>> I may have misunderstood your configuration, but nothing is replicated
>> from a consumer to a master unless the consumer is actually configured
>> as a hub with an agreement back to the supplier. You can use
>> passthrough authentication trickery to cause binds to be performed at
>> the master if you don't want bi-directional replication.
>>
>> Also, those three attributes (passwordRetryCount, retryCountResetTime,
>> accountUnlockTime) are special and will not replicate in any case unless
>> you set passwordIsGlobalPolicy to on in cn=config.
>>
>> Ulf
>>
>> Bliss, Aaron wrote:
>>
>>
>>
>>> P.S. Normal replication is happening, as well as typical referrals from
>>>
>>
>>
>>
>>
>>> consumer to supplier (i.e. password changes). Any help with this
>>> will be much appreciated, as this is a rather huge problem right
>>> now. Thanks again.
>>>
>>> Aaron
>>>
>>> -----Original Message-----
>>> From: fedora-directory-users-bounces at redhat.com
>>> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of
>>> Bliss, Aaron
>>> Sent: Tuesday, February 07, 2006 5:11 PM
>>> To: General discussion list for the Fedora Directory server project.
>>> Subject: [Fedora-directory-users] Account lockout counters not
>>> replicating;how to unlock users?
>>>
>>> Here's my setup; 2 directory servers, 1 supplier, 1 consumer; I'm
>>> not sure why, but for some reason I'm not seeing password retry
>>> counters being replicated from the consumer to the supplier; here is
>>> what I've seen (I have fds setup to lock accounts after 5 bad
>>> password attempts, reset failure count after 15 minutes):
>>> -if a user types their password incorrectly on a server that binds
>>> first to a consumer, then their password retry count increments only on
>>>
>>
>>
>>
>>
>>> the consumer -if a user successfully binds to the server, then their
>>> password retry count does get reset This is a problem for a couple
>>> of reasons. If an account becomes locked out because of bad password
>>> attempts, I've tried deleting the attributes of passwordRetryCount
>>> and accountUnlockTime
>>> (http://directory.fedora.redhat.com/wiki/Howto:PasswordReset) from
>>> the supplier, however for some reason this is not replicated to the
>>> consumer (is this an indication of a different problem?) this is a
>>> problem as I have some of my linux servers to look to the supplier
>>> first for authentication, and then the consumer second, and visa
>>> versa for load balancing. According to fds documentation, account
>>> lockout counters may not work as expected in a multi master environment
>>> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/password.html#1086
>>> 4
>>> 46 ; this is one of the reasons that I opted for a single master
>>> environment; please advise and thanks. Given the issues that I'm
>>> having, what is the best way to unlock accounts that have been
>>> locked due to bad password attempts?
>>>
>>> Aaron
>>>
>>> www.preferredcare.org
>>> "An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>>> Power and Associates
>>>
>>> Confidentiality Notice:
>>> The information contained in this electronic message is intended for
>>> the exclusive use of the individual or entity named above and may
>>> contain privileged or confidential information. If the reader of
>>> this message is not the intended recipient or the employee or agent
>>> responsible to deliver it to the intended recipient, you are hereby
>>> notified that dissemination, distribution or copying of this
>>> information is prohibited. If you have received this communication
>>> in error, please notify the sender immediately by telephone and
>>> destroy the copies you received.
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>
>> www.preferredcare.org
>> "An Outstanding Member Experience," Preferred Care HMO Plans -- J. D.
>> Power and Associates
>>
>> Confidentiality Notice:
>> The information contained in this electronic message is intended for
>> the exclusive use of the individual or entity named above and may
>> contain privileged or confidential information. If the reader of
>> this message is not the intended recipient or the employee or agent
>> responsible to deliver it to the intended recipient, you are hereby
>> notified that dissemination, distribution or copying of this
>> information is prohibited. If you have received this communication
>> in error, please notify the sender immediately by telephone and
>> destroy the copies you received.
>>
>>
>> --
>> Fedora-directory-users mailing list
>> Fedora-directory-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
More information about the Fedora-directory-users
mailing list