NIS und NFS

Ich bin sicher kein Unix Administrator sondern eher Spezialist für Active Directory und Exchange. Aber vielleicht ist das gar keine schlechte Ausgangssituation, für Windows und AD-Administratoren die Zusammenhänge zu erklären. Sehen Sie mit aber nach, wenn ich nicht alles 100% korrekt erkläre oder auf die verschiedenen Varianten (z.B.: SHADOW-Passwd etc.) eingehen.

Achtung: SFU 3.5 sind nur bis Windows 2003 kompatibel.
Windows Services für Unix Version 3.5
http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=274
Die hier beschrieben Funktionen sind Bestandteil von Windows 2008.

utilities and SDK für Subsystem für Unix-based Applications in Microsoft Windows 7 and Windows Server 2008 R2
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=2391
Dieses Paket ist hilfreich, wenn Sie die ein oder anderen "unix-Style"-Programme auch unter Windows nutzen wollen. für die Verwaltung von Anmeldungen oder NFS-Server sind sie nicht erforderlich.

Windows 2012R2

Wichtige Information: Seit Windows 2012R2 gibt es keine NIS-Services mehr

Die Funktionen NFS-Server und NFS-Client sind noch vorhanden:

Allerdings keine NIS-Services. Die AD-Felder für UID und GID sind aber weiterhin vorhanden und können auch weiter genutzt werden

Für eine Übergangszeit wird man wohl noch mit Windows 2012 RTM-DCs arbeiten können, aber mittelfristig wird man wohl auf das AD und Kerberos setzen müssen, um von *NIX-Clients die Windows Domänen zur Authentifizierung zu nutzen. Entsprechende Lösungen gibt es aber schon viele Jahre.

Grundfunktionen mit Windows

Für uns Windows Administratoren ist das Leben doch leicht. Seit es die Windows Domäne gibt (also schon vor dem Active Directory) nehmen wir all unsere Server und Arbeitsstationen wie selbstverständlich in die Domäne auf und denken uns gar nichts dabei. Ein Computer in einer Arbeitsgruppe hat nur seine "lokale Benutzerdatenbank" und kein vernünftiger Admin würde mehrere Systeme ohne Domäne betreiben. Mit der Aufnahme in die Domäne vertrauen diese Systeme nun einer zentralen Benutzerdatenbank, d.h. eine Anmeldung ist möglich, ohne dass es einen passenden lokalen Benutzer gibt. Und jedes Konto bekommt seine eindeutige SID, anhand welcher Zugriffe kontrolliert werden können. Die Zugriffe auf Dateien anderer Systeme erfolgt über das Protokoll SMB.

Grundfunktionen mit Unix

Nun lässt es ich ja nicht leugnen, dass auch andere Betriebssysteme verwendet werden. Wenn man OS/2 und DOS als "ausgestorben" ansieht und Hostsystem wie VMS, BS2000 oder IBM 390 außen vor lässt, dann haben wir es mit diverses Unix-Ausprägungen (Ubuntu, Fedora, Red Hat, BSD, Solaris, MacOS etc.) zu tun, die ebenfalls im Netzwerk unterwegs sind.

Auch dieses Systeme erfordern natürlich eine Anmeldung am System. Dazu dient z.B. eine einfache "Passwd"-Datei (etc/passwd), in der die lokalen Benutzer mit ihrem Anmeldenamen, ihrer UserID (uID), dem Heimatverzeichnis, der zu startenden Shell und dem Kennwort hinterlegt sind. Auch hier können Verzeichnisse (Laufwerke gibt es so ja nicht) z.B.: per NFS von anderen Systemen eingebunden (Mount) werden.

In meiner Praxis sehe ich (leider) sehr oft, dass in Firmen mehrere Unix-Systeme genau so betrieben werden, obwohl es eigentlich ein unding ist.

Wo ist die Unix-Domäne ?

Vermutlich wissen es die meisten gestandenen Unix-Administratoren schon lange, dass SuN vor vielen Jahren ein System mit dem Namen "Yellow Pages" entwickelt hat, welches aber dann in "NIS" (Network Information Service) umbenannt und an wohl alle Unix-Hersteller lizenziert wurde. Der NIS-Server stellt zentrale ebenfalls Datenbanken bereit (z.B.: passwd, group aber auch network, hosts etc.), die NIS-Clients bei sich einbinden können.

Auch NIS spricht von einer Domäne und die Clients muss man derart in diese Struktur aufnehmen, dass diese Clients im NIS-Server "zugelassen" werden und auf dem Client die Einbindung der NIS-Datenbanken konfiguriert werden muss. Das geht natürlich nicht ganz so mit ein paar Mausklicks wie bei Windows. aber ist auch nicht besonders schwer, wenn der NIS-Server einmal läuft.

Active Directory und NIS

Es gibt natürlich NIS-Server für Unix und sie können sogar mehrere NIS-Server aufsetzen, die sich wie früher der PDC und die BDCs replizieren. Aber mit dem Active Directory haben Sie ja schon ein vollwertiges Verzeichnis. Und tatsächlich liefert Microsoft schon viele Jahre die "Services für Unix" mit Windows aus, die aus jedem Windows Server einen NIS-Server machen. Er kann dabei wahlweise "Standalone" oder sogar ins Active Directory integriert arbeiten.

Ihre Active Directory Benutzer und Gruppen können nach einer Schemaerweiterung mit einer uID und GID versehen werden, so dass der NIS-Server diese Daten an NIS-Clients abgeben kann. Beachten Sie aber, dass die Mitgliedschaften in Gruppen getrennt gepflegt werden, d.h. eine Windows Gruppe hat nun zwei Einstellungen zu "Mitgliedern". Hier ein paar Bildschirmauszüge:

Zuerst einmal die Installation der Komponenten auf einem Windows DC. Die Installation kann nur auf einem DC erfolgen

Die Installation erweitert natürlich das Schema, um die entsprechenden Informationen unter zu bekommen. Und es ist natürlich ratsam, auch zumindest einen zweiten DC als NIS-Server zu etablieren, damit auch hier eine Ausfallsicherheit gewährleistet ist. Danach können Sie über die normale MMC für Benutzer und Computer sowohl bei Gruppen als auch bei Benutzern die Unix-Attribute pflegen:

In der Verwaltungskonsole des NIS-Servers finden Sie die von Server bereit gestellten "Maps".

Die genaue Einrichtung und Konfiguration des NIS-Servers entnehmen Sie bitte der Windows Dokumentation. Die Einrichtung ist zwar einfach und geht technisch schnell von der Hand. Allerdings sind einige organisatorische Aufgaben zu bewältigen, z.B. wie die Administration verteilt wird und wie die uIDs vergeben werden. Es darf z.B. keinen Konflikt mit lokalen uIDs der "etc/passwd" geben.

und sie sollten sicherstellen dass der NIS-Server nur von vertrauenswürdigen Systemen angesprochen werden kann, da jeder Client mit einer Verbindung z.B. die PASSWD-Datei sich als Kopie ziehen kann (Risiko: Brute Force Attacke). Das ist auch einer der Gründe, warum NIS immer weniger oft genutzt wird und LDAP und Kerberos als Anmeldemodule bevorzugt werden.

Wenn Sie dem Windows Domain Controller als stabilen und schnellen NIS-Server nicht trauen, dann können Sie problemlos weitere NIS-Server auf Unix installieren, die als Slave ihre Daten ab und an vom Windows Master replizieren. Damit erhalten Sie sich den "Single Account"-Vorteil und bleiben in ihrer gewohnten Unix-Umgebung.

Einrichtung auf dem Client

Bei fast allen Unix-Derivaten gibt es eine Datei "nsswitch" (Name Service Switch), welche steuert, wie das Unix-System seine Konfigurationsdaten enthält. Oft finden Sie schon eine NSSWITCH.NIS als Beispiel, um NIS einzubinden.

passwd: files nis
group: files nis
hosts: files nis [NOTFOuND=return] dns

Hiermit wird dem Unix gesagt, dass er zuerst die Dateien in ETC befragen soll und dann NIS. Bei der Abfrage der Hosts wurde noch DNS aktiviert. Meist reicht es, wenn sie ihre bestehende NSSWITCH um die Einträge NIS an der passenden Stelle ergänzen.

Zusätzlich müssen Sie ihrer Unix-Installation noch mitteilen, zu welche NIS-Domain der Client nun gehört. welches die NIS-Server sind und dass der NIS-Client entsprechend gestartet wird. Da diese Einrichtungen aber je Derivat abweichend sein können, verweise ich hier auf weiterführenden Seiten.

Ob und wie ihr NIS-System funktioniert, können sie mit einigen Kommandozeilentools prüfen, die alle mit "YP"  (Yellow Pages) anfangen. Einen Teil der Programme gibt es auch auf Windows

  • ypcat - Gibt die Einträge einer MAP aus
    z.B. "ypcat passwd" gibt die Benutzer und Kennworte aus. Dabei nutzt das Programm die in der Konfiguration hinterlegten Default Domains und NIS-Server Diese können aber auch optional über Parameter (-d domain -h host) vorgegeben werden.
  • ypwhich - Liefert die NIS-Server
    Auch hier kann optional mit "-d domain" eine andere Domain angegeben werden.
  • ypmatch - Eintrag einer Map anzeigen
    Über die Angabe eines Namens und der MAP können Sie prüfen, welche Informationen der NIS-Server dazu bereit stellt, z.B.: ob ein Benutzer in der passwd enthalten ist.

Da NIS per Default "unverschlüsselt" arbeitet, können Sie die Arbeitsweise auch mit einem Netzwerk-Sniffer analysieren.

Was ist mit NFS ?

Diese Funktion ist seit Windows 2003 R2 Bestandteil der Grundinstallation und muss nur mit installiert werden. In früheren Versionen von Windows müssen Sie dazu die "Services für Unix" (SFu) herunter laden und installieren.

Analog zum Protokoll SMB im Windows Umfeld, welches durch das Samba-Projekt auch für Unix zur Verfügung steht, gibt es auch das NFS-Protokoll, welches den Zugriff auf entfernte Dateisysteme erlaubt, ohne die Dateien erst per FTP o.ä. übertragen zu müssen. Auch dieses Protokoll stammt ursprünglich von SuN. Erst ab Version 4 kann NIS aber auch die Benutzer Authentifizierung. Vorher war nur eine Kontrolle pro Maschine möglich, d.h. der Link des entfernten Dateisystems in das eigene Dateisystem war rechnerabhängig. Trotzdem wurde natürlich Berechtigungen betrachten, wozu Unix wieder mit UserID (uID) und Gruppen heranzieht, die auch über NIS bereit gestellt werden.

Die "unix Services für Windows" erweitern das Betriebssystem sowohl um einen NFS-Client als auch um einen NFS-Server. So können Sie ein Verzeichnis eines Windows Servers auch für Unix-Systeme "freigeben" und umgekehrt auch ein Verzeichnis eines Unix-Systems unter Windows "mappen". Wobei viele Firmen oft ein Unix-System als natürlich den umgekehrten Weg gehen und einfach auf den Unix-Systemen mit SMB auf Windows zugreifen. Wobei bis NFS3 ein Zugriff auf "Freigaben" nur über Computernamen gesteuert werden kann.

Bei Windows 2008 und Windows 2008 R2 ist diese Funktion als "Services für NS"  eine Teilkomponente der "Dateiserver-Rolle":

Danach wird im Windows Explorer bei der Freigabe eine neue Karteikarte eingeblendet, um die NFS-Freigaben zu nutzen:

Die effektiven Berechtigungen des Benutzers mach der NFS-Server dann wieder an der uID/GID fest, die der von dem Client gesendet bekommt. Eine weitere Prüfung (Kennwort o.ä.) findet nicht statt. Es ist daher ein Risiko, wenn die Client nicht "vertrauenswürdig" sind und ich bei einem NFS-Client einfach eine fremde uID verwenden könnte. Damit der NFS-Server zu den übergebenen uIDs und GIDs die passen den Windows-Konten finden kann, muss es einen entsprechenden Dienst geben. Es bietet sich an, diese Daten aus dem Active Directory zu beziehen, was aber konfiguriert werden muss:

Früher gab es dazu den eigenständigen Dienst zum Mappen von Benutzern. Seit Windows 2003 R2 können die NFS-Server und NFS-Clients auch direkt das Active Directory fragen, so dass sogar ein paralleler Betrieb möglich ist (z.B. für Migration). Aber der Dienst wird nach Windows 2008 nicht mehr weiter geführt:

So bildet sich letztlich ein Kreis, in dem Windows, Unix, Active Directory, NIS und NFS-Server und Client zusammen arbeiten.

Der Anwender meldet sich auf dem Unix-System an und der Anmeldeprozess besorgt sich über den NIS-Server die Daten zum Benutzer (uID, GID, Shell und HomeDir). Der Anwender kann dann über die bereits vom Administrator verbundene NFS-Freigabe auf Dateien eines Windows Servers zugreifen.

Was hat das mit Exchange zu tun ?

Genau genommen nicht viel. Auf einen Exchange Server können nur bedingt über Dateifreigaben zugreifen. Wenn Sie nicht z.B. die Message Tracking Logs von Unix auswerten lassen (die aber auch per FTP geladen werden könnten) oder das "PICKuP-Verzeichnis" für den Versand von Mails genutzt wird, (unix SENDMAIL per SMTP ist hier vorzuziehen), dann haben Sie keinen nennenswerten Mehrwert. Das früher verfügbare Laufwerk M: sollten deswegen auch sie nicht wieder einführen.

Der Mehrwert ist eher in der integrierten und vereinfachten Verwaltung von Anmeldekonten zu sehen. Wird ein Active Directory Konto angelegt, kann der gleiche Prozess nun auch den Zugriff auf Unix-Dienste erlauben und natürlich auch wieder entfernen.

Die Anwender werden nur noch einmal gepflegt und nutzen immer das gleiche Kennwort. Die "Single Account"-Konzeption ist damit näher gerückt. Allerdings ist es noch ein weiter Schritt zur Umsetzung einer "Single SignIn" Lösung. Hier ist dann wieder Kerberos ein Stichwort.

Ich hoffe ich habe sie trotzdem etwas neugierig gemacht, in Zukunft nicht mehr auf jedem Unix-System eine lokale Benutzerdatenbank zu pflegen. Übrigens kann Windows auch als Radius-Server dienen. Der nächste Schritt wäre dann die Integration der Switches, Router und anderer Geräte an das Active Directory als zentrale Account-Datenbank.

Kennworte und zwei Verzeichnisdienste

Wer nun doch nicht komplett auf Anmeldedienste unter Unix verzichten und auf das Active Directory mit NIS oder LDAP/Kerberos umsteigen möchte, kann natürlich auch weiter Anmeldedienste auf Unix betreiben. Mit den "Services für Unix" bietet Microsoft sogar einen "Kennwortsync" an, d.h. immer wenn ein Kennwort auf Windows geändert wird, setzt ein Prozess auf dem Server diese Daten auch im uNXI-System. Auch umgekehrt kann eine Änderung des Kennworts unter Unix mit einem PAM-Modul erkannt werde und das dazu gehörige Kennwort unter Windows mit ändern.

Weitere Links

Die meisten Funktionen der Benutzernamenzuordnung wurden durch die Active Directory-Suche ersetzt. Die Active Directory-Suche ermöglicht Client für NFS und Server für NFS das direkte Abrufen von uID- und GID-Informationen (Benutzer-ID und Gruppen-ID) aus Active Directory.