Thanks, I'm reviewing what I did to see where this went wrong. I did supply credentials for the service accounts.
Question about inheritance of subtree password policies: How do you see that it has been applied to a subtree of a subtree? dsconf claims that there is no subtree policy on ou=test,ou=accounts: > dsconf -D "cn=Directory Manager" -w "xxxx" ldap://localhost:3389 localpwp list ou=accounts,ou=etc etc (subtree policy) > dsconf -D "cn=Directory Manager" -w "xxxx" ldap://localhost:3389 localpwp get > "ou=test,ou=accounts,ou=etc etc" Error: No password policy was found for this entry Tim Darby Systems Integration and Architecture | The University of Arizona | tda...@arizona.edu<mailto:tda...@arizona.edu> | they/he<https://diversity.arizona.edu/pronouns> ________________________________ From: Mark Reynolds <marey...@redhat.com> Sent: Monday, August 26, 2024 07:14 To: General discussion list for the 389 Directory server project. <389-users@lists.fedoraproject.org>; Darby, Tim - (tdarby) <tda...@arizona.edu> Subject: [EXT] Re: [389-users] Password policies and replication service accounts External Email On 8/19/24 11:05 AM, tda...@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<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-le...@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
