Hi,

(In reply to Ondrej from comment #0)
> Description of problem:
> 
> The newly introduced option "ldap_ignore_unreadable_references" defaults to
> false which makes SSSD not backward compatible (with say RHEL-8).
> 
> If, for example, AD group contains a foreign security principals which
> belongs to one-way trusted domain, then on RH-9 group enumeration might
> fail, but on RH-8 it works (these security principals are ignored).

What do you mean under "group enumeration" - `getent group ...` or `sssd.conf::$domain::enumerate=true`?

There should be no functional difference between SSSD at RHEL8.7 and RHEL9.1 in this regard.

with 'ldap_ignore_unreadable_references = false'
[root@slsrvadm-02v ~]# getent group beryl     <---- FAIL
[root@slsrvadm-02v ~]# getent group acacia
acacia:*:11030:ovalouse,bwaldie,aarguell,ppischle,ahartber,cazzolin

with 'ldap_ignore_unreadable_references = true'
[root@slsrvadm-02v ~]# getent group beryl
beryl:*:10817:mesch,eisman,mschlenk,ksyed,sbolliri,tmahajan,psmith,sphillip,rmoffat,tbarisik,gmckenzi,mpeitz,rtaruc,bwaldie,easig,mvogt,meckert,mfranke,sba....

Note that both beryl & acacia have same AD structure, only difference is that beryl contains foreign security principals from a one-way trusted domain (i.e. makes a sense that SSSD fails to enumerate them)

On RH-8, there is no parameter ldap_ignore_unreadable_references but yet both work OK.

Now I agree with Sumit Bose that ldap_ignore_unreadable_references should probably default to false, but this obviously makes SSSD behave differently to the previous versions.

I recommend you either change the default settings
OR
You detect foreign security principals in AD and silently ignore them

(In reply to Ondrej from comment #2)
> 
> On RH-8, there is no parameter ldap_ignore_unreadable_references

It is there since 8.7:

# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.7 (Ootpa)

# rpm -q sssd-ldap
sssd-ldap-2.7.3-4.el8_7.3.x86_64

# man sssd-ldap | grep ldap_ignore_unreadable_references
       ldap_ignore_unreadable_references (bool)

Ok I was trying with older version 2.5.2-2 (i.e RH8.5).
I can confirm that after upgrading to version 2.7.3-4 I can see the same behavior as with RHEL-9

Hi,

the patch which handles the option is https://github.com/SSSD/sssd/commit/5c7fb41f3f1f4b1a1bbf7ddcb3d5b123ade0becb and it looks like the handling of unreadable objects was not consistent before. While in the first two places (sdap_x_deref_parse_entry and sdap_asq_search_parse_entry) the patch actually allows SSSD to ignore an error, in the last place, which is the one relevant here, the error was actually ignored before and is now treated as an error by default. See also https://github.com/SSSD/sssd/pull/5881#issuecomment-975573308.

Looks like we clearly missed to document this properly in the SSSD 2.7 release notes.

bye,
Sumit

Hi,

(In reply to Ondrej from comment #2)

> You detect foreign security principals in AD and silently ignore them

just to make sure we mean the same, you mean to ignore all 'member' DNs which are coming from the 'CN=ForeignSecurityPrincipals,DC=domain,DC=com' sub-tree?

bye,
Sumit

Ok, let me allow bit more explanation here:
My situation:
DIASEMI.COM ---> one_way_trust ----> ADWIN.RENESAS.COM

I configured SSSD for domain diasemi.com (see bug #2164852 for details), everything works except the problem with the foreign security principals which point to accounts in ADWIN.RENESAS.COM.

Just for fun, I also tried to join the machine to domain ADWIN.RENESAS.COM using adcli, but keeping sssd.conf intact (for some strange reason, I also had to use 'ldap_sasl_authid = <hostname>$@ADWIN.RENESAS.COM' to ensure sssd uses right principal to authenticate, but that was the only change). This way, I forced SSSD to work in domain DIASEMI.COM using machine account from ADWIN.RENESAS.COM.
Now this worked exactly the same way as before (i.e. did not solve the problem with security principals).

Just for fun I also tried to define 2nd domain adwin.renesas.com in sssd.conf -> great, now I can see all users from both domains together (pretty much as expected), but it also did not solve the problem with following the foreign security principals (i.e. 'getent group beryl' shows nothing).

Clearly SSSD is not clever enough to follow these even in cases it technically could (and bugreport in https://github.com/SSSD/sssd/issues/4633 suggests the same).

So, long story short I suggest when processing group membership, you process the 'member' attribute and when the member contains Foreign security principal (i.e. "objectclass=top; foreignSecurityPrincipal") you drop some warning like "Cross domain membership is not supported yet, see bug https://github.com/SSSD/sssd/issues/4633 for more" but do not fail altogether.

Does it make a sense?

Hi,

are the two domains from the same forest or different forests? I would expect they are from different forests.

About having two [domain/...] sections in sssd.conf. SSSD treats those two domains as two separate instances without any connections and hence cross-domain memberships are not possible in the case by design. However, SSSD's 'ad' and 'ipa' provider support trusted domains and here cross-domain memberships are supported. But there are currently the limitations that automatically only two-way trusts are handled and that even a two-way trust between two AD forests is not supported.


About the foreign security principal. If would of course be possible to check the objectclass 'foreignSecurityPrincipal', but this requires to read the object the DN in the 'member' attribute is pointing to. This is what SSSD currently does. However I wonder if it might be possible to speed things up and avoid reading the foreign security principal object by just checking if the DN is coming form the 'CN=ForeignSecurityPrincipals,DC=domain,DC=com' sub-tree. Do you see foreign security principal objects in other places in the AD LDAP tree than the 'CN=ForeignSecurityPrincipals,...' sub-tree? But maybe, to be on the safe side, we can just do both, do not read DNs from the 'CN=ForeignSecurityPrincipals,...' sub-tree and check the objectclass of the other read objects.

bye,
Sumit

Hi,

Yes 2 different forests
> But there are currently the limitations that automatically only two-way trusts are handled and that even a two-way trust between two AD forests is not supported.
Yes, that's what I guessed already.

> About the foreign security principal. If would of course be possible to check the objectclass 'foreignSecurityPrincipal', but this requires to read the object the DN in the 'member' attribute is pointing to.

But SSSD can read it, see:

(2023-02-06  7:09:24): [be[diasemi]] [sdap_find_entry_by_origDN] (0x4000): [RID#6] Searching cache for [CN=S-1-5-21-602162358-1060284298-725345543-466597,CN=ForeignSecurityPrincipals,DC=diasemi,DC=com].
(2023-02-06  7:09:24): [be[diasemi]] [sdap_fill_memberships] (0x0080): [RID#6] Member [CN=S-1-5-21-602162358-1060284298-725345543-466597,CN=ForeignSecurityPrincipals,DC=diasemi,DC=com] was not found in cache. Is it out of scope?
(2023-02-06  7:12:27): [be[diasemi]] [sysdb_cache_search_users] (0x2000): [RID#5] Search users with filter: (&(objectCategory=user)(originalDN=CN=S-1-5-21-602162358-1060284298-725345543-453308,CN=ForeignSecurityPrincipals,DC=diasemi,DC=com))
(2023-02-06  7:12:27): [be[diasemi]] [sysdb_cache_search_groups] (0x2000): [RID#5] Search groups with filter: (&(objectCategory=group)(originalDN=CN=S-1-5-21-602162358-1060284298-725345543-453308,CN=ForeignSecurityPrincipals,DC=diasemi,DC=com))
(2023-02-06  7:12:27): [be[diasemi]] [sdap_nested_group_split_members] (0x4000): [RID#5] [CN=S-1-5-21-602162358-1060284298-725345543-453308,CN=ForeignSecurityPrincipals,DC=diasemi,DC=com] is unknown object

... I think here is the problem because SSSD says (probably because Foreign Security Principals does not have objectcategory "user" nor "group") that object is unknown. Looks like it CAN read it, it just does not understand it, got confused -> group enumeration fails.

Is that possible?

(In reply to Ondrej from comment #14)
> Hi,
> 
> Yes 2 different forests
> > But there are currently the limitations that automatically only two-way trusts are handled and that even a two-way trust between two AD forests is not supported.
> Yes, that's what I guessed already.
> 
> > About the foreign security principal. If would of course be possible to check the objectclass 'foreignSecurityPrincipal', but this requires to read the object the DN in the 'member' attribute is pointing to.
> 
> But SSSD can read it, see:
> 
> (2023-02-06  7:09:24): [be[diasemi]] [sdap_find_entry_by_origDN] (0x4000):
> [RID#6] Searching cache for
> [CN=S-1-5-21-602162358-1060284298-725345543-466597,
> CN=ForeignSecurityPrincipals,DC=diasemi,DC=com].
> (2023-02-06  7:09:24): [be[diasemi]] [sdap_fill_memberships] (0x0080):
> [RID#6] Member
> [CN=S-1-5-21-602162358-1060284298-725345543-466597,
> CN=ForeignSecurityPrincipals,DC=diasemi,DC=com] was not found in cache. Is
> it out of scope?
> (2023-02-06  7:12:27): [be[diasemi]] [sysdb_cache_search_users] (0x2000):
> [RID#5] Search users with filter:
> (&(objectCategory=user)(originalDN=CN=S-1-5-21-602162358-1060284298-
> 725345543-453308,CN=ForeignSecurityPrincipals,DC=diasemi,DC=com))
> (2023-02-06  7:12:27): [be[diasemi]] [sysdb_cache_search_groups] (0x2000):
> [RID#5] Search groups with filter:
> (&(objectCategory=group)(originalDN=CN=S-1-5-21-602162358-1060284298-
> 725345543-453308,CN=ForeignSecurityPrincipals,DC=diasemi,DC=com))
> (2023-02-06  7:12:27): [be[diasemi]] [sdap_nested_group_split_members]
> (0x4000): [RID#5]
> [CN=S-1-5-21-602162358-1060284298-725345543-453308,
> CN=ForeignSecurityPrincipals,DC=diasemi,DC=com] is unknown object
> 
> ... I think here is the problem because SSSD says (probably because Foreign
> Security Principals does not have objectcategory "user" nor "group") that
> object is unknown. Looks like it CAN read it, it just does not understand
> it, got confused -> group enumeration fails.
> 
> Is that possible?

Hi,

yes, that's how it currently works. I was just wondering if we have to read it at all since the DN contains '...,CN=ForeignSecurityPrincipals,...' SSSD can check for this before reading the object from AD and then can skip it immediately with sending an ldapsearch to AD.

bye,
Sumit

> yes, that's how it currently works. I was just wondering if we have to read it at all since the DN contains '...,CN=ForeignSecurityPrincipals,...' SSSD can check for this before reading the object from AD and then can skip it immediately with sending an ldapsearch to AD.

Well that could be risky because I can create normal user/group in that container -> it does not seem to be restricted in any way.
Out of interest - How did the older version 2.5.2 work so that it could cope with foreign principals better?

... also not quite sure if the suggested documentation patch is really adequate as strictly speaking, this has nothing to do with error reading object in AD.
What we really want to say is "hey man, don't forget to turn this option on if you happen to have group members from a different forest" or "turn this on if you managed to push a DN of an object that is not user or group into member attribute of group you want SSSD to enumerate".

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.