> On 16 Nov 2023, at 14:19, John Apple II <jappleii@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/replication.py#L409
This uses https://github.com/389ds/389-ds-base/blob/main/src/lib389/lib389/replica.py#L2616 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.py#L2644C18-L2644C18
Each "replica" ( https://github.com/389ds/389-ds-base/blob/main/src/lib389/lib389/replica.py#L1193 ) 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.py#L1757
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
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No comments:
Post a Comment