bind+Samba4 verweigert Updates von DNS-Einträgen

Moin,

Auf unserem UCS-Master trinculo gibt’s Tonnen folgender Meldungen:

Apr 16 15:02:22 trinculo named[19275]: samba_dlz: starting transaction on zone bs.linet-services.de Apr 16 15:02:22 trinculo named[19275]: samba_dlz: disallowing update of signer=amarone\$\@BS.LINET-SERVICES.DE name=Amarone.bs.linet-services.de type=AAAA error=insufficient access rights Apr 16 15:02:22 trinculo named[19275]: client 10.199.92.13#59986: updating zone 'bs.linet-services.de/NONE': update failed: rejected by secure update (REFUSED) Apr 16 15:02:22 trinculo named[19275]: samba_dlz: cancelling transaction on zone bs.linet-services.de

Das gleiche Problem haben wir mit fast allen Windows-Rechnern und -Servern. amarone selber ist ein Windows 7, das Problem besteht aber auch mit Windows Server 2008, Windows 8.x. Alle Windows-Rechner sind in die Domäne gejoint. Die IP-Adresse für amarone ist ebenfalls korrekt:

[0 root@trinculo ~] host amarone.bs.linet-services.de amarone.bs.linet-services.de has address 10.199.92.13

Die Datei /var/lib/samba/private/named.conf.update:

/* this file is auto-generated - do not edit */ update-policy { grant BS.LINET-SERVICES.DE ms-self * A AAAA; grant Administrator@BS.LINET-SERVICES.DE wildcard * A AAAA SRV CNAME; grant TRINCULO$@bs.linet-services.de wildcard * A AAAA SRV CNAME; };

und sie wird in /etc/bind/named.conf.samba4 auch richtig includiert.

Es funktioniert eigentlich nur bei unserem Windows-2008-Server:

Apr 16 04:11:58 trinculo named[19275]: samba_dlz: starting transaction on zone bs.linet-services.de Apr 16 04:11:58 trinculo named[19275]: samba_dlz: allowing update of signer=equinox\$\@BS.LINET-SERVICES.DE name=equinox.bs.linet-services.de tcpaddr= type=AAAA key=1160-ms-7.247-1816e6ed.9e607b14-c15f-11e3-50a2-000c29dc13a5/160/0 Apr 16 04:11:58 trinculo named[19275]: samba_dlz: allowing update of signer=equinox\$\@BS.LINET-SERVICES.DE name=equinox.bs.linet-services.de tcpaddr= type=A key=1160-ms-7.247-1816e6ed.9e607b14-c15f-11e3-50a2-000c29dc13a5/160/0 Apr 16 04:11:58 trinculo named[19275]: samba_dlz: allowing update of signer=equinox\$\@BS.LINET-SERVICES.DE name=equinox.bs.linet-services.de tcpaddr= type=AAAA key=1160-ms-7.247-1816e6ed.9e607b14-c15f-11e3-50a2-000c29dc13a5/160/0 Apr 16 04:11:58 trinculo named[19275]: samba_dlz: allowing update of signer=equinox\$\@BS.LINET-SERVICES.DE name=equinox.bs.linet-services.de tcpaddr= type=AAAA key=1160-ms-7.247-1816e6ed.9e607b14-c15f-11e3-50a2-000c29dc13a5/160/0 Apr 16 04:11:58 trinculo named[19275]: samba_dlz: allowing update of signer=equinox\$\@BS.LINET-SERVICES.DE name=equinox.bs.linet-services.de tcpaddr= type=A key=1160-ms-7.247-1816e6ed.9e607b14-c15f-11e3-50a2-000c29dc13a5/160/0 Apr 16 04:11:58 trinculo named[19275]: client 10.199.93.20#57491: updating zone 'bs.linet-services.de/NONE': deleting rrset at 'equinox.bs.linet-services.de' AAAA Apr 16 04:11:58 trinculo named[19275]: samba_dlz: cancelling transaction on zone bs.linet-services.de

(Unter der Annahme, dass »cancelling transaction« am Ende trotzdem Erfolg bedeutet)

Im von mir ursprünglich verfassten [bug]34595[/bug] dazu tippte Stefan Gohmann darauf, dass die DNS-Einträge manuell als Admin angelegt wurden. Das trifft in der Tat zu. Nun ist für mich die Frage, wie ich das wieder geradeziehe.

Eigentlich mehrere Fragen.

  1. Wie fixe ich die Berechtigungen der DNS-Einträge, sodass auch die dynamischen Updates funktionieren? Alternativ, wie lösche ich die DNS-Einträge so, dass sie danach automatisch mit den richtigen Berechtigungen eingerichtet werden? Was ich vermeiden will ist, dass ich die Windows-Rechner allesamt aus der Domäne herauswerfen und wieder joinen muss…
  2. Warum erscheint in dem oben zitierten Beispiel die Meldung »cancelling transaction…«, obwohl alle darüber stehenden Einträge augenscheinlich erlaubt waren, und wie fixe ich das nun wieder?

Danke sehr.

MfG,
Moritz Bunkus

Hallo,

Für die DNS-Objekte gibt es in der Management Console den Modul “DNS”, dort kann man die jeweilige Zone öffnen und die Einträge rauslöschen, die jeweils zusammengehören (A = “Host Record” in der Forward Zone, und PTR = “Pointer Record” in der Reverse Zone). Das sollte eigentlich funktionieren.

Der Logeintrag “cancelling transaction” sieht für mich nicht gefährlich aus; Wenn die betreffenden Einträge trotzdem richtig aktualisiert wurden, würde ich ihn ignorieren.

viele Grüße
Frank Greif.

Moin,

Die Meldungen »cancelling transaction« sind alles andere als harmlos. Ein anderer unserer Windows-Rechner: »wasser«. Diesen hatte ich definitiv nicht manuell angelegt, sondern einfach nur in die Domäne gejoint.

Fehlermeldungen aus dem syslog:

May 13 09:01:07 trinculo named[19275]: samba_dlz: starting transaction on zone bs.linet-services.de May 13 09:01:07 trinculo named[19275]: samba_dlz: allowing update of signer=wasser\$\@BS.LINET-SERVICES.DE name=wasser.bs.linet-services.de tcpaddr= type=AAAA key=1364-ms-7.7-eddc1.3162053a-da6a-11e3-7599-c0cb38a784ca/160/0 May 13 09:01:07 trinculo named[19275]: samba_dlz: allowing update of signer=wasser\$\@BS.LINET-SERVICES.DE name=wasser.bs.linet-services.de tcpaddr= type=A key=1364-ms-7.7-eddc1.3162053a-da6a-11e3-7599-c0cb38a784ca/160/0 May 13 09:01:07 trinculo named[19275]: samba_dlz: allowing update of signer=wasser\$\@BS.LINET-SERVICES.DE name=wasser.bs.linet-services.de tcpaddr= type=AAAA key=1364-ms-7.7-eddc1.3162053a-da6a-11e3-7599-c0cb38a784ca/160/0 May 13 09:01:07 trinculo named[19275]: samba_dlz: allowing update of signer=wasser\$\@BS.LINET-SERVICES.DE name=wasser.bs.linet-services.de tcpaddr= type=AAAA key=1364-ms-7.7-eddc1.3162053a-da6a-11e3-7599-c0cb38a784ca/160/0 May 13 09:01:07 trinculo named[19275]: samba_dlz: allowing update of signer=wasser\$\@BS.LINET-SERVICES.DE name=wasser.bs.linet-services.de tcpaddr= type=A key=1364-ms-7.7-eddc1.3162053a-da6a-11e3-7599-c0cb38a784ca/160/0 May 13 09:01:07 trinculo named[19275]: client 10.199.92.127#55502: updating zone 'bs.linet-services.de/NONE': deleting rrset at 'wasser.bs.linet-services.de' AAAA May 13 09:01:07 trinculo named[19275]: samba_dlz: cancelling transaction on zone bs.linet-services.de

Und ja, das ist gefährlich, weil im AD (und damit im Bind) ausschließlich zwei AAAA-(IPv6-)Records vorhanden sind und nicht die A-(IPv4-)Records, die der Rechner ebenfalls hat.

Sprich: hier ist irgend etwas falsch, im Argen, wie auch immer.

UCR-Variable dns/backend steht auf samba4. Im AD stehen auch nur die zwei AAAA-Einträge:

[0 root@trinculo ~] ucr get dns/backend samba4 [0 root@trinculo ~] univention-s4search name=wasser|grep -i dnsrecord dnsRecord:: EAAcAAXwAAABAAAAAAADhAAAAAAAAAAAIAEG+BPcAAI5eCpnRpdMew== dnsRecord:: EAAcAAXwAAABAAAAAAADhAAAAAAAAAAA/QEG+BPcAAI5eCpnRpdMew==

Noch irgendwelche Ideen, wo ich nachforschen könnte?

Hallo!

dieses Verhalten konnte im Rahmen von Univention Corporate Server 3.2 Erratum 117 verbessert werden:

[quote=" Univention Corporate Server 3.2 Erratum 117"]
[…]

  • DNS updates of records with existing IPv6 addresses have been fixed.
    […]
    [/quote]

Mit freundlichen Grüßen,
Tim Petersen

Jup, ich hatte dazu Kontakt mit dem Univention-Support. Das Errate habe ich vorhin eingespielt und teste momentan.

Guten Tag,

auf unserem UCS (4.1-2 errata204) finden sich dieselben, in diesem Post genannten Fehlermeldungen, die von versuchten DNS-Einträgen Updates von Windows 8.1-Clients herrühren.

Beispiel für Windows-Client “AgentSmith”

Jul  1 14:11:09 odin named[3214]: samba_dlz: starting transaction on zone s3-domain.intra
Jul  1 14:11:09 odin named[3214]: client 10.101.212.25#53282: update 's3-domain.intra/IN' denied
Jul  1 14:11:09 odin named[3214]: samba_dlz: cancelling transaction on zone s3-domain.intra
Jul  1 14:11:09 odin named[3214]: samba_dlz: starting transaction on zone s3-domain.intra
Jul  1 14:11:09 odin named[3214]: samba_dlz: disallowing update of signer=AgentSmith\$\@S3-DOMAIN.INTRA name=AgentSmith.s3-domain.intra type=AAAA error=insufficient access rights
Jul  1 14:11:09 odin named[3214]: client 10.101.212.25#49217: updating zone 's3-domain.intra/NONE': update failed:rejected by secure update (REFUSED)
Jul  1 14:11:09 odin named[3214]: samba_dlz: cancelling transaction on zone s3-domain.intra

Gibt er hier eine empfohlene Vorgehensweise?

Aus diesen Einträgen kann ich keine Vorgehensweise ableiten:

Die DNS Objekte sind nicht “mit einem administrativem Account angelegt worden” (forge.univention.org/bugzilla/s … i?id=34595)

danke,
Mit freundlichen Grüßen,

Axel Voigt
Schul-Support-Service e.V.
Große Weidestraße 4-16, 28195 Bremen
Hotline: 0421-361-6600, Mo-Fr 7.30 - 15.30 Uhr
schul-support-service.de

Moin,

wir haben das Problem durchaus auch noch. Ich habe leider keine Lösung anzubieten. Vielleicht sollten Sie noch mal einen Bugeintrag erstellen; aktuell finde ich nur diesen hier, der aber für PTR-Records gilt, nicht für AAAA wie bei Ihnen und uns.

Haben Sie schon mal versucht, das Rechnerobjekt samt dazugehöriger IPv4- und IPv6-DNS-Einträge zu löschen und den Rechner neu in die Domäne zu joinen? Nicht, dass ich das für eine große Anzahl von Rechnern empfehlen würde, aber ob es dann geht würde Hinweise darauf geben, was genau kaputt ist.

Gruß,
mosu

Moin,

danke für die Antwort!

Tatsächlich,

  • Austritt des Rechners aus der Domäne
  • Löschen des Rechnerobjekts (nicht aber weiterer Einträge)
  • und Rejoin
    scheint eine Lösung zu sein.

Eintrag im syslog nun bei jedem Neustart des Rechners (“Hotline2”):

Jul  4 14:36:54 odin named[3214]: samba_dlz: starting transaction on zone s3-domain.intra
Jul  4 14:36:54 odin named[3214]: client 10.101.212.24#50780: update 's3-domain.intra/IN' denied
Jul  4 14:36:54 odin named[3214]: samba_dlz: cancelling transaction on zone s3-domain.intra
Jul  4 14:36:54 odin named[3214]: samba_dlz: starting transaction on zone s3-domain.intra
Jul  4 14:36:54 odin named[3214]: samba_dlz: allowing update of signer=HOTLINE2\$\@S3-DOMAIN.INTRA name=Hotline2.s3-domain.intra tcpaddr= type=AAAA key=844-ms-7.1-592c.fc8c39d8-41e3-11e6-c382-901b0e5f2e91/160/0
Jul  4 14:36:54 odin named[3214]: samba_dlz: allowing update of signer=HOTLINE2\$\@S3-DOMAIN.INTRA name=Hotline2.s3-domain.intra tcpaddr= type=A key=844-ms-7.1-592c.fc8c39d8-41e3-11e6-c382-901b0e5f2e91/160/0
Jul  4 14:36:54 odin named[3214]: samba_dlz: allowing update of signer=HOTLINE2\$\@S3-DOMAIN.INTRA name=Hotline2.s3-domain.intra tcpaddr= type=A key=844-ms-7.1-592c.fc8c39d8-41e3-11e6-c382-901b0e5f2e91/160/0
Jul  4 14:36:54 odin named[3214]: client 10.101.212.24#64872: updating zone 's3-domain.intra/NONE': deleting rrset at 'Hotline2.s3-domain.intra' AAAA
Jul  4 14:36:54 odin named[3214]: client 10.101.212.24#64872: updating zone 's3-domain.intra/NONE': deleting rrset at 'Hotline2.s3-domain.intra' A
Jul  4 14:36:54 odin named[3214]: samba_dlz: subtracted rdataset Hotline2.s3-domain.intra 'Hotline2.s3-domain.intra.#0111200#011IN#011A#01110.101.212.24'
Jul  4 14:36:54 odin named[3214]: client 10.101.212.24#64872: updating zone 's3-domain.intra/NONE': adding an RR at 'Hotline2.s3-domain.intra' A
Jul  4 14:36:54 odin named[3214]: samba_dlz: added rdataset Hotline2.s3-domain.intra 'Hotline2.s3-domain.intra.#0111200#011IN#011A#01110.101.212.24'
Jul  4 14:36:54 odin named[3214]: samba_dlz: committed transaction on zone s3-domain.intra

Aber es muss doch eine elegantere Lösung geben?
univention liest doch dieses Forum auch mit …?

danke und Gruß,
Axel Voigt

Moin,

es kann sein, dass dieser Bugeintrag auch bei Ihen zutrifft. Leider kenne ich keinen Weg, den ntSecurityDescriptor manuell neu/richtig zu setzen (um das mal auszuprobieren), außer den Rechner neu zu joinen.

Vielleicht hat noch jemand von Univention eine Idee.

LG,
mosu

Gibts was neues in der Sache? Mir sind die Meldungen bei mir jetzt auch aufgefallen.

Vorab: Mit UCS 4.2-2 Erratum 43 wurde das hier beschriebene Verhalten produktseitig angepasst

Wenn ein Windows-Client z.B. per DHCP dynamisch eine IP-Adresse zugewiesen bekommt und später dann eine andere, so de-registriert er die alte IP-Adresse im DNS auch wieder.

Das Problem, welches am Bug gefixed wurde ist:

In Samba/AD werden gelöschte DNS-Objekte erst einmal nur als DNS_TYPE_TOMBSTONE markiert, die aber weiterhin per DS-ACL (im ntSecurityDescriptor) ihrem früheren Besitzer gehören. Dadurch konnten neue Clients den DNS-Record dann nicht für sich reklamieren, wenn sie später die entsprechende IP-Adresse zugewiesen bekommen haben. Dieses Problem betraf jedoch nur Reverse-DNS-Records. Bei Forward-Records bleibt die Zuordnung “DNS-Name” zu Rechner ja erhalten, jedenfalls bei der Verwendung von DHCP.
Zusätzlich haben wir dort eingebaut, dass wenn sich ein Rechner gegenüber Samba/Kerberos authentifizieren kann, dann darf er den entsprechenden DNS-Record schreiben, auch wenn bereits ein gleichnamiger Eintrag vorhanden ist, der ihm eigentlich von der SID her nicht gehört. Das löst Probleme, wenn ein Client durch einen anderen ersetzt wird (bzw. das Rechnerobjekt entfernt und dann neu gejoined wird).

Mastodon