On 16 Nov 2023, at 14:19, John Apple II <jappleii(a)redhat.com>
wrote:
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.
Even *reading* is a problem - if you have two != rules that overlap anywhere, then it
allows the other rule to get full access to everything in the directory.
As well, there are internal directory server attributes that shouldn't be disclosed,
and I will guarantee that you have missed them in your != rule.
Never use them please. Ever. I can not stress enough how these should never be used in
production and are a security risk.
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.\
Off the top of my head no, I don't have something.
Your best bet is to look at dsconf:
https://github.com/389ds/389-ds-base/blob/main/src/lib389/lib389/cli_conf...
This uses
https://github.com/389ds/389-ds-base/blob/main/src/lib389/lib389/replica....
underneath, and you can look at that to see that it's accessing a few structures:
https://github.com/389ds/389-ds-base/blob/main/src/lib389/lib389/replica....
Each "replica" (
https://github.com/389ds/389-ds-base/blob/main/src/lib389/lib389/replica.... ) is
setup as a kind of "magic python object" that underneath will issue queries. In
this case, it's using the "Replicas" plural class to discover all the
"Replica" that have the status.
https://github.com/389ds/389-ds-base/blob/main/src/lib389/lib389/replica....
From this you can see it's effectively doing searches on DN_MAPPING_TREE for entries
with the class REPLICA_OBJECTCLASS_VALUE - more concretely, this is querying
'(objectClass=nsds5Replica)' under 'cn=mapping tree,cn=config'.
This means you should only need to make an ACI for cn=mapping tree,cn=config for
targetAttrs that are on this class, then you can use dsconf's replication tools
pointed at this for it to work.
Note though, that ACI's in cn=config are NOT replicated unlike other parts of the
tree, as cn=config is per server so you'll need to make some changes across your
topology.
Also if you do this with a "user" that isn't (yet) privileged to read this,
you can see the queries in the access log which will tell you what you need to access.
Hope that gives you some ideas.
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia