From fb3e663678be412df4668b05e76480908da2c080 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Matthias=20Dieter=20Walln=C3=B6fer?= Date: Tue, 22 Jul 2008 11:06:47 +1000 Subject: [PATCH] Improve DNS and Group poicy configurations. - fixes bug #4813 (simplify DNS setup) - This reworks the named.conf to be a fully fledged include - This also moves the documentation into named.txt - improves bug #4900 (Group policy support in Samba) - by creating an empty GPT.INI - fixes bug #5582 (DNS: Enhanced zone file) - This is now closer to the zone file AD creates committed by Andrew Bartlett (This used to be commit 74d684f6b329d7dd573cdc55e16bb8e629474b02) --- source4/scripting/python/samba/provision.py | 5 +- source4/setup/named.conf | 63 +++++---------------- source4/setup/named.txt | 46 +++++++++++++++ source4/setup/provision.zone | 7 ++- 4 files changed, 68 insertions(+), 53 deletions(-) create mode 100644 source4/setup/named.txt diff --git a/source4/scripting/python/samba/provision.py b/source4/scripting/python/samba/provision.py index 6eb47c8595d..40b61a0ac41 100644 --- a/source4/scripting/python/samba/provision.py +++ b/source4/scripting/python/samba/provision.py @@ -1043,6 +1043,7 @@ def provision(setup_dir, message, session_info, policy_path = os.path.join(paths.sysvol, names.dnsdomain, "Policies", "{" + policyguid + "}") os.makedirs(policy_path, 0755) + open(os.path.join(policy_path, "GPT.INI"), 'w').write("") os.makedirs(os.path.join(policy_path, "Machine"), 0755) os.makedirs(os.path.join(policy_path, "User"), 0755) if not os.path.isdir(paths.netlogon): @@ -1081,12 +1082,11 @@ def provision(setup_dir, message, session_info, hostip6=hostip6, hostname=names.hostname, dnspass=dnspass, realm=names.realm, domainguid=domainguid, hostguid=hostguid) - message("Please install the zone located in %s into your DNS server" % paths.dns) create_named_conf(paths.namedconf, setup_path, realm=names.realm, dnsdomain=names.dnsdomain, private_dir=paths.private_dir, keytab_name=paths.dns_keytab) - message("See %s for example configuration statements for secure GSS-TSIG updates" % paths.namedconf) + message("See %s for an example configuration include file for BIND" % paths.namedconf) create_krb5_conf(paths.krb5conf, setup_path, dnsdomain=names.dnsdomain, hostname=names.hostname, realm=names.realm) @@ -1394,6 +1394,7 @@ def create_named_conf(path, setup_path, realm, dnsdomain, "REALM_WC": "*." + ".".join(realm.split(".")[1:]), "DNS_KEYTAB": keytab_name, "DNS_KEYTAB_ABS": os.path.join(private_dir, keytab_name), + "PRIVATE_DIR": private_dir, }) def create_krb5_conf(path, setup_path, dnsdomain, hostname, realm): diff --git a/source4/setup/named.conf b/source4/setup/named.conf index 4f98bbd9148..0b087069c77 100644 --- a/source4/setup/named.conf +++ b/source4/setup/named.conf @@ -1,12 +1,15 @@ +# This file should be included in your main BIND configuration file # -# Insert these snippets into your named.conf or bind.conf to configure -# the BIND nameserver. -# +# For example with +# include "${PRIVATE_DIR}/named.conf"; -# You should always include the actual forward zone configuration: zone "${DNSDOMAIN}." IN { type master; - file "${DNSDOMAIN}.zone"; + file "${PRIVATE_DIR}/${DNSDOMAIN}.zone"; + /* + * Attention: Not all BIND versions support "ms-self". The instead use + * of allow-update { any; }; is another, but less secure possibility. + */ update-policy { /* * A rather long description here, as the "ms-self" option does @@ -44,6 +47,8 @@ zone "${DNSDOMAIN}." IN { # 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"; @@ -51,54 +56,12 @@ zone "123.168.192.in-addr.arpa" in { 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 +# The most recent BIND versions (9.5.0a5 or later) support 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}"; - -# - 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/named.txt b/source4/setup/named.txt new file mode 100644 index 00000000000..c1e6b3a9ee5 --- /dev/null +++ b/source4/setup/named.txt @@ -0,0 +1,46 @@ +# Additional informations for DNS setup using BIND + +# 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}"; + +# - 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/provision.zone b/source4/setup/provision.zone index 28c1c297621..17ae3bb47a0 100644 --- a/source4/setup/provision.zone +++ b/source4/setup/provision.zone @@ -14,10 +14,12 @@ ${HOSTIP6_BASE_LINE} ; ${HOSTIP6_HOST_LINE} ${HOSTNAME} IN A ${HOSTIP} -${HOSTGUID}._msdcs IN CNAME ${HOSTNAME} +gc._msdcs IN CNAME ${HOSTNAME} +${HOSTGUID}._msdcs IN CNAME ${HOSTNAME} ; ; global catalog servers _gc._tcp IN SRV 0 100 3268 ${HOSTNAME} +_gc._tcp.${DEFAULTSITE}._sites IN SRV 0 100 3268 ${HOSTNAME} _ldap._tcp.gc._msdcs IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.${DEFAULTSITE}._sites.gc._msdcs IN SRV 0 100 389 ${HOSTNAME} ; @@ -25,12 +27,15 @@ _ldap._tcp.${DEFAULTSITE}._sites.gc._msdcs IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.dc._msdcs IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.pdc._msdcs IN SRV 0 100 389 ${HOSTNAME} +_ldap._tcp.${DOMAINGUID} IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.${DOMAINGUID}.domains._msdcs IN SRV 0 100 389 ${HOSTNAME} +_ldap._tcp.${DEFAULTSITE}._sites IN SRV 0 100 389 ${HOSTNAME} _ldap._tcp.${DEFAULTSITE}._sites.dc._msdcs IN SRV 0 100 389 ${HOSTNAME} ; ; krb5 servers _kerberos._tcp IN SRV 0 100 88 ${HOSTNAME} _kerberos._tcp.dc._msdcs IN SRV 0 100 88 ${HOSTNAME} +_kerberos._tcp.${DEFAULTSITE}._sites IN SRV 0 100 88 ${HOSTNAME} _kerberos._tcp.${DEFAULTSITE}._sites.dc._msdcs IN SRV 0 100 88 ${HOSTNAME} _kerberos._udp IN SRV 0 100 88 ${HOSTNAME} ; MIT kpasswd likes to lookup this name on password change