Active Directory unter Root Domain mit externen DNS-Servern

Im folgenden wird beschrieben, wie das DNS für die Windows-Umgebung am KIT umgesetzt ist. Dabei wird am KIT die Domain “kit.edu” als Forest Root Domain im Active Directory genutzt. Die Zone “kit.edu” wird jedoch nicht im AD selbst verwaltet, sondern vom zentralen DNS-Service bereitgestellt. Die DNS-Funktionen des AD werden nicht genutzt.

Damit sich Clients trotzdem automatisch mit dem AD verbinden können, müssen einige DNS-Records in der Zone “kit.edu” eingerichtet sein.

Microsoft stellt entsprechende Dokumente bereit, in denen beschrieben ist, wie das Zusammenspiel zwischen DNS und AD aussieht und welche SRV-Records benötigt werden.

Beispiele für DNS-Records für einen Domain Controller am KIT sind in folgendem Zonenausschnitt zu sehen:

_gc._tcp.kit.edu.                                                      SRV   0 100 3268 dc-1.kit.edu.
_kerberos._tcp.kit.edu.                                                SRV   0 100   88 dc-1.kit.edu.
_kerberos._tcp.kit.edu.                                                SRV   0 100   88 dc-1.kit.edu.
_kpasswd._tcp.kit.edu.                                                 SRV   0 100  464 dc-1.kit.edu.
_kpasswd._udp.kit.edu.                                                 SRV   0 100  464 dc-1.kit.edu.
_ldap._tcp.kit.edu.                                                    SRV   0 100  389 dc-1.kit.edu.
_kerberos._tcp.ka._sites.dc                                            SRV   0 100   88 dc-1.kit.edu.
_ldap._tcp.ka._sites.dc                                                SRV   0 100  389 dc-1.kit.edu.
_kerberos._tcp.dc                                                      SRV   0 100   88 dc-1.kit.edu.
_ldap._tcp.dc                                                          SRV   0 100  389 dc-1.kit.edu.
_ldap._tcp.87654321-ba09-fedc-4321-edcba098765.domains._msdcs.kit.edu. SRV   0 100  389 dc-1.kit.edu.
_ldap._tcp.ka._sites.gc._msdcs.kit.edu.                                SRV   0 100 3268 dc-1.kit.edu.
_ldap._tcp.gc._msdcs.kit.edu.                                          SRV   0 100 3268 dc-1.kit.edu.
_gc._tcp.ka_sites.kit.edu.                                             SRV   0 100 3268 dc-1.kit.edu.
_kerberos._tcp.ka_sites.kit.edu.                                       SRV   0 100   88 dc-1.kit.edu.
_ldap._tcp.ka_sites.kit.edu.                                           SRV   0 100  389 dc-1.kit.edu.
gc._msdcs.kit.edu.                                                     AAAA  2001:db8::1
gc._msdcs.kit.edu.                                                     A     192.0.2.1
12345678-90ab-cdef-1234-567890abcdef._msdcs.kit.edu.                   CNAME dc-1.kit.edu.

In den oben genannten Artikeln ist beschrieben, wie man die DNS-Einträge bilden kann. Diese sind auch unter “systemroot\System32\Config\Netlogon.dns” zu finden. Microsoft stellt ein Dokument bereit, das beschreibt, wie man die Funktionalität prüfen kann. Am KIT werden die DNS-Einträge von einem Skript generiert.

Die AD-Testumgebung des KIT wird unter der Subdomain “adtest.kit.edu” nach dem selbem Prinzip wie für kit.edu betrieben. Alle genannten Konfigurationen sind entsprechend hierfür abgewandelt.

Da am KIT das Ziel ist, soweit wie möglich auf Split-DNS zu verzichten, gab es Probleme mit Clients außerhalb des KIT-Netzes: diese konnten die oben genannten Einträge im öffentlichen DNS abrufen, der Versuch einer Verbindung zu den Domain-Controllern schlug jedoch fehl, da diese nicht außerhalb des KIT-Netzes erreichbar sind. Dies führte dann zu langen Wartezeiten beim Login, da Windows erst nach mehreren Minuten auf den lokalen Cache zurückgreift.

Hierfür wurde am KIT eine dedizierte Split-DNS-Lösung ausgerollt, für die die folgenden Zonen auf separate Nameserver deligiert sind:

_gc._tcp.kit.edu.
_kerberos._tcp.kit.edu.
_kerberos._udp.kit.edu.
_kpasswd._tcp.kit.edu.
_kpasswd._udp.kit.edu.
_ldap._tcp.kit.edu.
_msdcs.kit.edu.
_sites.kit.edu.

Anfragen aus dem KIT-Netzwerk werden entsprechend der oben genannten Vorgaben beantwortet. Anfragen von außerhalb dem KIT-Netzwerks werden mit dem DNS Status Code “REFUSED” beantwortet. Die Clients nutzen dann direkt die lokale zwischengespeicherten Anmeldeinformationen und lange Wartezeiten beim Login werden vermieden.