Hmm; thanks very much for your help; so what are my options?
Changing
from supplier/consumer to multi-master?
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(a)redhat.com
[mailto:fedora-directory-users-bounces@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: [Fedora-directory-users] 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(a)redhat.com
>>>[mailto:fedora-directory-users-bounces@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(a)redhat.com
>>>>[mailto:fedora-directory-users-bounces@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(a)redhat.com
>>>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>>
>>>>--
>>>>Fedora-directory-users mailing list
>>>>Fedora-directory-users(a)redhat.com
>>>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>--
>>>Fedora-directory-users mailing list
>>>Fedora-directory-users(a)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(a)redhat.com
>>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>>>
>>>
>
>
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users