[389-users] Re: Replication manager with expired password
On 27 Feb 2020, at 00:04, Eugen Lamers
<eugen.lamers(a)br-automation.com> wrote:
Hi,
we have set up a multi master replication (two peers, SIMPLE authentication) and added a
global password policy to cn=config. We included the passwordMustChange attribute to
cn=config, which led to the fact that the server process could not authenticate to the
replication manager of the peer host. We solved it by removing the generated attribute
passwordExpirationTime.
How is it usually handled to include something like passwordExp in the global policy at
cn=config without preventing something like replication from working:
1. Apply a user based policy (w/o passwordExp) to the user-like object "replication
manager", or
2. Place the user-like objects like "replication manager" to the DIT (not
cn=config) and apply a subtree based policy (w/o passwordExp) to the subtree containing
the object, or
3. avoid setting pwdExp and pwdMustChange to a global policy at cn=config, or
4. something else?
I've not seen or encountered this kind of issue before, so I'm not sure what is
the correct course of action here. I think generally in my experience we see password
policies only applied to subtrees or databases rather than globally.
It also depends where your replication manager is - generally we see them as
"cn=replication manager,cn=config" rather than being "in the
database". Can you confirm the FQDN of your replication manager that was affected
here?
Thanx,
Eugen
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs