Bundesamt für Sicherheit in der Informationstechnik

M 4.333 Sichere Konfiguration von Winbind unter Samba

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Wird Samba im "domain"- oder "ads"- Security-Mode eingesetzt (siehe M 4.328 Sichere Grundkonfiguration eines Samba-Servers ), spielt die sicherere Konfiguration von Winbind eine wichtige Rolle. In diesem Fall sind eine ganze Reihe von Empfehlungen zu berücksichtigen.

Mit dem Beitreten einer Domäne ist smbd in der Lage, Benutzer beim Domain Controller (DC) zu authentisieren. Je nach Security Mode und Client geschieht dies durch Auswertung des Kerberos-Tickets oder durch Nachfragen beim DC. Insbesondere letzteres ist aufwändig, da sich smbd einen DC suchen und sich dort anmelden muss, bevor er die Benutzerauthentisierung durchführen kann. Dies generiert mindestens 30 Netzpakete, von denen nur zwei für die eigentliche Authentisierung relevant sind.

Windows arbeitet anders. Die Local Security Authority (LSA) baut beim Start des Domänenmitglieds einmal eine Verbindung zum DC auf und authentisiert sich als Maschine. Sämtliche Benutzerauthentisierungen laufen danach nur noch über diese Verbindung. Dieses Konzept mit smbd allein umzusetzen funktioniert nicht, da es für jeden Client einen eigenen smbd-Prozess gibt und sich Netzverbindungen nicht einfach von mehreren Prozessen gleichzeitig nutzen lassen.

Daher kann als Proxy für die Verbindung zum DC winbindd eingesetzt werden. Er hat eine, mit der LSA unter Windows vergleichbare, Funktion. Insbesondere hält er eine Verbindung zum DC offen und bietet seine Dienste für alle Prozesse im System über einen Unix Domain Socket unter /tmp/winbindd/pipe an. Die smbd-Prozesse versuchen sich bei einer Authentisierung zunächst mit diesem Socket zu verbinden. Erst wenn dies fehlschlägt, initiieren die Prozesse selbst eine Verbindung mit einem DC.

Neben der erfolgreichen Authentisierung benötigt Samba weitere Informationen über einen Benutzer. Es ist erforderlich, dass für jeden Benutzer ein Windows- und ein Unix-Benutzerkonto auf dem Samba-Server vorhanden sind. Das Unix-Benutzerkonto wird unter anderem benötigt, damit Samba die Zugriffskontrolle im Dateisystem dem Kernel überlassen kann (siehe auch M 4.332 Sichere Konfiguration der Zugriffssteuerung bei einem Samba-Server ).

Das heißt, dass jeder Domänenbenutzer mit allen Gruppenmitgliedschaften im Unix-Betriebssystem existieren muss. Theoretisch ist es möglich, alle Domänenbenutzer von Hand unter Unix nachzupflegen. Von dieser Vorgehensweise sollte aber abgesehen und stattdessen Winbind eingesetzt werden.

Winbind ist in der Lage, dynamisch zu Windows-Benutzern und -Gruppen passende Unix-Benutzer und -Gruppen zu erzeugen, falls diese unter Unix noch nicht existieren. Dabei kommt das "nss_winbind"-Modul zum Einsatz., es kann durch einen Eintrag in /etc/nsswitch.conf eingebunden werden. Dies könnte beispielsweise folgendermaßen aussehen:

passwd: files winbind
group: files winbind

Mit diesen Einstellungen sucht das Betriebssystem Benutzernamen erst in der Datei /etc/passwd. Findet es dort keinen passenden Benutzer, kontaktiert es winbindd. Damit winbindd in der Lage ist, zu einem Benutzernamen dynamisch alle erforderlichen Unix-Benutzerattribute (beispielsweise Benutzer-ID, Heimatverzeichnis oder Login-Shell) zu erzeugen, muss der Daemon zwei Schritte durchführen. Zuerst erfragt Winbind beim DC den Security Identifier (SID) des Benutzernames. Danach muss Winbind, da der DC normalerweise die Unix-Benutzer-ID für einen Benutzer nicht kennt, selbst eine passende Unix-Benutzer-ID zur SID finden. Je nach konfiguriertem ID-Mapping-Backend geht Winbind anders vor:

  • tdb:
    Dabei handelt es sich um die Standardeinstellung. Meldet sich ein Benutzer, dem noch keine Unix-Benutzer-ID zugeordnet ist, an, so weist Winbind dem Benutzer aus einem vorgegebenen Bereich die nächste freie Unix-Benutzer-ID zu und speichert das ID-Mapping lokal in einer tdb-Datei. Die ID-Mappings werden in der Datei winbindd_idmap.tdb abgelegt.
    Ein Verlust dieser Datei führt zum Verlust sämtlicher Rechtezuordnungen im Dateisystem. Dies kann zu schwerwiegenden Sicherheitslücken führen. Folgendes Beispiel verdeutlicht dies:
    Der Benutzer "Benutzer1" meldet sich mit seinem Windows-Benutzernamen BERLIN\benutzer1 zum ersten Mal am Samba-Server an. Der Benutzer BERLIN\benutzer1 hat in der Windows-Domäne die SID S-1-5-12-7623811015-3361044348-030300820-1013. Windbind reserviert eine freie Unix-Benutzer-ID und ordnet der SID die Unix-Benutzer-ID 2000 zu. Dieses Mapping wird in der Datei winbindd_idmap.tdb abgelegt.
    Nach einer erfolgreichen Anmeldung legt der Benutzer BERLIN\benutzer1 einige Dateien auf dem Samba-Server ab. Diese werden unter der Unix-Benutzer-ID 2000 abgespeichert. Nach einer falsch durchgeführten Sicherung der Datei winbindd_idmap.tdb gehen einige der darin gespeicherten Mappings verloren. Kurze Zeit später meldet sich der Benutzer "Benutzer2" mit seinem Windows-Benutzernamen BERLIN\benutzer2 am Samba-Server an. Der Benutzer BERLIN\benutzer2 hat in der Windows-Domäne die SID S-1-5-12-7623811015-3361044348-030300820-1017. Da die Zuordnung der Unix-Benutzer-ID 2000 durch den Datenverlust verloren gegangen ist, ordnet Winbind diese der SID von Benutzer2 zu.
    Der Benutzer "Benutzer2" kann nun auf alle Dateien zugreifen, die der Benutzer Benutzer1 ursprünglich unter der Unix-Benutzer-ID 2000 abgelegt hat.
    Es muss daher eine regelmäßige Sicherung der Datei winbindd_idmap.tdb durchgeführt werden. Zusätzlich zu den in M 6.135 Regelmäßige Sicherung wichtiger Systemkomponenten eines Samba-Servers angeführten Erläuterungen und Empfehlungen kann das ID-Mapping auch auf folgende Weise gesichert werden. Der Befehl "net idmap dump" führt zu einer Klartextdatei, die sich im Bedarfsfall mit "net idmap restore" wiederherstellen lässt.
  • rid:
    Dieses Backend verwendet den Relative Identifier (RID), die Zeichen hinter dem letzten Bindestrich des Windows-SID, um die Unix-Benutzer-ID algorithmisch zu berechnen. Bei diesem Backend wird keine Datenbank benötigt, da das Mapping deterministisch erfolgt.
  • ad:
    Dieses Backend lässt sich verwenden, wenn im Active Directory die Erweiterungen für die Services For Unix (SFU) implementiert sind und Samba im "ads" Security Mode betrieben wird. Im Rahmen dieser Erweiterung kann der Administrator im Active Directory explizit Unix-Benutzer-IDs vergeben. Winbind liest bei diesem Backend die ID-Mappings nur aus. Ergänzungen oder Änderungen an ID-Mappings werden von Winbind nicht vorgenommen.
    Außerdem handelt es sich bei diesem Backend um das Einzige, das Winbind nutzen kann, um noch weitere Unix-Benutzerattribute zu beziehen (zum Beispiel das Heimatverzeichnis oder die Login-Shell eines Benutzers). Bei allen anderen Backends müssen hierfür andere Mechanismen eingesetzt werden, beispielsweise die Konfigurationsparameter "template shell" und "template homedir" in der Konfigurationsdatei smb.conf.
  • ldap:
    Dieses Backend speichert selbst gewählte ID-Mappings in einem Lightweight Directory Access Protocol ( LDAP )-Verzeichnis.
  • nss:
    Dieses Backend nimmt kein Mapping anhand von SIDs vor, sondern setzt voraus, dass Domänencontroller und Domänenmitglied die /etc/passwd Informationen mit anderen Mitteln, etwa per nss_ldap, synchronisieren. Fragt ein System Winbind dennoch nach einem Mapping, liefert er dieses namensbasiert zurück. Das heißt, er konvertiert einen SID zunächst in den zugehörigen Benutzernamen und schlägt den Namen in /etc/passwd nach. Dieses Backend löst den Winbind Parameter "winbind trusted domains only" ab.

Weitere Informationen über die unterschiedlichen Backends für das ID-Mapping finden sich in deren Manpages. Diese sind nach dem Schema "idmap_<name des backends>" benannt. Die Eingabe "man idmap_nss" liefert weitere Informationen zum nss-Backend. Jedes der ID-Mapping-Backends hat individuelle Konfigurationsparameter. Zur Fehleranalyse sollte das Programm "wbinfo" benutzt werden.

Neben der Unix-Benutzer-ID muss Winbind in der Regel jedem Benutzer weitere Unix-Benutzerattribute zuordnen, beispielsweise ein Heimatverzeichnis. Dies lässt sich über Parameter wie "template homedir" oder "template shell" steuern. Nur beim ID-Mapping-Backend "ad" steht, wie bereits angeführt, zusätzlich ein anderer Mechanismus zur Verfügung.

Wenn es nur einen Samba-Server als Domänenmitglied gibt und die Unix-Benutzer-IDs serverübergreifend nicht synchronisiert werden müssen, kann das ID-Mapping-Backend tdb benutzt werden.

Gibt es mehrere Samba-Server als Domänenmitglieder und müssen daher die Unix-Benutzer-IDs serverübergreifend synchronisiert werden, dann muss auf eines der anderen ID-Mapping-Backends zurückgegriffen werden.

Falls eine Vertrauensstellung zwischen Domänen im Informationsverbund existiert, so muss die folgende Empfehlung im Abschnitt Vertrauensstellungen zwischen Domänen umgesetzt werden.

Vertrauensstellungen zwischen Domänen

Eine Vertrauensstellung ist eine Beziehung zwischen Domänen, durch die Benutzer einer Domäne von einem DC authentifiziert werden können, der sich in einer anderen Domäne befindet.

Auch wenn momentan noch keine Vertrauensstellungen zwischen Domänen im Informationsverbund existieren, ist es sinnvoll, in Hinblick auf die Zukunft, die Maßnahmen in diesem Abschnitt umzusetzen.

Unix-Benutzer-IDs

Windows weist jedem Benutzer und jeder Gruppe eine eindeutige ID zu, den SID (Security Identifier). Der SID enthält einen 96 Bit großen Domänenanteil und einen, innerhalb der Domäne eindeutigen, RID (Relative Identifier). Solange nur eine Domäne im Informationsverbund existiert, kann Unix den RID verwenden um eine eindeutige Unix-Benutzer-ID zu berechnen. Existieren im Informationsverbund mehrere Domänen, die sich gegenseitig vertrauen, funktioniert diese Vorgehensweise nicht mehr. Vertraut die Domäne, in der der Samba-Server Mitglied ist, einer anderen Domäne, ist der RID nicht mehr eindeutig. Der RID "500" bezeichnet grundsätzlich den Administrator, der RID "513" ist der Gruppe der Domänenbenutzer zugeordnet und ab 1000 aufsteigend vergibt jede Domäne fortlaufend RIDs.

Seit Samba Version 3.0.25 gibt es den Parameter "idmap domains". Dieser Parameter ermöglicht es das ID-Mapping, abhängig vom Namen der Domäne, zu konfigurieren.

[global]
idmap domains = BONN BERLIN
idmap config BONN:backend = rid
idmap config BONN:range = 10000 - 49999
idmap config BERLIN:backend = rid
idmap config BERLIN:range = 50000 - 99999

Im oben angeführten Beispiel würde dem Benutzer BONN\Administrator die Unix-Benutzer-ID 10500 zugewiesen, während der Benutzer BERLIN\Administrator die Unix-Benutzer-ID 50500 von Winbind erhalten würde.

Existieren Vertrauensstellungen zwischen Domänen im Informationsverbund, so muss eines der folgenden ID-Mapping-Backends verwendet werden:

  • Backend rid mit idmap domains Konfiguration.
  • Backend ldap mit idmap domains Konfiguration.
  • Backend ad.
  • Backend nss.

Unix Heimatverzeichnis

Die Domäne des Benutzers sollte in den Pfad seines Heimatverzeichnisses aufgenommen werden. Diese Maßnahme verhindert Namenskollisionen bei Vertrauensstellungen. Der Benutzer "benutzer1" in der Domäne BERLIN muss ein anderes Heimatverzeichnis bekommen als der Benutzer "benutzer1" in der Domäne BONN. Dies kann mit folgendem Eintrag in der smb.conf Konfigurationsdatei realisiert werden:

template homedir = /home/%D/%u

Alternativ kann man die Heimatverzeichnisse der Benutzer auch im Active Directory ( AD ) pflegen, wenn Winbind das ID-Mapping-Backend "ad" einsetzt. Im oben angeführten Beispiel würde der Benutzer BERLIN\benutzer1 das Unix Heimatverzeichnis /home/BERLIN/benutzer1 zugewiesen bekommen.

Die Heimatverzeichnisse werden von Winbind nicht automatisch erzeugt. Dies ist, wenn der Samba-Server beispielsweise als Dateiserver eingesetzt wird, auch nicht wünschenswert.

Unix-Benutzername

Um die Eindeutigkeit der Benutzernamen zu gewährleisten, müssen Windows-Benutzernamen auf folgende Art und Weise in Unix-Benutzernamen umgesetzt werden. Der Unix-Benutzername des Windows-Benutzers BONN\benutzer1 lautet BONN<winbind seperator>benutzer1. Standardmäßig ist der Parameter "winbind seperator" auf das Zeichen '\' voreingestellt. Bereitet das voreingestellte Zeichen auf Unix-Systemen Probleme, beispielsweise hat das Zeichen '\' für Unix Eingabeaufforderungen eine Sonderbedeutung, so kann in der Konfigurationsdatei smb.conf ein anderes Zeichen spezifiziert werden.

Beim Ändern des Parameters "winbind seperator" muss vorher geprüft werden an welchen Stellen Domänenbenutzer und -gruppen angegeben sind (beispielsweise in der Konfigurationsdatei smb.conf). Alle diese Stellen müssen nach Ändern des Parameters angepasst werden.

Prüffragen:

  • Wurde Winbind so konfiguriert, dass es zu keinen Kollisionen bei Unix-Benutzer- ID s kommt?

  • Wurde Winbind so konfiguriert, dass es zu keinen Kollisionen bei Benutzerverzeichnissen in Domänen mit Vertrauensstellungen kommt?

  • Setzt Winbind Windows-Benutzernamen in eindeutige Unix-Benutzernamen um?

  • Wird regelmäßig eine Sicherung des ID -Mappings erstellt?

Stand: 11. EL Stand 2009

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK