3.12.2001

NetBIOS / WINS - Übersicht

Für NetBIOS werden 15 Zeichen für den Namen und das 16te für den Dienst angegeben. Der Eintrag am WINS-Server erfolgt automatisch. Die Namensauflösung läuft über den Cache, den NetBIOS-Nameserver (WINS) und den Broadcast. Der Knotentyp ist demzufolge H. Es müssen der WINS- und der DNS-Server am Client eingetragen sein, wenn man beides nutzt.

Für nicht NetBIOS-fähige oder WINS-fähige Rechner kann man eine statische IP-Adresse eingeben. Als WINS-Proxys kommen Rechner ab Win95 in Frage:

Für ausstehende Fragen verweise ich gerne auf meine Softwaresektion oder auf meinen FTP-Server, wo die Zip-Dateien liegen, die die PowerPoint-Folien mit WINS und anderen Sachen enthalten.

Bei der WINS-Replikation muss der 2. WINS-Server dem Client erst mal bekannt gemacht werden. Als nächstes stellt man dem 1. WINS-Server einen Replikationspartner zur Seite. Beide WINS-Server haben statische IP-Adressen. Wenn man auf der Hälfte der Clients die 1. mit der 2. IP-Adresse der WINS-Server vertauscht, hat man eine Fehlertoleranz und einen Lastausgleich.

Zur Replikation zwischen den WINS-Datenbanken findet bei dem Pull-Partner-Verfahren die Replikation zeitgesteuert statt. Der jew. Rechner zieht die Daten von seinem Partner. Der typische Einsatz hierfür wäre laut Microsoft eine langsame WAN-Verbindung. Beim Push-Partner-Verfahren wird die Replikation anhand einer Anzahl von Änderungen an der Datenbak initiiert. Der Partner wird von der Änderung benachrichtigt, erst dann erfolgt der Transfer. Der Verwendungszweck wäre eine schnelle Verbindung. Das Push/Pull-Verfahren ist eine Kombination aus beiden und der Standard, den Rechner unter W2k erwarten. Bei der letzteren Art, die wir auch einsetzen wollen, kann man sich erstmal Gedanken darüber machen, ob man eine Stern- oder Kreistopologie in Betracht zieht. Damit die Replikation relativ zügig erfolgt, richten wir eine Sterntopologie ein.

Die Konfiguration der Replikation erfordert auf beiden WINS-Servern das Häkchen bei "nur mit Partner". Die automatische Konfiguration des Partners setzt Multicast vorraus und ist standardmässig deaktiviert. Die Push-Einträge geben die Anzahl (Standard: 0, also keine Replikation) der Änderungen wieder, bevor eine Replikation initiiert wird und eine standardmässig deaktivierte ständige Verbindung. Bei Pull wird die Startzeit, das Replikationsintervall (Standard 30 min.) und ebenfalls die ständige Verbindung eingerichtet. Diese Einstellungen erfolgen in den Eigenschaften des Ordners Replikationspartner, sind also global, können aber auch von den speziellen Eigenschaften der Rechner überschrieben werden. Alle WINS-Server sind demnach gleichberechtigt. Mit der rechten Maustaste auf den Replikationspartner kann man die Replikation manuell auslösen.

Die WINS-Datenbank

Man kann die WINS-Datenbank komprimieren. Im Online-Fall erfolgt das automatisch, bei Offline muss das manuell initiiert werden. Wie bei einer DHCP-Datenbank muss erst der Dienst beendet werden (RM auf den WINS-Server). Danach wird mit dem Jetpack-Befehl mit dem Namen der Datenbank (winnt\system32\wins\wins.mdb) und mit der temporären Datenbank die Datenbank komprimiert. Das Starten des Dienstes ist selbstverständlich.

Ebenfalls identisch zur DHCP-Datenbank gibt es auch eine Sichern- und Restorefunktion:

Aus mir unbekannten Gründen gibt Microsoft die Startpartition als Standard vor. Es wird ein Ordner namens wins_bak mit dem Unterordner namens new mit mehreren Dateien abgelegt: eine Patchdatei (wins.pat), eine komplette wins.mdb und eine log-Datei. Da die Sicherung im Online-Fall geschehen ist, wird eine Patchdatei angelegt. In dieser sind Daten enthalten, die in der Datenbank noch nicht fest gespeichert wurden. Automatisch sichert Windows die WINS-Datenbank alle drei Stunden.

Beim Sichern wird nur die Datenbank, nicht die Konfiguration des WINS-Servers gesichert. Genauso wird unter der Sicherung der Systemstatusdaten (wir erinnern uns...) nicht die WINS-Datenbank mitgesichert.

Die WINS-Datenbank kann man sich sortieren lassen. Und zwar nach NetBIOS-Namen und nach Besitzer. Das ist der Rechner, auf dem die Registrierung stattgefunden hat. Als weiteren Unterpunkt bei der Besitzersortierung kann man bestimmte Diensttypen sortieren. Die Einträge stellen den Namen und dessen IP-Adresse dar. Bei Microsoft wird das 16te Zeichen als Diensttyp mit angegeben. Als Besitzer wird die IP-Adresse des registrierenden Rechners angezeigt. Weiterhin ist das Ablaufdatum, die Versionsnummer der WINS-Datenbank und die Art der Einträge (statisch) sichtbar.

Der mögliche Status in einer WINS-Datenbank könnte aktiv sein. Weitere Möglichkeiten könnten freigegeben, veraltet und gelöscht lauten.

aktiv aktiver Client, in Verwendung
freigegeben Client hat sich abgemeldet (runtergefahren) und die Registrierung wird aufgehoben.
veraltet (tombstoned) zum Löschen vorgemerkt (Ein Tombstone ist ein Grabstein)
gelöscht dieser Status wird nicht angezeigt, weil der Client gelöscht ist

Der Tombstoned-Eintrag gibt bei einer Replikation den anderen WINS-Servern die Mitteilung weiter, dass er gelöscht werden soll. Es werden nur die Änderungen der Einträge aktiv und veraltet repliziert.

Der freigegeben-Eintrag bezieht sich nur auf den zu registrierenden Server. Der gelöschte Eintrag ist ja nicht mehr vorhanden. Den Status aktiv erhält ein Rechner, der sich registriert hat und angemeldet ist. Der freigegeben-Status ist dann sichtbar, wenn der Client ordentlich beendet bzw. heruntergefahren wurde. Wenn das Erneuerungsintervall abgelaufen ist (Standard 6 Tage), erhält er ebenfalls den Status freigegeben. Wenn das Alterungsintervall abgelaufen ist (Standard 4 Tage) bekommt der Eintrag den Status veraltet. Dieser Eintrag war dann schon vorher freigegeben oder wurde manuell mit Replikation gelöscht (aus dem aktiv-Status). Ein Eintrag ist gelöscht, wenn er ohne Replikation entfernt wird oder es ist das Alterungszeitüberschreitungsintervall (Standard: 6 Tage) abgelaufen. Das Löschen ohne Replikation ist von überall her möglich. Es kann also maximal 16 Tage dauern, bis ein Client aus der Datenbank gelöscht ist.

WINS-Misc.:

Das Überprüfungsintervall stellt die Zeit dar, nach der Einträge anderer WINS-Server überprüft werden. Standardmässig ist dieses auf 24 Tage gestellt und ist in den Eigenschaften des WINS-Servers zu finden. Dort ist auch der Standardpfad der Sicherunsdatei einstellbar. Weiterhin ist dort die Datenüberprüfungszeit angegeben, welche man natürlich auch manuell auslösen kann. Die Datenkonsistenz wird mit den Replikationspartnern (Besitzer oder zufälliger Partner) durchgeführt.

Im Burstmode erhält der Server mehr Anfragen, als er verarbeiten kann und seine Reaktion kann dort eingestellt werden:

In diesem Modus erhalten die Clients eine Nutzungserlaubnis mit kurzer TTL nach Zufall, bevor sie sich noch einmal nach Ende der TTL nochmal registrieren müssen. Detaillierte Protokolle sind bei Fehlern sinnvoll.

 

PKI (Public Key Infrastructure)

Nehmen wir ein Beispiel: Alice und Bob, zwei Mitarbeiter in einem Unternehmen, besitzen jeweils einen Rechner. Alice will Bob eine Mail schicken, die vertrauliche Inhalte enthält. Jetzt gibt es mehrere Methoden: Alice verschlüsselt ihre Mail und teilt ihren Schlüssel Bob mit, damit er die Mail entschlüsseln kann. Das ist aber nicht im Sinne des Erfinders und hat mit PKI nichts zu tun.

Eine andere Möglichkeit wäre, dass Bob ein Schlüsselpaar besitzt, einen Öffentlichen und einen Privaten. Diese beiden Schlüssel bilden gemeinsam eine eindeutige Kennung zum Ver- und Entschlüsseln von Mails. Alice bekommt zum Verschlüsseln den öffentlichen Schlüssel von Bob. Sie verschlüsselt die Mail und versendet sie an Bob. Der entschlüsselt die Mail mit seinem privaten Schlüssel. Solange nur Bob verschlüsselte Mails empfangen soll, braucht man nur ein einziges Schlüsselpaar. Der Öffentliche ist allen Leuten zugänglich, den Privaten hingegen darf Bob niemals aus der Hand geben. Falls dieser doch verloren gehen sollte, muss Bob sich ein neues Schlüsselpaar besorgen und mit dem alten Schlüssel verschlüsselte Mails können nicht mehr geöffnet werden. Da die Schlüssel "nur" zwischen 40 Bit und 2048 Bit lang sind, ist es nur eine Frage der Zeit, bis man aus dem öffentlichen Schlüssel die Mail zurückrechnen kann, indem man die Kombinationen ausprobiert o.ä. Je länger der Schlüssel ist, desto sicherer ist die Mail.

Den öffentlichen Schlüssel bekommt man z. B. von einem Exchange-Server, wenn der andere User ebenfalls in Exchange eingetragen ist. Arbeitet man in einer reinen W2k-Umgebung, übernimmt Active Directory fast völlig transparent die Schlüsselverwaltung.

Ein zweites Beispiel: Alice schickt Bob eine Mail. Diesmal soll aber sichergestellt werden, dass Alice diese Mail geschickt hat und sie zwischendurch nicht verändert wurde. Also muss die Integrität der Mail überprüft werden, um die Authentifizierung zu gewährleisten. Das heisst, der Mail wird eine digitale Signatur hinzugefügt. Diesmal ist es Alice, die ein Schlüsselpaar benötigt. Sie signiert mit ihrem privaten Schlüssel die Mail und schickt diese ab. Beide Rechner haben einen Hash-Wert, der die Integrität sicherstellt. Bob überprüft mit dem öffentlichen Schlüssel von Alice die Mail.

Im ersten Beispiel ist die Authentifizierung in Frage gestellt, im zweiten ist die Mail nicht verschlüsselt.

Zertifikate werden von Certificate Authorities (CA) ausgestellt. Die Zertifikatsdatenbank gehört zu den Systemstatusdaten, wird also dort mitgesichert. Ein Server, der als CA in einer Domäne eingerichtet ist, verwaltet die Zertifikate, die wir für PKI benötigen. Der CA prüft die Anforderung von einem Client und stellt diesem ein Zertifikat aus. Diese CA ist auf jeden Fall dafür verantwortlich, dass Zertifikate zurückgezogen bzw. gesperrt werden. Zertifikate werden gesperrt, wenn sie abgelaufen oder wenn private Schlüssel verloren gegangen sind (CRL / Certificate Revocation List). Die Verantwortlichkeit kann erweitert werden, um Zertifikate zu veröffentlichen. Das Schlüsselpaar wird von dem eigenen Rechner generiert. Dieser schickt zur Anforderung den schon generierten öffentlichen Schlüssel an die CA, um sich das Zertifikat zu besorgen. Also ist das Zertifikat nichts anderes, als eben dieser Schlüssel, der von der CA digital signiert wurde. Daraufhin generiert sich der Rechner seinen privaten Schlüssel. Wer der ausstellenden CA vertraut, erkennt das Zertifikat als echt an.