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