On 8/26/24 6:33 PM, Darby, Tim - (tdarby) wrote:
I know about the replication agreements, cn=replication manager, and
all that, but...
Sorry I wasn't trying to be rude or condescending - I just wanted to
make sure it was setup right because "Inappropriate auth" is usually
when a password is not provided (or doesn't exist in the entry?).
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.
That is still fine, and the CLI handles both. The local(subtree/user)
polices are just for fine-grained control, and these policy
configurations replicate which is nice (set it on one server and you're
good to go). Those are its pros, but the global password policy under
cn=config is perfectly fine as well.
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 the service account does not yet exist on the consumer, then yes it
will cause issues (error 32/49 on bind). We actually have bootstrap
settings
<https://www.port389.org/docs/389ds/design/repl-agmt-bootstrap-design.html>
to help in these scenario (but I'm not sure that's what your issue is).
If you're saying that having it all in cn=config is still fine, I will
happily revert to that.
You shouldn't have to though. I think there is just some conflict going
on (or misconfiguration). In the 2.x versions there is a new password
policy error logging level (1048576), It will tell you why a
bind/password update failure happens and by what policy.
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?"
Ahh yeah, that would be a nice improvement to the CLI/UI, and definitely
doable!
Back to replication. If you say password policy is the reason for the
error 48 -> inappropriate auth, then I disagree that is the root cause.
I think turning on replication logging (level 8192) will help point us
where to look. Password policy issues usually results in an error 49 or
53. That's why I think it's not password policy related.
Either way we need more info. It might be best to turn on both of those
error logging levels (combine them 1048576+8192=1056768). Just set it
back to 0 when you're done reproducing the issue (do this on both
supplier and consumer). Then send us the log clips please.
Thanks,
Mark
Tim Darby
------------------------------------------------------------------------
*From:* Mark Reynolds <[email protected]>
*Sent:* Monday, August 26, 2024 12:13
*To:* General discussion list for the 389 Directory server project.
<[email protected]>; Darby, Tim - (tdarby)
<[email protected]>
*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
<http://ldap//localhost:3389> localpwp list
ou=accounts,ou=etc etc (subtree policy)
> dsconf -D "cn=Directory Manager" -w "xxxx" ldap://localhost:3389
<http://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 |
[email protected] <mailto:[email protected]> | they/he
<https://diversity.arizona.edu/pronouns>
------------------------------------------------------------------------
*From:* Mark Reynolds <[email protected]> <mailto:[email protected]>
*Sent:* Monday, August 26, 2024 07:14
*To:* General discussion list for the 389 Directory server project.
<[email protected]>
<mailto:[email protected]>; Darby, Tim - (tdarby)
<[email protected]> <mailto:[email protected]>
*Subject:* [EXT] Re: [389-users] Password policies and replication
service accounts
External Email
On 8/19/24 11:05 AM, [email protected] <mailto:[email protected]>
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
--
Identity Management Development Team
--
Identity Management Development Team
--
_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
