Re: Account lockout counters not replicating; how to unlock users?

[Richard Megginson <rmeggins@xxxxxxxxxx>]

Bliss, Aaron wrote:

> Hmm; thanks very much for your help; so what are my options?  Changing
> from supplier/consumer to multi-master?
That would certainly solve the problem.

> Does the global password issue
> still exist in a multi-master environment?
No.

> Are there any concerns with
> this?  Or is the global password issue with supplier/consumer
> replication something that is or can be addressed?
AFAIK there is no other way to do it.  We've got a couple of ways to do 
it that we're working on.

> Thanks.
>
> Aaron 
>
> -----Original Message-----
> From: fedora-directory-users-bounces@xxxxxxxxxx
> [mailto:fedora-directory-users-bounces@xxxxxxxxxx] On Behalf Of Richard
> Megginson
> Sent: Tuesday, February 07, 2006 10:10 PM
> To: Ulf Weltman
> Cc: General discussion list for the Fedora Directory server project.
> Subject: Re:  Account lockout counters not
> replicating;how to unlock users?
>
> Ulf Weltman wrote:
>
>  
>
> > 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.
> >    
>
> Oh, that's right.  We need to chain the bind requests.
>
> So the answer to the original question is - no - you cannot have global
> password policy yet.
>
>  
>
> > > > Aaron
> > > >
> > > > -----Original Message-----
> > > > From: fedora-directory-users-bounces@xxxxxxxxxx
> > > > [mailto:fedora-directory-users-bounces@xxxxxxxxxx] 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:  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@xxxxxxxxxx
> > > > > [mailto:fedora-directory-users-bounces@xxxxxxxxxx] On Behalf Of 
> > > > > Bliss, Aaron
> > > > > Sent: Tuesday, February 07, 2006 5:11 PM
> > > > > To: General discussion list for the Fedora Directory server
> > > > >          
> project.
>  
>
> > > > > Subject:  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@xxxxxxxxxx 
> > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > > > >
> > > > >
> > > > > --
> > > > > Fedora-directory-users mailing list 
> > > > > Fedora-directory-users@xxxxxxxxxx 
> > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > > > >
> > > > >
> > > > >
> > > > >  
> > > > >          
> > > >
> > > >
> > > > --
> > > > Fedora-directory-users mailing list
> > > > Fedora-directory-users@xxxxxxxxxx
> > > > 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@xxxxxxxxxx
> > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > > >
> > > >
> > > >        
> >    
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users