[Fedora-directory-users] Account lockout counters not replicating; how to unlock users?

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
>>  
>>