ich nutze zwei BIND9-Server (=192.168.0.1 + 192.168.0.2) auf Debian Squeeze Basis (primary+secondary). Sämtliche Clients haben in ihrer Netzwerkconfig diese zwei DNS-Server eingetragen. Nun möchte ich mit Samba4 einen neuen Active-Directory Domänencontroller erstellen (=192.168.0.100). Der hat einen internen DNS-Server am Laufen. Es gibt drei Möglichkeiten die Kommunikation zwischen meinem bestehenden BIND9 und dem AD-DC zu bewerkstelligen. Zwei dieser Optionen fallen weg, weswegen ich gerne die dritte nutzen möchte und zwar folgende:
Alle Anfragen der Clients die was mit AD zu tun haben, müssen den Samba4-Server (IP= .100) erreichen können. Deshalb muss ich meinem BIND9 beibringen, dass alle AD-relevanten Anfragen an die 192.168.0.100 weitergeleitet werden sollen. Sollte ich an diesem Schritt schon falsch liegen, so bitte ich um Korrektur.
Meine bestehende BIND9-Konfiguration sieht wie folgt aus:
/etc/bind9/named.conf.local:
Code: Alles auswählen
include "/etc/bind/secret.key";
controls {
inet 127.0.0.1 allow {localhost; } keys { "secret-key"; };
};
#meine statische Zonen
zone "mycompany.de" {
type master;
file "/var/cache/bind/forwardzone.mycompany.de";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/var/cache/bind/reversezone.192.168.0";
};
[...hier folgen noch meine dynamischen Zonen für DHCP, ist aber irrelevant...]
Code: Alles auswählen
options {
directory "/var/cache/bind";
auth-nxdomain no; # conform to RFC1035
# ich erlaube meinem secondary ns2 Zonentransfers zu erhalten
allow-transfer { 192.168.0.2; };
notify yes;
query-source address * ;
listen-on-v6 { none; };
version "GET LOST !!!";
allow-query {
127.0.0.1;
192.168.0.0/24;
10.0.0.0/24; <-- ist für meine VPN-Clients
};
recursion yes;
allow-recursion {
127.0.0.1;
192.168.0.0/24;
10.0.0.0/24;
};
forwarders {
192.168.0.254; ;das ist meine Hardware-Firewall IPCop
};
forward only;
};
Code: Alles auswählen
$TTL 1W ; 1 week
@ IN SOA derprimary.mycompany.de. admin.mycompany.de. (
2012121801 ; serial
8H ; refresh time
2H ; retry time
4W ; expire
11H ; minimum negative cache
)
NS derprimary.mycompany.de.
NS dersecondary.mycompany.de.
derprimary A 192.168.0.1
dersecondary A 192.168.0.2
rechner1 A 192.168.0.61
xyzmachine A 192.168.0.77
Ich bin mir nun nicht sicher, ob ich für meinen neuen AD-Controller die realm "ad.mycompany.de" nutzen sollte und als Domänenname "AD", oder doch lieber die realm "mycompany.lan" und Domänenname "AD". Was empfiehlt sich hier, um keine zukünftige Komplikationen zu begegnen?
Und dann bin ich mir nicht sicher, wie ich meine config ergänzen muss, um diese neue Zone fürs AD einzurichten. Ich denke hier an zwei Lösungsansätze
(Möglichkeit A)
Wenn ich statt meiner bisherigen mycompany.de DNS-Domäne für die neue AD-Domäne einfach mycompany.lan verwenden würde (siehe oben), so könnte ich ja einfachhalber eine neue Zone in meiner BIND9-Config hinzufügen, á-la:
Code: Alles auswählen
[...]
zone "mycompany.lan" {
type master;
file "forwardzone.mycompany.lan";
forwarders { };
};
Code: Alles auswählen
$TTL 1W ; 1 week
@ IN SOA derprimary.mycompany.de. admin.mycompany.de. (
2012121801 ; serial
8H ; refresh time
2H ; retry time
4W ; expire
11H ; minimum negative cache
)
NS derprimary.mycompany.de.
NS dersecondary.mycompany.de.
$ORIGIN mycompany.lan.
@ NS dc1.mydomain.lan.
dc1 A 192.168.0.100
-oder-
**(Möglichkeit B)**
Ich behalte meine DNS-Struktur bei integriere meinen neuen AD in diese Domäne hinein, indem der neue Domänencontroller dc1 die Domäne ad.mycompany.de nutzt (realm=ad.mycompany.de, Domänenname=AD). Somit bleib ich in meiner vorhandenen DNS-Zone mycompany.de
Also müsste ich explizit alle AD-relevanten Abfragen herauspicken und explizit diese nur an den 192.168.0.100 (=dc1) senden. Ich dachte dabei an folgende config, nachdem ich mir dieses Microsoft WhitePaper angeschaut habe (http://technet.microsoft.com/en-us/libr ... 16373.aspx):
Ich dachte, damit in Zukunft weitere DCs dynamisch schreiben dürfen, erstelle ich lieber eine neue Zone, extra für ad.mycompany.de. Ich könnte natürlich auch meine vorhandene Zone mycompany.de nutzen, aber wenn BIND9 dynamisch in Zonenfiles reinschreibt, dann würfelt er die Anordnung total durcheinander und das kann schnell unübersichtlich werden ( siehe DHCP-Zonenfiles
). Also erstelle ich eine extra Zone mit extra Datei:ich füge in meine bestehende /etc/bind/named.conf.local eine neue Zone ein:
Code: Alles auswählen
zone "ad.mycompany.de" {
type master;
file "/var/cache/bind/forwardzone.ad";
allow-update { 192.168.0.101; }; <== die .101 soll später der dc2 werden, und der soll dyn. updaten dürfen
check-names ignore;
};
Code: Alles auswählen
$TTL 1W ; 1 week
@ IN SOA derprimary.mycompany.de. admin.mycompany.de. (
2012121801 ; serial
8H ; refresh time
2H ; retry time
4W ; expire
11H ; minimum negative cache
)
NS derprimary.mycompany.de.
NS dersecondary.mycompany.de.
dc1.mycompany.de. A 192.168.0.100
_ldap._tcp.ad.mycompany.de. SRV 0 0 389 dc1.ad.mycompany.de.
_kerberos._tcp.ad.mycompany.de. SRV 0 0 88 dc1.ad.mycompany.de.
_ldap._tcp.dc_msdcs.ad.mycompany.de. SRV 0 0 389 dc1.ad.mycompany.de.
_kerberos._tcp.dc._msdcs.ad.mycompany.de. SRV 0 0 88 dc1.ad.mycompany.de.
gc._mscds.ad.mycompany.de. SRV 0 0 3268 dc1.ad.mycompany.de.
Ich würde mich freuen wenn sich ein DNS Profi hier zu Wort melden könnte, und mir feedback zu diesem Vorhaben oder Thematik geben könnte. Recht herzlichen Dank im Voraus.
EDIT: Ich habe im Netz auch schon Setups gesehen, die ganz anders aussehen, indem solche Direktiven zum Einsatz kommen:
Grüße,
Pangu.