[Bug 1706284] Re: sssd fails to Update PTR if any A record update fails.

Łukasz Zemczak 1706284 at bugs.launchpad.net
Wed Aug 30 09:05:34 UTC 2017


** Also affects: sssd (Ubuntu Xenial)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1706284

Title:
  sssd fails to Update PTR if any A record update fails.

Status in sssd package in Ubuntu:
  In Progress
Status in sssd source package in Xenial:
  New

Bug description:
  sssd in both xenial and yakkety fails to update the PTR record of the
  current host on an active directory controller if any update for an
  A/AAA record returns a non-fatal error, this results in missing
  (and/or) mismatched Reverse DNS.

  This has already been fixed in 1.5.1 (which is present in Zesty and
  above), as failure to update any of the A/AAA should not affect
  updating the PTR as well, as not all servers in a given AD cluster may
  accept an A/AAA record update, especially if it would result in no
  update being made (NOERROR).

  See the attached conversation about this issue here:
  https://pagure.io/SSSD/sssd/issue/3227 for further information.

  I'll attach a debdiff against the relevant releases shortly, however
  for now I've attached the original patch which was used to fix the bug
  in 1.15.1

  ### SRU Justification ###

  [Impact]

  Currently users find that sssd will not update the reverse (PTR)
  records of a given host if an AD server returns non-fatal error for an
  A/AAA update.

  This causes strange issues to occur where we can end up with hosts
  with proper functioning forward records but no reverse. I propose we
  backport the fix from 1.15.1 to both Xenial and Yakkety to resolve the
  issue so PTR updates get processed (or at least attempted).

  The patch attached removes the error check that occurs should the
  return code of the A/AAA nsupdates be non zero, and instead allows the
  PTR update to occur before checking for errors.

  This is the same patch taken from the fix for 1.15.1

  [Test Case]

  For the configuration of sssd, a basic configuration of the following
  should suffice:

  [sssd]
  services = nss, pam
  config_file_version = 2
  domains = YOURDOMAIN.TLD

  [domain/YOURDOMAIN.TLD]
  id_provider=ad
  auth_provider=ad
  access_provider=ad
  chpass_provider=ad
  override_homedir=/home/%d/%u
  cache_credentials = true
  ad_gpo_access_control=permissive
  default_shell=/bin/bash
  ad_hostname = sssd-hostname.YOURDOMAIN.TLD

  In AD change the properties of the Forward zone Dynamic Updates to  "Nonsecure and Secure"
  Ensure a Reverse Zone is present in the AD DNS MMC.
  Remove any existing A/AAAA and PTR records from Active Directory DNS for the SSSD system
  Restart SSSD to trigger the nsupdate call
  Check the reverse zone in AD for PTR records, they do not get created but the A/AAAA records do.

  Expected results:
  Both A and PTR records get updated.

  [Regression Potential]

  As this patch is already present in a future release it has been
  fairly well tested already however back-porting the fix will result in
  sssd attempting PTR updates whether the A/AAA updates succeeds or not.

  As per the original bug report where a quick note was made about
  failed updates; If forward updates fail the result will be
  inconsistent DNS should the reverse succeed (reverse but no forward),
  however in that case the admin needs to look into with why the update
  failed, the code should at least try to record all updates (both A,
  AAA and PTR) and not just ignore the PTR because the forward update
  (may or may not have) failed.

  There is also the possibility that the patch may not resolve the
  problem completely however as this patch just moves the error handling
  before the PTR attempt I can see no reason not to backport the patch
  to the older version for Xenial/Yakkety.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1706284/+subscriptions



More information about the Ubuntu-sponsors mailing list