Inhaltsverzeichnis
Domänen-Mitgliedschaft ist ein Thema von regem Interesse. Samba muss fähig sein, als ein Mitgliedsserver in einem Microsoft-Domänen-Sicherheitskontext teilzunehmen, und Samba muss fähig sein, Maschinen-Vertrauenskonten für Domänen-Maschinen anzubieten; anderenfalls wäre es keine erwägenswerte Option für viele Anwender.
Dieses Kapitel umfasst Hintergrund-Informationen zur Domänen-Mitgliedschaft, zu der dazu notwendigen Samba-Konfiguration und zu MS-Windows-Client-Prozeduren zum Beitreten zu einer Domäne. Warum dies notwendig ist? Weil in beiden Bereichen sowohl in der MS-Windows-Netzwerk-Welt als auch insbesondere in der UNIX/Linux- Netzwerk- und Administrationswelt ein bemerkenswertes Maß an Uninformiertheit, falschen Vorstellungen und fehlendem Wissen existiert. Es ist zu hoffen, dass dieses Kapitel die Lücken füllt.
MS-Windows-Workstations und -Server, die an der Domänen-Sicherheit teilhaben wollen, müssen zu Domänen-Mitgliedern gemacht werden. Das Teilnehmen an der Domänen-Sicherheit wird oft Single Sign On oder kurz SSO genannt. Dieses Kapitel beschreibt den Prozess, der durchgeführt werden muss, um eine Workstation (oder einen anderen Server, z.B. einen MS Windows NT4/200x- Server) oder einen Samba-Server zu einem Mitglied in einem Microsoft-Domänen-Sicherheitskontext zu machen.
Samba-3 kann sich einer MS-Windows-artigen Domäne als nativer Mitgliedsserver anschließen oder einem Samba-kontrollierten Netzwerk. Domänen-Mitgliedschaft hat viele Vorteile:
MS-Windows-Workstation-Benutzer erhalten die Vorteile von SSO.
Zugriffsrechte von Domänen-Benutzern und Datei-Benutzer/Zugriffs-Kontrollen können über die einzelne „Domain Security Account Manager“-(SAM-)Datenbank gesetzt werden. (Sie arbeitet genauso mit Domänen-Mitgliedsservern wie auch mit MS-Windows-Workstations, die Domänen-Mitglieder sind.)
Nur MS Windows NT4/200x/XP Professional-Workstations, die Domänen-Mitglieder sind, können Netzwerk-Anmeldedienste benutzen.
Domänen-Mitglieds-Workstations können durch die Verwendung von Policy-Dateien (NTConfig.POL) und Desktop-Profilen besser kontrolliert werden.
Durch die Verwendung von Anmelde-Skripts können Benutzer transparenten Zugriff auf Netz-Anwendungen erhalten, die auf Applikationsservern laufen.
Netzwerk-Administratoren erhalten bessere Möglichkeiten zum Management von Applikations- und Benutzer-Zugriffen, da kein Bedarf mehr besteht, Benutzer-Konten auf irgendeinem Netzwerk-Client oder -Server zu verwalten, außer in der zentralen Domänen-Datenbank. (Diese ist entweder NT4/Samba-SAM-artig, eine NT4-Domäne, die durch ein LDAP-Backend ergänzt wird, oder eine Active-Directory-Infrastruktur.)
Ein Maschinen-Vertrauenskonto ist ein Konto, das dazu verwendet wird, eine Client-Maschine (und nicht einen Benutzer) am Domänen-Controller zu authentifizieren. In der Windows- Terminologie ist dies als „Maschinen-Konto“ bekannt. Der Zweck des Maschinen-Kontos ist es zu verhindern, dass ein böswilliger Benutzer einen Domänen-Controller missbraucht, um Zugriff auf eine Domänen-Mitglieds-Workstation zu erhalten.
Das Passwort eines Maschinen-Vertrauenskontos fungiert als „gemeinsames Geheimnis“ für die sichere Kommunikation mit dem Domänencontroller. Dies ist ein Sicherheits-Feature, um eine nicht autorisierte Maschine mit demselben NetBIOS-Namen davon abzuhalten, sich der Domäne anzuschließen und Zugriff auf Benutzer/Gruppen-Konten der Domäne zu erhalten. Windows NT/200x/XP Professional-Clients nutzen Maschinen-Vertrauenskonten, aber Windows 9x/Me/XP Home-Clients tun das nicht. Daher ist ein Windows 9x/Me/XP Home-Client nie ein vollwertiges Domänen-Mitglied, da er kein Maschinen-Vertrauenskonto besitzt und auf diese Weise kein „gemeinsames Geheimnis“ mit dem Domänencontroller teilt.
Ein Windows NT4-PDC speichert jedes Maschinen-Vertrauenskonto in der Windows-Registrierung. Die Einführung von MS Windows 2000 brachte auch die Einführung des Active Directory, dem neuen Repository für Maschinen-Vertrauenskonten. Ein Samba-PDC speichert jedoch jedes Maschinen-Vertrauenskonto in zwei Teilen, und zwar wie folgt:
In einem Domänen-Sicherheits-Konto (gespeichert in dem passdb backend, das in der Datei smb.conf konfiguriert wurde. Die exakte Form der gespeicherten Konten-Information ist vom Typ des gewählten Backends abhängig.
Das ältere Format dieser Daten ist die Datenbank smbpasswd, die die UNIX-Login-ID, den UNIX user identifier (UID), die LanMan- und die verschlüsselten NT-Passwörter enthält. Es gibt noch weitere Informationen zu dieser Datei, die uns jedoch an dieser Stelle nicht interessieren.
Die zwei neueren Datenbank-Typen heißen ldapsam und tdbsam. Beide speichern bei weitem mehr Daten als das ältere smbpasswd. Die zusätzlichen Informationen ermöglichen das Implementieren neuer Funktionen für Benutzer-Konten.
In einem entsprechenden UNIX-Konto, das meist in /etc/passwd gespeichert wird.
Es gibt drei Möglichkeiten, Maschinen-Vertrauenskonten anzulegen:
Manuelles Anlegen auf der UNIX/Linux-Befehlszeile. Hier werden sowohl das Samba- als auch das zugehörige UNIX-Konto von Hand angelegt.
Das Verwenden von MS Windows NT4 Server Manager, entweder auf einem NT4 Domain Member Server oder unter Verwendung des Nexus-Toolkits, das auf der Microsoft-Website verfügbar ist. Dieses Tool kann von jeder MS Windows-Maschine aus verwendet werden, solange der Benutzer als Administrator angemeldet ist.
„On-the-fly“ anlegen. Das Samba-Maschinen-Vertrauenskonto wird automatisch von Samba angelegt, wenn sich der Client der Domäne anschließt. (Aus Sicherheitsgründen ist dies die empfohlene Methode.) Das zugehörige UNIX-Konto kann automatisch oder manuell angelegt werden.
Der erste Schritt beim manuellen Anlegen eines Maschinen-Vertrauenskontos ist das manuelle Anlegen des zugehörigen UNIX-Kontos in der Datei /etc/passwd. Dies kann mit vipw oder einem anderen „add user“-Befehl geschehen, der normalerweise zum Anlegen von UNIX-Benutzern verwendet wird. Hier ein Beispiel für einen Linux-basierenden Samba-Server:
root# /usr/sbin/useradd -g machines -d /dev/null -c "machine nickname" \ -s /bin/false machine_name$ root# passwd -l machine_name$
Im obigen Beispiel gibt es eine System-Gruppe „machines“, die als primäre Gruppe für alle Maschinen-Konten verwendet wird. In den folgenden Beispielen hat die Gruppe „machines“ eine numerische GID von 100.
Auf *BSD-Systemen kann dies mit dem Utility chpass geschehen:
root# chpass -a \ 'machine_name$:*:101:100::0:0:Windows machine_name:/dev/null:/sbin/nologin'
Der Eintrag in /etc/passwd wird den Maschinen-Namen enthalten, mit einem angefügten „$“, ohne Passwort, mit einer Null-Shell und ohne home-Verzeichnis. Zum Beispiel würde eine Maschine namens „doppy“ diesen Eintrag haben:
doppy$:x:505:100:machine_nickname:/dev/null:/bin/false
Im obigen Beispiel kann machine_nickname eine beliebige Beschreibung des Clients sein, z.B. RechnerSekretariat. machine_name muss definitiv der NetBIOS-Name des Clients sein, der zu der Domäne hinzugefügt werden soll. Das Zeichen „$“ muss an den NetBIOS-Namen des Clients angefügt werden, oder Samba wird dieses Konto nicht als Maschinen-Vertrauenskonto erkennen.
Jetzt, wo das zugehörige UNIX-Konto angelegt worden ist, besteht der nächste Schritt im Anlegen des Samba-Kontos für den Client. Das Konto enthält das wohlbekannte ursprüngliche Passwort des Maschinen-Vertrauenskontos. Dies kann mit dem Befehl smbpasswd geschehen, wie hier gezeigt:
root# smbpasswd -a -m machine_name
wobei machine_name der NetBIOS-Namen der Maschine ist. Die RID des neuen Maschinen-Kontos wird aus der UID des zugehörigen UNIX-Kontos generiert.
Das manuelle Anlegen eines Maschinen-Vertrauenskontos mit dieser Methode entspricht dem Anlegen eines Maschinen-Vertrauenskontos auf einem Windows NT-PDC mit dem Server Manager. Vom Zeitpunkt des Anlegens des Kontos bis zum Anschließen des Clients an die Domäne und zum Ändern des Passworts ist Ihre Domäne durch Eindringlinge bedroht, die sich mit einer Maschine mit dem gleichen NetBIOS-Namen der Domäne anschließen. Ein PDC vertraut Mitgliedern der Domäne und wird eine große Menge Benutzer-Informationen an solche Clients weitergeben. Sie wurden gewarnt!
Ein funktionierendes add machine script-Skript ist unbedingt notwendig, um Maschinen-Vertrauenskonten automatisch anlegen zu können. Dies gilt unabhängig davon, ob man das automatische Anlegen der Konten verwendet oder den NT4 Domain Server Manager.
Wenn die Maschine, von der aus Sie versuchen, die Domäne zu verwalten, eine MS Windows NT4 Workstation oder MS Windows 200x/XP Professional ist, müssen Sie als Werkzeug das Package namens SRVTOOLS.EXE wählen. Wenn es im Zielverzeichnis ausgeführt wird, entpackt es SrvMgr.exe und UsrMgr.exe. Beides sind Domänen-Management-Werkzeuge für MS Windows NT4 Workstation.
Wenn Ihre Workstation ein Produkt der Microsoft Windows 9x/Me-Familie ist, sollten Sie das Package Nexus.exe von der Microsoft-Website laden. Auch dies wird dieselben Tools entpacken, aber eben für die Windows 9x/Me-Plattformen.
Weitere Informationen zu diesen Tools können Sie von folgenden Stellen beziehen:
| http://support.microsoft.com/default.aspx?scid=kb;en-us;173673 |
| http://support.microsoft.com/default.aspx?scid=kb;en-us;172540 |
Starten Sie srvmgr.exe (Server Manager für Domänen), und folgen Sie diesen Schritten:
Prozedur 7.1. Verwaltung von Maschinen-Konten mittels Server Manager
Wählen Sie den Eintrag aus dem Menü.
Klicken Sie auf .
Klicken Sie im Panel Select Domain auf den Namen der Domäne, die Sie administrieren wollen, und dann auf .
Wählen Sie nochmals das Menü .
Wählen Sie .
Klicken Sie auf den Radio-Button Add NT Workstation of Server in der folgenden Dialogbox, geben Sie den Maschinen-Namen im vorgegebenen Feld ein, und klicken Sie auf .
Die zweite (und empfohlene) Art, Maschinenkonten anzulegen, besteht darin, es einfach dem Samba-Server zu erlauben, diese Konten bei Bedarf anzulegen, wenn der Client der Domäne angeschlossen wird.
Da jedes Maschinen-Vertrauenskonto unter Samba ein zugehöriges UNIX-Konto benötigt, wird üblicherweise eine Methode zum automatischen Anlegen eines UNIX-Kontos bereitgestellt; dies erfordert die Konfiguration der Option „add machine script“ in der Datei smb.conf. Diese Methode ist jedoch nicht erforderlich, die benötigten UNIX-Konten können auch von Hand angelegt werden.
Hier ein Beispiel für ein Red Hat Linux-System.
| [global] |
| # <...Erinnerung an Parameter...> |
| add machine script = /usr/sbin/useradd -d /dev/null -g 100 \ |
| -s /bin/false -M %u |
Die Vorgehensweise, wie Sie eine MS Windows-Workstation oder einen MS Windows-Server zum Domänen-Mitglied machen, hängt von der Version von Windows ab.
Wenn der Benutzer den Client dazu „auserwählt“, ein Domänen-Mitglied zu werden, fragt Windows 200x nach einer Konto/Passwort-Kombination, die dazu berechtigt ist, Maschinen-Konten in der Domäne anzulegen. Ein Samba-Administrator-Konto (also ein Samba-Konto, das root-Rechte auf dem Samba-Server hat) muss hier verwendet werden; der Vorgang wird scheitern, wenn ein normales Benutzerkonto verwendet wird.
Aus Sicherheitsgründen sollte das Passwort für dieses Administrator-Konto auf ein anderes Passwort gesetzt werden als jenes, das für den Benutzer root in /etc/passwd verwendet wird.
Der Name des Kontos, das zum Anlegen von Domänenmitglieds-Maschinen-Konten verwendet wird, kann etwas Beliebiges sein, das der Netzwerk-Administrator wählt. Wenn dieser Name etwas anderes als root ist, wird er einfach auf den dem Benutzer root zugehörigen Eintrag in der Datei „gemappt“, die vom Parameter username map = /etc/samba/smbusers in der Datei smb.conf bezeichnet wird.
Der „Session-Key“ des Samba-Administrator-Kontos fungiert als Verschlüsselungsschlüssel zum Setzen des Passworts für das Maschinen-Vertrauenskonto. Das Maschinen-Vertrauenskonto wird on-the-fly angelegt oder aktualisiert, falls es bereits existiert.
Wenn das Maschinen-Vertrauenskonto manuell angelegt wurde, geben Sie im Menü „Identification Changes“ den Domänen-Namen an, aber aktivieren Sie NICHT die Box Create a Computer Account in the Domain. In diesem Fall wird das bereits existierende Maschinen-Vertrauenskonto verwendet, um die Maschine an die Domäne anzuschließen.
Wenn das Maschinen-Vertrauenskonto on-the-fly angelegt werden soll, geben Sie im Menü „Identification Changes“ den Domänen-Namen an und aktivieren die Box Create a Computer Account in the Domain. In diesem Fall wird der Anschluss an die Domäne wie oben für Windows 2000 beschrieben fortgesetzt (d.h., Sie müssen ein Samba-Administrator-Konto angeben, wenn danach verlangt wird).
Das Anschließen eines Samba-Clients an eine Domäne wird in Domänen-Mitgliedsserver beschrieben.
Diese Server-Betriebsart beinhaltet, dass die Samba-Maschine zum Domänen-Mitglied gemacht wird. Das bedeutet per Definition, dass jegliche Benutzer-Authentifikation durch ein zentral bestimmtes Authentifikationsregime erfolgen wird. Das Authentifikationsregime kann von einem NT3/4-artigen (alte Domänen-Technologie) Server kommen, oder es kann von einem Active Directory Server (ADS) bereitgestellt werden, der unter MS Windows 2000 oder einem neueren MS Windows läuft.
Es sollte natürlich klar sein, dass das Authentifikations-Backend selbst ein Server von jeder Verzeichnis-Dienst-Architektur sein kann, die von Samba unterstützt wird. Es kann LDAP (von OpenLDAP) sein, oder iPlanet von Sun, ein NetWare Directory Server und so weiter.
Bitte besuchen Sie Domain Control für mehr Informationen darüber, wie man ein Domänen-Maschinen-Konto anlegt. Sie erfahren dort auch, wie man eine Samba-Maschine, die Domänen-Mitglied ist, dazu befähigt, sich der Domäne anzuschließen und deren volles Vertrauen zu gewinnen ...
Die nächste Tabelle enthält eine Liste von Namen, die im Rest dieses Kapitels verwendet wurden.
Tabelle 7.1. Annahmen
| NetBIOS-Namen: | SERV1 |
| Windows 200x/NT-Domänen-Namen: | MITTELERDE |
| NetBIOS-Namen des Domänen-PDC: | DOMPDC |
| NetBIOS-Namen der Domänen-BDCs: | DOMBDC1 und DOMBDC2 |
Als Erstes müssen Sie Ihre Datei smb.conf editieren, um Samba mitzuteilen, dass es ab jetzt Domänen-Sicherheit verwenden soll.
Ändern Sie die Zeile (oder fügen Sie sie hinzu) security im Abschnitt [global] Ihrer smb.conf auf:
| security = domain |
Als Nächstes ändern Sie die Zeile workgroup im Abschnitt [global] auf:
| workgroup = MITTELERDE |
Dies ist der Name der Domäne, der wir uns anschließen.
Sie müssen auch den Parameter encrypt passwords auf yes setzen, um Ihren Benutzern die Authentifikation am NT-PDC zu ermöglichen. Dies ist die Standard-Einstellung, falls dieser Parameter nicht gesetzt wird. Es gibt keinen Grund, diesen Parameter zu setzen, aber wenn er in der Datei smb.conf gesetzt wird, muss er auf Yes gesetzt werden.
Zuletzt fügen Sie dem Abschnitt [global] die Zeile password server hinzu (oder ändern sie), sodass sie wie folgt lautet:
| password server = DOMPDC DOMBDC1 DOMBDC2 |
Dies sind der PDC und die BDCs, die Samba kontaktieren wird, um Benutzer zu authentifizieren. Samba wird versuchen, jeden dieser Server in der angegebenen Reihenfolge zu kontaktieren, daher können Sie durch die Reihung der Server die Last auf die einzelnen Domänencontroller verteilen.
Wenn Sie andererseits wollen, dass smbd automatisch die Liste der zu verwendenden Domänencontroller bestimmt, können Sie diese Zeile auf Folgendes setzen:
| password server = * |
Diese Methode erlaubt es Samba, genau denselben Mechanismus wie NT zu verwenden. Sie verwendet entweder Namensauflösung, die auf Broadcasts basiert, führt eine WINS-Datenbank-Abfrage durch, um einen Domänencontroller zu finden, oder lokalisiert einen Domänencontroller mittels DNS-Namensauflösung.
Zum Anschluss an eine Domäne geben Sie diesen Befehl:
root# net join -S DOMPDC -UAdministrator%Passwort
Wenn das Argument -S DOMPDC nicht angegeben wird, wird der Domänen-Name aus der Datei smb.conf gelesen.
Die Maschine schließt sich der Domäne DOM an, und der PDC für diese Domäne (die einzige Maschine, die Schreibzugriff auf die SAM-Datenbank der Domäne hat) ist DOMPDC, daher benutzen Sie die Option -S. Administrator%Passwort ist das Benutzer/Passwort-Paar für ein Konto, das die nötigen Privilegien hat, um Maschinen der Domäne hinzuzufügen. Wenn dies erfolgreich ist, werden Sie eine Nachricht in Ihrem Terminal-Fenster sehen, die den unten gezeigten Text enthält. Wo alte NT4-artige Domänen-Architektur eingesetzt wird, lautet sie:
Joined domain DOM.
Wo Active Directory eingesetzt wird, lautet sie:
Joined SERV1 to realm MYREALM.
Lesen Sie die net-Manpage für mehr Informationen.
Dieser Prozess schließt den Server an die Domäne an, ohne davor das Maschinen-Konto auf dem PDC anlegen zu müssen.
Dieser Befehl durchläuft das Protokoll zum Ändern des Maschinen-Konto-Passworts, dann schreibt er das neue (zufällige) Maschinen-Konto-Passwort für diesen Samba-Server in eine Datei in demselben Verzeichnis, in dem normalerweise die Datei smbpasswd gespeichert würde:
/usr/local/samba/private/secrets.tdb oder /etc/samba/secrets.tdb.
Diese Datei wird von root angelegt, gehört root und ist nicht von einem anderen Benutzer lesbar. Sie ist der Schlüssel zur Domänen-Sicherheit Ihres Systems und sollte genauso umsichtig behandelt werden wie eine Shadow-Passwort-Datei.
Zuletzt starten Sie Ihre Samba-Daemonen neu und machen sich bereit für die Clients, die die neue Domänen-Sicherheit zu benutzen beginnen. Die Art, auf die Sie die Samba-Daemons neu starten, hängt von Ihrer Distribution ab, aber in den meisten Fällen wird Folgendes ausreichen:
root# /etc/init.d/samba restart
Derzeit befreit die Domänen-Sicherheit in Samba Sie nicht von der Aufgabe, lokale UNIX-Benutzer anlegen zu müssen, um die Benutzer, die sich an Ihrem Server anmelden, zu repräsentieren. Das bedeutet: Wenn sich der Domänen-Benutzer DOM\fred an Ihrem Samba-Domänen-Server anmeldet, muss es einen lokalen UNIX-Benutzer fred geben, um diesen Benutzer im UNIX-Datei-System zu repräsentieren. Dies ähnelt dem früheren Samba-Betriebsmodus security = server, wo Samba die Authentifizierungsanfrage an einen Windows NT-Server weitergeleitet hat, genau wie es ein Windows-95- oder Windows-98-Server tun würde.
Lesen Sie das Kapitel Winbind: Verwendung von Domänen-Konten für Informationen darüber, wie ein System automatisch UNIX-UIDs und -GIDs an Windows NT-Domänen-Benutzer und -Gruppen zuweisen kann.
Der Vorteil der Domänen-Level-Security ist, dass die Authentifikation in der Domänen-Level-Security über den authentifizierten RPC-Channel läuft, und zwar in exakt derselben Art, wie sie ein NT-Server ausführen würde. Das bedeutet, dass Samba-Server nunmehr in genau derselben Art an Domänen-Vertrauensverhältnissen teilnehmen, wie es NT-Server tun (z.B. können Sie Samba-Server einer Ressourcen-Domäne hinzufügen, und die Authentifikation vom Ressourcen-Domänencontroller auf einen Konten-Domänen-PDC weiterleiten).
Zusätzlich dazu muss jeder Samba-Daemon bei gesetzter Option security = server eine Verbindung zum Authentifikationsserver offen halten, solange der Daemon läuft. Das kann die Ressourcen eines Microsoft NT-Servers stark belasten, und es kann passieren, dass er nicht genügend verfügbare Verbindungen öffnen kann. Mit security = domain verbinden sich die Samba-Daemons nur so lange mit dem PDC/BDC, wie es zum Authentifizieren des Benutzers nötig ist. Danach trennen sie die Verbindung und schonen damit die Ressourcen des PDCs.
Zuletzt führt das identische Verhalten zu einem NT-Server dazu, dass beim Authentifizieren am PDC der Samba-Server als Teil der Authentifikationsantwort Benutzer-Informationen wie die Benutzer-SID, die Liste der Gruppen, der er angehört, und so weiter erhält.
Ein großer Teil dieses Dokuments wurde zuerst im Web-Magazin LinuxWorld veröffentlicht, und zwar als Artikel http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html url="http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html"/> Doing the NIS/NT Samba.
Dies ist eine knapp gefasste Anleitung für das Setup von Samba-3 mit Kerberos-Authentifikation an einem Windows 200x-KDC. Wir setzen voraus, dass Sie mit Kerberos vertraut sind.
Sie müssen zumindest die folgenden drei Optionen in smb.conf verwenden:
| realm = ihre.kerberos.realm |
| security = ADS |
| # Der folgende Parameter muss nur gesetzt werden, wenn er vorhanden ist. |
| # Der Standard-Wert, wenn er nicht vorhanden ist, ist yes. |
| encrypt passwords = yes |
Falls Samba den entsprechenden ADS-Server nicht korrekt über den Realm-Namen identifizieren kann, verwenden Sie die Option password server in smb.conf:
| password server = ihr.kerberos.server |
Sowohl mit MIT- als auch mit Heimdal-Kerberos ist es unnötig, /etc/krb5.conf zu konfigurieren, es kann sogar schädlich sein.
Microsoft Active Directory Server legen automatisch SRV-Einträge in der DNS-Zone _kerberos.REALM.NAME an, und zwar für jeden KDC in der Realm. Dies ist Teil des Installations- und Konfigurationsprozesses zum Anlegen einer Active-Directory-Domäne.
Die aktuellen KRB5-Libraries des MIT und von Heimdal prüfen beide standardmäßig auf SRV-Einträge, werden also automatisch die KDCs finden. Zusätzlich gilt, dass krb5.conf nur die Angabe eines einzelnen KDC erlaubt, sogar wenn es mehr als einen gibt. Die Verwendung von DNS-Lookups erlaubt es den KRB5-Libraries, jeden verfügbaren KDC zu verwenden.
Beim manuellen Konfigurieren von krb5.conf sieht die minimale Konfiguration so aus:
[libdefaults]
default_realm = IHRE.KERBEROS.REALM
[realms]
IHRE.KERBEROS.REALM = {
kdc = ihr.kerberos.server
}
[domain_realms]
.kerberos.server = IHRE.KERBEROS.REALM
Bei der Verwendung von Heimdal-Versionen vor 0.6 sind folgende Einstellungen vorzunehmen:
[libdefaults]
default_realm = IHRE.KERBEROS.REALM
default_etypes = des-cbc-crc des-cbc-md5
default_etypes_des = des-cbc-crc des-cbc-md5
[realms]
IHRE.KERBEROS.REALM = {
kdc = ihr.kerberos.server
}
[domain_realms]
.kerberos.server = IHRE.KERBEROS.REALM
Prüfen Sie Ihre Konfiguration mit kinit BENUTZERNAME@REALM, und stellen Sie sicher, dass Ihr Passwort vom Win2000-KDC akzeptiert wird.
Mit Heimdal-Versionen vor 0.6 können Sie nur neu in ADS angelegte Konten verwenden oder Konten, deren Passwörter nach der Migration geändert worden sind (bzw. im Falle des Kontos Administrator nach der Installation). Im Moment kann ein Windows 2003-KDC nur mit Heimdal-Versionen nach 0.6 verwendet werden (und ohne default_etypes in krb5.conf). Unglücklicherweise ist dieser gesamte Bereich noch immer in Veränderung begriffen.
Die Realm muss in GROSSBUCHSTABEN angegeben werden, sonst erhalten Sie den Fehler „Cannot find KDC for requested realm while getting initial credentials“ (Kerberos ist case-sensitive!).
Zwischen zwei Servern muss die Zeit synchronisiert werden. Sie erhalten „kinit(v5): Clock skew too great while getting initial credentials“, wenn die Zeitabweichung mehr als fünf Minuten beträgt.
Die Limits für die Zeitabweichung sind in den Kerberos-Protokollen konfigurierbar. Die Voreinstellung beträgt fünf Minuten.
Sie müssen auch sicherstellen, dass Sie einen Reverse-DNS-Lookup auf die IP-Adresse Ihres KDCs durchführen können. Außerdem muss der Name, auf den dieser Reverse-Lookup zeigt, entweder der NetBIOS-Name des KDCs (z.B. der Hostname ohne angehängte Domäne) sein, oder er kann der NetBIOS-Name, gefolgt von der Realm, sein.
Am leichtesten erreichen Sie dies, indem Sie einen Eintrag in /etc/hosts hinzufügen, der die IP-Adresse Ihres KDCs dessen NetBIOS-Namen zuordnet. Wenn Sie dies nicht korrekt erstellen, erhalten Sie einen local error, wenn Sie versuchen, sich der Realm anzuschließen.
Wenn Sie nur Kerberos-Support in smbclient wollen, können Sie direkt zu Testen mit smbclient springen. Die Abschnitte Anlegen des Maschinen-Kontos und Testen des Server-Setups werden nur benötigt, wenn Sie Kerberos-Support für smbd und winbindd brauchen.
Als Benutzer mit Schreibzugriff auf das Samba-Verzeichnis (üblicherweise root) führen Sie Folgendes aus:
root# net ads join -U Administrator%Passwort
Wenn Sie einen Windows-Client zum Mitglied einer ADS-Domäne innerhalb einer komplexen Organisation machen, wollen Sie vielleicht das Maschinen-Konto innerhalb einer bestimmten Organisationseinheit anlegen. Samba-3 erlaubt dies mit folgender Syntax:
root# kinit Administrator@ihre.kerberos.REALM
root# net ads join „Organisations-Einheit“
Zum Beispiel wollen Sie vielleicht das Maschinen-Konto innerhalb eines Containers namens „Server“ unterhalb des organisatorischen Verzeichnisses „Computer\Geschäftsstelle\Abteilung“ anlegen. Das tun Sie wie folgt:
root# net ads join "Computer\Geschäftsstelle\Abteilung\Server"
Samba muss rekonfiguriert (entfernen Sie config.cache) und danach neu kompiliert werden, nachdem die Kerberos-Libraries und Header-Dateien installiert wurden.
Sie müssen sich mit kinit BENUTZERNAME@REALM an der Domäne anmelden. BENUTZERNAME muss ein Benutzer sein, der berechtigt ist, Maschinen zur Domäne hinzuzufügen.
Stellen Sie sicher, dass die Datei /etc/krb5.conf für den Typ und die Version des installierten Kerberos korrekt konfiguriert ist.
Wenn das Anschließen an die Domäne erfolgreich war, werden Sie ein neues Maschinen-Konto im Active Directory sehen, mit dem NetBIOS-Namen Ihres Samba-Servers (im „Computer“ -Folder unter „Benutzer“ und „Computer“).
Versuchen Sie auf einem Windows 2000-Client net use * \\server\share. Sie sollten mit Kerberos eingeloggt werden, ohne ein Passwort zu brauchen. Wenn dies scheitert, führen Sie klist tickets aus. Haben Sie ein Ticket für den Server bekommen? Hat es den Verschlüsselungstyp DES-CBC-MD5?
Versuchen Sie, sich mit smbclient und Kerberos auf Ihrem Samba-Server an einem Win2000-Server oder einem Samba-Server anzumelden. Verwenden Sie smbclient wie gewohnt, aber geben Sie die Option -k an, um die Kerberos-Authentifikation zu wählen.
Sie müssen das Administrator-Passwort zumindest einmal nach der DC-Installation ändern, um die richtigen Verschlüsselungsarten zu installieren.
Windows 200x scheint die Parameter _kerberos._udp und _ldap._tcp nicht im standardmäßigen DNS-Setup zu installieren. Vielleicht wird dies in späteren Service-Packs bereinigt werden.
Samba weist UNIX-Benutzer und -Gruppen (gekennzeichnet durch UIDs und GIDs) auf Windows-Benutzer und Gruppen zu (gekennzeichnet durch SIDs). Diese Zuweisungen werden vom idmap-Subsystem von Samba vorgenommen.
In manchen Fällen ist es hilfreich, diese Zuweisungen unter Samba-Domänen-Mitgliedern zu teilen, damit die Zuweisung name->id auf allen Maschinen identisch ist. Dies kann im Speziellen benötigt werden, wenn man Dateien sowohl über CIFS als auch über NFS bereitstellt.
Um LDAP ldap idmap suffix zu verwenden, setzen Sie:
| ldap idmap suffix = ou=Idmap,dc=quenya,dc=org |
Lesen Sie den smb.conf-Manpage-Eintrag zum Parameter ldap idmap suffix für mehr Informationen dazu.
Vergessen Sie auch nicht, die Option ldap admin dn anzugeben, und sicherzustellen, dass das LDAP-Administrationspasswort in der Datei secrets.tdb gesetzt ist, indem Sie Folgendes ausführen:
root# smbpasswd -w ldap-admin-passwort
In dem Ablauf von Hinzufügen/Löschen/Wiederhinzufügen von Domänen-Maschinen-Konten gibt es viele Fallen für den unvorsichtigen Spieler und viele „kleine“ Dinge, die schief gehen können. Es ist besonders interessant, wie oft Teilnehmer der Samba-Mailing-Liste nach wiederholten gescheiterten Versuchen, ein Maschinen-Konto hinzuzufügen, den Schluss gezogen haben, dass es nötig sei, MS Windows auf der betreffenden Maschine „neu zu installieren“. In Wirklichkeit ist dies bei diesem Problem selten nötig. Die eigentliche Lösung ist oft ziemlich einfach, und das Problem lässt sich leicht beheben, wenn Sie verstehen, wie MS Windows-Netzwerke funktionieren.
„Eine Windows-Workstation wurde neu installiert. Das Original-Maschinen-Konto wurde gelöscht und unmittelbar hinzugefügt. Die Workstation schließt sich der Domäne nicht an, wenn ich denselben Maschinen-Namen verwende. Meine Versuche, die Maschine hinzuzufügen, scheitern mit der Meldung, dass die Maschine bereits im Netzwerk existiert. Ich weiß, dass sie dies nicht tut. Warum scheitert dies?“
Der Original-Name ist nach wie vor im NetBIOS-Namens-Cache und muss erst ablaufen, nachdem das Maschinen-Konto gelöscht wurde, bevor man denselben Namen wieder als Domänen-Mitglied hinzufügen kann. Der beste Tipp dazu ist, das alte Konto zu löschen und dann die Maschine mit einem neuen Namen wieder hinzuzufügen.
„Das Hinzufügen einer Windows 200x- oder XP Professional-Maschine zur Domäne scheitert mit der Meldung Der Computer konnte der Domäne nicht hinzugefügt werden,... Warum?“
Sie sollten prüfen, dass es die Option add machine script in Ihrer Datei smb.conf gibt. Wenn es sie nicht gibt, fügen Sie bitte eine hinzu, die passend für Ihr Betriebssystem ist. Falls ein Skript definiert ist, werden Sie dessen Funktion prüfen müssen. Erhöhen Sie das log level in der smb.conf-Datei auf level 10, und versuchen Sie dann nochmals, sich der Domäne anzuschließen. Prüfen Sie die Log-Dateien, um zu sehen, welche Operation scheitert.
Mögliche Ursachen sind:
Das Skript existiert nicht oder kann nicht in dem angegebenen Pfad gefunden werden.
Korrektur: Fixen Sie es. Stellen Sie sicher, dass das Skript beim Ausführen von Hand sowohl das UNIX-Konto als auch das Samba-SAM-Konto anlegt.
Die Maschine konnte nicht zur UNIX-Systemkonten-Datei /etc/passwd hinzugefügt werden.
Korrektur: Überprüfen Sie, dass der Maschinenname ein gültiger UNIX-Systemkonten-Name ist. Wenn das UNIX-Werkzeug useradd aufgerufen wird, stellen Sie sicher, dass der Maschinen-Name, den Sie hinzufügen wollen, auch mit diesem Werkzeug hinzugefügt werden kann. Auf manchen Systemen erlaubt useradd keine Großbuchstaben oder Leerzeichen in dem Namen.
Das add machine script legt kein Maschinen-Konto in der Samba-Backend-Datenbank an, es ist nur dazu da, ein UNIX-System-Konto anzulegen, dem ein Samba-Backend-Datenbank-Konto zugewiesen werden kann.