Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

disabled root ad domain causes subdomains to be marked offline #5770

Closed
sumit-bose opened this issue Sep 2, 2021 · 1 comment
Closed

disabled root ad domain causes subdomains to be marked offline #5770

sumit-bose opened this issue Sep 2, 2021 · 1 comment
Assignees
Labels
Bugzilla Closed: Fixed Issue was closed as fixed.

Comments

@sumit-bose
Copy link
Contributor

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 2000238

[+] Description of problem:
 - when the root ad domain is not listed in ad_enabled_domains, sssd will mark
the subdomains as offline

[+] Version-Release number of selected component (if applicable):
 - sssd-1.16.5-10.el7_9.8.x86_64

[+] How reproducible:
 - sometimes - the failure occurs when sssd tries to retrieve trust information
from the root domain

[+] Steps to Reproduce:
1. configure an ad forest with two or more domains
2. enable only the ad subdomains in ad_enabled_domains
3. monitor sssd to see subdomains marked offline

[+] Actual results:
 - all domains are marked offline and sssd fails to perform user lookups for a
certain period

[+] Expected results:
 - root domain being disabled is treated as normal and sssd keeps all
subdomains online

[+] Workaround:
 - list ad root domain in ad_enabled_domains
@sumit-bose sumit-bose self-assigned this Sep 2, 2021
sumit-bose added a commit to sumit-bose/sssd that referenced this issue Sep 2, 2021
Even if the forest root is disabled for user and group lookups a sdap
object is needed to lookup trusted domains.

This already works if the forest root is discovered for the first time
at runtime. But if SSSD is restarted only the domain object but not the
sdap object is created.

Resolves: SSSD#5770
sumit-bose added a commit to sumit-bose/sssd that referenced this issue Sep 21, 2021
Even if the forest root is disabled for user and group lookups a sdap
object is needed to lookup trusted domains.

This already works if the forest root is discovered for the first time
at runtime. But if SSSD is restarted only the domain object but not the
sdap object is created.

Resolves: SSSD#5770

:fixes: Even is the forest root is disabled for lookups all required
  internal data is initialized to be able to refresh the list of trusted
  domains in the forest from a DC of the forest root.
sumit-bose added a commit to sumit-bose/sssd that referenced this issue Sep 24, 2021
Even if the forest root is disabled for user and group lookups a sdap
object is needed to lookup trusted domains.

This already works if the forest root is discovered for the first time
at runtime. But if SSSD is restarted only the domain object but not the
sdap object is created.

Resolves: SSSD#5770

:fixes: Even if the forest root is disabled for lookups all required
  internal data is initialized to be able to refresh the list of trusted
  domains in the forest from a DC of the forest root.
pbrezina pushed a commit that referenced this issue Sep 24, 2021
Even if the forest root is disabled for user and group lookups a sdap
object is needed to lookup trusted domains.

This already works if the forest root is discovered for the first time
at runtime. But if SSSD is restarted only the domain object but not the
sdap object is created.

Resolves: #5770

:fixes: Even if the forest root is disabled for lookups all required
  internal data is initialized to be able to refresh the list of trusted
  domains in the forest from a DC of the forest root.

Reviewed-by: Pavel Březina <pbrezina@redhat.com>
(cherry picked from commit 2a617c0)
@pbrezina
Copy link
Member

Pushed PR: #5771

  • master
    • 2a617c0 - sdap: always create sdap object for a forest root
  • sssd-1-16
    • 46b1941 - sdap: always create sdap object for a forest root

@pbrezina pbrezina added the Closed: Fixed Issue was closed as fixed. label Sep 24, 2021
shridhargadekar pushed a commit to shridhargadekar/sssd that referenced this issue Apr 1, 2022
Even if the forest root is disabled for user and group lookups a sdap
object is needed to lookup trusted domains.

This already works if the forest root is discovered for the first time
at runtime. But if SSSD is restarted only the domain object but not the
sdap object is created.

Resolves: SSSD#5770

:fixes: Even if the forest root is disabled for lookups all required
  internal data is initialized to be able to refresh the list of trusted
  domains in the forest from a DC of the forest root.

Reviewed-by: Pavel Březina <pbrezina@redhat.com>
etrunko pushed a commit to etrunko/sssd that referenced this issue Nov 16, 2023
Even if the forest root is disabled for user and group lookups a sdap
object is needed to lookup trusted domains.

This already works if the forest root is discovered for the first time
at runtime. But if SSSD is restarted only the domain object but not the
sdap object is created.

Resolves: SSSD#5770

:fixes: Even if the forest root is disabled for lookups all required
  internal data is initialized to be able to refresh the list of trusted
  domains in the forest from a DC of the forest root.

Reviewed-by: Pavel Březina <pbrezina@redhat.com>
(cherry picked from commit 2a617c0)
etrunko pushed a commit to etrunko/sssd that referenced this issue Nov 16, 2023
Even if the forest root is disabled for user and group lookups a sdap
object is needed to lookup trusted domains.

This already works if the forest root is discovered for the first time
at runtime. But if SSSD is restarted only the domain object but not the
sdap object is created.

Resolves: SSSD#5770

:fixes: Even if the forest root is disabled for lookups all required
  internal data is initialized to be able to refresh the list of trusted
  domains in the forest from a DC of the forest root.

Reviewed-by: Pavel Březina <pbrezina@redhat.com>
(cherry picked from commit 2a617c0)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bugzilla Closed: Fixed Issue was closed as fixed.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants