Replication manager with expired password

[Eugen Lamers]

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?
Thanx,
Eugen

[William Brown]

> On 27 Feb 2020, at 00:04, Eugen Lamers  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:
> Apply a user based policy (w/o passwordExp) to the user-like object "replication manager", or
> 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
> avoid setting pwdExp and pwdMustChange to a global policy at cn=config, or
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Marc Sauton]

The internal suffix cn=config is not really designed to have a global
password policy applied to it.
A replication manager usually does not have a password policy.
If it is required to have some special DNs with a password policy, they
should be in a different suffix.
Thanks,
M.

On Thu, Feb 27, 2020 at 6:11 PM William Brown  wrote:
> > On 27 Feb 2020, at 00:04, Eugen Lamers
>
> 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:
> > Apply a user based policy (w/o passwordExp) to the user-like object
>
> "replication manager", or
> > 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
> > avoid setting pwdExp and pwdMustChange to a global policy at
>
> cn=config, or
> > 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]....
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....