Bug 1848364

Summary:	Add verification when replication managers group is modified.
Product:	Red Hat Enterprise Linux 9	Reporter:	Thorsten Scherf <tscherf>
Component:	ipa	Assignee:	Florence Blanc-Renaud <frenaud>
Status:	CLOSED WONTFIX	QA Contact:	ipa-qe <ipa-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	mreynolds, rcrit, rcritten, spichugi, tapazogl, tbordaz, tscherf, vashirov
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-02-10 13:15:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thorsten Scherf 2020-06-18 08:54:28 UTC

Description of problem:
When modifications are performed on the 'cn=replication managers' group, make sure the object that is added/modified is valid.

We have seen cases where replication conflict objects are part of this group which results in replication failures because replicas can't authenticate to other servers using GSSAPI.

dn: cn=replication managers,cn=sysaccounts,cn=etc,dc=example,dc=com
cn: replication managers
member: krbprincipalname=ldap/foo.example.com,cn=services,cn=accounts,dc=example,dc=com
member: krbprincipalname=ldap/bar.example.com+nsuniqueid=12ab9e01-323511ea-a290cb22-f583e5cf,cn=services,cn=accounts,dc=example,dc=com



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 mreynolds 2020-06-18 12:47:04 UTC

Should this be an IPA bug?  Not sure what you want DS to do.  It is not practical for DS to check what members are added to a "group" - that would cause a performance nightmare especially with large static groups.

Comment 2 Thorsten Scherf 2020-06-18 13:00:05 UTC

(In reply to mreynolds from comment #1)
> Should this be an IPA bug?  Not sure what you want DS to do.  It is not
> practical for DS to check what members are added to a "group" - that would
> cause a performance nightmare especially with large static groups.

Yes, of course, this one should be assigned to ipa, not 389-ds. My bad. Changing the component now.

Comment 4 Rob Crittenden 2021-11-10 15:34:34 UTC

The original report has no reproducer of how this can happen, but I doubt it can happen today with the changes 389-ds made regarding conflict entries. They require a very specific search to find.  Mark, what do you think?

Comment 5 mreynolds 2021-11-10 20:44:45 UTC

(In reply to Rob Crittenden from comment #4)
> The original report has no reproducer of how this can happen, but I doubt it
> can happen today with the changes 389-ds made regarding conflict entries.
> They require a very specific search to find.  Mark, what do you think?

Right, you have to use a search filter with the objectclass ldapsubentry to find conflicts (starting in RHEL 8, on RHEL 7 you don't need this objectclass in the filter), but that would not prevent someone, or possibly a plugin, from adding that DN to a group.  I don't know how IPA manages its replication manager group, so I can not say if it's a user doing it, or a plugin, etc.

Comment 6 Rob Crittenden 2021-11-12 14:21:33 UTC

Its hard to say how a conflict entry can become a member. IPA generally only obtains a DN in two ways:

1. It creates it manually with knowledge of the IPA DIT
2. A search for an entry

So I can only assume this came from a search result. We probably could add protection to filter out conflict entries but I'd need to know more about how this happened in the first place. It may be, for example, that multiple entries are returned in a search and we use the first one returned because we assume there can be only one, which would be bad.

Comment 7 mreynolds 2021-11-12 14:37:36 UTC

(In reply to Rob Crittenden from comment #6)
> Its hard to say how a conflict entry can become a member. IPA generally only
> obtains a DN in two ways:
> 
> 1. It creates it manually with knowledge of the IPA DIT
> 2. A search for an entry
> 
> So I can only assume this came from a search result. We probably could add
> protection to filter out conflict entries but I'd need to know more about
> how this happened in the first place. It may be, for example, that multiple
> entries are returned in a search and we use the first one returned because
> we assume there can be only one, which would be bad.

If this can be reproduced it might be useful to enable the audit log and set nsslapd-plugin-binddn-tracking to on under cn=config.  Then we will know "who" made this change (unless you already know what did it).

Comment 9 Theodoros Apazoglou 2021-12-08 14:03:20 UTC

I am prolonving the stale date since we need more time to discuss on this tkt.

Comment 10 Rob Crittenden 2022-01-19 15:50:01 UTC

I'm inclined to close this as WONTFIX. We don't have a reproducer and I think with the changes in 389 related to conflict entries this should not be possible in new installations.

Comment 11 Florence Blanc-Renaud 2022-01-19 16:09:57 UTC

(In reply to Rob Crittenden from comment #10)
> I'm inclined to close this as WONTFIX. We don't have a reproducer and I
> think with the changes in 389 related to conflict entries this should not be
> possible in new installations.

+1 for closing as WONTFIX, since 389-ds 1.3.7.4 (https://directory.fedoraproject.org/docs/389ds/releases/release-1-3-7-4.html) replication conflict entries are not visible any more unless a specific search filter is used "(&(objectClass=ldapSubEntry)(nsds5ReplConflict=*))"

Comment 12 Florence Blanc-Renaud 2022-02-10 13:15:53 UTC

As discussed previously (in #c10 and #c11), we don't think that the issue can happen any more, thanks to the changes done on 389-ds-side. Closing as WONTFIX.