Univention Bugzilla – Bug 23161
Konfiguration für Dynamische DNS Updates in Samba4
Last modified: 2011-12-13 15:50:41 CET
Für Samba4 http://wiki.samba.org/index.php/Samba4/HOWTO#Step_10_Configure_kerberos_DNS_dynamic_updates sollte getestet werden, ob dynamische DNS updates gegen Port 53 im UCS-Setup überhaupt funktionieren. Theoretisch vermutlich eher nicht?! Wenn man das aufsetzen will, müsste vermutlich das Template /etc/univention/templates/files/etc/bind/named.conf so angepasst werden, dass es eine include-Datei /etc/bind/samba4.conf einbindet, falls diese existiert. Diese include-Datei sollte dann mit folgendem Inhalt durch das Paket univention-samba4 installiert werden: options { tkey-gssapi-credential "DNS/@%@domainname@%@"; tkey-domain "@%@kerberos/realm@%@"; }; Damit der bind9 named dann auch weiterhin starten kann, muss das Script /etc/runit/univention-bind/run um folgende Zeilen erweitert werden: KRB5_KTNAME="/var/lib/samba/private/dns.keytab" export KRB5_KTNAME Analoges gilt ggf. für den bind-proxy.
Siehe auch Bug 23168
1. samba_dnsupdate --verbose benötigt das Tool /usr/bin/nsupdate aus dem Paket dnsutils. 2. Man kann den Port dafür per smb.conf Option setzen: "nsupdate command = /usr/bin/nsupdate -g -p 7777"
Es scheint mir, als könne /usr/bin/nsupdate einfach nicht mit unsren Bind-LDAP-Patches funktionieren, da bzw. falls diese keinen Write-Support haben. Als Alternative wäre es zwar denkbar, den DLZ LDAP driver aus Bind9 zu verwenden ( http://bind-dlz.sourceforge.net/ldap_driver.html ), um Bind9 an OpenLDAP anzubinden, aber auch der scheint read-only zu sein ( siehe Abschnitt "dynamic updates and DLZ" in http://blog.tridgell.net/?cat=5 ). Für mich sieht es daher im Moment so aus, als müsse man im Samba4-Setup für Dynamische DNS Updates den Bind9-Server per dlz-dlopen (Bug #23168) an das Samba-LDB-Backend anbinden, statt wie bisher an OpenLDAP. Für UDM müssen dann die DNS-Objekte synchronisiert werden.
Created attachment 3440 [details] Seit Bind 9.8.0 gibt es die Option tkey-gssapi-keytab, die die Optionen tkey-gssapi-credential und tkey-domain ersetzt.
Wenn der parallele Betrieb von S4 und AD nicht unterstützt wird, dann muss IMHO das DNS Update auch nicht funktionieren. Erneutes prüfen zum RC, siehe auch Bug #22863.
Created attachment 3548 [details] Dokumentation der Schritte zum Test von nsupdate. Momentan scheitert samba_dnsupdate noch, inzwischen bin ich jedoch einen Schritt weiter: Bisher bekam ich immer die Fehlermeldung "dns_tkey_negotiategss: TKEY is unacceptable", und das hat anscheinend daran gelegen, das das Kerberos-Ticket, das nsupdate sich für die Bind-Anfrage holt, einen inkompatiblen Encryption-Type hat (siehe man nsupdate). Wenn man in /etc/krb5.conf in der Liste der "default_tkt_enctypes" den enctype "arcfour-hmac-md5" nach vorne zieht, dann scheint die TSIG/GSS-Authentifikation schonmal erfolgreich abzulaufen. Die Schritte zum Testen sind im Anhang beschrieben. Leider erhält man dann die Meldung "update failed: NOTAUTH" von nsupdate bzw. von bind. Entweder die Authentifikation war dann doch nicht erfolgreich (unwahrscheinlich) oder in der DNS-Zone sind für den Kerberos-Prinzipal keine Update-Rechte definiert (siehe /var/lib/samba/private/named.conf.update).
Created attachment 3549 [details] Beiepiel-Debug-Output von nsupdate -g -D
Created attachment 3550 [details] Beispiel-Debug-Output von nsupdate -g -D , in dem man "tsig verification successful" sieht.
Mit der aktuellen UCS 3.0 DVD war folgendes möglich: - nach der Installation samba4 als bind Backend konfigurieren: ucr set dns/backend=samba4 /etc/init.d/bind9 restart - DHCP Objekt für einen Windows Client anlegen - Windows 7 booten und die IP Adresse per DHCP beziehen - In der Windows Netzwerkkonfiguration "automatische DNS Registrierung aktivieren" - Windows 7 Client joinen und neu starten - Beim nächsten Boot hat der Windows 7 Client ein DNS Update durchgeführt: Oct 15 23:10:32 master51 named[1737]: samba_dlz: starting transaction on zone deadlock5.local Oct 15 23:10:32 master51 named[1737]: client 10.201.5.30#51104: update 'deadlock5.local/IN' denied Oct 15 23:10:32 master51 named[1737]: samba_dlz: cancelling transaction on zone deadlock5.local Oct 15 23:10:32 master51 named[1737]: samba_dlz: starting transaction on zone deadlock5.local Oct 15 23:10:32 master51 named[1737]: samba_dlz: allowing update of signer=win7pro\$\@DEADLOCK5.LOCAL name=win7pro.deadlock5.local tcpaddr= type=AAAA key=316-ms-7.1-6f55.d80ed1e0-f76e-11e0-c191-525400bfc415/160/0 keydatalen=1586 Oct 15 23:10:32 master51 named[1737]: samba_dlz: allowing update of signer=win7pro\$\@DEADLOCK5.LOCAL name=win7pro.deadlock5.local tcpaddr= type=A key=316-ms-7.1-6f55.d80ed1e0-f76e-11e0-c191-525400bfc415/160/0 keydatalen=1586 Oct 15 23:10:32 master51 named[1737]: samba_dlz: allowing update of signer=win7pro\$\@DEADLOCK5.LOCAL name=win7pro.deadlock5.local tcpaddr= type=A key=316-ms-7.1-6f55.d80ed1e0-f76e-11e0-c191-525400bfc415/160/0 keydatalen=1586 Oct 15 23:10:32 master51 named[1737]: client 10.201.5.30#52975: updating zone 'deadlock5.local/NONE': deleting rrset at 'win7pro.deadlock5.local' AAAA Oct 15 23:10:32 master51 named[1737]: client 10.201.5.30#52975: updating zone 'deadlock5.local/NONE': deleting rrset at 'win7pro.deadlock5.local' A Oct 15 23:10:32 master51 named[1737]: client 10.201.5.30#52975: updating zone 'deadlock5.local/NONE': adding an RR at 'win7pro.deadlock5.local' A Oct 15 23:10:32 master51 named[1737]: samba_dlz: added win7pro.deadlock5.local win7pro.deadlock5.local.#0111200#011IN#011A#01110.201.5.30 Oct 15 23:10:32 master51 named[1737]: samba_dlz: subtracted rdataset deadlock5.local 'deadlock5.local.#01110800#011IN#011SOA#011master51.deadlock5.local. root.deadlock5.local. 29 28800 7200 604800 0' Oct 15 23:10:32 master51 named[1737]: samba_dlz: added rdataset deadlock5.local 'deadlock5.local.#01110800#011IN#011SOA#011master51.deadlock5.local. root.deadlock5.local. 30 28800 7200 604800 0' Oct 15 23:10:32 master51 named[1737]: samba_dlz: committed transaction on zone deadlock5.local - Anschließend war der Name per host auflösbar: root@master51:~# host win7pro.deadlock5.local win7pro.deadlock5.local has address 10.201.5.30
Das S4-Backend ist für Samba 4 Systeme jetzt default. Damit funktioniert es Out-of-the-Box. Changelog nicht notwendig.
Beim Test mit einem Windows7 IPv6-only Client erhielt ich nach dem erfolgreichen Join eine Fehlermeldung bzgl. Fehlgeschlagener DNS-Registrierung. Serverseitig war trotzdem ein DNS-Record für den Client angelegt worden mit der korrekten IPv6-Adresse. Setup siehe Bug 24875. Im Syslog des Masters steht: Nov 24 19:14:58 master140 named[6976]: samba_dlz: starting transaction on zone arucs3rci5.qa Nov 24 19:14:58 master140 named[6976]: client 2001:4dd0:ff00:8c42:ff08::144#63478: update 'arucs3rci5.qa/IN' denied Nov 24 19:14:58 master140 named[6976]: samba_dlz: cancelling transaction on zone arucs3rci5.qa Nov 24 19:14:58 master140 named[6976]: samba_dlz: starting transaction on zone arucs3rci5.qa Nov 24 19:14:58 master140 named[6976]: samba_dlz: allowing update of signer=win7pro\$\@ARUCS3RCI5.QA name=WIN7PRO.a rucs3rci5.qa tcpaddr= type=AAAA key=1008-ms-7.2-5acf1.0378d280-16bf-11e1-90a7-525400b72d46/160/0 keydatalen=1579 Nov 24 19:14:58 master140 named[6976]: client 2001:4dd0:ff00:8c42:ff08::144#52861: updating zone 'arucs3rci5.qa/NON E': deleting an RR at WIN7PRO.arucs3rci5.qa AAAA Nov 24 19:14:59 master140 named[6976]: samba_dlz: cancelling transaction on zone arucs3rci5.qa
Wenn ich dem Wind7-Client IPv4 und IPv6 Adressen gebe, erhalte ich die gleiche Meldung, aber beide Adressen sind dann korrekt am neuen DNS-Objekt notiert.
Kannst du aus den Logs erkennen, ob er auch gegen den Master gejoint hat?
(In reply to comment #11) > Beim Test mit einem Windows7 IPv6-only Client erhielt ich nach dem > erfolgreichen Join eine Fehlermeldung bzgl. Fehlgeschlagener DNS-Registrierung. > Serverseitig war trotzdem ein DNS-Record für den Client angelegt worden mit der > korrekten IPv6-Adresse. Setup siehe Bug 24875. Kein Blocker für 3.0; neuer Bug: Bug #24880.
Zu Comment 13: Kann ich gerade nicht mehr sehen (hatte aber zumindest immer nur den Master als DNS-Server eingetragen, was für den Registrierungsschritt ja entscheidend sein sollte). Mit IPv4 funktioniert die Registrierung in der Forward-Zone und im Mixed-Setup ebenfalls, siehe auch Bug 24880#c1. Die Konfiguration berücksichtigt alle bekannterweise notwendigen Samba4-Einstellungen für das nsupdate-Setup (tkey-gssapi, Grant und check-names). Rechte für die Reverse-Zone sind in unserer Samba4-DNS-Konfiguration im Moment nicht gewährt, aber das ist auch als optionale Einstellung dokumentiert.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"