DDI/docs/ACTIVE-DIRECTORY.md

Active Directory mit dynamischen Zonen

Diese Anleitung beschreibt, wie die DNS-Zonen einer Active-Directory-Domäne (AD) auf den von der DDI Suite verwalteten BIND-Servern liegen. Grundlage ist ADR 0023.

Grundsatz

Domain Controller (DC) registrieren ihre Einträge selbst per RFC-2136-Update (dynamisches DNS): A-Records der DCs, SRV-Records für LDAP, Kerberos und den globalen Katalog sowie die Einträge unter _msdcs. Die Zone der AD-Domäne muss deshalb eine dynamische Zone sein. Bei dynamischen Zonen gilt:

• Der DNS-Agent legt die Zone in BIND an und schreibt nur beim ersten Mal eine Anfangsdatei. Danach gehören Zonendatei und Journal BIND; die DDI Suite überschreibt sie nie.
• Records, die Sie in der Oberfläche für eine dynamische Zone anlegen, landen nur in dieser Anfangsdatei. Spätere Änderungen an ihnen wirken auf bestehenden Servern nicht.
• Updates werden nur von den eingetragenen Quellen angenommen: IP-Adressen bzw. Netze (allow_update) und/oder TSIG-Schlüssel.

Nicht unterstützt (Version 1): GSS-TSIG (Kerberos-gesicherte „sichere“ Updates, wie sie AD-integrierte Microsoft-DNS-Server verwenden). Updates werden daher über die IP-Adressen der DCs oder über TSIG abgesichert.

Einrichtung

1. Zone anlegen (Zonen → Neue Zone): Name der AD-Domäne, z. B. ad.example.com, Modus dynamisch, DNS-Cluster wählen.
2. Update-Quellen eintragen: die IP-Adressen aller Domain Controller als /32 bzw. /128, z. B. 192.0.2.10/32 und 192.0.2.11/32. Keine ganzen Client-Netze eintragen – sonst kann jeder Rechner darin Einträge der Domäne überschreiben.
3. _msdcs: Die Einträge unter _msdcs.ad.example.com gehören in dieselbe dynamische Zone. Eine eigene Zone _msdcs.… ist nicht nötig (und wird nicht abgeleitet); die DCs legen die Records darin selbst an.
4. Reverse-Zonen: Sollen DCs oder Clients auch PTR-Records eintragen, die betroffene Reverse-Zone ebenfalls als dynamische Zone anlegen (z. B. 2.0.192.in-addr.arpa) und dieselben Update-Quellen eintragen. Reverse-Zonen von Netzen, deren Adressen die DDI Suite verwaltet, bleiben besser managed.
5. Revision erzeugen und ausrollen. Der Primary des Clusters nimmt die Updates an, die Secondaries erhalten die Änderungen per NOTIFY und IXFR.
6. Windows-Seite: Auf den DCs als DNS-Server die Adressen der BIND-Server eintragen. In den DNS-Einstellungen der Netzwerkkarte „Adressen dieser Verbindung in DNS registrieren“ aktiv lassen. Die DCs schicken Updates an den Server aus dem SOA-Record (MNAME) der Zone; das ist der Primary des Clusters (bzw. primary_ns).

Prüfen lässt sich die Registrierung nach einem Neustart des Dienstes „Netlogon“ auf einem DC (nltest /dsregdns) mit:

dig @<primary> SRV _ldap._tcp.dc._msdcs.ad.example.com

Updates mit TSIG

Statt über IP-Adressen lassen sich Updates mit einem TSIG-Schlüssel absichern, etwa für DHCP-Server, Skripte oder nsupdate:

1. TSIG-Schlüssel → Neuer Schlüssel (Algorithmus hmac-sha256).
2. In der dynamischen Zone den Schlüssel unter „Update-Schlüssel“ auswählen.
3. Geheimnis anzeigen (nur Administratoren, wird protokolliert) und beim Client hinterlegen, z. B. für nsupdate:

key "updater.ad.example.com" {
    algorithm hmac-sha256;
    secret "<Geheimnis>";
};

nsupdate -k updater.key <<EOF
server <primary>
zone ad.example.com
update add host1.ad.example.com. 3600 A 192.0.2.50
send
EOF

Microsoft-Clients und -DCs beherrschen TSIG nicht; für sie bleibt nur die Freigabe per IP-Adresse.

Hinweise

• Wird eine dynamische Zone gelöscht oder einem anderen Cluster zugeordnet, entfernt der Agent den Zonenblock aus der Konfiguration, löscht aber Zonendatei und Journal nicht. Die Daten liegen weiter im Zonenverzeichnis des Servers.
• Eine Zone von managed auf dynamic umzustellen ist möglich: Die vorhandene Zonendatei bleibt bestehen und wird ab dann von BIND gepflegt. Der umgekehrte Weg verwirft alle per Update angelegten Records.
• Scavenging (Aufräumen veralteter dynamischer Einträge) übernimmt BIND nicht; veraltete Records müssen per nsupdate entfernt werden.