9Netzwerkdienste im AD-Umfeld

Nur Maultier’ erlegt’ er zuerst und hurtige Hunde:
Doch nun gegen sie selbst das herbe Geschoß hinwendend,
Traf er; und rastlos brannten die Totenfeuer in Menge.
Schon neun Tage durchflogen das Heer die Geschosse des Gottes.

In diesem Kapitel geht es um zwei ganz wesentliche Dienste: DNS und DHCP. Ohne DNS ist ein Active Directory nicht lebensfähig, und DHCP ist, obwohl es für den Betrieb des AD an sich nicht notwendig ist, in den meisten Unternehmen im Einsatz.

Die Grundfunktionen der Dienste sind in Abschnitt 4.3.1 und in Abschnitt 4.3.3 erläutert worden, sodass wir an dieser Stelle direkt in die Konfiguration einsteigen können.

9.1 DNS

Über den Sinn und Zweck von DNS braucht man nicht lange zu philosophieren: DNS macht aus Namen IP-Adressen. Wenn Sie den ersten Domänencontroller installieren, wird der DNS-Server im Normalfall mehr oder weniger automatisch mitinstalliert, sodass sich viele Administratoren nicht sonderlich viele Gedanken über dieses Thema machen. Da ein einwandfrei funktionierendes DNS für das Active Directory aber extrem wichtig ist, kann ein wenig Hintergrundwissen durchaus nicht schaden.

9.1.1 Zonen

Ein wichtiger Begriff im DNS-Umfeld ist die Zone. Eine Zone beschreibt – vereinfacht gesagt – den Namensraum, für den der DNS-Server »zuständig« ist. Diese sehr abstrakte Betrachtung lässt sich durch einen wesentlichen »physikalischen« Aspekt ergänzen: Ein DNS-Server verfügt für sein(e) Zone(n) über die »Quelldaten«, also die Informationen, welcher Host über welche IP-Adresse verfügt.

Sie können in Abbildung 9.1 erkennen, dass ein »typischer« DNS-Server in einer Active Directory-Umgebung über mehrere Zonen verfügt. In diesem Beispiel sind dies:

• _msdcs.ubinf.intra: Dies ist die ForestDNSZone, die etliche Diensteinträge für die Gesamtstruktur enthält.
• ubinf.intra: Diese DNS-Zone enthält die Namensauflösungsdaten für die eine »normale« Domäne.
• 2.168.192.in-addr.arpa ist eine Reverse-Lookupzone, die dazu dient, zu einer IP-Adresse den Hostnamen zu ermitteln. Eine Reverse-Lookupzone ist optional. Es empfiehlt sich aber durchaus, eine solche Zone einzurichten.

Je nach Aufbau der Umgebung können durchaus noch weitere Zonen auf dem Host existieren.

Abbildung 9.1 Auf einem DNS-Server gibt es mehrere Zonen.

Zonentypen (primär, sekundär, Active Directory-integriert)

In (fast) allen Bereichen der IT kommt es darauf an, dass Dienste, wie beispielsweise DNS, nicht ausfallen. Der einfachste Ansatz ist, dass ein Dienst einfach auf zwei oder mehr Servern installiert wird – fällt einer aus, übernimmt der andere (oder übernehmen die anderen) die Aufgabe.

Es reicht natürlich nicht, einfach einen zweiten DNS-Server zu installieren. Dieser muss natürlich auch die Daten der Zone erhalten. Klassischerweise wird dies wie in Abbildung 9.2 gezeigt realisiert:

• Ein Server verfügt über die primäre DNS-Zone.
• Auf einem oder mehreren anderen Servern ist eine sekundäre Zone eingerichtet.
• Über regelmäßige Zonentransfers werden die Daten von der primären Zone auf die sekundären Zonen übertragen.
• Folglich kann der Client jeden beliebigen, also den primären oder einen der sekundären DNS-Server kontaktieren, um die Namensauflösung für diese Zone durchzuführen.

Abbildung 9.2 Klassischerweise erhalten die DNS-Server mit sekundärer Zone die Daten über Zonentransfers.

In einer Active Directory-Umgebung geht es allerdings noch ein wenig eleganter, da Sie mit Active Directory-integrierten Zonen arbeiten können. Das Verfahren ist in Abbildung 9.3 skizziert. Kurz gesagt werden die Zonendaten über die Replikationsmechanismen des Active Directory verteilt.

Die Vorteile liegen auf der Hand:

• Man braucht sich keinerlei Gedanken über Zonentransfers und dergleichen zu machen.
• Die Replikationsmechanismen des Active Directory (AD) sind sehr effizient.

Abbildung 9.3 Bei der Verwendung einer Active Directory-integrierten Zone werden die Zonendaten über die Replikationsmechanismen des Active Directory verteilt.

Die Voraussetzung für die Nutzung von Active Directory-integrierten Zonen ist allerdings, dass der DNS-Server gleichzeitig ein Active Directory-Domänencontroller ist. Warum das so ist, ist einfach zu erklären. Dazu schauen wir mit dem ADSI-Editor ein wenig tiefer ins AD.

Abbildung 9.4 zeigt die Partitionskonfiguration des Active Directory. Im Container CN=Partitions sind die Partitionen dieser Gesamtstruktur zu sehen, unter anderem die ForestDnsZone, die Sie im DNS-Manager als _msdcs ... finden, und die DomainDnsZone, die die DNS-Daten einer Domäne enthält.

Wenn man nun mit dem ADSI-Editor in die DomainDnsZone hineinschaut, sieht es dort so wie in Abbildung 9.5 aus. Sie können in den Eigenschaften eines einzelnen Servers die IP-Adresse erkennen, was ja eigentlich auch nicht weiter erstaunlich ist. Viele weitere Informationen stehen ebenfalls zur Einsichtnahme bereit.

Abbildung 9.4 Die DNS-Zonen sind separate Partitionen im Active Directory.

Abbildung 9.5 So sieht es in einer DomainDnsZone aus.

Da auf einem Nicht-Domänencontroller keine lokale Kopie von Active Directory-Partitionen vorhanden ist, kann er auch kein DNS-Server sein, der über Active Directory-integrierte Zonen verfügt.

Ist die Theorie so weit klar? Gut. Abbildung 9.6 zeigt die Eigenschaften der ForestDnsZone (_msdcs...) und einer DomainDnsZone:

• Beide Zonen sind Active Directory-integriert konfiguriert.
• Unterschiedlich ist allerdings die Konfiguration der Replikation. Die ForestDnsZone wird auf sämtliche DNS-Server der Gesamtstruktur (Forest) repliziert, während die DomainDnsZone »nur« auf die DNS-Server der eigenen Domäne repliziert wird. Diese Einstellungen können zwar angepasst werden, sind aber im Grunde genommen sinnvoll: Die ForestDnsZone wird überall benötigt, die DomainDnsZone nur in der eigenen Domäne.

Abbildung 9.6 Die Eigenschaften der »ForestDnsZone« (rechts) und einer »DomainDnsZone« (links)

Nochmals zurück zu den Zonentypen: In Abbildung 9.7 sehen Sie den Dialog zur Auswahl eines Zonentyps. Dort ist eine primäre in Active Directory-integrierte Zone ausgewählt. Beachten Sie, dass eine Active Directory-integrierte Zone stets eine primäre Zone ist. Eine sekundäre AD-integrierte Zone oder dergleichen gibt es nicht. Dass es sozusagen nur primäre Zonen gibt, erklärt sich unter anderem damit, dass die Active Directory-Replikation alle Replikate gleich behandelt, d. h., dass jedes Replikat aktualisiert werden kann. Bei einem »klassischen« Primär-Sekundär-Modell sind die sekundären Zonen sozusagen »read-only«.

Kurz gesagt lautet die Empfehlung, dass die für das Active Directory benötigten DNS-Server auf Domänencontrollern installiert werden sollten, um mit Active Directory-integrierten Zonen arbeiten zu können. Natürlich kann man das auch anders machen, aber es ist wenig sinnvoll, sich das Leben extra schwer zu machen.

Abbildung 9.7 Die Auswahl des Zonentyps

Das gilt übrigens auch für die theoretisch mögliche Konstellation, nicht den Microsoft DNS-Server zu verwenden. Das geht zwar, ich habe das aber – aus gutem Grund – bisher nicht in einer Kundenumgebung gemacht.

Sonstiges zur Zonenkonfiguration

Wie Sie im Eigenschaften-Dialog der Zone erkennen können, gibt es noch etliche weitere Konfigurationsmöglichkeiten. Einige sind in Abbildung 9.8 zu sehen. Es ist gut, diese Einstellungen prinzipiell zu kennen; in einem »durchschnittlichen AD« werden Sie damit aber wenig zu tun haben:

• Der Autoritätsursprung (Start of Authority, SOA) ist einer der wichtigsten Einträge einer DNS-Zone. Er enthält unter anderem Informationen über den primären Namenserver und die Aktualisierungsintervalle für den Zonentransfer. In einer AD-integrierten Zone gibt es hier im Normalfall keinen Anpassungsbedarf (nicht abgebildet).
• Auf der Registerkarte Namenserver sind (wenig überraschend) die DNS-Server der Zone eingetragen. Hier sollten Sie alle installierten Server finden. Im Normalfall muss hier nichts eingestellt werden.

  

  Abbildung 9.8 Einige weitere Registerkarten mit Zonen-Einstellungen

• Falls Sie Zonenübertragungen zulassen wollen (beispielsweise um die DNS-Informationen auf einem Nicht-Microsoft-DNS-Server verfügbar zu haben, der eine Spezialaufgabe in Ihrer Organisation erfüllt), müssen Sie dies auf der gleichnamigen Registerkarte einstellen.
• Falls Sie in Ihrer Umgebung beispielsweise alte NT4-Server betreiben, die sich nicht im DNS registrieren, können Sie WINS-Forward-Lookup aktivieren. Vereinfacht gesagt schaut der DNS-Server, wenn eine Anfrage für diese Zone kommt, die nicht aufgelöst werden kann, beim angegebenen WINS-Server nach.

9.1.2 Server

Neben der Konfiguration der Zonen können Sie einige Einstellungen in den Eigenschaften des DNS-Servers selbst vornehmen. Darüber hinaus gibt es einige Funktionen, die im Kontextmenü des Servers aufgerufen werden können (Abbildung 9.9).

Die Eigenschaften des DNS-Servers verteilen sich immerhin auf acht Registerkarten. Ich möchte hier nicht jedes Detail durchkauen. Die Registerkarten, mit denen man »routinemäßig« so gut wie immer zu tun hat, sehen Sie in Abbildung 9.10:

• Standardmäßig »hört« der DNS-Server auf alle IP-Adressen des Servers; dies kann aber eingeschränkt werden.
• Im Allgemeinen müssen nicht »nur« interne IP-Adressen aufgelöst werden, sondern auch die aus dem öffentlichen Internet. Auf der Registerkarte Weiterleitungen können DNS-Server eingetragen werden, an die nicht-auflösbare Anfragen weitergeleitet werden sollen. Falls keine Weiterleitung konfiguriert ist, kann die Verwendung von Stammhinweisen aktiviert werden.

Abbildung 9.9 Im Kontextmenü des Servers gibt es diverse Funktionen und natürlich den Menüpunkt »Eigenschaften«.

Abbildung 9.10 Einige Registerkarten der Eigenschaften des Servers

Mehr zum Thema Weiterleitungen finden Sie im nächsten Abschnitt.

Wichtig könnten weiterhin die Einstellungen auf den Registerkarten Debugprotokollierung und Ereignisprotokollierung sein – diese sind aber selbsterklärend und werden demzufolge hier nicht lang und breit beschrieben.

9.1.3 Weiterleitungen und Delegierungen

Ein DNS-Server ist selten allein auf der Welt. Es gibt zwei Fälle, die Sie betrachten sollten, nämlich die Kommunikation mit übergeordneten und mit untergeordneten DNS-Servern.

Weiterleitungen

Eine Weiterleitung ist schnell erklärt: Wenn ein DNS-Server nicht in der Lage ist, eine Anfrage aufzulösen, fragt er bei einem der Weiterleitungsserver an. Hier gibt es letztendlich zwei Fälle (Abbildung 9.11):

• Im Normfallfall werden die DNS-Server auf der obersten Ebene so konfiguriert, dass sie die Anfrage an einen externen DNS-Server weiterleiten. Falls Sie in der DMZ einen weiterleitenden DNS-Server konfiguriert haben, würde die Weiterleitung zu diesem konfiguriert (Abbildung 9.11 links).
• Die DNS-Server der untergeordneten Domäne werden so konfiguriert, dass als Weiterleitungen die DNS-Server der jeweils übergeordneten Domäne eingetragen werden (Abbildung 9.11 rechts).

Abbildung 9.11 Weiterleitungen können zu externen Servern konfiguriert werden (links), aber auch zu internen DNS-Servern übergeordneter Domänen (rechts).

Bedingte Weiterleitungen

Es ist durchaus denkbar, dass Anfragen nach Hostnamen für bestimmte Domänen an noch bestimmtere DNS-Server geleitet werden sollen; man spricht hier von Bedingten Weiterleitungen.

Die bedingten Weiterleitungen werden im gleichnamigen Knoten angelegt (Abbildung 9.12): Eingetragen werden der Name der DNS-Domäne und die IP-Adressen der Server, an die die Anfragen geleitet werden sollen. Auf Wunsch (Checkbox) kann diese bedingte Weiterleitung auf die anderen DNS-Server der Domäne oder der Gesamtstruktur repliziert werden.

Abbildung 9.12 Einrichtung einer bedingten Weiterleitung

Stammhinweise

Im Internet gibt es dreizehn Root-Server – sozusagen die obersten Namenserver des gesamten Internets. Diese Root-Server könnten prinzipiell als Ausgangspunkt für Namensauflösungen verwendet werden. Der Haken an diesen Root-Servern ist, dass sie recht stark belastet sind. Daher ist es im Normalfall die bessere Einstellung, den DNS-Server Ihres Providers als Weiterleitung einzutragen.

Abbildung 9.13 Die Liste der Root-Server

Damit diese Root-Server ein wenig vor Überlastung geschützt sind, beantworten sie nur interaktive Anfragen.

In Abbildung 9.13 ist die Registerkarte mit den Root-Servern zu sehen. Mit der Schalterfläche Vom Server kopieren können Sie diese Liste aktualisieren lassen.

Delegierung

Delegierung ist immer dann ein Thema, wenn in untergeordneten Domänen eigene DNS-Server verwendet werden. Abbildung 9.14 zeigt das Prinzip:

• Der Client möchte einen Hostnamen in der Domäne sub01.ubinf.intra auflösen und wendet sich dazu an den DNS-Server der Domäne ubinf.intra.
• Beim DNS-Server der Domäne ubinf.intra (bzw. der Zone ubinf.intra) ist eine Delegierung konfiguriert, die besagt, dass für DNS-Anfragen an sub01.ubinf.intra ein untergeordneter DNS-Server zu kontaktieren ist.
• Der für die Zone sub01.ubinf.intra zuständige DNS-Server gibt die Adresse des gesuchten Hosts an den übergeordneten DNS-Server weiter, der das Ergebnis wiederum an den Client übermittelt.

Abbildung 9.14 Das Prinzip der Delegierung

Im besten Fall brauchen Sie sich nicht mit der Konfiguration der Delegierung auseinanderzusetzen. Wenn Sie eine untergeordnete Domäne einrichten und dabei als zusätzliche Option die Installation eines DNS-Servers vorgeben, wird der Assistent zum Installieren von Active Directory-Domänendiensten eine DNS-Delegierung erstellen. In Abbildung 9.15 sehen Sie die Option zur Installation des DNS-Servers in diesem Assistenten.

Abbildung 9.15 Beim Anlegen einer untergeordneten Domäne mit eigenem DNS-Server wird automatisch eine DNS-Delegierung erstellt.

Das Ergebnis des Einrichtens der untergeordneten Domäne nebst DNS-Server ist in Abbildung 9.16 zu sehen: In der übergeordneten Domäne befindet sich ein Eintrag für die Delegierung, in dessen Eigenschaften der »zuständige« DNS-Server angegeben ist. Sofern vorhanden, können natürlich auch mehrere DNS-Server eingetragen werden.

Abbildung 9.16 Die Eigenschaften der Delegierung

9.1.4 Einen DNS-Server für das AD hinzufügen

Wenn in einer Domäne ein Domänencontroller nebst DNS-Server vorhanden ist, stellt sich die Frage nach der Redundanz. Eine Maßnahme ist die Installation eines weiteren Domänencontrollers, eine zweite Maßnahme wäre die Installation eines weiteren DNS-Servers. Einen zusätzlichen Domänencontroller zu installieren ist eine »schmerzfreie« Angelegenheit – der neue Domänencontroller erhält per Replikation die Daten und ist kurze Zeit später einsatzbereit.

Beim DNS-Server verhält es sich ähnlich: Wenn auf einem Domänencontroller ein DNS-Server installiert wird, erhält er per Replikation die Daten der entsprechend konfigurierten Zonen. (Bei Zonen kann eingestellt werden, dass diese auf alle Domänencontroller der Domäne oder der Gesamtstruktur repliziert werden sollen; siehe Abschnitt 9.1.1.)

9.1.5 Manuell Einträge hinzufügen

Als Administrator werden Sie hin und wieder den einen oder anderen Eintrag manuell hinzufügen müssen. Dabei ist eigentlich nicht viel Spannendes zu vermelden:

• Im Kontextmenü der Zone sind etliche Neu-Einträge vorhanden. Falls der gesuchte Typ nicht dabei ist, können Sie den Menüpunkt Weitere neue Einträge wählen. Sie gelangen so zu einer Auswahlliste mit knapp zwei Dutzend Ressourceneintragstypen (Abbildung 9.17 und Abbildung 9.18).

  

  Abbildung 9.17 Das manuelle Hinzufügen eines Eintrags beginnt hier.

  

  Abbildung 9.18 Die DNS-Ressourceneintragstypen

• In Abbildung 9.19 ist der Eintrag für das Erstellen eines neuen Host-Eintrags (A-Eintrag) zu sehen – nicht wirklich spektakulär.

Abbildung 9.19 Anlegen eines neuen Host-Eintrags (A-Eintrag)

9.1.6 Reverse-Lookupzone einrichten

Eine Reverse-Lookupzone dient zum Auflösen von IP-Adressen in Hostnamen. Diese Funktionalität ist zwar nicht unbedingt notwendig, trotzdem macht es Sinn, zumal sie mit wenigen Handgriffen eingerichtet ist.

Abbildung 9.20 zeigt den Ausgangspunkt des Vorgangs. Im DNS-Manager können Sie über den Menüpunkt Neue Zone einen Assistenten aufrufen, der das Anlegen einer Reverse-Lookupzone maximal einfach macht.

Abbildung 9.20 Hier beginnt das Anlegen einer neuen Reverse-Lookupzone.

Die wesentlichen Schritte des Assistenten sind folgende:

• Zunächst müssen Sie den Zonentyp auswählen. Im Normalfall wird eine Active Directory-integrierte Zone ausgewählt, diese muss notwendigerweise eine Primäre Zone sein (Abbildung 9.21, links).

  

  Abbildung 9.21 Die neue Reverse-Lookupzone wird als Active Directory-integrierte Zone angelegt.

• Auf der nächsten Dialogseite konfigurieren Sie, in welchem Replikationsbereich die Zone verteilt werden soll: Gesamtstruktur oder Domäne. Falls Sie Windows 2000-Domänencontroller einsetzen, müssen Sie die dritte Option auswählen (Abbildung 9.21, rechts).
• Die folgende Dialogseite dient zur Auswahl, ob Sie eine IPv4- oder eine IPv6-Reverse-Lookupzone erstellen möchten. Wenn Sie sowohl IPv4 als auch IPv6 einsetzen, benötigen Sie zwei Reverse-Lookupzonen. (Führen Sie einfach den Assistenten zweimal aus; Abbildung 9.22, links).
• In Abbildung 9.22 sehen Sie rechts, wie der Name der neuen Reverse-Lookupzone ermittelt wird. Sie müssen lediglich die Netzwerk-ID, also die IP-Adresse des Netzes, eingeben.

Abbildung 9.22 Der Name der Reverse-Lookupzone leitet sich von der Netzwerk-ID ab.

Ob das Reverse-Lookup funktioniert, können Sie recht einfach mittels Ping prüfen. Der Aufruf muss ping –a [adresse] lauten. Das Ergebnis sehen Sie in Abbildung 9.23: Der DNS-Name wird, sofern er ermittelt werden konnte, in der Ping wird ausgeführt-Zeile angegeben.

Abbildung 9.23 Ein »ping –a« löst die IP-Adresse in einen Namen auf.

9.1.7 Wie findet der Client einen Domänencontroller?

Mit den Service-Resource-Records-Einträgen (SRV-Records) werden Sie im Normalfall (also wenn es keine Probleme gibt) nicht unmittelbar etwas zu tun haben. Sie sollten allerdings deren Bedeutung kennen. Wenn ein Client einen Domänencontroller, einen globalen Katalogserver oder eine sonstige Ressource sucht, kann er diese anhand eines SRV-Eintrags im DNS ermitteln. In Abbildung 9.24 sehen Sie einige dieser Einträge. Die unteren drei Einträge, die mit _sip beginnen, sind übrigens nicht standardmäßig im Active Directory zu finden; sie werden benötigt, damit die Lync-Applikation den Lync Server finden kann.

Abbildung 9.24 Die Service Resource Records im DNS

Mit SRV-Einträgen können Sie übrigens auch ermitteln, welche Ressoucen an einem Standort vorhanden sind. Sie sehen in der Abbildung den aufgeklappten _sites-Knoten, unterhalb dessen die Standorte aufgelistet sind. Unterhalb der Standorte finden sich wiederum die SRV-Einträge der dort vorhandenen Ressourcen.

Wie bereits erwähnt wurde, brauchen Sie sich um diese Einträge im Normalfall nicht zu kümmern, da sie automatisch angelegt werden.

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.