Bug 10881 - Wrong keytab permissions when joining additional DC with BIND backend
Wrong keytab permissions when joining additional DC with BIND backend
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Tools
4.2.0rc2
All Linux
: P5 major
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
: 11242 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-16 10:48 UTC by Marc Muehlfeld
Modified: 2016-02-21 17:28 UTC (History)
4 users (show)

See Also:


Attachments
Joining an additional DC - Log (3.64 KB, text/plain)
2014-10-16 11:39 UTC, Marc Muehlfeld
no flags Details
Provisioning the first DC - log (2.35 KB, text/plain)
2014-10-16 11:44 UTC, Marc Muehlfeld
no flags Details
Test patch (2.34 KB, patch)
2014-12-05 23:25 UTC, Christian Ambach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Muehlfeld 2014-10-16 10:48:00 UTC
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.
Comment 1 Marc Muehlfeld 2014-10-16 11:39:45 UTC
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.
Comment 2 Marc Muehlfeld 2014-10-16 11:44:44 UTC
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.
Comment 3 Christian Ambach 2014-12-05 23:25:10 UTC
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.
Comment 4 Marc Muehlfeld 2014-12-06 15:12:27 UTC
(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.
Comment 5 Christian Ambach 2014-12-07 21:22:49 UTC
Okay.. now I need to create a clean version of the fix that does not violate the DRY principle. Stay tuned.
Comment 6 Louis 2015-04-29 09:10:28 UTC
*** Bug 11242 has been marked as a duplicate of this bug. ***
Comment 7 Andrew Bartlett 2015-12-07 23:03:42 UTC
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
Comment 8 Christian Ambach 2015-12-30 22:40:27 UTC
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.
Comment 9 Christian Ambach 2016-02-18 21:09:01 UTC
as Andrew's fix landed in master, this should be fixed in 4.4
Comment 10 Marc Muehlfeld 2016-02-21 17:28:41 UTC
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