#3351 User lookup failure due to search-base handling

Created 6 months ago by sbose
Modified 4 months ago

There is an issue with looking up users from AD child domains at least in the IPA provider server-mode code.

Looking up a user from a child domain of a trusted forest fails although it was successfully read from AD. In the logs this is shown by:

(Fri Mar 24 14:01:02 2017) [sssd[be[ipaf25.devel]]] [sdap_search_user_process] (0x0400): Search for users, returned 1 results.
(Fri Mar 24 14:01:02 2017) [sssd[be[ipaf25.devel]]] [sdap_search_user_process] (0x2000): Retrieved total 0 users

So the user was read from AD (1 results) but SSSD thinks it does not belong to the current domain (0 users)

I added some debugging output to SSSD:

diff --git a/src/providers/ldap/sdap_domain.c b/src/providers/ldap/sdap_domain.c
index 5cba9df..6c98f68 100644
--- a/src/providers/ldap/sdap_domain.c
+++ b/src/providers/ldap/sdap_domain.c
@@ -60,6 +60,7 @@ sdap_domain_get_by_dn(struct sdap_options *opts,
     }

     DLIST_FOR_EACH(sditer, opts->sdom) {
+DEBUG(SSSDBG_TRACE_ALL, "[%s][%s][%s].\n", dn, sditer->dom->name, sditer->user_search_bases[0]->basedn);
         if (sss_ldap_dn_in_search_bases_len(tmp_ctx, dn, sditer->search_bases,
                                             NULL, &match_len)
             || sss_ldap_dn_in_search_bases_len(tmp_ctx, dn,
@@ -82,6 +83,7 @@ sdap_domain_get_by_dn(struct sdap_options *opts,
         }
     }
     talloc_free(tmp_ctx);
+DEBUG(SSSDBG_TRACE_ALL, "match [%s][%s][%s].\n", dn, sdmatch->dom->name, sdmatch->user_search_bases[0]->basedn);
     return sdmatch;
 }

With this it can be see:

(Fri Mar 24 14:00:57 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=t u,CN=Users,DC=ad,DC=devel][ad.devel][DC=ad,DC=devel].
(Fri Mar 24 14:00:57 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=t u,CN=Users,DC=ad,DC=devel][ChIlD.ad.devel][dc=child,dc=ad,dc=devel].
(Fri Mar 24 14:00:57 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): match [CN=t u,CN=Users,DC=ad,DC=devel][ad.devel][DC=ad,DC=devel].
(Fri Mar 24 14:01:02 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=c u,CN=Users,DC=ChIlD,DC=ad,DC=devel][ad.devel][DC=ChIlD,DC=ad,DC=devel].
(Fri Mar 24 14:01:02 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=c u,CN=Users,DC=ChIlD,DC=ad,DC=devel][ChIlD.ad.devel][dc=child,dc=ad,dc=devel].
(Fri Mar 24 14:01:02 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): match [CN=c u,CN=Users,DC=ChIlD,DC=ad,DC=devel][ad.devel][DC=ChIlD,DC=ad,DC=devel].
(Fri Mar 24 14:03:44 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=t u,CN=Users,DC=ad,DC=devel][ad.devel][DC=ad,DC=devel].
(Fri Mar 24 14:03:44 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=t u,CN=Users,DC=ad,DC=devel][ChIlD.ad.devel][dc=child,dc=ad,dc=devel].
(Fri Mar 24 14:03:44 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): match [CN=t u,CN=Users,DC=ad,DC=devel][ad.devel][DC=ad,DC=devel].

I think it is somewhat related to setting the search bases at connection time. It looks like when the child domain is connected for the first time the search bases are set in all sdap_domain objects to the search base of the child domain. As a result sdap_domain_get_by_dn() returns the first match which would be the forest root and then sdap_object_in_domain() returns false which lets SSSD drop the user.

If ldap_user_search_base for the child domain is set to a wrong value it starts working:

[domain/ipaf25.devel/child.ad.devel]
ldap_search_base = dc=wrong,dc=ad,dc=devel

becasue the wrong value is used by the forest root while the sdap_domain object of the child domain seems to use the autodeteced one:

(Fri Mar 24 15:04:17 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=c u,CN=Users,DC=ChIlD,DC=ad,DC=devel][ad.devel][dc=wrong,dc=ad,dc=devel].
(Fri Mar 24 15:04:17 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): [CN=c u,CN=Users,DC=ChIlD,DC=ad,DC=devel][ChIlD.ad.devel][dc=child,dc=ad,dc=devel].
(Fri Mar 24 15:04:17 2017) [sssd[be[ipaf25.devel]]] [sdap_domain_get_by_dn] (0x4000): match [CN=c u,CN=Users,DC=ChIlD,DC=ad,DC=devel][ChIlD.ad.devel][dc=child,dc=ad,dc=devel].

Just a wild guess. Try to revert commit 25699846bd1c9f8bb513b6271eb4366ab682fbd2.

Maybe the root cause is the same as in https://pagure.io/SSSD/sssd/issue/3331#comment-431232.

I just checked to be on the safe side and reverting the commit does not help. But I doubted it anyway becasue this issue is cleary between ' Search for users, returned 1 results.' and 'Retrieved total 0 users' in sdap_search_user_process() and as far as I can see no code from the commit is executed there.

6 months ago

Metadata Update from @lslebodn:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1437199

6 months ago

Metadata Update from @lslebodn:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1437199

Issue linked to Bugzilla: Bug 1437199

Issue linked to Bugzilla: Bug 1435662

6 months ago

Metadata Update from @jhrozek:
- Issue priority set to: critical
- Issue set to the milestone: SSSD 1.15.3

6 months ago

Metadata Update from @jhrozek:
- Issue assigned to mzidek

5 months ago

Metadata Update from @mzidek:
- Assignee reset
- Custom field rhbz reset (from https://bugzilla.redhat.com/show_bug.cgi?id=1437199, https://bugzilla.redhat.com/show_bug.cgi?id=1435662)
- Issue priority set to: None (was: critical)
- Issue set to the milestone: None (was: SSSD 1.15.3)

5 months ago

Metadata Update from @lslebodn:
- Issue priority set to: critical
- Issue set to the milestone: SSSD 1.15.3

5 months ago

Metadata Update from @jhrozek:
- Issue assigned to mzidek

5 months ago

Metadata Update from @jhrozek:
- Custom field patch adjusted to on

master:

  • 4c49edbd8df651b1737c59459637962c117212c6
4 months ago

Metadata Update from @lslebodn:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 months ago

Metadata Update from @lslebodn:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 months ago

Metadata Update from @lslebodn:
- Custom field version adjusted to 1.15.2

Login to comment on this ticket.

1.15.2

on

https://bugzilla.redhat.com/show_bug.cgi?id=1435662

cancel