Merge branch 'v4-0-local' of git://git.id10ts.net/samba into 4-0-local

(This used to be commit 0e429dd1fb15137a2a7c25e051b9af8c4ed8c7f3)

2 files changed, 109 insertions, 27 deletions

diff --git a/source4/setup/named.conf b/source4/setup/named.conf
index 025788093e..9cf0b48a7c 100644
--- a/source4/setup/named.conf
+++ b/source4/setup/named.conf
@@ -3,35 +3,116 @@
 # the BIND nameserver.
 #
 
-# If you have a very recent BIND, supporting GSS-TSIG, 
-# insert this into options {}  (otherwise omit, it is not required if we don't accept updates)
-tkey-gssapi-credential "DNS/${DNSDOMAIN}";
-tkey-domain "${REALM}";
-
-# You should always include the actual zone configuration reference:
+# You should always include the actual forward zone configuration:
 zone "${DNSDOMAIN}." IN {
-        type master;
-        file "${DNSDOMAIN}.zone";
+	type master;
+	file "${DNSDOMAIN}.zone";
 	update-policy {
-		/* use ANY only for Domain controllers for now */
-		/* for normal machines A AAAA PTR is probbaly all is needed */
-		grant ${HOSTNAME}.${DNSDOMAIN}@${REALM} name ${HOSTNAME}.${DNSDOMAIN} ANY;
+		/*
+		 * A rather long description here, as the "ms-self" option does
+		 * not appear in any docs yet (it can only be found in the
+		 * source code).
+		 *
+		 * The short of it is that each host is allowed to update its
+		 * own A and AAAA records, when the update request is properly
+		 * signed by the host itself.
+		 *
+		 * The long description is (look at the
+		 * dst_gssapi_identitymatchesrealmms() call in lib/dns/ssu.c and
+		 * its definition in lib/dns/gssapictx.c for details):
+		 *
+		 * A GSS-TSIG update request will be signed by a given signer
+		 * (e.g. machine-name$@${REALM}).  The signer name is split into
+		 * the machine component (e.g. "machine-name") and the realm
+		 * component (e.g. "${REALM}").  The update is allowed if the
+		 * following conditions are met:
+		 *
+		 * 1) The machine component of the signer name matches the first
+		 * (host) component of the FQDN that is being updated.
+		 *
+		 * 2) The realm component of the signer name matches the realm
+		 * in the grant statement below (${REALM}).
+		 *
+		 * 3) The domain component of the FQDN that is being updated
+		 * matches the realm in the grant statement below.
+		 *
+		 * If the 3 conditions above are satisfied, the update succeeds.
+		 */
+		grant ${REALM} ms-self * A AAAA;
 	};
 };
 
-# Also, you need to change your init scripts to set this environment variable
-# for named: KRB5_KTNAME so that it points to the keytab generated.
-# In RedHat derived systems such RHEL/CentOS/Fedora you can add the following
-# line to the /etc/sysconfig/named file:
-# export KRB5_KTNAME=${DNS_KEYTAB_ABS}
-#
-# Please note that most distributions have BIND configured to run under
-# a non-root user account.  For example, Fedora Core 6 (FC6) runs BIND as
-# the user "named" once the daemon relinquishes its rights.  Therefore,
-# the file "${DNS_KEYTAB}" must be readable by the user that BIND run as.
-# If BIND is running as a non-root user, the "${DNS_KEYTAB}" file must have its
-# permissions altered to allow the daemon to read it.  In the FC6
-# example, execute the commands:
-# 
-# chgrp named ${DNS_KEYTAB_ABS}
-# chmod g+r ${DNS_KEYTAB_ABS}
+# The reverse zone configuration is optional.  The following example assumes a
+# subnet of 192.168.123.0/24:
+zone "123.168.192.in-addr.arpa" in {
+	type master;
+	file "123.168.192.in-addr.arpa.zone";
+	update-policy {
+		grant ${REALM_WC} wildcard *.123.168.192.in-addr.arpa. PTR;
+	};
+};
+# Note that the reverse zone file is not created during the provision process.
+
+# The most recent BIND version (9.5.0a5 or later) supports secure GSS-TSIG
+# updates.  If you are running an earlier version of BIND, or if you do not wish
+# to use secure GSS-TSIG updates, you may remove the update-policy sections in
+# both examples above.
+
+# If you are running a capable version of BIND and you wish to support secure
+# GSS-TSIG updates, you must make the following configuration changes:
+
+# - Insert the following lines into the options {} section of your named.conf
+# file:
+tkey-gssapi-credential "DNS/${DNSDOMAIN}";
+tkey-domain "${REALM}";
+
+# - Add settings for the ${REALM} realm to the Kerberos configuration on the DNS
+# server.  The easiest way is to add the following blocks to the appropriate
+# sections in /etc/krb5.conf:
+[realms]
+	${REALM} = {
+		kdc = ${HOSTNAME}.${DNSDOMAIN}:88
+		admin_server = ${HOSTNAME}.${DNSDOMAIN}:749
+		default_domain = ${DNSDOMAIN}
+	}
+
+[domain_realm]
+	.${DNSDOMAIN} = ${REALM}
+	${DNSDOMAIN} = ${REALM}
+
+# - Modify BIND init scripts to pass the location of the generated keytab file.
+# Fedora 8 & later provide a variable named KEYTAB_FILE in /etc/sysconfig/named
+# for this purpose:
+KEYTAB_FILE="${DNS_KEYTAB_ABS}"
+# Note that the Fedora scripts translate KEYTAB_FILE behind the scenes into a
+# variable named KRB5_KTNAME, which is ultimately passed to the BIND daemon.  If
+# your distribution does not provide a variable like KEYTAB_FILE to pass a
+# keytab file to the BIND daemon, a workaround is to place the following line in
+# BIND's sysconfig file or in the init script for BIND:
+export KRB5_KTNAME="${DNS_KEYTAB_ABS}"
+
+# - Set appropriate ownership and permissions on the ${DNS_KEYTAB} file.  Note
+# that most distributions have BIND configured to run under a non-root user
+# account.  For example, Fedora 9 runs BIND as the user "named" once the daemon
+# relinquishes its rights.  Therefore, the file ${DNS_KEYTAB} must be readable
+# by the user that BIND run as.  If BIND is running as a non-root user, the
+# "${DNS_KEYTAB}" file must have its permissions altered to allow the daemon to
+# read it.  Under Fedora 9, execute the following commands:
+chgrp named ${DNS_KEYTAB_ABS}
+chmod g+r ${DNS_KEYTAB_ABS}
+
+# - Ensure the BIND zone file(s) that will be dynamically updated are in a
+# directory where the BIND daemon can write.  When BIND performs dynamic
+# updates, it not only needs to update the zone file itself but it must also
+# create a journal (.jnl) file to track the dynamic updates as they occur.
+# Under Fedora 9, the /var/named directory can not be written to by the "named"
+# user.  However, the directory /var/named/dynamic directory does provide write
+# access.  Therefore the zone files were placed under the /var/named/dynamic
+# directory.  The file directives in both example zone statements at the
+# beginning of this file were changed by prepending the directory "dynamic/".
+
+# - If SELinux is enabled, ensure that all files have the appropriate SELinux
+# file contexts.  The ${DNS_KEYTAB} file must be accessible by the BIND daemon
+# and should have a SELinux type of named_conf_t.  This can be set with the
+# following command:
+chcon -t named_conf_t ${DNS_KEYTAB_ABS}
diff --git a/source4/setup/secrets_dc.ldif b/source4/setup/secrets_dc.ldif
index 71c7fc2f5b..abc5860cf7 100644
--- a/source4/setup/secrets_dc.ldif
+++ b/source4/setup/secrets_dc.ldif
@@ -33,6 +33,7 @@ objectClass: secret
 objectClass: kerberosSecret
 realm: ${REALM}
 servicePrincipalName: DNS/${DNSDOMAIN}
+msDS-KeyVersionNumber: 1
 privateKeytab: ${DNS_KEYTAB}
 secret:: ${DNSPASS_B64}