Hey, William,
I have taken a look at the dsconf tooling as well, but so far all of the
ones I've looked at and tested (dsconf, ipa-replica-manage, cipa, etc) fail
if I try to use them with any sysaccount - but work perfectly using
Directory Manager or a normal user. Unfortunately, this isn't acceptable
for my environment so I have to build another solution that uses
least-privilege.
I'll take the != rules under advisement and note that this is why the
above LDIF only permits search/read/compare permissions - write of any kind
in the target system is expressly forbidden for monitoring tooling in my
environment. Any permissions I can drop once I have the system worked out,
I will do - and I'll bring it back here and see if you lovely folks might
be able to help or perhaps utilize.
On the off chance that you know something about it: I don't suppose you
might have any other ideas of where I can find a non-superuser-based
replication-monitoring setup/description for IdM/389ds? If you do, I've
been hunting everywhere for something that gives even a basic look at how
to do this for over a month with no success.
--
John Apple II
On Thu, Nov 16, 2023 at 1:06 PM William Brown <william.brown(a)suse.com>
wrote:
> On 16 Nov 2023, at 11:50, John Apple II <jappleii(a)redhat.com> 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?).
>
> 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";)
don't use != rules, they have bypasses allowing full directory data
disclosure. See
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
Generally to monitor replication you should look at the replication
monitoring tools from the 389 project in dsconf (I think).
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia