The following doesn't work on (at least) 4.2.0rc2 and 4.1.12: When you join an additional DC with BIND backend (--dns-backend=BIND9_DLZ) to the AD, then the dns.keytab is only accessable by root and not by BIND: # ls -l /usr/local/samba/private/dns.keytab -rw-------. 1 root root 822 16. Okt 11:56 /usr/local/samba/private/dns.keytab The problem is, that Samba and Bind seems to work. BUT: samba_dnsupdate isn't able to write the DNS entries into the Zone ("dns_tkey_negotiategss: TKEY is unacceptable"). The bad result is, that without these DNS entries, clients don't use the new DC for logons, because it would be located through DNS entries. Users may thinking, that they're having 2 or more DC for failure safety, but when the first is down, then the clients can't logon, because the don't find other DCs because of the missing DNS entries. This only happens when joining additional DCs. If you provision the first DC, then the file is automatically readable by the "named" group: # ls -l /usr/local/samba/private/dns.keytab -rw-r-----. 1 root named 822 16. Okt 12:36 /usr/local/samba/private/dns.keytab That's why I report this as a bug, because during the provisioning we can find out this information. I've added a workaround to the "Join as DC" HowTo in the Wiki. So users can at least bypass this problem.
Created attachment 10351 [details] Joining an additional DC - Log Attached you can see, that when joining an additional DC, before there's no dns.keytab (of course ;-)) and after the join, it exists, but is only accessable by root.
Created attachment 10352 [details] Provisioning the first DC - log Attached you can see, that when provisioning the first DC, before there's no dns.keytab (of course ;-)) and after the provisioning, the file exists and is readable by group "named". So this works when provisioning the first DC, but not when joining additional ones.
Created attachment 10495 [details] Test patch Can you try this patch? It is completely untested, so it might even fail with syntax errors. But maybe you can fix them on your own if they show up.
(In reply to Christian Ambach from comment #3) > Can you try this patch? It is completely untested, so it might even fail with > syntax errors. But maybe you can fix them on your own if they show up. Your patch fixes the problem.
Okay.. now I need to create a clean version of the fix that does not violate the DRY principle. Stay tuned.
*** Bug 11242 has been marked as a duplicate of this bug. ***
I created a similar patch in: http://git.catalyst.net.nz/gitweb?p=samba.git;a=commitdiff;h=1be4a3fac640273216fed520d2520f9d7b2f812e;hp=fb2efca5888dd024152f4b1d762596c76bf3f68f We should get one or the other of these in
Yours isn't much better than mine with regards to avoiding code duplication. But I am afraid that it can only be solved without the duplication by refactoring the provisioning process.
as Andrew's fix landed in master, this should be fixed in 4.4
Sorry for the late reply. I confirm that it's fixed in master. Keytab belongs now to named group, which has read permissions. # la /usr/local/samba/private/dns.keytab -rw-r----- 1 root named 822 21. Feb 18:23 /usr/local/samba/private/dns.keytab