Monday, August 26, 2024

[389-users] Re: Password policies and replication service accounts

On 8/19/24 11:05 AM, tdarby@arizona.edu wrote:
> I encountered a problem with replication service accounts in the process of moving my one remaining very old (1.9.x) 389ds system to the new container. This is likely a misunderstanding on my part about how password policies work, so I'd appreciate any insights on this.
>
> This system has two MMR instances and an ou=Accounts containing thousands of user accounts. It uses a global password policy for the user accounts (there's no subtree policy on ou=Accounts). As I did with a previous migration to 3.x, I created a new ou, ou=Services,ou=Accounts, to hold the service accounts for replication. When I tried to do the initial replication, it failed because the source instance couldn't authenticate to the destination instance. I was seeing weird messages like "inappropriate authentication", etc.
>
> It occurred to me that maybe the issue had to do with the fact that this system had a global policy set whereas the previous system was not using a global policy. I tried removing the global policy and adding a subtree policy instead to ou=Accounts and that solved the problem. So, questions:
>
> - Is there a way to have a global password policy but not have it apply to a particular ou?

The global password policy under cn=config applies to all entries in the
database.  Then subtree policies (or fine-grained policies) can
over-rule the global policy.  If you want the global and subtree
policies to blend together then you must set the polices to inherit the
global policy:

https://docs.redhat.com/en/documentation/red_hat_directory_server/11/html/configuration_command_and_file_reference/core_server_configuration_reference#cnconfig-nsslapd_pwpolicy_inherit_global_Inherit_Global_Password_Policy

But, if you want the subtree policy to completely bypass the global
policy then do NOT set that attribute from the doc.

> - It appears that setting a subtree policy on an ou (ou=Accounts), does not inherit to a subtree of that tree (ou=Services). Is that right?
It should apply to all entries under the subtree policy, if not it's a
bug.  But we have tests for this so it should definitely be working in
newer versions of 389.
> - It's not clear to me what actually causes the global policy to be active. Does it become active simply by changing any of its password attributes in cn=config?

Yes, but like I said subtree policies overrule it.  All changes to
global/fine-grain polices take effect immediately.


Now going back to your replication issue, the password policy should not
impact replication.  Inappropriate auth means a password/credential was
not provided.  It's possible the consumer does not have a replication
manager defined, or you left out the credentials attribute in the
agreement.  Either way that's a replication config issue (agreement or
replica config) and unrelated to password policy.

HTH,

Mark

--
Identity Management Development Team

--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

No comments:

Post a Comment