Letzte Änderung: 15.4.98 von B. Tritsch
Zurück zum Index "PC- und MS-Windows-Support"
Ein zentrales Problem bei der Verwaltung eines Unternehmensnetzwerks mit vielen Client- und Server-Komponenten ist die Konsistenz der Konfigurationsdateien. Die Firma Sun Microsystems entwickelte daher das vormals "Yellow Pages" genannte verteilte Namenssystem zur zentralen Administration von Benutzern und Computern. Die Realisierungsgrundlage ist eine Art "Nachschlage-Service", der insbesondere System-Administratoren entlasten soll.
Der Name "Yellow Pages" wurde dann aus lizenzrechtlichen Gründen in "Network Information System" geändert. Es existiert auch eine NIS+ Implementierung, die erweiterte Funktionalitäten bereitstellt. NIS+ konnte sich bisher jedoch im Gegensatz zu NIS nicht als Standard durchsetzen.
NIS ist ein sogenannter Name Service, der anderen Rechnern die verwalteten Informationen auf Anfrage bereitstellt. Damit lassen sich jene Konfigurationen zentral verwalten, die auf UNIX-Rechnern standardmäßig in lokalen Dateien im /etc-Verzeichnis gehalten werden. Eine NIS-Domäne (nicht zu verwechseln mit einer NT-Domäne) ist daher eine Gruppe von Rechnern, die sich eine Reihe von gemeinsamen Daten teilen:
Der NIS-Namensraum (Name Space) besteht dabei aus folgenden Informationen:
Die grundlegende Architektur von NIS baut dabei auf eine Architektur mit Master Servers und Slave Servers (Replicators). Der NIS-Namensraum ist hierbei flach, d.h. er ist nicht hierarchisch. Die Informationen werden in einem Satz von Dateien gespeichert, die "Maps" oder "Databases" genannt werden. Die Maps dürfen dabei nur auf dem NIS Master Server erzeugt werden, niemals auf einem NIS Slave Server. Die Slave Servers haben grundsätzlich nur die Aufgabe, den Master Server bei vielen Anfragen zu entlasten und Sicherheitskopien der Maps zu halten.
Bei Änderungen an den Maps des Master Servers müssen diese an die Slave Server weitergegeben werden. Dies geschieht mit dem Kommando Yppush, der für eine Synchronisation aller erreichbaren NIS-Server sorgt. Ist ein Slave nicht kontaktierbar (z.B. weil er ausgeschaltet ist), so muß er beim Systemstart in der Lage sein, sich eigenständig mit dem Master zu synchronisieren. Dies läßt sich z.B. mit einem sogenannten Cron-Job, das heißt einem regelmäßig automatisch ausgeführten Kommando realisieren.
Eine NIS-Map ist physikalisch eine ASCII-Datei, die vom zuständigen NIS-Prozeß ausgewertet wird. Alle durch NIS verfügbaren Informationen werden aus den Maps in ein binäres Datenbankformat gewandelt (dbm-Format). Das Format besteht dabei aus zwei Feldern, wobei das erste einem indizierten Schlüssel und das zweite der zugehörigen Information entspricht. Bei einer Anfrage an den NIS-Dienst wird das zugehörige Ordnungskriterium für den Schlüssel mit angegeben, wodurch die Suche genau spezifiziert wird. Dieses Vorgehen resultiert in beschleunigten Suchverfahren innerhalb der spezifizierten NIS-Map, da diese nur einen Schlüssel enthalten kann.
Zumeist wird über NIS-Maps die Konfigurationeinstellung des Betriebssystems verwaltet, auf die Clients mit speziellen Kommandos zugreifen können. Einige der Informationen sind in mehreren Datenbank-Dateien gespeichert. So gibt es z.B. für die Benennung von Workstations die Dateien "host.byname" und "host.byaddr".
Im folgenden sind die wichtigsten Datenbank-Dateien und ihr Inhaltsformat aufgeführt:
Passwort-Datenbank
Automount-Datenbank
Gruppen-Datenbank
Die Gesamtheit der Datenbank-Dateien haben folgende Bedeutung:
Die benötigten NIS-Daemons unter UNIX sind:
Die verwendeten Abkürzungen in der obenstehenden Abbildung sind folgende:
Die Technik, die NT-Ankopplung an NIS zu realisieren, besteht in einer "Wrapper-DLL" um die Microsoft/Citrix GINA (Graphical Identification and Authentication DLL). Die GINA-DLL ist das zugehörige Programm zur "Logon-Box". Der Wrapper nimmt Benutzernamen sowie Passwort und validiert sie gegen die NIS-Datenbank.
Die benötigten NIS-Eigenschaften für WinCenter Pro sind die folgenden:
Hierbei zeigen sich auch eine Reihe von Unterschieden zwischen NIS und NT-Accounts, die über verschiedene Mechanismen ausgeglichen werden:
Das Logon-Verhalten bzw. die Authorisierung von Benutzern bei NT-Accounts und NIS-Accounts erfolgt nach folgendem Schema:
Um sich über einem NIS-Account anzumelden, muß sich ein Benutzer bei der NIS-Datenbank autentifizieren. Dafür nimmt die speziell angepaßte GINA.DLL auf dem WinCenter-Server Verbindung zu einem NIS-Server auf, indem Kontoname und Paßwort (unverschlüsselt) dorthin übertragen werden. Existiert dort das Konto und kann validiert werden, so wird als nächstes überprüft, ob dieses Konto auch schon auf dem WinCenter-Server existiert. Wenn ja, dann wird dieses Konto auf das Schlüsselwort "NIS" im Beschreibungsfeld untersucht. Ist dieses Wort vorhanden, dann ist der Benutzer erfolgreich angemeldet.
Existiert das Konto auf dem WinCenter-Server nicht, dann wird es es automatisch generiert, da die korrekte Autentifikation schon durch den NIS-Server stattgefunden hat. Das neue Konto erhält entsprechend seinem Ursprung das Schlüsselwort "NIS" im Beschreibungsfeld und ein NT-konformes Paßwort. Dieses kann aus dem zwischengespeicherten Paßwort aus der Login-Vorgang erzeugt werden. Nach der automatischen Erzeugung des NT-Kontos ist der Benutzer am System angemeldet.
Fehlt bei einem vorhandenen Benutzerkonto auf dem WinCenter-Server nach der Validierung beim NIS-Server das Schlüsselwort "NIS" im Beschreibungsfeld, dann wurde es möglicherweise dort von einem Administrator entfernt. Daher muß zur Sicherheit das Konto über das NT-Paßwort zusätzlich validiert werden. Ist diese Validierung erfolgreich, ist der Benutzer angemeldet. Ist sie erfolglos, wird der Benutzer vom System abgelehnt.
Wurde beim Login schon ganz zu Anfang festgestellt, daß der Benutzer kein NIS-Konto besitzt, dann wird sein Login-Vorgang dennoch weitergeführt. Es wird überprüft, ob der Benutzer einen NT-Account mit dem Schlüsselwort "NIS" im Beschreibungsfeld auf dem WinCenter-Server besitzt. Wenn ja, dann wird der Benutzer abgelehnt und sein Konto auf dem WinCenter-Server deaktiviert. In diesem Fall wurde das Konto auf dem NIS-Server gelöscht, was auf dem WinCenter-Server automatisiert nachgezogen wird.
Hat der Benutzer kein NIS-Konto, jedoch ein NT-Konto ohne das "NIS"-Schlüsselwort, dann wird er über dieses letzte Konto autentifiziert. In diesem Fall ist der Anmeldevorgang identisch zu einem "normalen" Login an einem NT-Rechner. Der System-Administrator eines WinCenter-Servers kann daher dem Standardwerkzeug User Manager for Domains das Konto verwalten wie jedes andere NT-Konto.
Die Einstellungen über das NIS-Konfigurationsfenster enthalten Optionen für:
Die hierbei genutzten Dialogfelder werden im folgenden aufgeführt:
Das erste Feld in der NIS-Dialogbox erlaubt die Eingabe der NIS-Domäne und des NIS-Servers (logischer Name oder IP-Adresse).
Im zweiten Feld erfolgt die Auswahl der Datenbankdateien. Hierbei sind die Verwendung der Automount- und der Group-Datei optional.
Im dritten Feld werden Benutzer-spezifische Angaben eingetragen. Für jeden Benutzer können auch mit Hilfe des User Managers eine Reihe von Attributen gesetzt werden:
Das vierte Feld wird das Login-Verhalten kontrolliert. Eine Option ist hierbei das Anlegen von NIS-Accounts auf dem WinCenter-Server. Im speziellen lassen sich hierbei folgende Einstellungen machen.
Die weiteren Felder dienen der Gruppenverwaltung, der Anbindung von NT-Domänen und dem Test der Einstellungen. Insbesondere für die Gruppenverwaltung ergeben sich daher folgende Möglichkeiten:
Zentrale Wichtigkeit für die NIS-Anbindung von WinCenter Pro hat die Behandlung der Sicherheit für Dateien und Verzeichnisse. Das Security-Konzept von Windows NT hängt dabei direkt von der Authentifikation des Benutzers ab.
Am Anfang der Login-Prozedur erzeugt der "WinLogon"-Prozeß einen "Token", der auf dem "Security Identifier" (SID) basiert. Daraus wird eine "Access Control List" (ACL) generiert, die entsprechend der SID aufgebaut ist.
Der WinLogon-Prozeß leitet das Zugriffs-Token vom NT Security Subsystem ab, das wiederum abhängig vom Security Administration Manager (SAM) ist. Ist der Benutzer authentifiziert übergibt der WinLogon-Prozeß die ACL und das Token an das Win32-Subsystem.
Möchte der Benutzer auf ein "Objekt" zugreifen, fragt das Security Subsystem nach dem Benutzer-Token, verifiziert die zugehörigen Werte und liefert einen Objekt-Handle aus. Dieser erlaubt dem Benutzer die Manipulation des Objekts entsprechend seiner Berechtigungen.
Basierend auf dem Konzept der WinStations und unter Verwendung des Objekt-Managers und des Executive-Subsystems mit seinen separaten und geschützten Speicherbereichen haben die Benutzer einen geschützten und sicheren Zugriff auf die Ressourcen des WinFrame-Server.