Univention Bugzilla – Bug 39806
DDNS PTR update fails if IP is reused by other client
Last modified: 2021-04-21 12:30:16 CEST
We had a report of a Samba/AD-domain where PTR records registered by Windows clients where not updated properly (Ticket# 2015100821000533). In that case the issues showed up at an increased rate, because apparently the DHCP server used by the clients was configured to issue dynamic leases. During the UCS 4.1 product tests I just saw that Windows clients are actually behave like good citizens by removing the registred PTR records from DNS in case they change the IP. This works when manually changing a static client IP as well as when the client obtains a new IP from DHCP during boot. But: On the Samba/AD server side, the LDAP objects are still there, only the dnsRecord attribute changed from DNS_TYPE_PTR to DNS_TYPE_TOMBSTONE. That way, the bind9 nameserver doesn't find them any longer as PTR records. Fine. Problem is that the obejcts ntsecuritydescriptor still says that the object belongs to the client that initially registered it. I'll attach the two LDIFs before and after DDNS removal. When a different Windows client wants to register a PTR record for that address later, the DDNS update is denied by the bind9 server: ============================================================================== Nov 5 19:22:42 master100 named[2492]: samba_dlz: starting transaction on zone 8.200.10.in-addr. arpa Nov 5 19:22:42 master100 named[2492]: client 10.200.8.238#51169: update '8.200.10.in-addr.arpa/ IN' denied Nov 5 19:22:42 master100 named[2492]: samba_dlz: cancelling transaction on zone 8.200.10.in-add r.arpa Nov 5 19:22:42 master100 named[2492]: samba_dlz: starting transaction on zone 8.200.10.in-addr. arpa Nov 5 19:22:42 master100 named[2492]: samba_dlz: disallowing update of signer=WIN7PRO2\$\@AR41S 4PT1.QA name=238.8.200.10.in-addr.arpa type=PTR error=insufficient access rights Nov 5 19:22:42 master100 named[2492]: client 10.200.8.238#58965: updating zone '8.200.10.in-add r.arpa/NONE': update failed: rejected by secure update (REFUSED) Nov 5 19:22:42 master100 named[2492]: samba_dlz: cancelling transaction on zone 8.200.10.in-addr.arpa ============================================================================== Maybe it would be possible to adjust the dlz_bind9 plugin to detect this case, remove the tombstone (with local system level access via LDAPI) and then try the update again, all directly during that DDNS update call. A mechanism like that could also help us resolve systematic problems like the one in Bug 33637 and in Bug 33638. Some good security checks would be required.
Created attachment 7258 [details] DNS_TYPE_PTR record
Created attachment 7259 [details] DNS_TYPE_TOMBSTONE record
Note: Things would be a lot easier (especially for Bug 33637 and Bug 33638) when both, the S4-Connector and the bind9 dlz module would perform their operations as S-1-5-18 ("local system", and that's actually close to the truth). This SID is e.g. present in the ntSecurityDescriptor of the DNS record objects, with access_mask 0x000f01ff (full control).
Ok, apart from the general remark of Comment 3, we should check how Sambas own DNS implementation handles this. Grepping for DNS_TYPE_TOMBSTONE finds: source4/rpc_server/dnsserver/dnsdata.c source4/dns_server/dns_update.c source4/dns_server/dnsserver_common.c Here is a bit of rationale behind this record type: https://bugzilla.samba.org/show_bug.cgi?id=10749
Re-tagging as bug because it seems to be a problem in several customer environments.
Created attachment 8772 [details] Delete tombstoned objects if mismatched access rights.
Created attachment 8773 [details] Escalate priviledges if maschine name matches.
Attached are patches for samba in two parts. The first one handles the update of tombstoned objects. The second modifies the Samba DLZ modul to allow updates to forward-zones if the requesting maschine has the same name, but insufficient access rights (due to prior modifications by the S4-Connector). Some background for the first case: [1] describes the behaviour of the MS implementation. This can't be found in any of the official documentation ([MS-DNSP] or [MS-ADTS]). We have two cases: a) "Updates while the record is `dnsTombstoned`", b) "Updates while the record is dnsTombstoned, but the SID of the maschine has changed.". The common Samba DNS code (used by the DLZ modul and the build-in DNS server), consists of primarily two functions `dns_common_lookup()` and `dns_common_replace()`. Both handle tombstoned objects, `dns_common_replace()` resurrects them if necessary. Case a) is therefore handled. Case b) is neither handled by the build-in DNS server, nor by the DLZ modul. The first attached patch implements deleting the tombstoned object if an updates with insufficient access rights is requested. The second patch implements a Univention specific case: If a maschine tries to access a forward-zone without the proper access-rights, but the FQDN as computed from the DN and the actual FQDN of the requesting maschine match, a modification is allowed and the privileges for this operation are escalated to system-rights. [1]: https://blogs.technet.microsoft.com/isrpfeplat/2010/09/23/dns-scavenging-internals-or-what-is-the-dnstombstoned-attribute-for-ad-integrated-zones/
Bug 41190 might be Case a. We should also test the status of Bug 41190 once this one is fixed.
Created attachment 8829 [details] Escalate priviledges if maschine name matches. Updated 2nd patch: Fix a typo.
Created attachment 8846 [details] this script adds the SID of a client in the nTsecuritydescriptor IMHO the customer has the same problem for some clients in his environment. The script we provided (fix_ownership_of_dns_hostrecord.sh) does not fit in here. More information in Ticket# 2017051221000102
Ok, the first patch works: > attachment 8772 [details] > Delete tombstoned objects if mismatched access rights. Maybe we could even simplify it, because https://blogs.technet.microsoft.com/isrpfeplat/2010/09/23/dns-scavenging-internals-or-what-is-the-dnstombstoned-attribute-for-ad-integrated-zones/ says: ============================================================================== Note: The default behavior for Windows 2008 R2 was modified and will be acting as if the SID of the machine has changed regardless of whether it’s true or not. Meaning when a record update is sent to a DNS server hosted on a Windows 2008 R2 Domain Controller and the record’s dnsTombstone=True the record is deleted regardless of the permissions issue described earlier. ============================================================================== So, I guess we could simply adjust the first patch, from if (ldb_ret == LDB_ERR_INSUFFICIENT_ACCESS_RIGHTS && is_tombstoned) { ldb_ret = ldb_delete(state->samdb, dn); to if (is_tombstoned) { ldb_ret = ldb_delete(state->samdb, dn); But that's a minor thing. If we want to upstream the patch, we should simply let them decide, both implementations would work for us.
The second patch on the other hand needs some adjustment: > attachment 8829 [details] > Escalate priviledges if maschine name matches. It checks if (name == fqdn) but "name" is is not "the actual FQDN of the requesting machine": I wrote a script to nsupdate a tombstoned machine DNS record simply as a normal user, and it worked even though the username differed from the machine FQDN. In my test "name" was the fqdn of the DNS record that the nsupdate request was referring to (visible in /var/log/syslog). I think we would have to ldb_search for the sAMAccountName/userPrincipalName of the authenticated identity and check if the returned object has a dNSHostName attribute that matches the "name" requested in the update. That's a bit more tricky, because the Kerbers Principal of the authenticated updater can differ from userPrincipalName attributes found in the Active Directory data (e.g. MACHINE$@REALM.EXAMPLE). We'll have to scan the Samba sources to see how this can be done. Maybe we should split this patch off to a separate bug, because it is independent of the tombstone issue and we wont be able to upstream it.
(In reply to Arvid Requate from comment #12) > Ok, the first patch works: > [...] > So, I guess we could simply adjust the first patch, from > > if (ldb_ret == LDB_ERR_INSUFFICIENT_ACCESS_RIGHTS && is_tombstoned) { > ldb_ret = ldb_delete(state->samdb, dn); > > to > > if (is_tombstoned) { > ldb_ret = ldb_delete(state->samdb, dn); I'd rather not, as `dsdb_check_access_on_dn()` and `dsdb_check_access_on_dn_internal()` can also return `LDB_ERR_OPERATIONS_ERROR` which would signal an internal error (error parsing the GUID, ..).
Created attachment 8925 [details] 8829: Escalate priviledges if maschine name matches. Update of the second patch. This version gets the account name of the user that signed the request against bind9 (`session_info->info->account_name`), checks if it is a machine account (ends with `$`) and if it matches the `dc` attribute of the dns-record object.
Ok works.
<http://errata.software-univention.de/ucs/4.2/42.html> <http://errata.software-univention.de/ucs/4.2/43.html>
*** Bug 34910 has been marked as a duplicate of this bug. ***
See also: https://github.com/univention/samba/tree/39806-bind-dlz-tombstoned