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 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 >>>> >>>> >>>> >>>> >> >> > > >-- >Fedora-directory-users mailing list >Fedora-directory-users at redhat.com >https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3178 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20060208/6456a757/attachment.bin
