> On 16 Nov 2023, at 14:19, John Apple II <jappl...@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-le...@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
