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

"Darby, Tim - (tdarby)" <tdarby@xxxxxxxxxxx> · Mon, 26 Aug 2024 22:33:00 +0000

I know about the replication agreements, cn=replication manager, and all that, but...

In the process of moving my old instances to 2.5, I decided to use lib389 as much as possible to script my replicas, replication agreements, replication accounts, etc. lib389, as far as I can tell, only creates replication service accounts in ou=Services. As
 such, I assumed that the old system, where everything was in cn=config, was no longer the recommendation. It seems to me that having the replication accounts in an OU makes them susceptible to password polices, which I do believe was causing the issues I was
 seeing. If you're saying that having it all in cn=config is still fine, I will happily revert to that.

On subtree policies, if that's the expected behavior of dsconf, which I find rather unhelpful to be honest, then it's all good. It just feels like there out to be something in the system that you can point at any given ou and ask "what's the policy that's active
 on this ou?"

Tim Darby

From: Mark Reynolds <mareynol@xxxxxxxxxx>

Sent: Monday, August 26, 2024 12:13

To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>; Darby, Tim - (tdarby) <tdarby@xxxxxxxxxxx>

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

External Email

On 8/26/24 1:18 PM, Darby, Tim - (tdarby) wrote:

Thanks, I'm reviewing what I did to see where this went wrong. I did supply credentials for the service accounts.

I was referring to the entry you use in the replication agreement (typically cn=replication manager, cn=config):

Supplier:

dn: cn=replication manager,cn=config

objectClass: top

objectClass: inetUser

objectClass: netscapeServer

objectClass: nsAccount

cn: replication manager

uid: replication manager

userPassword:: e1BCS0RGMi1TSEE1MTJ9MTAwMDAkQ0c5N08xK2crMWZyU0czQkdhcjN6WTNqM2Y

 2eHEvMHEkdXlPTnhmdW43RUEycVBFcmtKMHdXVGtSUXNpL3VBbDVpQTNySHJkRFJZejZGZTdjcHpi

 SHYzRnRQNlJ0Nnl4a1dvTFJ6clJ3a1lnYk9mMmo1OSsyZHc9PQ==

dn: cn=darby,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

objectClass: top

objectClass: nsds5replicationagreement

cn: darby

nsDS5ReplicaRoot: dc=example,dc=com

description: darby

nsDS5ReplicaHost: localhost

nsDS5ReplicaPort: 389

nsDS5ReplicaBindMethod: simple

nsDS5ReplicaTransportInfo: LDAP

nsDS5ReplicaBindDN: cn=replication manager,cn=config

nsDS5ReplicaCredentials: {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVG

 RERBNEJDUmxObUk0WXpjM1l5MHdaVE5rTXpZNA0KTnkxaE9XSmhORGRoT0MwMk1ESmpNV014TUFBQ

 0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCQUVqZlE0RzhhaHF5Rz

 dUN0F3Mmk3WQ==}14bMwBr/FBN6L1kPTBuyRA==

On the consumer side you must specify the bind that that can perform replication updates in the replica configuration entry:

dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

objectClass: top

objectClass: nsds5Replica

cn: replica

nsDS5ReplicaRoot: dc=example,dc=com

nsDS5ReplicaBindDN: cn=replication manager,cn=config
...
...

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

Right, so anything under "ou=accounts,ou=etc" should have that local policy applied to it.  It will only be listed under the the original subtree.  So this all looks correct.  Please provide your password policy settings and describe how it's not working
 as you expect:

    # dsconf slapd-INSTANCE localpwp get "ou=accounts,ou=etc"

Thanks,

Mark

Tim Darby

Systems Integration and Architecture | The University of Arizona | 
tdarby@xxxxxxxxxxx | 
they/he

From: Mark Reynolds
<mareynol@xxxxxxxxxx>

Sent: Monday, August 26, 2024 07:14

To: General discussion list for the 389 Directory server project. 
<389-users@xxxxxxxxxxxxxxxxxxxxxxx>; Darby, Tim - (tdarby) 
<tdarby@xxxxxxxxxxx>

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

External Email

On 8/19/24 11:05 AM, 
tdarby@xxxxxxxxxxx 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

-- 
Identity Management Development Team

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