Hi. Dns secure updates not working on samba 4.3.0. if you go back to 4.2.4, DNS update works fine. if set allow dns updates to nonsecure, DNS update works fine. tcpdump: 13:25:42.404632 IP 192.168.1.230.56320 > core.ircclub.net.domain: 20669+ SOA? TESTPC.dc.core.lan. (36) 13:25:42.404788 IP core.ircclub.net.domain > 192.168.1.230.56320: 20669 NXDomain- 0/0/0 (36) 13:25:42.533247 IP 192.168.1.230.51597 > core.ircclub.net.domain: 36039+ SOA? dc.core.lan. (29) 13:25:42.533456 IP core.ircclub.net.domain > 192.168.1.230.51597: 36039* 1/0/0 SOA (81) 13:25:42.539825 IP 192.168.1.230.57056 > core.ircclub.net.domain: 46529+ A? core.dc.core.lan. (34) 13:25:42.539994 IP core.ircclub.net.domain > 192.168.1.230.57056: 46529* 1/0/0 A 192.168.1.1 (50) 13:25:42.544886 IP 192.168.1.230.58746 > core.ircclub.net.domain: 45414 update [1a] [3n] SOA? dc.core.lan. (99) 13:25:42.545001 IP core.ircclub.net.domain > 192.168.1.230.58746: 45414 update Refused- 1/3/0 (Class 254) CNAME TESTPC.dc.core.lan. (99) 13:25:42.579959 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [S], seq 3220419354, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 13:25:42.579976 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [S.], seq 3773246463, ack 3220419355, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 13:25:42.580864 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], ack 1, win 256, length 0 13:25:42.616443 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], seq 1:1461, ack 1, win 256, length 1460638 [1au] TKEY? 1044-ms-7.32-46ea7e.39f3f51b-5ac0-11e5-5fa5-000c2991ce12. (1458) 13:25:42.616464 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [.], ack 1461, win 251, length 0 13:25:42.616561 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], seq 1461:2921, ack 1, win 256, length 146016794 zoneRef+% [b2&3=0x7b10] [19818a] [15921q] [26415n] [51682au][|domain] 13:25:42.616579 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [.], ack 2921, win 274, length 0 13:25:42.617183 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [P.], seq 2921:2942, ack 1, win 256, length 2128751 updateD [b2&3=0x5228] [21559a] [1979q] [33571n] [55924au] Type55015 (Class 22528)? [|domain] 13:25:42.617200 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [.], ack 2942, win 274, length 0 13:25:42.620154 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [P.], seq 1:344, ack 2942, win 274, length 343638 1/0/1 ANY TKEY (341) 13:25:42.659054 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [F.], seq 2942, ack 344, win 255, length 0 13:25:42.659096 IP core.ircclub.net.domain > 192.168.1.230.56042: Flags [F.], seq 344, ack 2943, win 274, length 0 13:25:42.695723 IP 192.168.1.230.56042 > core.ircclub.net.domain: Flags [.], ack 345, win 255, length 0 13:25:45.696811 IP 192.168.1.230.56322 > core.ircclub.net.domain: 27420+ SOA? TESTPC.dc.core.lan. (36) 13:25:45.696983 IP core.ircclub.net.domain > 192.168.1.230.56322: 27420 NXDomain- 0/0/0 (36) 13:25:45.815491 IP 192.168.1.230.64699 > core.ircclub.net.domain: 28979+ SOA? dc.core.lan. (29) 13:25:45.815735 IP core.ircclub.net.domain > 192.168.1.230.64699: 28979* 1/0/0 SOA (81) 13:25:45.905602 IP 192.168.1.230.59570 > core.ircclub.net.domain: 43031+ A? core.dc.core.lan. (34) 13:25:45.905826 IP core.ircclub.net.domain > 192.168.1.230.59570: 43031* 1/0/0 A 192.168.1.1 (50) 13:25:45.921770 IP 192.168.1.230.49491 > core.ircclub.net.domain: 51542 update [1a] [3n] SOA? dc.core.lan. (99) 13:25:45.921906 IP core.ircclub.net.domain > 192.168.1.230.49491: 51542 update Refused- 1/3/0 (Class 254) CNAME TESTPC.dc.core.lan. (99) 13:25:45.986995 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [S], seq 3303964566, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 13:25:45.987008 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [S.], seq 608504169, ack 3303964567, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 13:25:45.987807 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], ack 1, win 256, length 0 13:25:46.059021 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], seq 1:1461, ack 1, win 256, length 146057057 [1au] TKEY? 1044-ms-7.33-46f7c7.39f3f51b-5ac0-11e5-5fa5-000c2991ce12. (1458) 13:25:46.059041 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [.], ack 1461, win 251, length 0 13:25:46.059103 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], seq 1461:2921, ack 1, win 256, length 14602921 updateDA NotImp* [15879q],,,,[|domain] 13:25:46.059112 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [.], ack 2921, win 274, length 0 13:25:46.059797 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [P.], seq 2921:2942, ack 1, win 256, length 2118341 op3 Refused-| [4981q][|domain] 13:25:46.059803 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [.], ack 2942, win 274, length 0 13:25:46.062682 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [P.], seq 1:344, ack 2942, win 274, length 34357057 1/0/1 ANY TKEY (341) 13:25:46.099691 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [F.], seq 2942, ack 344, win 255, length 0 13:25:46.099745 IP core.ircclub.net.domain > 192.168.1.230.63855: Flags [F.], seq 344, ack 2943, win 274, length 0 13:25:46.106054 IP 192.168.1.230.63855 > core.ircclub.net.domain: Flags [.], ack 345, win 255, length 0 log: [2015/09/14 13:29:43.873322, 2] ../source4/dns_server/dns_update.c:792(dns_server_process_update) Got a dns update request. [2015/09/14 13:29:43.873412, 2] ../source4/dns_server/dns_update.c:749(dns_update_allowed) Update not allowed for unsigned packet. [2015/09/14 13:29:43.954648, 1] ../source4/dns_server/dns_query.c:526(handle_tkey) Tkey handshake completed
I't appears all versions of Samba 4.2.X allow secure updates. It's transitioning to any version of Samba 4.3.X that prevents secure updates. Looking at the Wireshark captures of a successful update https://www.cloudshark.org/captures/79e72c42de44 I see two transactions concerning the TKEY. I also see the update request from the client signed with the TSIG. Looking at a failed update https://www.cloudshark.org/captures/44f706b2cc61 I see three transactions concerning the TKEY. I also am missing the TSIG with the update request from the client. I do see a TSIG with the TKEY exchange from the DC. The TSIG as far as I know, should not be sent in the additional records section of the TKEY exchange. Secure update process fails during the TKEY exchange. This causes the client to repeat the whole DNS query exchange. The client should send the dynamic update request immediately after the TKEY exchange has taken place. The lack of the TSIG with the client update explains why Samba reports 'Update not allowed for unsigned packet' on the second update request.
confirmed. With Samba 4.3 you currently have to set allow dns updates = unsecure to allow dns updates - until the root cause is found and fixed.
Hello, I'm using Samba 4.3.x or 4.4.1 with Bind. DNS Update Secure works very well : Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone sodexi.lan Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#55738: update 'sodexi.lan/IN' denied Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: cancelling transaction on zone sodexi.lan Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone sodexi.lan Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=clt-winxp-sp3.sodexi.lan tcpaddr= type=A key=1016-ms-7.1-1588b..../160/0 Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=clt-winxp-sp3.sodexi.lan tcpaddr= type=A key=1016-ms-7.1-1588b..../160/0 Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#55094/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone 'sodexi.lan/NONE': deleting rrset at 'clt-winxp-sp3.sodexi.lan' A Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: subtracted rdataset clt-winxp-sp3.sodexi.lan 'clt-winxp-sp3.sodexi.lan.#0111200#011IN#011A#011172.16.199.3' Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#55094/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone 'sodexi.lan/NONE': adding an RR at 'clt-winxp-sp3.sodexi.lan' A Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: added rdataset clt-winxp-sp3.sodexi.lan 'clt-winxp-sp3.sodexi.lan.#0111200#011IN#011A#011172.16.199.3' Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: committed transaction on zone sodexi.lan Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone 199.16.172.in-addr.arpa Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#51813: update '199.16.172.in-addr.arpa/IN' denied Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: cancelling transaction on zone 199.16.172.in-addr.arpa Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: starting transaction on zone 199.16.172.in-addr.arpa Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=3.199.16.172.in-addr.arpa tcpaddr= type=PTR key=1016-ms-7.1-1588b..../160/0 Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: allowing update of signer=CLT-WINXP-SP3\$\@SODEXI.LAN name=3.199.16.172.in-addr.arpa tcpaddr= type=PTR key=1016-ms-7.1-1588b..../160/0 Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#56906/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone '199.16.172.in-addr.arpa/NONE': deleting rrset at '3.199.16.172.in-addr.arpa' PTR Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: subtracted rdataset 3.199.16.172.in-addr.arpa '3.199.16.172.in-addr.arpa.#0111200#011IN#011PTR#011clt-winxp-sp3.sodexi.lan.' Mar 17 11:21:23 srv-dc2 named[866]: client 172.16.199.3#56906/key CLT-WINXP-SP3\$\@SODEXI.LAN: updating zone '199.16.172.in-addr.arpa/NONE': adding an RR at '3.199.16.172.in-addr.arpa' PTR Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: added rdataset 3.199.16.172.in-addr.arpa '3.199.16.172.in-addr.arpa.#0111200#011IN#011PTR#011clt-winxp-sp3.sodexi.lan.' Mar 17 11:21:23 srv-dc2 named[866]: samba_dlz: committed transaction on zone 199.16.172.in-addr.arpa
Looking into this as well. There are several issues: 1. before 0062a2f5fb464b7c0991ccefd2f9d146fca54a0e we never attempted to add a TSIG to the TKEY reply (fwiw, nsupdate ignores TSIG on TKEY response, they have a comment and #ifdef 0 code that explains their reasoning). 2. now we add TSIK to TKEY response, but do the MAC calculation wrong (we add the request id which is wrong and TSIG field must not use DNS name compression) 3. fixing 1 and 2, we create correct TKEY response with TSIG record, but then fail to verify the MAC of the TSIG MAC in the client modify request Currently looking what we're doing wrong in 3.
Created attachment 12103 [details] Fix DNS-TKEY/TSIG WIP patch for master, testing appreciated, especially with different Windows versions. Works with Windows 7 for me.
(In reply to Ralph Böhme from comment #5) Thanks Ralph! I also found the dns name compression difference, it seems that that all names in a signed packet are not compressed (it you look at captures from Windows servers) I started with something like this: https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=faaf92c84a0dfb8798c0a So we would not use ndr_push_struct_blob(), but so same on our own (or add a new helper function) and set ndr->flags |= LIBNDR_FLAG_STR_NO_COMPRESSION. If state->state.sign is true (within dns_sign_tsig() and also in its caller while marshalling the final response)
(In reply to Stefan Metzmacher from comment #6) I started with a similar hack which was goood enough to verify that name compression is indeed one of the problems. But this simple approach won't work for the name field of dns record responses, where we only want to prevent compression for tsig records, but probably keep it for other record types: https://git.samba.org/?p=slow/samba.git;a=commitdiff;h=94a6aa692a46263ced28a53d5f4794ae971c5675#patch1
I can at least confirm that Ralph's earlier patch works for me on some of the 2012 boxes I have. And it's probable that it also fixes a number of scattered bug reports to do with DNS.
(In reply to Garming Sam from comment #8) Thanks for confirming! I have a slightly simplified version https://git.samba.org/?p=slow/samba.git;a=shortlog;h=refs/heads/dns-tkey that doesn't add a new type dns_unique_string but instead uses a new ndr flag (as also suggested by metze). I didn't know that you could push flags for specific union members, very handy.
*** Bug 10718 has been marked as a duplicate of this bug. ***
Created attachment 12187 [details] Patch for 4.4 cherry-picked from master
Patch doesn't apply to 4.3 as 4.3 is missing several commits. After carefully studying the merge conflicts I concluded I don't want to take the risk of breaking something else. So no backport for 4.3.
(In reply to Ralph Böhme from comment #12) I think we should at least restore the 4.2 behavior in 4.3, using a hack like this: https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=fdf292b3f005a30c642fb37aa8a1f395201f018a
*** Bug 11675 has been marked as a duplicate of this bug. ***
Comment on attachment 12187 [details] Patch for 4.4 cherry-picked from master Looks as expected. Should we include the patch that Jeremy put on top? c3dfeb3aa6c7df5127022abc090e446adc1b7d71 There's one other TSIG test that we wrote which matched one of our Windows bugs (I think we can take it or leave it). c752e93fc5960d2d31d80fcf608eff0fbfa784a0 I agree with Ralph that 4.3 seems non-trivial.
Created attachment 12197 [details] Patch for 4.4 cherry-picked from master Updated patchset for 4.4 including Jerermy's talloc check and the Garming's additional test.
Created attachment 12198 [details] Patch for 4.3
Pushed to autobuild-v4-[4|3]-test.
(In reply to Karolin Seeger from comment #18) Pushed to both branches. Closing out bug report. Thanks!
Fixed in master by c752e93fc5960d2d31d80fcf608eff0fbfa784a0 for 4.5.0 Backported to 4.4.6 and workaround backported to Samba 4.3.11