Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
description: Ticket was cloned from Red Hat Bugzilla (product ''RHEL RFE''): [https://bugzilla.redhat.com/show_bug.cgi?id=1140022 Bug 1140022]

''Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.''

{{{
1. Allow sssd to add a new option that would specify which server to update DNS with

1. What is the nature and description of the request?
   At this stage, SSSD can only update the server it talks to for identity data. With this RFE, SSSD should be able to talk to the specific server to update DNS with. This server sssd will speak with may or may not be providing identity data.

2. Why this is needed?
   If you have a DNS server that can't accept updates the client registration fails. Because of above situation, any new system is not able to join to the AD domain, as it fails while trying to write/create
   the dns record for the client. The registration fails on talking to this
   readonly DNS. AD server DNS forwards to infoblox, and the
   communication works fine). But the problem is the registration commands (net
   ads join -k) will fail due to trying to write to its own record (which infoblox
   will not allow, DNS entries are centrally managed. Infoblox does allow for the
   verification, but not the writing). Is there a way to force SSSD and the join
   to just verify the DNS entry is correct and not need to write to the entry

}}}

=> Ticket was cloned from Red Hat Bugzilla (product ''RHEL RFE''): [https://bugzilla.redhat.com/show_bug.cgi?id=1140022 Bug 1140022]

''Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.''

1. Allow sssd to add a new option that would specify which server to update DNS with

2. What is the nature and description of the request?
   At this stage, SSSD can only update the server it talks to for identity data. With this RFE, SSSD should be able to talk to the specific server to update DNS with. This server sssd will speak with may or may not be providing identity data.

3. Why this is needed?
   If you have a DNS server that can't accept updates the client registration fails. Because of above situation, any new system is not able to join to the AD domain, as it fails while trying to write/create the dns record for the client. The registration fails on talking to this readonly DNS. AD server DNS forwards to infoblox, and the communication works fine). But the problem is the registration commands (net ads join -k) will fail due to trying to write to its own record (which infoblox will not allow, DNS entries are centrally managed. Infoblox does allow for the verification, but not the writing). Is there a way to force SSSD and the join to just verify the DNS entry is correct and not need to write to the entry

design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
mark: no => 0
review: True => 0
selected: =>
testsupdated: => 0

Have they tried realmd?

net ads join -k is a samba component that is used as a part of the join procedure.
F20/RHEL7/CentOS7 uses a different client called adcli. It is automatically invoked when you use realmd.

I wonder if this works in this environment.
Can this be tested?

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

Makes sense together with the other nsupdate enhancements, but it's certainly lower-priority.

priority: major => minor

Fields changed

owner: somebody => preichl
sensitive: => 0

This ticket has an associated downstream bugzilla. Bumping priority.

priority: minor => critical

Fields changed

patch: 0 => 1

• master:
  • 8145ab5
  • 7c3cc1e
  • 4f2a07c

resolution: => fixed
status: new => closed

Additional patches:
- 12a1c64
- a741d0c

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3537

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.