Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 9 Netzwerkdienste im AD-Umfeld
Pfeil 9.1 DNS
Pfeil 9.1.1 Zonen
Pfeil 9.1.2 Server
Pfeil 9.1.3 Weiterleitungen und Delegierungen
Pfeil 9.1.4 Einen DNS-Server für das AD hinzufügen
Pfeil 9.1.5 Manuell Einträge hinzufügen
Pfeil 9.1.6 Reverse-Lookupzone einrichten
Pfeil 9.1.7 Wie findet der Client einen Domänencontroller?
Pfeil 9.2 DHCP
Pfeil 9.2.1 Einen neuen DHCP-Server einrichten
Pfeil 9.2.2 Konfiguration und Betrieb
Pfeil 9.2.3 Redundanz
Pfeil 9.3 WINS
Pfeil 9.4 NetBIOS über TCP/IP

9Netzwerkdienste im AD-Umfeld Zur nächsten Überschrift

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.


Galileo Computing - Zum Seitenanfang

9.1 DNS Zur nächsten ÜberschriftZur vorigen Überschrift

Ü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.

Achten Sie auf korrekte Namen

Viele merkwürdige bis katastrophale Probleme haben ihre Ursache in der Namensauflösung. Die Ursache liegt dann aber zumeist nicht im eigentlichen DNS-Server, sondern vielmehr darin, dass die Clients nicht richtig konfiguriert sind. »Beliebt« ist beispielsweise das Szenario, dass ein Server, der vormals den DNS-Dienst bereitgestellt hat, eingemottet wurde und auf dieser IP-Adresse nun eben kein DNS mehr vorhanden ist.

Wenn nun auf dem ein oder anderen Client oder Server diese wesentliche Änderung nicht durchgeführt worden ist (sprich: die IP-Adresse des neuen DNS-Servers nicht eingetragen wurde), steht der Client unter Umständen »ohne« da.

Teilweise finden die Clients sogar noch die ein oder andere Ressource, was dann aber eher mit Glück als mit stabilem Netzwerkbetrieb zu tun hat.

Das Fazit lautet also: Achten Sie darauf, dass die DNS-Einträge in Clients und Servern korrekt sind.


Galileo Computing - Zum Seitenanfang

9.1.1 Zonen Zur nächsten ÜberschriftZur vorigen Überschrift

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

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

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

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

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

Abbildung

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

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

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

    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.

Galileo Computing - Zum Seitenanfang

9.1.2 Server Zur nächsten ÜberschriftZur vorigen Überschrift

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

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

Abbildung

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.


Galileo Computing - Zum Seitenanfang

9.1.3 Weiterleitungen und Delegierungen Zur nächsten ÜberschriftZur vorigen Überschrift

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

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

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

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

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

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

Abbildung 9.16 Die Eigenschaften der Delegierung


Galileo Computing - Zum Seitenanfang

9.1.4 Einen DNS-Server für das AD hinzufügenZur nächsten ÜberschriftZur vorigen Überschrift

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.)

Seien Sie geduldig

Sie brauchen nichts weiter zu tun: Der DNS-Server erhält die Daten automatisch. Zu beachten ist allerdings, dass diese Replikation dauern kann – unter Umständen einige Stunden. Werden Sie also nicht ungeduldig!

Denken Sie daran, dass ein DNS-Server nur dann verwendet wird, wenn die Clients ihn kennen. Fügen Sie den DNS-Clients also die IP-Adresse des neuen DNS-Servers hinzu, gegebenenfalls über DHCP.


Galileo Computing - Zum Seitenanfang

9.1.5 Manuell Einträge hinzufügenZur nächsten ÜberschriftZur vorigen Überschrift

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

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

    Abbildung

    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

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


Galileo Computing - Zum Seitenanfang

9.1.6 Reverse-Lookupzone einrichten Zur nächsten ÜberschriftZur vorigen Überschrift

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

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

    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

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

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


Galileo Computing - Zum Seitenanfang

9.1.7 Wie findet der Client einen Domänencontroller?Zur vorigen Überschrift

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

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.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de


  Zum Katalog
Zum Katalog: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Vmware vSphere 5






 Vmware vSphere 5


Zum Katalog: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo