Home       Servicebereich  Projekte  Kontakt  

Logo LWsystems LWsystems berät und betreut Sie in allen Fragen Ihrer IT.
Rufen Sie einfach an!

05455 - 932 132 oder 05403 - 55 56

Windows 2000 im Netzwerk


Nächste Seite: Domänenstrukturen Aufwärts: Einführung in Windows 2000 Vorherige Seite: Aufbau des Systems   Index


Unterabschnitte

Windows 2000 im Netzwerk

WINS

NetBIOS und WINS

Zur Beibehaltung der Rückwärskompatibilität mit älteren Microsoft-Sytstemen unterstützt W2K immer noch die NetBIOS (über TCP/IP, auch NetBT) Namensauflösung im Netzwerk. Auch hier darf ein Rechnername im Netzwerk nur einmal vorkommen. Er kann jedoch für einen einzelnen Compter gelten oder auch für eine ganze Gruppe (sogenannter Scope, der aber selbst von Microsoft nicht empfohlen wird). Daneben können für einen einzelnen Rechner verschiedene NetBIOS Namen vergeben werden, die verschiedene Dienste darstellen, die auf diesem Rechner laufen. Das System ist in dieser Hinsicht mit dem DNS-System vergleichbar. Die Registrierung der Rechnernamen und somit die Abbildung auf IP- (bzw. MAC-Adressen) kann hier verschiedene Arten erfolgen.

Namenscache
Jeder Rechner baut einen eigenen Cache auf, in dem das Mapping von NetBIOS Namen auf IP-Adressen festgehalten wird. Diese Methode der Namensauflösung ist die schnellste, da sich der Cache komplett im Speicher befindet. Um die Einträge im Namenscache zu überprüfen wird der Befehl nbtstat -c genutzt. Diese Art der Namensauflösung wird unabhängig von der Konfiguration zuallererst durcheführt.
Broadcast
Ein neu ins Netzwerk eingefügter Rechner versendet einen Broadcast im Netzwerksegment. Hiermit teilt er allen Rechnern mit, welchen Rechnernamen er belegen möchte. Falls kein anderer Rechner im Netz diesen Namen belegt hat, bekommt er von allen anderen Rechnern eine Bestätigung in der ihm die Namen der anderen Rechner mitgeteilt werden. Diese fügt er in seinen lokalen Cache ein. Falls ein Rechner diesen Namen schon belegt hat, bekommt er von diesem eine negative Rückmeldung. Die neue Maschine gibt eine Fehlermeldung aus, aus der zu erkennen sein sollte, daß der Name schon vergeben ist.
LMHOSTS
Mit Hilfe der Datei %SYSTEMROOT%\system32\drivers\etc\lmhosts kann eine statische Namensauflösung festgelegt werden. Hier werden die die Rechnernamen den IP-Adressen zugeordnet. Diese Art wird z.B. genutzt, wenn sich einige Rechner in anderen Netzwerksegmenten befinden und daher keine Auflösung per Broadcast erfolgen kann.
WINS-Server
Im Netzwerk wird ein sogenannter WINS-Server eingesetzt, der ähnlich einem DNS-Server die Namensauflösung vornimmt. Die IP-Adresse des Wins-Servers wird auf den Client-Maschinen in der IP-Adresskonfiguration festgelegt, bzw. bei der Adressfestlegung mittels DHCP übermittelt.
Statisches Mapping
Auf dem WINS-Server kann zusätzlich noch ein statisches Mapping von IP-Adressen auf Rechnernamen erfolgen. Dieses bietet sich dann an, wenn die Namen von Clients aufgelöst werden sollen, die keine Clients dieses WINS Servers sind.

Die Freigabe erfolgt automatisch, falls der Rechner ordnungsgemäß heruntergefahren werden kann.

Die einzelnen Rechner, die auch Konten oder Nodes genannt werden können zur Namensauflösung auf unterschiedliche Arten konfiguriert werden. Der sogenannte Knotentyp legt fest, auf welche Art die Namensauflösung bei der jeweiligen Maschine erfolgt. Die Einstellungen erfolgen in der Regel automatisch, können jedoch in der Registry (unter dem Schlüssel ...NodeType) editiert werden oder dem Client in der DHCP Konfiguration übergeben werden.

b-Knoten
Die Namensauflösung erfolgt allein über Broadcasts. Dieser Knotentyp wird automtisch eingestellt, falls sich kein WINS Server im Netzwerk befindet. Der Registry-Schlüssel wird hierfür auf den Wert 1 eingestellt.
p-Knoten
Der Name wird mit Hilfe einer Point-to-Point Verbindung zu einem WINS Server aufgelöst. Dieser Typ wird automatisch eingestellt, wenn mindestens ein WINS Server im Netzwerksegment vorhanden ist.
m-Knoten
Diese Einstellung kombiniert den B- und den P-Knoten mit der Defaulteinstellung der Namensauflösung per Broadcast. Falls der Name so nicht aufgelöst werden kann, wird eine Auflösung per WINS Server versucht. Der Registryeintrag muß hierfür auf 4 gesetzt werden.
h-Knoten
Beim h-Knoten (Hybrid-Knoten) erfolgt auch eine kombinierte Auflösung der Rechnernamen. Allerdings ist hier die Defaulteinstellung die WINS Auflösung. Der Schlüssel in der Registry wird hier auf 8 gesetzt.
Der h-Knotentyp wird auf einer Maschine automatisch als Default eingestellt, wenn in den Netzwerkeinstellungen ein WINS-Server angegeben wird.

Namensauflösung per WINS und WINS Proxy

Wird das Netzwerk mit WINS konfiguriert, versucht der Client die Namensauflösung per default über den primären WINS Server. Falls dieses dreimal hintereinander fehlschlägt, wird versucht einen eventuell vorhandenen sekundären WINS Server zu erreichen. Falls dieses auch keinen Erfolg hat, wird ein Broadcast versandt. Zu allerletzt sieht der Client in seine LMHOSTS Datei, ob sich der Name hier auflösen läßt. Falls sich im lokalen Netzwerksegmet kein WINS Server befindet und auf den Clients auch keine WINS-Server Adresse konfiguriert wurde kann ein WINS-Proxy eingesetzt werden. Dieses ist ein entsprechend konfigurierter Server, der den Broadcast eines Clients aufnimmt und direkt an einen WINS Server in einem anderen Netzwerksegment weiterleitet. Er arbeitet als transparenter Proxy, so daß der Client gar nicht bemerkt, daß die Anfrage an den WINS-Server weitergeleitet wird. Die positive oder negative Antwort vom WINS-Server wiederum wird vom Proxy an den Client zurückgesandt. Der Proxy speichert den Namen des neuen Clients und die IP-Adresse in seinem lokalen Cache, so daß er zukünftig auch Anfragen von Clients für diesen Namen direkt beantworten kann. Pro Netzwerksegment darf nur ein WINS-Proxy installiert werden um eine doppelte Namensvergabe zu verhindern.

WINS Namensauflösung per DNS

Im W2K Netzwerk ist der Namensauflösung per DNS die eigentlich eingesetzte Methode. Die NetBIOS Namensauflösung existiert nur noch für die Kompatibilität mit den alten Microsoft Systemen. Falls jetzt ein W2K Rechner einen NetBIOS Namen einer IP-Adresse zuordnen soll, stellt er eine Anfrage an den DNS Server. Der für die jeweilige Zone primär zuständige Server kann so konfiguriert werden, daß er für diese Zone ein WINS-Lookup durchführt, falls er den Namen nicht auflösen kann.10.1 Die Anfrage wird dann an den für diese Zone konfigurierten WINS-Server gerichtet. Falls ein nicht W2K Server für die Zone zuständig ist, muß auf dem W2K DNS-Server eingestellt werden, daß nur die dem Standard entsprechenden Records mit den anderen Servern abgeglichen werden.

Primäre nicht W2K DNS-Server und WINS

Falls im Netzwerk primäre DNS-Server eingesetzt werden, die dem Standard entsprechen, kann ein WINS-Lookup nicht direkt auf diesen Servern konfiguriert werden. Hier erfolgt die Konfiguration so, daß einen extra Zone direkt unterhalb der Hostnames erstellt wird, für die WINS-Clients zuständig ist. Hierfür wird eine W2K DNS-Server aufgestetzt, auf dem das WINS-Lookup für diese Zone konfiguriert ist. Die Zone selbst enthält auf dem W2K Server keinerlei Einträge, da diese diese ja sofort an den WINS Server weiterleiten muß. Die (W2K-) Clients werden in den erweiterten TCP/IP- Einstellungen so konfiguriert, daß sie den Namen dieser Zone (=Subdomain) automatisch anhängen. Falls der Client jetzt eine Anfrage zur Namensauflösung an den primären DNS-Serve richtet und eine negative Antwort bekommt, wiederholt er seine Anfrage indem er bei der die oben konfiguriert Subdomain zwischen Hostname und Domainname einfügt und die Anfrage dann an den hierfür zuständigen WINS-Server stellt.

Die WINS Datenbank

Komprimierung

Die Namenszuordnungen des WINS-Servers werden mit erweiterten Angaben in der WINS-Datenbank in einem File im mdb Format gespeichert. Die Records enthalten neben den Angaben über Rechnernamen und IP-Adressen noch Einträge über Diensttype, Status, Eigentümer, eine bei jeder änderung inkrementierte Versionsnummer und das Ablaufdatum. Die einzelnen Tupel können mit Hilfe der MMC manuell bearbeitet werden. Falls die Datenbank zu groß wird, wird sie vom System automatisch komprimiert. Dieses kann auch manuell mit Hilfe des Tools jetpack durchgeführt werden. Hierfür muß der WINS dienst beendet und nach der Komprimierung wieder manuell neu gestartet werden.

Verifizierung

Neben der Komprimierung sollte die Datenbank regelmäßig auf ihre Konsistenz überprüft werden. Die Zeitintervalle hierfür werden in den Eingenschaften für den WINS-Server festgelegt. Zur Verifizierung überprüft der WINS-Server unter anderem die Clients. Dieses bewirkt einen nicht zu vernachlässigenden Traffic auf dem Netzwerk, so daß die Zeitintervalle nicht zu klein gewählt werden sollten.

Backup der WINS-Datenbank

In regelmäßigen Abständen sollte ein Backup der WINS-Datenbank durchgeführt werden. Bei einem manuellen Backup wird der WINS-Dienst zuerst gestoppt. Dann wird im Fenster für WINS per Menüeintrag ausgewählt werden daß ein Backup der Datenbank durchgeführt werden soll und wohin die Daten gespeichert werden. Das Backup kann auch so konfiguriert werden, daß es automatisch in bestimmten Intervallen durchgeführt wird. In diesem Fall muß allerdings darauf geachtet werden, daß die Backup-Datei lokal auf dem Rechner gespeichert wird, da das Backup sonst fehlschlägt. Das Restore erfolgt durch Auswählen des entsprechenden Menüpunktes und Auswahl des Pfades zu den Backupdateien.

Replizierung von WINS Datenbanken

In größeren gerouteten Netzwerken bietet es sich an, mehrere WINS-Server in verschiedenen Segmenten anzuordnen. Um die WINS-Datenbanken konsistent zu halten werden die WINS-Server so konfiguriert, daß sie sich untereinander abgleichen. Nach grundlegendem Abgleich werden nur noch die Änderungen an den WINS-Datenbanken ausgetauscht. Die Partner, mit denen sich die WINS-Server abgleichen werden in der Regel manuell konfiguriert. Falls sich die WINS Server im gleichen IP-Subnetz befinden, finden sie sich automatisch. Bei einem größeren Netzwerk mit mehreren IP-Subnetzen ist dieses nur möglich, wenn die Router Multicast unterstützen und alle WINS Server entsprechend konfiguriert werden. Die Server gehören per Default der Mulitcastgruppe 224.0.1.24 an.

Für den Abgleich der WINS-Datenbanken sind verschiedenen Szenarien möglich:

Pull
Ein WINS Server kan zum Abgleich als PULL Partner konfiguriert werden. Hier spricht dieser Server den oder die Partner in festgesetzten Zeitintervallen an, um eine Replizierung durchzuführen. Diese Vorgehensweise wird vor allem bei langsamen Verbindungen empfohlen.

PUSH
Bei der PUSH Einstellung wird eine Replikation nach einer festegelegten Zahl von Änderungen in der Datenbank angestoßen. Diese Änderungen erfolgen in erster Linie durch das An- und Abmelden von Clients. Die PULL Replikation wird empfohlen, falls der aktuelle Stand der WINS Einträge im Netz auf beiden WINS Servern notwendig ist. Der Nachteil liegt hier im größeren Traffic zum Abgleich der Datenbanken.

PUSH/PULL
Die einzelnen WINS-Server können auch auf einen kombinierten PUSH/PULL Abgleich eingestellt werden. Hier werden eine Replikationsschwelle und ein Zeitintervall parallel definiet. Eine Replikation findet entweder nach dem festgelegten Intervall statt oder wenn die Anzahl der Änderungen überschritten wurde.

Im Netz müssen sich in der Defaulteinstellung immer PUSH und PULL Partner befinden. Daher muß bei zwei WINS Servern weinigstens einer auf PUSH und der andere auf PULL eingestellt werden, bzw. beide werden für die PUSH/PULL Replikation konfiguriert.

Burstbehandlung von Anfragen

Falls der WINS-Server zeitweilig eine hohe Zahl von Clientregistrierungen vornehmen muß, wie dieses z.B. zu Dienstbeginn auftreten kann, kann er die jeweiligen Einträge nicht schnell genug in seinen Datenbank eintragen, um die Anfragen vor Ablaufen der Timeouts zu behandeln. Für diesen Fall kann das Burst Handling für den Server eingestellt werden. Falls einen gewisse Anzahl von Registrierungsanfragen in einem bestimmten Zeitraum an den Server gerichtet wird, beantwortet er die Anfragen ohne sie in seiner Datenbank abzulegen. Um mögliche Inkonsistenzen zu vermeiden wird für diese Registrierungen eine kurze Leasezeit festgelegt, so daß die Clients die Lease nach kurzer Zeit wiederholen müssen.


Internet Connection Sharing und NAT

Um in einem Netzwerk mit mehreren Clients per Dial-Up-Verbindung auf das Internet zugreifen zu können, wird an dem Rechner mit dem Internetzugang das Internet Connection Sharing eingestellt. Der Rechner mit der Dial-Up Internetverbindung fungiert jetzt automatisch als DHCP-Server, der den Clients private IP-Adressen und die Einstellungen für das Default-Gateway zuweist.Die Client-Maschinen werden so konfiguriert, daß sie die IP-Adressen automatisch erhalten. Eingehende Verbindungen werden ins Internet geroutet, wobei die Absenderadresse der ausgehenden Pakete auf die eigene vom ISP (Internet Service Provider) zugewiesene umgesetzt wird. Eingehende Pakete werden umadressiert und an den jeweiligen Empfänger im lokalen Netz weitergeleitet.

Network Address Translation

Falls sich im Netzwerk schon DNS-Server, Gateways oder DHCP-Server befinden, sollte kein Internet Connection Sharing genutzt werden, sondern NAT (Network Address Translation). Hier fungiert der Rechner mit der Internetverbindung als ein (transparenter) Proxy, der TCP/IP-Adressen der Clients intern auf Portnummern abbildet und dann mit die Adressen im Internet kontakt aufnimmt. Die zurückkommenden Pakete werden dann an die jeweiligen Ports weitergeleitet.


Routing und Remote Access Service (RRAS)

Der Routing und Reomote Access Service unter W2K bietet verschiedene Möglichkeiten der Netzwerkkonfiguration hinsichtlich Routing und Remote Access, also den Zugriff auf die Maschine bzw. das Netzwerk über Telefon- oder ISDN-Leitungen. Bei RAS werden die Netzwerkprotokolle in ein PPP-Protokoll gekapselt, also quasi durch die Punkt-zu-Punkt Verbindung getunnelt. Alle auf dem jeweiligem Rechner installierten Netzwerkprotokolle können automatisch ohne weitere Konfiguration für den Betrieb über eine Punkt-zu-Punkt Verbindung genutzt werden. Dieses ist daher möglich, da das PPP-Protokolll unterhalb der IP-Schicht ansetzt und im System ein Netzwerkdevice zur Verfügung stellt, daß auf dieser Abstraktionsebene wie eine beliebige Netzwerkkarte angesprochen werden kann. Auf der Maschine die als RRAS-Server fungiert, kann eingestellt für jedes werden ob es von dieser Maschine auch in das angeschlossene Netzwerk bzw. über die PPP-Verbindung geroutet wird.

Beim Start des RRAS Services wird für jedes an das System angeschlossene Modem und für jede parallele Schnittstelle ein sogenannter Port erstellt. Die Ports stellen ein Netzwerkgerät im System dar, über das die Kommunikation abgewickelt werden kann. Für Modems kann optional die Telefonnummer des jeweiligen Anschlusses angegeben werden. Neben den Ports für die physikalischen PPP-fähigen Netzwerkschnittstellen werden automatisch jeweils 5 L2TP (s.a. 27.0.36) und 5 PPTP (s.a. 27.0.48) Ports erstellt.

Die Konfiguration von Einwahlmöglichkeiten wird unterschiedlich durchgeführt. Ist die Maschine ein Server, der ein Mitglied einer Domäne ist, wird RRAS für die Konfiguration der Einwahlports genutzt. Hier können VPNs und die Nutzung von Modem-Pools eingestellt werden. Eine Workstation oder eine Server, der keiner Domäne angehört wird mit Hilfe des Internet Connection Wizards konfiguriert.

IP-Adressvergabe bei RRAS

Die Remote-Clients, die das Netzwerk per Modem nutzen wollen benötigen eine für dieses Netzwerk gültige IP-Adresse. Diese kann in den Clients fest verdrahtet werden, also dem Modemdevice für jeden einzelnen Remote-Partner, zu dem einen Verbindung aufgebaut werden soll, fest eingestellt werden. Diese Möglichkeit sollte allerdings nicht genutzt werden. Die Pflege der Clientadressen ist sehr aufwendig und extrem Fehleranfällig.

Der RRAS Server kann so konfiguriert werden, daß er den Clients, die sich einwählen eine IP-Adresse zuweist. Hierdurch werden die IP-Adressen im Netzwerk selbst verwaltet. Diese Möglichkeit hält den Aufwand und die Gefahr einer doppelten Vergabe von IP-Adressen gering. Die Verwaltung der IP-Adressen auf Seiten des RRAS Servers kann auf zwei Arten erfolgen:

RRAS mit eigenem Adresspool Hier wird dem RRAS Server ein eigener Adresspool zugewiesen, den er an die Clients bei der Einwahl vergibt. Dieser Adresspool wird direkt auf dem RRAS Server verwaltet. Zu beachten ist, daß dieser Adressbereich nicht mit den schon im Netzwerk vergebenen Adressen in Konflikt gerät.

RRAS und DHCP Falls sich schon ein DHCP Server im Netzwerk befindet, kann der RRAS Server so konfiguriert werden, daß er diesen nutzt, um gültige Adressen für die Einwahlclients zu erhalten. Der RRAS Server fordert beim Start 10 IP-Adressen vom DHCP Server an. Die erste Adresse nimmt er für sich. Die anderen werden an die Clients vergeben. Falls alle Adressen vergeben sind, fordert er einen neuen Pool von 10 Adressen vom DHCP Server an.

Falls die Nutzung des DHCP Servers konfiguriert wurde, dieser aber beim Start des RRAS Servers nicht erreichbar ist, wechselt der RRAS Server zum Automatic Private IP Addressing über. Hier vergibt er an sich und die Clients Adressen aus dem Bereich 169.254.0.1 - 169.254.255.254.

RRAS Policies

Die Berechtigungseinstellungen für den RRAS-Zugriff auf das lokale Netzwerk erfolgen in zwei Ebenen.

Die erste Ebene bildet die Remote Access Policy, über die die grundlegenden Einstellungen zur Einwahl auf dem jeweiligen RRAS Server konfiguriert werden. An dieser Stelle läßt sich eine Einwahl in den RRAS Server und somit auch in das Netzwerk zentral unterbinden. Wird diese Richline z.B. entfernt ist keine Einwahl in den RRAS mehr möglich. Diese Richtlinie wird direkt auf dem RRAS Server gespeichert und nicht im Active Directory, so daß die Einstellungen verschiedener RRAS Server im Netzwerk durchaus voneinander abweichen können. Die RAS-Richtlinie setzt sich aus drei Komponenten zusammen:

Bedingungen (conditions)
stellen Eingenschaften hinsichtlich der Verbindung dar, die vom Client bzw. der Verbindung erfüllt werden müssen, damit diese Richtlinie überhaupt angewandt wird. Bespiele hierfür sind:
  • Zeit der Einwahl,
  • IP-Adresse des Clients (bei fester vergebenen IP-Adressen),
  • Gruppe der der Client angehören muß,
  • User ID des Clients

Berechtigungen (permissions)
Hier werden die globalen Einwahlberechtigungen festgelegt, wie z.B. einer Gruppe von Usern die Einwahl zu erlauben. So kann z.B. der Gruppe der Administratoren die Einwahl jederzeit erlaubt werden, einer Benutzergruppe wird die Erlaubnis nur zu den Geschäftszeiten erlaubt.

Profil (profile)
Im Profil werden Einstellungen hinsichtlich der Verbindung festgelegt. Eine Verbindung kann z.B. auf ein bestimmtes Verschlüsselungs- oder Authentifikationsprotokoll festgelegt werden. Die Begrenzung einer Verbindung auf eine maximale Verbindungsdauer wird auch hier festgelegt.

Mit der zweiten Ebene werden die Einstellungen für den jeweiligen User festgelegt. Diese erfolgen bei den Einstellungen für den Useraccount unter Einwahlberechtigungen und werden daher im Active Directory gespeichert.

Anwendung der RRAS Policies

Erfolgt jetzt ein Einwahlversuch, so werden vom System die verschiedenen Berechtigungen in einer festgelegten Reihenfolge überprüft.
  1. Prüfung der Routing- und Remotezugriffsrichtlinie
    Sie wird auf zutreffende Bedingungen (z.B. Tageszeit) überprüft. Falls hier keine Bedingungen zutrifft (s.o.) wird der Zugang schon hier abgeblockt. Auch eine nicht vorhandene Richtlinie untersagt den Zugriff.
    Falls eine Bedingung zutrifft werden die nächsten Punkte überprüft.
  2. Überprüfung der Einwahlberechtigungen des jeweiligen Useraccounts
    Die Einwahlberechtigungen können so eingestellt werden, daß der Zugriff erlaubt oder verboten wird, oder daß Eingestellten Berechtigungen, die in der Remote Access Policy eingestellt sind, über den Zugriff entscheiden.

Authentifizierungsprotokolle

Für die Authentifizierung über PPP-Verbindungen wurden verschiedene Protokolle entwickelt und teilweise in RFCs veröffentlicht. Die Art der Authentifizierung für eine Einwahlverbindung wird auf dem Feld Security in den Eigenschaften für den RRAS Server eingestellt. Die Einstellungen können nur für den gesamten Server erfolgen, nicht für einzelne Einwahlports. (?) Bei Einwahl in einen RRAS Server unter W2K kann mit Hilfe der folgenden Protokolle eine Authentifizierung erfolgen:

PAP
Das Password Authentication Protocol bietet ein reines Name-Passwort basiertes Login. Der gravierende Nachteil hier ist, daß die Passwörter im Klartext übertragen werden. Des weiterten besteht natürlich die Möglichkeit von Brute-Force Angriffen, wobei die Sicherheit hier natürlich durch eine geschickte Passwortwahl erheblich vergrößer werden kann.

PAP ist in der Regel immer verfügbar. Aufgrund der Nachteile hinsichtlich der Klartext-Passwortübertragung sollte es nur dann eingesetzt werden, wenn einer der Kommunikationspartner kein anderes Authentifizierungsprotokoll unterstützt. Beim Einsatz der unverschlüsselten Passwortübermittlung ist auf jeden Fall darauf zu achten, daß die Übertragungskanäle relativ sicher sein sollten.

SPAP
Das Shiva Password Authentication Protocol arbeitet mit reversibel verschlüsselten Passwörtern, so daß eine gewisse Sicherheit hinsichtlich des Logins gegeben ist.

SPAP ist nicht allzu weit verbreitet, bzw. wird nicht bei allen Systemen direkt mitgeliefert und wird daher eher selten eingesetzt.

CHAP
Das Challenge Handshake Authentication Protocol oder Message Digest 5 (MD-5)- CHAP arbeitet mit MD5 Verschlüsselung. Der hier eingesetzte Algorithmus bietet eine sehr sichere Einwegverschlüsselung und somit eine große Sicherheit gegen Angriffe.

Das CHAP- Protokoll ist sehr weit verbreitet und wird bei den gängigsten Systemen mitgeliefert. Aufgrund der verschlüsselten Passwortübertragung und seiner Verbreitung sollte dieses Authentifizierungsprotokoll bevorzugt eingesetzt werden.

Der Login-Vorgang läuft bei CHAP 3-Stufig ab:

  1. Einer der beiden Partner (bei RRAS unter W2K immer der RRAS-Server) sendet dem anderen eine Anforderung zur Authentifikation. Das Anforderungs-Paket enthält einen für diese Sitzung eindeutigen Sitzungsschlüssel und einen willkürlich erzeugten String (der sogenannte Challenge String).
  2. Die Gegenseite empfängt dieses Paket und erzeugt ein Antwortpaket, indem der Username und mit die mit einer Einwegverschlüsselung verknüpften Elemente Passwort, Sitzungsschlüssel und Challenge-String enthalten sind.
  3. Wenn die anfordernde Seite (idR der Server, s.o.) das Paket erhält vergleicht extrahiert er hieraus den Usernamen. Er erzeugt aus den in seiner lokalen Authentifizierungsdatenbank hinterlegten Daten von Username und Passwort auf die gleiche Weise ein Paket und vergleicht die beiden miteinander. Sind die verschlüsselten Daten gleich, ist die Authentifizierung erfolgreich. CHAP bietet daneben noch Optionen an, um diesen Vorgang während der Sitzung in regelmäßigen Abständen zu wiederholen. Hierdurch läßt sich erkennen, wenn eine Sitzung ``entführt'' wurde, der Gegenpart sich inzwischen geändert hat.

MS-CHAP
ist ein propritäres Authentifizierungsprotokoll, daß ähnlich wie CHAP arbeitet. Es ist außerhalb der Microsoft-Welt kaum verbreitet. Die Passwortverschlüsselung arbeitet hier wie auch bei Standard-CHAP mit einem Algorithmus zur Einwegverschlüsselung. MS-CHAP ermöglicht eine Punkt-zu-Punkt Verschlüsselung der übertragenen Daten, wobei natürlich beide Seiten der Verbindung MS-CHAP unterstützen müssen. Ein W2K arbeitet in der Defaulteinstellung mit MS-CHAP zur Authentifizierung.

MS-CHAP kann nur dann eingesetzt werden, wenn alle beteiligten Systeme dieses Protokoll unterstützen. Daher sollte wenn möglich mit offenen Standards wie CHAP gearbeitet werden.

MS-CHAP v2
ist eine Weiterentwicklung des proprietären MS-CHAP Protokolls. Es bietet gegenüber von MS-CHAP eine wechselseitige Authentifizierung, eine stärkere Verschlüsselung der übertragenen Daten und unterschiedliche Schlüssel für den Versand und den Empfang von Daten. W2K bietet bei der Installation eines VPN vorrangig die Authentifizierung mit MS-CHAP v2 an. Das MS-CHAP v2 Protokoll kann nur von W2K Clients und nur bei VPN-Verbindungen genutzt werden. NT4 und Windows 98 Maschinen können MS-CHAP v2 nur für die Authentifikation bei Eröffnung einer VPN Verbindung einsetzen.

MS-CHAP v2 wird nur von Windows 2000 unterstützt, kann daher nur in einer streng homogenen Umgebung eingesetzt werden. Beim praktischen Einsatz ist abzuwägen, ob die Anforderungen den Einsatz von MS-CHAP v2 unbedingt erforderlich machen und somit die zukünftige Richtung der Lösung festgeschrieben wird, oder ob sich das gegebene Ziel nicht auch mit einer flexibeleren Lösung erreichen läßt.

EAP
Das Extensible Authentifikation Protocol stellt eine API (Application Programming Interface, Programmierschnittstelle) für andere Authentifikationsprotokolle zur Verfügung. EAP ist in den RFCs 2284 und 2716 definiert. Mit Hilfe von EAP können die Kommunikationspartner vor der eigentlichen Authentifizierung aushandeln, welche Authentifizierungsmethode verwandt wird. Aufgrund der Ausführung als API können auch in Zukunft entwickelte Protokolle auf EAP aufsetzen und dieses Nutzen. Zur Zeit bietet EAP die Möglichkeit die folgenden Protokolle zu nutzen:
MD5-CHAP
Verschlüsselung von Usernamen und Passwörtern mit MD5 (s.o.)
Transport Layer Security
wird bei Smart-Cards und anderen Sicherheitsmechanismen gentutzt, die verschiedene Medien zur Authentifizierung einsetzen.
Dritthersteller
bieten u.U. Systeme an, die auf EAP aufsetzen können.

Die EAP Authentifizierung in den Eigenschaften auf der Security Karte eingestellt.

RAS-Protokolle

W2K unterstützt verschiedene RAS Protokolle:
PPP
ist das am weitesten verbreitete RAS-Protokoll. PPP ist ein offener Standard und kann relaiv einfach implementiert werden.
SLIP
Das Serial Line Internet Protocol ist ein offenes Protokoll zur Punkt-zu-Punkt Verbindung. Es kann als das Vorläuferprotokoll von PPP angesehen werden, bietet allerdings erheblich weniger Möglichkeiten und wird daher kaum noch eingesetzt. W2K unterstützt PPP nur noch als SLIP-Client; die Verbindung zu einem W2K RAS-Server mittels SLIP ist nicht möglich.
Microsoft RAS
ist ein proprietäres Punkt-zu-Punkt Protokoll von Microsoft, daß in den Vorläufer-Versionen zu W2K eingesetzt wurde. Es íst außerhalb der MS-Welt kaum verbreitet. Es wird benötigt, falls sich ein W2K-Client mit einem RAS-Server verbinden muß, der unter WfW, WinNT 3.1, MSDos oder mit LAN Manager läuft.
ARAP
Das AppleTalk Remote Access Protocol wird für PPP-Verbindungen in AppleTalk-Netzen eingesetzt und ist auch nur hier verbreitet. W2K unterstützt ARAP auf der Serverseite, so daß sich Clients die dieses Protokoll nutzen auf dem W2K Server einwählen können.

Verschlüsselte Kommunikation unter RRAS

Eine verschlüsselte Kommunikation über die PP-Verbindung ist zum einen Möglich, wenn ein verschlüsselter Kanal über die Verbindung aufgebaut wird, oder wenn die beiden Endpunkte der PP-Verbindung, der RAS-Server und der Client die Daten verschlüsseln wenn sie diese an die Verbindung senden. Die Verschlüsselung wird mit Hilfe einer Policy aktiviert, wobei zwischen mehrenen Optionen gewählt werden kann, die unterschiedliche Arten der Verschlüsselung ermöglichen. Jede dieser Optionen kann einzeln eingestellt werden, so daß auch eine Kombination möglich ist:
keine Verschlüsselung
Diese Gruppe darf auch unverschlüsselte Verbindungen aufbauen.
Standardverschlüsselung (Basic)
Die Mitglieder dieser Gruppe können mit einer 56-Bit DES Verschlüsselung auf IPSec oder mit einer 40-Bit MPPE12.1 Verschlüsselung der Verbindung gearbeitet.
Starke Verschlüsselung
Hier die IPSec 56-Bit DES oder die MPPE 56-Bit Datenverschlüsselung aktiviert.
Stärkste Verschlüsselung
Bei Wahl der starken Verschlüsselung dürfen die Gruppenmitglieder eine Verbindung aufbauen, die mit IPSec und Triple DES (3DES) oder mit MPPE 128-Bit verschlüsselt wird. Zur Nutzung der 128-Bit Verschlüsselung muß allerdings das W2K Pakte für die starke Verschlüsselung vom MS-Update-Webserver geladen werden!

Weitere Konfigurationsoptionen von RRAS

Callback
Mit Hilfe der Callback Funktion kan für spezifische Benutzer festgelegt werden, daß die Verbindung nach erfolgreicher Authentifizierung unterbrochen wird. Der RRAS Server baut dann selbstständig eine Verbindung zu einer vorkonfigurierten Telefonnummer oder zur Nummer des Anrufers auf. Aus Sicherheitsgründen sollte möglichst ein Rückruf zu einer vorkonfigurierten Nummer erfolgen.

DHCP-Relay-Agent
In RRAS ist ein DHCP-Relay-Agent implementiert, der die Broadcasts eines DHCP-Clients zur Ermittlung seiner IP-Adresse an einen DHCP-Server in einem anderen Netzwerksegment weiterleiten kann (s.a. 27.0.25). Hierbei wird die Anfrage gezielt an den jeweiligen Server weitergeleitet. Dieser erkennt aufgrund des Formates, daß die Anfrage über einen Forwarder gekommen ist, und sendet seine Antwort entsprechend direkt an diesen zurück.

Dial-in Konfiguration
Die Möglichkeit der Einwahl wird je nach Typ der RRAS-Maschine unterschiedlich konfiguriert. Auf einem Standalone- Server erfolgen die Einstellungen im Dial-In Feld der Eigenschaften-Box für den jeweiligen User-Accounts. Hier ist nur einen Einstellung zwischen grundsätzlicher Erlaubnis oder grundsätzlichem Verbot der Einwahl möglich.

Ein Server, der in das Active-Directory eingebunden ist wird in den Eigenschaften für Active Directory Benutzer und Computer konfiguriert. Hier wird der RRAS-Server global so eingestellt, daß die Einwahl grundsätzlich erlaubt oder verboten ist. Ist die Einwahl erlaubt werden für bestimmte Profile oder direkt für einzelne Useraccounts die Feineinstellungen mit Hife von Policies festgelegt. Diese überschreiben auch die globalen Einstellungen für RRAS. Mit Hilfe der RAS-Richlinien läßt sich unter W2K genau einstellen welcher RAS-Client bzw. User sich wann in das Netzwerk einwählen darf. Hierfür muß sich die Domäne jedoch im einheitlichen Modus befinden. Neben diesen Optionen ist auch eine Überprüfung der Telefonnummer des Anrufers möglich, so daß die Einwahl nur bestimmten Anrufern gestattet wird. Zu beachten ist bei dieser Lösung jedoch, daß die gesamte Kommunikationsstrecke die Übermittlung von Telefonnummern unterstützen muß.

Die Einwahloptionen für das System kann nur für Benutzer oder Gruppen angepaßt werden. Eine Einstellung für ein spezifisches Gerät (z.B. Modem x) ist nicht möglich. (?) Für die Nutzung der RAS-Richtlinien ist allerdings der Einheitliche Modus der Domäne voraussetzung. Bei Servern im gemischten Modus besteht nur die Möglichkeit dem einzelnen User die grundsätzliche Berechtigungen zur Einwahl zu erteilen oder zu verweigern.

Bei nach der Authentifizierung des Clients wird zuerst die Default Remote Access Policy überprüft, die die allgemeinen Einstellungen für jeden sich einwählendne Client festlegt. Danach werden die Einstellungen der Policies des einzelnen Benutzers übernommen, die die Default Remote Access Policy überschreiben können. Falls die Default Remote Access Policy entfernt wurde, kann sich niemand mehr über diesen RRAS Server einwählen.

Dial on Demand
Ein für Dial on Demand konfigurierter WAN-Router baut bei Bedarf eine Verbindung zu einem anderen Rechner per Wählleitung auf. Der WAN-Router ist so konfiguriert, daß seine Routingtabellen für die Dial on Demand Einträge auf das Device zeigen, über das der Datenverkehr für die Wählverbindung abgewickelt wird. Treffen bei diesem Device nun IP-Pakte ein, wird eine Verbindung aufgebaut. Weiterhin kan eingestellt werden, daß nach erfolgreichem Verbindungsaufbau ein- oder mehrere statische Routen über dieses Device erstellt werden.

Multilink und BAP
RRAS ermöglicht es eine Verbindung parallel über mehrere Kanäle (Modems, ISDN-Kanalbündelung) aufzubauen um die Bandbreite zu vergrößern. Diese Kanalbündelung wird durch eine Erweiterung des PPP Protokolls erreicht. Hierfür stehen die Protokolle PPP-Multilink (RFC 1990) oder das BAP (Bandwith Allocation Protocol, RFC 2125) zur Verfügung. BAP bietet gegenüber PPP Multilink den Vorteil, daß hier dynamisch weitere Kanäle hinzuzuschalten bzw. geschlossen werden können.

Multiprotokoll Routing
Die Routingfunktionalität ermöglicht das Routing der Protokolle IP und IPX.

NAT
RRAS bietet Network Address Translation (NAT), s.a. 27.0.43, bei der eine IP-Adresse auf mehreren anderen IP-Adressen abgebildet werden kann. Dieses wird z.B. bei der Verbindung eines privaten Netzes (Intranet) mit dem Internet genutzt.

RAS Einwahl von Außerhalb
Es kann eine Einwahl in den Rechner bzw. das angeschlossene Netzwerk von außerhalb per Modem- oder ISDN- Leitung stattfinden. Hierbei können Verbindungen mit den Protokollen IP, IPX und Appletalk aufgebaut werden.

RIP und OSPF
Mit Hilfe von RRAS werden für IP-Netze die Routing Protokolle RIP (Routing Information Protocol, s.a. 27.0.54) und OSPF (Open Shortest Path First, s.a. 27.0.47) unterstützt.

Paktetfilterung
Die RRAS Implementierung ermöglicht eine einfache Paketfilterfuntionalität. Hier kann z.B. eingestellt werden, daß IP-Pakete, die von außerhalb kommend an eine bestimmte Adresse oder einen bestimmten Port gehen, nicht weitergeleitet werden.

RAS Kontosperrung
RRAS läßt sich konfigurieren, daß ein Konto deaktiviert wird, wenn hier wiederholt eine Einwahl aufgrund eines falschen Passwortes fehlgeschlagen ist. Diese Möglichkeit ist in der Defaulteinstellung allerdings deaktiviert. Sie läßt sich nur direkt in der Registry einstellen.

RADIUS-Authentifizierung
RRAS bietet die Möglichkeit, daß zur Authentifizierung eines Bentzers ein RADUIS Server kontaktiert wird. Der W2K Server arbeitet in diesem Fall als RADIUS-Client. Die Nutzung eines RADIUS-Servers wird bei den RRAS Optionen konfiguriert.

EAP
Mit Hilfe der EAP (Extensible Authentifikation Protocol) Schnittstelle lassen sich verschiedene andere Authentifizierungsmöglichkeiten verwenden.

VPN
Ein W2K Server läßt sich mit Hilfe von RRAS als VPN (Virtual Private Network) Server einsetzen. VPN Clients können hiermit einen gesicherten Kanal über das Internet zum privaten Netzwerk aufbauen (s.a. 27.0.68). Die VPN-Verbindungen laufen über sogenannte VPN-Ports ab, die bein unter den Einstelloptionen für RRAS konfiguriert werden können.

DHCP Konfiguration

Mit Hilfe eines DHCP-Servers wird die Zuweisung der IP-Adressen an die Clients automatisiert. Die Servermaschinen sollten feste IP-Adressen erhalten. Bei der Konfiguration des DHCP-Servers werden genügend IP-Adressen für die sich gleichzeitig am Netz angemeldeten Clientmaschinen ``reserviert'', es wird ein sogenannter Scope gebildet. Diese Adressen müssen fortlaufend in einem zusammenhängenden Bereich gewählt werden.

Bei AD integrierten DCHP-Servern muß der DHCP-Server authorisiert werden, um IP-Adressen an die Clients zu vergeben. Falls dieses nicht der Fall ist, wird der Client eine Fehlermeldung wie ``DCHP unavailable'' ausgeben.(?)

Aus Redundanzgründen werden in einem Subnetz manchmal zwei DHCP-Server betrieben. Wenn ein Client einen Broadcast zur Adressabfrage sendet wird die Adresse von dem DCHP-Server vergeben, der zuerst antwortet. Die Scopes auf den Servern werden hier so eingestellt, daß auf beide Maschinen der gesamte Adressbereich als Scope definiert wird, wobei zwei sich aneinander anschließende Bereiche definiert werden, die von der Adressvergabe ausgeschlossen sind. Dieser Bereich umfaßt auf der einen Maschine ca. 20% des gesamten Adressbereichs, während er auf der anderen Maschine 80% aller Adressen einschließt.

Wird ein Adressbereich erweitert, oder sollen andere Änderungen am Scope vorgenommen werden, sollten alle Clients ihre IP-Adressen erneuern. Hier müssen dann alle Clients gleichzeitig vom Netz genommen werden bevor die Änderungen am Scope durchgeführt werden können. Soll ein ``gleitender'' Übergang erfolgen, oder kann der Bereich der zu vergebenden Adressen aus irgendeinem Grund nicht zusammenhängend gewählt werden kann, so müssen die einzelnen Bereiche zu einem sogenannten Superscope zusammengefaßt werden.

Wird bei laufendem DHCP-Server ein Scope neu erstellt, muß dieser nach Abschluß der Konfiguration aktiviert werden.

Superscopes

Der Superscope ist eine übergeordnete logische Einheit, die mehrere Scopes enthalten kann. Der Superscope kann verwaltungstechnisch als eine Einheit angesprochen werden wie jeder andere Scope auch.

Die Bildung von Superscopes bietet sich an, falls der gesamte zu nutzende Adressbereich nicht kontinuierlich verläuft, oder wenn er erweitert werden soll. Die einzelnene Adressbereiche bilden dann den Superscope. Mit dieser Maßnahme wird eine Umstellung oder Erweiterung des Netzwerkes im laufenden Betrieb ermöglicht, da der ursprüngliche Scopt nicht extra gelöscht werden muß und die Client nicht zu einer Erneuerung ihrer Adressen aufgefordert werden müssen. Sich neu anmeldenden Rechner erhalten jetzt automatisch Adressen aus dem neuen Superscope, der beide ursprünglichen Adressbereiche umfaßt.

Auch wenn ein Subnetz in mehrere logische Segmente unterteilt werden soll (Multinet), wird hierfür ein Superscope eingerichtet. Dieser enthält dann die einzelnen Scopes für die Adressbereiche der logischen Subnetze.

Ein Superscope kann im Verwaltungstool für den DHCP Server erstellt werden.

Eine feste Zuordnung von IP-Adressen zu Clientmaschinen ist möglich, indem der IP-Adresse eine MAC-Adresse der NIC zugeordnet wird. Diese Adressen werden bei einer Anfrage nach Überprüfung der MAC-Adresse vergeben. Ansonsten verläuft die Adressvergabe wie bei allen anderen Anfragen auch. Aus diesem Grunde dürfen sich reservierte Adressen nicht außerhalb des Scopes befinden. Auch die Zuordnung zu einem von der Vergabe ausgenommenen Berereich (Exclusion-Range) ist nicht sinnvoll, da dann keine Vergabe stattfindet.

Es ist in keinem Fall möglich, einigen Maschinen Adressen aus einem bestimmten Bereich zuzuordnen, also eine Zuordnung einer Menge von MAC-Adressen zu einer Menge von IP-Adressen.

User-Classes

Falls für eine Gruppe von Usern/Maschinen eine spezielle Konfiguration gelten sollt, erfolgt dieses über die Definition einer Benutzerklasse (User-Class). Die Benutzerklasse wird in den Eigenschaften des DHCP-Servers deklariert. Nach Vergabe eines Namens und einer eideutigen Class-ID werden die Eigenschaften für diese spezielle Gruppe eingestellt. Dieses kann z.B. eine kürzere Leasedauer für mobile Rechner sein, oder ein anderer anzusprechender DNS-Server. Auf den Clientmaschinen, die dieser Benutzerklasse angehören sollen, wird die Klassen ID dem Befehl ipconfig /setclassid zugeordnet.

DHCP und DDNS (dynamisches DNS)

DHCP Clients, die mit Windows 2000 oder Windows 98 laufen können ihre IP-Adresse automatisch bei einem DNS-Server registrieren, der den RFC 2136 unterstützt. Im Falle der Adressverwaltung mittels DHCP kann dieses auch vom DCHP-Server vorgenommen werden. Dieses wird in den Eigenschaften für den DHCP-Server oder für einen Scope des DHCP-Servers eingestellt. An den (primären) DNS-Server werden in einem solchen Falle DNS-Updates gesandt. Falls im Logfile eines DNS- Servers solche Nachrichten in regelmäßigen Abständen auftauchen und abgewiesen werden, sollte nach einem falsch konfigurierten DHCP-Server im Netzwerk Ausschau gehalten werden.

DHCP Relay Agent

Die Client-Anfragen für DHCP erfolgen mittels Broadcasts, so daß sie im Regelfall nicht geroutet werden. Um einen Anfrage an einen DCHP-Server weiterzuleiten, der sich in einem anderen Subnetz befindet besteht zum einen die Möglichkeit einen kompatiblen Router einzusetzen. Die andere Möglichkeit ist die Nutzung eines DCHP Relay Agent. Dieses ist ein speziell konfigurierter Server, auf dem im Falle von W2K das RRAS-Protokoll installiert sein muß (s.a. [*]). Der DCHP Relay Agent erkennt die Anfrage eines Clients und leitet sie direkt an den in seiner Konfuration eingestellten DHCP-Server weiter. Dieser erkennt, daß die Anfrage über eine Relay Agent erfolgte und sendet die gewünschten Informationen an diesen zurück, der sie dann an den Client weiterleitet. Der DCHP Relay Agent muß so konfiguriert werden, daß dieser Service für die Interfaces eingerichtet wird, aus dessen Subnetzen Anfragen erwartet werden. Dieses kann z.B. auch ein ISDN-Interface eines RRAS Einwahlservers sein.

Das DNS System

Windows 9x und Windows NT 4.0 unterstützen selbst kein dynamisches DNS. Die Unterstützung erfolgt hier über einen (Windows 2000) DHCP-Server. Falls kein W2K DHCP-Server im Netz läuft, können diese Maschinen manuell eingetragen werden.

Zonen

Ein DNS Server verwaltet eine logische Einheit, eine sogenannte Zone. Hier werden Gruppen von Rechnern zusammengefaßt, die auf irgendeine Art und Weise logisch zusammengehören. Eine Zone im Sinne von DNS kann sich über mehrere Domänen erstrecken oder auch ein Teil einer Domäne sein.

Innerhalb einer Zone wird ein DNS-Server zum primären (autorisierenden) DNS Server erklärt. Dieser hat das alleinige Verwaltungsrecht (also das Recht Einträge zu ändern) an der DNS-Zone. Diese Hierarchie wurde aus Gründen der Konsistenz eingeführt. Die nicht autorisierenden DNS Server in der Zone dienen daher nur dazu die Rechenlast zu verteilen. Sie besitzen Kopien der zentralen DNS Datenbank des authorisierenden DNS-Servers. Der Vorgang des Kopierens wird als Zonentransfer oder Replikation bezeichnet. Zur Verringerung der Netzlast wurde ein Verfahren entwickelt, mit dem beim Zonentransfer nicht mehr die gesamte Datenbank übertragen wird, sondern nur kann der Zonentransfer auch inkrementell erfolgen. Das heißt, daß nur noch die Änderungen an der Datenbank übertragen werden. Dieses Verfahren ist in RFC 1995 festgelegt.

Der Zonentransfer kann entweder im Pull- bzw. Polling- Verfahren oder im push Verfahren erfolgen. Beim Pull-Verfahren fragen die sekundären Server in regelmäßigen Abständen beim primären Zonenserver an, ob sich in der Zonendatenbank Änderungen ergeben haben.
Beim Transfer im Push- Verfahren initiert der primäre Server die Zonentransfers. Er sendet den sekundären Servern eine Benachrichtigung, falls sich Änderungen an seiner Datenbank ergeben haben. Der Sekundäre Server fragt beim Master dann die Änderungen ab. Die Konfiguration für diese Verfahren erfolgt direkt in der Registry.

Form eines DNS-Eintrags

Ein DNS- Eintrag wird als Ressorce Record (RR) bezeichnet. Neben der Zuordnung von Hostnamen zu IP-Adresse wird hier auch der Typ des Eintrags festgelegt, der bestimmt für welchen Einsatzzweck dieser DNS-Name vorgesehen ist. So wird ein MX-Record z.B. die IP-Adresse für einen Mail Server festlegen, an den die Mail für diesen DNS-Namen gesandt wird. Für einen NS-Record können u.a. die folgenden Typen festgelegt werden:

SOA
Definiert allgemeine Parameter.
NS
Nameserver
A
Host
CNAME
Aliasname für einen Host
MX
Mail Exchange, Mail-Server
HINFO
liefert Informationene über einen Host
WINS
Host ist ein WINS-Server
PTR
Pointer (Zeiger) Einträge

Reverse Lookup Zone

Zur rückwärtigen Zuordnung einer IP-Addresse auf einen DNS-Namen speichert ein DNS-Server zusätzliche Einträge in der speziellen Reverse-Lookup-Zone in der Zonendatei für die Domain in-addr.arpa . Falls ein Rechner den Hostnamen sucht, der einer speziellen IP-Adresse (a.b.c.d) zugeordnet ist, sucht der DNS-Server in der Reverse-Lookup-Zonendatei nach dem PTR Eintrag d.c.b.a.in-add.arpa. Dieser enthält den gewünschten Hostnamen sowie die zugehörige IP-Addresse.

Formen der DNS Abfrage

Ein Client, der einen anderen Rechner adressieren will, stellt eine Anfrage an den DNS-Sever, der in seiner Konfiguration eingetragen ist. Dieser DNS Server sieht zuerst in seinem lokalen Cache und dann in seiner Datenbank nach, ob er diesen DNS-Namen zuordnen kann. Falls nicht, leitet er die Anfrage an einen in der Hirarchie über ihm stehenden Server weiter. Dieses geht so lange, bis schließlich ein Eintrag aufgelöst werden kann, oder ein Root-Server gefragt werden muß. Diese Art der Abfrage wird als iterative Abfrage bezeichnet.
Eine andere Form der Abfrage ist die rekursive Abfrage. Falls der Nameserver den Namen nicht auflösen kann, sendet er dem Client die Adresse des hierarchisch über ihm stehenden DNS-Servers, der dann vom Client direkt gefragt wird.
Die inverse Abfrage schließlich ist eine Anfrage, bei der zu einer gegebenen IP-Adresse ein Hostname geliefert wird.

Das DNS-Caching läßt sich für jeden DNS Server hinsichtlich der Zeitdauer, wie lange ein Abfrageergebnis gecached wird, individuell einstellen. Seit Windows 2000 Workstation (W2K Professional) läßt sich das Caching auch auf den Clients einstellen.

Neben dem DNS-Cache auf den Workstations und dem dynamischen DNS ist bei W2K auch das Round-Robin-DNS eingeführt worden. Hier sind in der Zonendatei für einen FQDN (Fully Qualified Domain Name) mehrere IP-Adressen angegeben. Mit dieser Konfiguration besteht die Möglichkeit eine Lastverteilung durchzuführen. Das DNS-System liefert jeder Anfrage für einen so konfigurierten Hostnamen eine andere IP-Adresse zurück. Hiermit ist für den Client völlig transparent, daß die Ressourcen parallel von verschiedenen Servern geliefert werden.

Active Directory Integration

Unter W2K kann die Speicherung der DNS auch im Active Directory erfolgen. Falls jetzt das System der primären und sekundären DNS- Server eingehalten wird, so daß Änderungen nur von einem Rechner aus erfolgen können, wird man beim Zonentransfer von einer Single-Master-Replikation sprechen. Windows 2000 bietet die zusätzlich die Möglichkeit, daß bei einem AD basierten DNS-System Änderungen an der DNS-Tabelle von jedem beliebigen DNS-Server durchgeführt werden können. Dieses wird auch als Multi-Master-Replikation bezeichnet. Wenn der DNS-Server in das Active Directory integriert wurde besteht die Möglichkeit ACL-Listen von Benutzeraccounts zu führen, die diese Zonen updaten dürfen (Allow only secure updates).

Unter NT oder Un*x erfolgt immer eine vollständige Replikation der Zonendatei, wohingegen ein Active Directory basiertes DNS-System unter W2K nur die Änderungen repliziert.

In gemischten Umgebungen können sowohl das herkömmliche (NT4) DNS als auch das Active Directory basierte DNS - auf verschiedenen DNS Servern - parallel eingesetzt werden. Wird ein Domänencontroller mit Active Directory installiert, so wird diese Maschine zusätzlich automatisch als DNS Server konfiguriert.

Dynamisches DNS per DHCP

Um dem W2K- DHCP-Server zu ermöglichen die DNS-Einträge dynamisch zu aktualisieren, die Datenbank des DNS-Servers also bei der Vergabe einer Adresse an einen Host und bei Ablauf der Leasezeit zu ändern, muß das System auf Active Directory aufsetzten. Die DNS- Einträge enthalten jetzt eine Liste mit Eigenschaften, in der auch der Eigentümer eingetragen ist, der diesen Eintrag in die Datenbank eingefügt hat. Im Falle eines dynamischen Eintrags vom DHCP-Server können die Einträge auch nur von diesem gelöscht werden, was in der Praxis Probleme mit sich bringen könnte. Aus diesem Grunde wurde die Sicherheitsgruppe DnsUpdateProxy eingeführt. Alle Rechner die dieser Gruppe angehören fügen Einträge in das DNS System ein, ohne sich als Eigentümer für diesen Wert in die Datenbank einzutragen. Diese Einträge können dann später von anderen Rechnern problemlos wieder gelöscht werden.

Netzwerksicherheit

W2K bietet verschiedene Möglichkeiten und Hierarchieen um die Sicherheit und Vertrauchlichkeit der Daten im Netzwerk zu gewährleisten.

Windows 2000 PKI

W2K erlaubt es einer Organisation als ihre eigene CA aufzutreten, und somit digitale Zertifikate zu erzeugen und zu verteilen. Hier wird zwischen zwei Typen von CA's unterschieden:

Enterprise CA
Die Form der Enterprise CA wird gewählt, falls die Zertifizierung und Authentifizierung nur innerhalb des logischen Netzes der Organisation gültig werden soll. Um ein verteiltes System zu implementieren, kann eine Hierarchie mit Root- und Subordinate CA's aufgebaut werden. Die Zertifikate der Subordinate CA's werden dann von der eigenen Root CA signiert. Die Enterprise CA stützt sich auf das Active Directory und ist somit auf auf W2K-Systeme beschränkt. Alle Benutzer und Computer müssen einen Account im AD besitzen um die Zertifikate dieser CA nutzen zu können. In heterogenen Netzwerken (Internet) kann diese Form daher nicht verwandt werden.

Für die Implementierung einer Enterprise CA werden neben den administrativen Rechten am CA-Server selbst auch noch Rechte zur Konfiguration des Active Directory und des DNS benötigt. Falls weitere Zertifikate im Active veröffentlicht werden sollen, muß der veröffentlichende Mitglied der Gruppe der Zertifikationsdistributoren (?) (Cert Publisher) sein.

Stand-alone CA
Die Stand-alone CA wird in einem heterogenen Netzwerk gewählt, da sie kein Active Directory für die Funktion benötigt. Die Zertifikate können jetzt auch ausserhalb der eigenen Organisation verteilt und eingesetzt werden. Falls die Zertifikate der CA auch von dritten anerkannt werden sollen, muß eine Stand-alone Subordinate CA installiert werden, die sich wiederum von einer (externen) Root CA signieren läßt.

Innerhalb der Organsiation können die Zertifikate mit Hilfe des Active Directory repliziert. Die PKI ist allerdings nicht in jedem Fall auf Active Directory angewiesen. Zertifikate können auch mit Hilfe von Webseiten oder in anderer Form verteilt werden. Die PKI wird von Windows 2000 in Verbindung mit SSL (Secure Socket Layer) oder IPSec (IP Security) genutzt. Mit Hilfe von Zertifikaten können sich die einzelnen an der Kommunikation beteiligten Partner gegeneinander authentifizieren. Die Kommunikation erfolgt dann verschlüsselt über SSL oder IPSec.

Installation und Nutzung von Zertifikaten

Ein Zertifikat erlaubt die Authentifizierung eines Users oder eines Computers. Um dieses zu nutzen, muß es auf dem Computer oder für den Benutzeraccount installiert werden. Auf dem Computer wird ein Zertifikat installiert, indem sich der Administrator mit dem Administratoraccount anmeldet, die Zertifizierungsdienste installiert und dann ein Zertifikat im Namen des Computers für diesen anfordert. Der Computer hat dann ein Zertifikat, mit dem er sich gegenüber anderen Stellen authentifizieren kann. Um diesen Vorgang zu automatisieren wird eine Gruppenrichtlinie für öffentliche Schlüssel (Public Key Group Policy) für die Domäne erstellt. Hier wird allen gewünschten Rechnern das Recht zur Eintragung eines Zertifikates (Enroll permission) gegeben.

Der User kann das Zertifikat von der CA anfordern. Wie dieses geschieht ist abhängig vom Typ der CA. Bei einer Enterprise-CA kann das Zertifikat aufgrund der Bindung an das Active Direktory mit Hilfe eines Wizards angefordert werden. Bei den Stand-alone CA's erfolgt dieses über eine Webseite.

Templates für Zertifikate

Ein Enterprise CA kann Zertifikate für verschiedene Aufgaben basierend auf Systemrichtlinien (Policies) ausstellen. Folgende Typen von Zertifikaten sind vordefiniert:

Administrator
Das Zertifikat darf für die Signierung von Dateien, Vertrauenslisten, EFS (Encrypted File System), Email-Verschlüsselung und für die Client-Authentifizierung genutzt werden.
Domain Controller
Hiermit wird ein Zertifikat für die Authentifizierung von Client- und Servermaschinen erstellt.
Computer
Hiermit wird ein Zertifikat für die Authentifizierung von Client- und Servermaschinen erstellt.
Basic EFS
Das Zertifikat ist nur für die Benutzung von EFS gültig.
EFS Recovery Agent
Zertifikat zur Wiederherstellung von Dateien auf dem Encrypted File System
User
Gebrauch des Zertifikates für EFS, Authentifikation des Clients und die Verschlüsselung von Email
Web Server
Zertifikat für die Authentifizierung eines Servers gegenüber einem Client

Zertifizierung

Nachdem die Zertifizierungsdienste in einer Domäne installiert wurden, kann kein Computer nur aus dieser Domäne umbenannt, hinzugefügt oder herausgenommen werden, nachdem die Zertifizierungsdienste von diesem Rechner entfernt wurden.


Fußnoten

... kann.10.1
Achtung! Dieses ist eine Erweiterung des DNS-Systems von Microsoft, die nicht im Standard festgelegt ist.
... MPPE12.1
MPPE wird zur Verschlüsselung der Daten eingesetzt, die bei einer PPTP- VPN Verbindung zwischen dem Client und dem Server übertragen werden. MPPE bietet 3 Sicherheitsstufen: 40, 56 und 128 Bit.

Nächste Seite: Domänenstrukturen Aufwärts: Einführung in Windows 2000 Vorherige Seite: Aufbau des Systems   Index



Copyright © 2001 Martin Werthmöller

Der Text darf nicht verändert, allerdings frei kopiert werden falls dieser Copyright-Hinweis erhalten bleibt. Anregungen, Korrekturen und Beiträge zu diesem Dokument sind jederzeit willkommen. Bitte senden Sie diese per Email an: doku@werthmoeller.de