diff options
author | Andrew Bartlett <abartlet@samba.org> | 2008-05-21 14:34:43 +1000 |
---|---|---|
committer | Andrew Bartlett <abartlet@samba.org> | 2008-05-21 14:34:43 +1000 |
commit | 40ff67e4546780f422c01bb487921d93ac809def (patch) | |
tree | 4428dc977d302fd20304a87c80a917f03c8d3cd9 | |
parent | 3a29c33e821b78cad8b586c944fd182d363eda93 (diff) | |
parent | 25ea110c3814abcb824adb3619a44622ba8d2936 (diff) | |
download | samba-40ff67e4546780f422c01bb487921d93ac809def.tar.gz samba-40ff67e4546780f422c01bb487921d93ac809def.tar.bz2 samba-40ff67e4546780f422c01bb487921d93ac809def.zip |
Merge branch 'v4-0-local' of git://git.id10ts.net/samba into 4-0-local
(This used to be commit 0e429dd1fb15137a2a7c25e051b9af8c4ed8c7f3)
-rw-r--r-- | howto.txt | 2 | ||||
-rw-r--r-- | source4/scripting/python/samba/provision.py | 32 | ||||
-rw-r--r-- | source4/setup/named.conf | 135 | ||||
-rw-r--r-- | source4/setup/secrets_dc.ldif | 1 |
4 files changed, 135 insertions, 35 deletions
@@ -27,7 +27,7 @@ There are 2 methods of doing this: method 1: "rsync -avz samba.org::ftp/unpacked/samba_4_0_test/ samba4" - method 2: "git clone git://git.samba.org/samba.git samba4; cd samba4; git checkout v4-0-test; cd .." + method 2: "git clone git://git.samba.org/samba.git samba4; cd samba4 && git checkout -b v4-0-test origin/v4-0-test; cd .." both methods will create a directory called "samba4" in the current directory. If you don't have rsync or git then install one of them. diff --git a/source4/scripting/python/samba/provision.py b/source4/scripting/python/samba/provision.py index ad8eb8bffd..4818a79f00 100644 --- a/source4/scripting/python/samba/provision.py +++ b/source4/scripting/python/samba/provision.py @@ -236,6 +236,7 @@ def provision_paths_from_lp(lp, dnsdomain): paths.secrets = os.path.join(paths.private_dir, lp.get("secrets database") or "secrets.ldb") paths.templates = os.path.join(paths.private_dir, "templates.ldb") paths.dns = os.path.join(paths.private_dir, dnsdomain + ".zone") + paths.namedconf = os.path.join(paths.private_dir, "named.conf") paths.winsdb = os.path.join(paths.private_dir, "wins.ldb") paths.s4_ldapi_path = os.path.join(paths.private_dir, "ldapi") paths.phpldapadminconfig = os.path.join(paths.private_dir, @@ -1059,12 +1060,14 @@ def provision(setup_dir, message, session_info, scope=SCOPE_SUBTREE) assert isinstance(hostguid, str) - create_zone_file(paths.dns, setup_path, samdb, + create_zone_file(paths.dns, paths.namedconf, setup_path, samdb, hostname=names.hostname, hostip=hostip, hostip6=hostip6, dnsdomain=names.dnsdomain, domaindn=names.domaindn, dnspass=dnspass, realm=names.realm, - domainguid=domainguid, hostguid=hostguid) + domainguid=domainguid, hostguid=hostguid, + private_dir=paths.private_dir, keytab_name=paths.dns_keytab) message("Please install the zone located in %s into your DNS server" % paths.dns) + message("See %s if you want to use secure GSS-TSIG updates" % paths.namedconf) create_phpldapadmin_config(paths.phpldapadminconfig, setup_path, ldapi_url) @@ -1281,12 +1284,18 @@ def create_phpldapadmin_config(path, setup_path, ldapi_uri): {"S4_LDAPI_URI": ldapi_uri}) -def create_zone_file(path, setup_path, samdb, dnsdomain, domaindn, - hostip, hostip6, hostname, dnspass, realm, domainguid, hostguid): +def create_zone_file(path_zone, path_conf, setup_path, samdb, dnsdomain, domaindn, + hostip, hostip6, hostname, dnspass, realm, domainguid, hostguid, + private_dir, keytab_name): """Write out a DNS zone file, from the info in the current database. + + Also writes a file with stubs appropriate for a DNS configuration file + (including GSS-TSIG configuration), and details as to some of the other + configuration changes that may be necessary. - :param path: Path of the new file. - :param setup_path": Setup path function. + :param path_zone: Path of the new zone file. + :param path_conf: Path of the config stubs file. + :param setup_path: Setup path function. :param samdb: SamDB object :param dnsdomain: DNS Domain name :param domaindn: DN of the Domain @@ -1307,7 +1316,7 @@ def create_zone_file(path, setup_path, samdb, dnsdomain, domaindn, hostip6_base_line = " IN AAAA " + hostip6 hostip6_host_line = hostname + " IN AAAA " + hostip6 - setup_file(setup_path("provision.zone"), path, { + setup_file(setup_path("provision.zone"), path_zone, { "DNSPASS_B64": b64encode(dnspass), "HOSTNAME": hostname, "DNSDOMAIN": dnsdomain, @@ -1321,6 +1330,15 @@ def create_zone_file(path, setup_path, samdb, dnsdomain, domaindn, "HOSTIP6_HOST_LINE": hostip6_host_line, }) + setup_file(setup_path("named.conf"), path_conf, { + "DNSDOMAIN": dnsdomain, + "REALM": realm, + "REALM_WC": "*." + ".".join(realm.split(".")[1:]), + "HOSTNAME": hostname, + "DNS_KEYTAB": keytab_name, + "DNS_KEYTAB_ABS": os.path.join(private_dir, keytab_name), + }) + def load_schema(setup_path, samdb, schemadn, netbiosname, configdn, sitename): """Load schema for the SamDB. 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} |