Hmm; thanks very much for your help; so what are my options? Changing from supplier/consumer to multi-master? Does the global password issue still exist in a multi-master environment? Are there any concerns with this? Or is the global password issue with supplier/consumer replication something that is or can be addressed? Thanks. Aaron -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] 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 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: 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: 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 >>> >>> > >
