On 11/16/23 02:50, John Apple II wrote:
Hi, William,
I am working on trying to figure out how to some basic monitoring
IdM Replication with a non-Directory-Manager service-account for some
internal work I do where we use IdM, and I'm trying to work on
figuring out how to create a service-account that will allow some
basic monitoring for LDAP replication between the IdM nodes (hopefully
similar to cipa?).
FYI on DS side we are prototyping a new monitoring mechanism as
monitoring replication is a long pending needs and current mechanisms
may have some drawbacks (complexity or false negative/positive)
I've been looking for information all over the web (including this
list) for this for about a month now. If you've made any progress on
something similar related to this, I'd be interested in
collaborating. I've come up with a basic LDIF and some test python
code to validate the ACIs for the service-account, but nothing else as
it took me 5 days just to figure out how to write ACI's.
In case it can help anyone in the future, my current LDIF follows -
the goal is to individually pull each server's LDAP entries directly
(as a start) and then compare them, but it allows the service-account
to access the replication data in the directory as well as the
sysaccounts directory itself.
SUFFIX="dc=domain,dc=example,dc=com"
ldif follows:
----
dn: uid=replmonitor,cn=sysaccounts,cn=etc,SUFFIX
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: replmonitor
userPassword: NOTAREALPASSWORD
passwordExpirationTime: 20381231235959Z
nsIdleTimeout: 0
dn: cn=sysaccounts,cn=etc,SUFFIX
changetype: modify
add: aci
aci: (targetattr != "userPassword || krbPrincipalKey ||
sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey ||
krbPrincipalName || krbCanonicalName || krbPwdHistory ||
krbLastPwdChange || krbExtraData || krbLastSuccessfulAuth ||
krbLastFailedAuth || ipaUniqueId || memberOf || enrolledBy ||
ipaNTHash || ipaProtectedOperation || aci || member") (version 3.0;
acl "allow (compare,read,search) of sysaccounts by replmonitor";
allow(search,read,compare) userdn =
"ldap:///uid=replmonitor,cn=sysaccounts,cn=etc,SUFFIX";;)
dn: cn=config
changetype: modify
add: aci
aci: (targetattr != "userPassword || krbPrincipalKey ||
sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey ||
krbPrincipalName || krbCanonicalName || krbPwdHistory ||
krbLastPwdChange || krbExtraData || krbLastSuccessfulAuth ||
krbLastFailedAuth || ipaUniqueId || memberOf || enrolledBy ||
ipaNTHash || ipaProtectedOperation || aci || member") (version 3.0;
acl "allow (compare,read,search) of cn=config by replmonitor";
allow(search,read,compare) userdn =
"ldap:///uid=replmonitor,cn=sysaccounts,cn=etc,SUFFIX";;)
----
John Apple II
On 16/11/23 03:59, William Faulk wrote:
I am running a RedHat IdM environment and am having regular problems
with missed replications. I want to understand how it's supposed to
work better so that I can make reasonable hypotheses to test, but I
cannot seem to find any in-depth documentation for it. Every time I
think I start to piece together an understanding, experimentation
makes it fall apart. Can someone either point me to some
documentation or help me understand how it works?
In particular, IdM implements multimaster replication, and I'm
initially trying to understand how changes are replicated in that
environment. What I think I understand is that changes beget CSNs,
which are comprised of a timestamp and a replica ID, and some sort of
comparison is made between the most recent CSNs in order to determine
what changes need to be sent to the remote side. Does each replica
keep a list of CSNs that have been sent to each other replica? Just
the replicas that it peers with? Can I see this data? (I thought it
might be in the nsds5replicationagreement entries, but the nsds50ruv
values there don't seem to change.) But it feels like it doesn't keep
that data, because then what would be the point of comparing the CSN
values be? Anyway, these are the types of questions I'm looking to
understand. Can anyone help, please?
_______________________________________________
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
_______________________________________________
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
