Samba - Anwendung Rechnernetzeuheuert/pdf/Anwendung Rechnernetze... · Chris Niederhausen INF03 HS-Merseburg 1/20 Samba 3 Einführung und

___________________________________________________________________ Chris Niederhausen INF03 HS-Merseburg 1/20

Samba 3

Einführung und Anwendungsgebiete

Ausarbeitung zum Vortrag zur Veranstaltung

Anwendung Rechnernetze

WS 2006/2007

Chris Niederhausen INF03

HS-Merseburg


Inhaltsverzeichnis 1 Einführung ........................................................................................................... 3

1.1 Samba Allgemein ......................................................................................... 3 1.1.1 Was ist Samba? .................................................................................... 3 1.1.2 Was muss Samba tun? ......................................................................... 3 1.1.3 Wer nutzt Samba? ................................................................................ 3 1.1.4 Wo gibt es Samba?............................................................................... 3

1.2 Begriffe/Definitionen ..................................................................................... 4 1.2.1 SMB/CIFS ............................................................................................. 4 1.2.2 PDC/BDC.............................................................................................. 4 1.2.3 LDAP..................................................................................................... 4 1.2.4 ADS....................................................................................................... 4

2 SMB/CIFS ........................................................................................................... 5 2.1 Historisches.................................................................................................. 5 2.2 Technisches ................................................................................................. 5

2.2.1 Protkollheader ....................................................................................... 6 2.2.2 Verbindungsaufbau ............................................................................... 7

3 Samba 3 .............................................................................................................. 7 3.1 Serverarten .................................................................................................. 7 3.2 Sicherheit ..................................................................................................... 8

3.2.1 User-Level-Sicherheit............................................................................ 8 3.2.2 Share-Level-Sicherheit.......................................................................... 8

3.3 Bestandteile.................................................................................................. 8 3.3.1 smbd ..................................................................................................... 8 3.3.2 nmbd ..................................................................................................... 8 3.3.3 smbclient ............................................................................................... 9 3.3.4 testparm ................................................................................................ 9 3.3.5 smbstatus.............................................................................................. 9

3.4 Accountdatenbank...................................................................................... 10 3.4.1 Plain Text ............................................................................................ 10 3.4.2 smbpasswd ......................................................................................... 10 3.4.3 ldapsam_compat................................................................................. 10 3.4.4 tdbsam ................................................................................................ 10 3.4.5 ldapsam............................................................................................... 11 3.4.6 mysqlsam............................................................................................ 11 3.4.7 xmlsam................................................................................................ 11

4 Konfigurationsbeispiel ....................................................................................... 11 4.1 OpenLDAP ................................................................................................. 11 4.2 Samba........................................................................................................ 15

4.2.1 smb.conf.............................................................................................. 15 4.2.2 pdbedit ................................................................................................ 16

4.3 Verwaltung mittels SWAT........................................................................... 17 4.3.1 Parameter für Freigaben ..................................................................... 18

5 Zusammenfassung............................................................................................ 19 6 Quellen .............................................................................................................. 20


1 Einführung

1.1 Samba Allgemein

1.1.1 Was ist Samba? Samba ist ein auf TCP/IP basierender Datei- und Druckserver. Es ist ein OpenSource-Projekt, das jeden aktiven SMB/CIFS Client unterstützt. Die größte Stärke von Samba ist dabei, dass man Windows- und Linuxmaschinen benutzen kann, ohne einen seperaten Windowsserver zu benötigen.

1.1.2 Was muss Samba tun? Da Samba als Vermittler zwischen der Unix- und der Windowswelt tätig ist, muss es einige Schwierigkeiten meistern. Darunter zählt z.B. die unterschiedlichen Richtlinien bei der Vergabe von Dateinamen und Verzeichnissen. Während Windows keine Unterscheidung in zwischen Groß- und Kleinschreibung macht, ist es unter Unix/Linux möglich eine Datei test.txt und eine Datei Test.txt in ein und demselben Verzeichnis zu haben. Ein weiterer Punkt ist das Pfadtrennzeichen, in Windows wird der Backslash benutzt und unter Linux der Slash. Der vermutlich größte Unterschied liegt in der Behandlung der Dateirechte. Da Samba als Demon läuft, kann es lediglich die Rechte des Dateisystems weiterleiten, bzw. diese gegebenenfalls einschränken, jedoch unter keinen Umständen erweitern.

1.1.3 Wer nutzt Samba? Samba findet in nahezu jeder Netzwerkgröße seinen Platz. Ob als Stand-Alone-Server in der kleinen Firma, als PDC, mit zusätzlichem BDC in großen Unternehmen oder als Druckserver. Durch seine Flexibilität, vor allem im Bezug auf das Datenbankbackend, kann Samba in Netzwerken beliebiger Größe eingesetzt werden.

1.1.4 Wo gibt es Samba? Außer in jeder großen Linux-Distribution gibt es Samba als freien Download unter www.samba.org.


1.2 Begriffe/Definitionen

1.2.1 SMB/CIFS SMB bzw. CIFS sind Abkürzungen für Server Message Block und Common Internet File System. Beide bezeichnen Kommunikationsprotokolle für Druck-, Datei- und weitere Serverdienste im Netzwerk, wobei CIFS lediglich eine neue Namensgebung von Microsoft ist, die entstanden ist als SMB (mal wieder) erweitert wurde.

1.2.2 PDC/BDC Primärer Domänencontroller bzw. Backup Domänencontroller. Als Domänencontroller bezeichnet man einen zentralen Server, der zur Benutzer- und Computer-Authentifizierung und Autorisierung benutzt wird. Der BDC dient dabei als Ersatz im Fall, dass der PDC nicht mehr verfügbar ist.

1.2.3 LDAP Das Lightweight Directory Access Protocol ist ein Netzwerkprotokoll zur Speicherung von Benutzerdaten in einer hierarchischen Datenbank. Es dient zur Kommunikation zwischen einem LDAP-Client (z.B. Samba) und einem LDAP Server (z.B. OpenLDAP).

1.2.4 ADS Der Active Directoy Service ist ein Verzeichnisdienst für Microsoft Windows 2000/2003 Server. Die Grundlage dafür sind die vier Komponenten LDAP (als Datenbasis) , Kerberos (zur Authentifizierung), CIFS (als „Dateisystem“) und DNS.


2 SMB/CIFS

2.1 Historisches Die erste Erwähnung fand das SMB-Protkolls in einem IBM Dokument von 1985. Es wurde zusammen von Microsoft, IBM und weiteren Firmen entwickelt. Ursprünglich basierte SMB auf dem NetBIOS-Protokoll, einem Transportprotokoll, welches als Protokoll auf der Vermittlungsschicht NetBEUI benutzte. Außer auf NetBIOS über NetBEUI, gibt es noch eine Version, bei der NetBIOS über TCP/IP übertragen wird, dies ist heute die gängigste Art.

Abbildung 2.1 mögliche Protokolleinbettung von SMB, Quelle: [CODEFX]

2.2 Technisches Dadurch, dass das SMB/CIFS Protokoll ständig erweitert wurde und weiterhin erweitert wird, gibt es eine Vielzahl von Protokollversionen. Hier eine Auflistung von einigen:

• Core • Core Plus • LAN Manager 1.0 • LAN Manager 2.0 • LAN Manager 2.1 • NT LAN Manager 1.0 (Windows NT 4.0) • Sambas NT LM 0.12 (Samba) • Common Internet File System (Windows 2000)

Wichtig hierbei ist zu erwähnen, dass alle Protokollversionen abwärtskompatibel sind. Das heißt, dass zwar weiterhin neue Features hinzukommen, jedoch keine alten Features herausgenommen werden.


2.2.1 Protkollheader

Abbildung 2.2 SMB-Protkollheader Quelle: http://www.codefx.com/CIFS_Explained.pdf

Wie in Abbildung 2.1 zu sehen ist, sind die ersten 4-Byte im SMB-Header fest definiert. Das erste Byte ist ein 0xFF, gefolgt von den drei ASCII-Zeichen S, M und B. Das nächste Byte enthält den zu erwartenden Befehl. Das Error Class Byte ist Null, falls kein Fehler aufgetreten ist, ansonsten beinhaltet dieses Feld einen Code, der die Fehlerklasse bestimmt. Im Feld Error Code ist dann der Fehler exakt codiert. Die beiden Flags Felder spezifieren weitere Optionen, z.B. über casesensitive/ insensitive Pfadnamen oder ob es sich um einen Request, bzw. Response handelt. Das pad-Feld ist überlichweise Null. Die Tree ID ist eine 16 Bit Bezeichnung für die Ressource, auf die sich bezogen wird. Die PID ist die Prozess ID, des Prozesses, dass den Aufruf auslöst. Die UID ist die User ID, des Users der den Aufruf auslöst. Die Multiplex ID dient dazu, dass die Response-Pakete einem bestimmten Request zugeordnet werden können. Die Felder WordCount und ByteCount sind sich sehr ähnlich. In beiden Feldern wird die Anzahl der Daten in ParameterWords bzw. Buffer festgehalten. In den Feldern ParameterWords und Buffer ist Platz für weitere Befehlsteile, diese Felder werden benutzt, wenn der Bereich im Command Feld nicht ausreichen ist, wobei ParameterWords für kleinere Mengen und Buffer für größere Mengen an Befehlsparametern benutzt wird.

Abbildung 2.3 Etherealmitschnitt


2.2.2 Verbindungsaufbau Der Verbindungsaufbau erfolgt bei SMB in vier Schritten.

• Aufbau einer TCP Verbindung über den 3-Wege-Handshake • Aushandeln der zu benutzenden Protokollversion • Aufbau der Sitzungsverbindung • Einbinden der Freigaben

3 Samba 3

3.1 Serverarten Unter Serverarten versteht man bei Samba die verschiedenen Betriebsmodi in denen der Sambaserver laufen kann. Da es als Projekt startete, welches mit Windows 3.x zusammenarbeiten sollte und es sich ständig weiterentwickelt hat, gibt es mehrere Arten einen Sambaserver zu konfigurieren. Grob kann man diese Arten wie folgt einteilen: Domänencontroller, Domänenserver und Stand-Alone Server. Wobei man die ersten beiden Arten wieder unterteilen kann. Bei Domänencontrollern betrachtet man primäre Domänencontroller, Backup-Domänencontroller und ADS-Domänencontroller. Wenn Samba als Mitglied in einer Domäne fungiert, ist dies einmal in einer ADS-Domäne und in einer klassischen NT4-Domäne möglich. Die einfachste Art einen Sambaserver zu gestalten ist der Stand-Alone Betrieb (siehe Konfigurationsbeispiel).

3-Wege Handshake

Negotiate Protocol Request Negotiate Protocol Response

Session Setup Request Session Setup Response

Tree Connect Request Tree Connect Response


3.2 Sicherheit In SMB/CIFS gibt es zwei Arten der Sicherheit. Einmal die User-Level-Sicherheit und einmal die Share-Level-Sicherheit. Mit Hilfe dieser Sicherheitslevels wird festgelegt, wie sich der Client beim Server authentifiziert.

3.2.1 User-Level-Sicherheit Bei der User-Level-Sicherheit schickt der Client nach dem Session Setup Request und einer Protokollabsprache eine User/Passwort Kombination. An diesem Punkt sind keine Informationen vorhanden, auf welche Freigabe der Client zugreifen möchte. Entweder akzeptiert der Server diese Kombination oder er verweigert sie. Im Fall, dass der Server die User/Passwort Kombination akzeptiert bindet der Client die Freigaben ein und kann die komplette Session darauf zugreifen, ohne ein weiteres Mal Name und Passwort angeben zu müssen.

3.2.2 Share-Level-Sicherheit Bei der Share-Level-Sicherheit hingegen authentifiziert sich der Client bei jedem Aufruf einer Freigabe. Das heißt, egal welcher Benutzer sich anmeldet, hat derjenige Benutzer Zugriff, sobald er das Passwort kennt. Mit Hilfe des Passwortes kann man noch unterscheiden, ob mit dem Passwort Schreibrechte verbunden sind oder nicht.

3.3 Bestandteile

3.3.1 smbd Der smbd ist der Server Message Block Demon, also der Dienst der die Freigaben zur Verfügung stellt und die Anfragen bearbeitet. Zu den Aufgaben gehört z.B. das Trennen und Verbindungen von Freigaben oder das öffnen und schließen von Druckern, sowie die gesamte Dateisystemarbeit. Für jeden verbundenen Benutzer wird eine eigene smbd Instanz erzeugt, die die Anfragen des Benutzers bearbeitet.

3.3.2 nmbd Der nmbd ist der NetBIOS Name-Server-Demon und ist für die Auflösung und Bekanntmachung der NetBIOS Namen zuständig. Die Bekanntmachung des eigenen Namens erfolgt dabei über Broadcasts, weshalb es in größeren Netzen auch üblich ist, diese Namen mittels des Windows Internet Name Service (WINS) zu verwalten. In solch einem Fall kann der nmbd auch als WINS-Server bzw. WINS-Client konfiguriert werden.


3.3.3 smbclient Der smbclient ist, welch Überraschung, ein Client für das SMB Protkoll. Die Handhabung ist ähnlich wie die eines FTP-Clients und auf die Konsole beschränkt.

3.3.4 testparm Dieses Tool wird benutzt um die Konfigurationsdatei von Samba (smb.conf) auf mögliche Fehler zu testen und ermöglicht so eine Fehleranalyse ohne dass man den Sambadienst stoppen und neustarten muss. Im Fall eines Fehlers gibt testparm eine Fehlermeldung an. In Abbildung 3.1 z.B. ist zu sehen, dass testparm einen Fehler in der smb.conf findet, da eine zu inkludierende Datei nicht gefunden wird.

Abbildung 3.1 testparm Konsolenausgabe

3.3.5 smbstatus Mit smbstatus ist es jederzeit möglich den Status des smbd anzuzeigen. Man erkennt z.B. die PID der neuen Instanz, den Nutzernamen und weitere Informationen.

Abbildung 3.2 smbstatus-Ausgabe


3.4 Accountdatenbank Samba 3 biete die Funktion mehrere Accountdatenbanken (auch Passwordbackends oder Accountbackends genannt) zu benutzen. Im Nachfolgenden sollten einige dieser Accountbackends genannt, sowie Vorteile bzw. Nachteile besprochen werden. Dabei unterscheidet man bei Samba 3 in abwärtskombatible Backends und Backends die mit Samba 3 neu hinzugekommen sind. Zu den alten Backends zählen die Optionen Plain Text, smbpasswd und ldapsam_compat.

3.4.1 Plain Text

Die Option Plain Text benutzt das altbekannte UNIX/Linux Modell, wie es aus /etc/passwd bekannt ist. Hierbei werden die Passwörter im Klartext in einer Datei gespeichert. Die Nachteile liegen auf der Hand, die Vorteile…Vorteile? Gibt es keine.

3.4.2 smbpasswd

Im Gegensatz zur Plain Text-Option werden bei der smbpasswd Methode die Passwörter als LanMan und NT-Stil Hashwerte gespeichert. Diese Art der der Passwortspeicherung enthält allerdings keine SAM (Security Account Manager)-Informationen. Diese Informationen sind notwendig um eine umfangreichere Zusammenarbeit mit NT/XP-Servern zu bieten.

3.4.3 ldapsam_compat

Diese Option dient dazu, die alte Samba 2.2 LDAP-Funktionalität zu unterstützen. Das heißt, wenn bereits ein LDAP Server mit Samba Informationen exisitiert, dann kann das alte LDAP-Schema von Samba 2.2 weiterhin verwendet werden.

Die bereits aufgezählten Optionen sind zur Migrationshilfe implementiert und sollten nicht weiter verwendet werden. Es wird empfohlen eines der neueren Passwortbackends zu benutzen. Zu den neuen Backends zählen tdbsam, ldapsam, mysqlsam und auch xmlsam, wobei letzteres eine Sonderstellung besitzt.

3.4.4 tdbsam

Diese Datenbank ist hauptsächlich als Datenbank für einen lokalen Server gedacht und eignet sich daher nicht, wenn Samba als PDC oder BDC konfiguriert ist. Diese Form des Datenbankbackends ist eigentlich eine erweiterte Form der smbpasswd-Option. Hierbei werden aber die erweiterten SAM-Informationen nicht in einer Klartextdatei abgelegt, sondern in einer tdb(trivial database)-Datei. Allerdings wird ab einer Benutzeranzahl von ca. 250 empfohlen, ein leistungsfähigeres Backend, wie z.B. LDAP, zu benutzen.


3.4.5 ldapsam

Diese Option wird verwendet, wenn die gesamten Benutzerinformationen in einem LDAP-Verzeichnis gespeichert werden sollen. Bei Benutzung eines LDAP-Backends muss das neue Samba3 Schema für LDAP-Verzeichnisse benutzt werden.

3.4.6 mysqlsam

Da in einigen Bereichen MySQL-basierende Datenbanken beliebt sind, war das Samba Team der Meinung Accountinformationen auch in einer solchen Datenbank speichern zu können.

3.4.7 xmlsam

Im Gegensatz zu den vorherigen Optionen ist xmlsam kein Datenbankbackend, welches nicht für den normalen Betrieb verwendet werden kann. Es soll vielmehr ein Hilfsmittel bei der Migration zwischen verschiedenen Datenbankbackends dienen. Mit der Hilfe dieser Option ist es möglich die Benutzerinformationen in einer xml-Datei abzulegen.

Alte Windows-Clients benutzten Klartext Passwörter zur Übermittlung, aus diesen Passwörtern wurden von Samba die UNIX-Hashwerte berechnet und diese mit den Hashwerten aus der UNIX-Benutzerdatenbank verglichen. Neue Windows Clients (ab SP3 für NT4.0) senden nurnoch Klartextpasswörter, wenn dies explizit in der Registry festgelegt wird. Ansonsten werden sogenannte LanMan- und NT-Hashes gesendet, die Samba dann mit den Daten in den jeweiligen Passwortbackends prüft. Außer den Benutzernamen und den Passworthashes werden in neueren Windowsversionen weitere Benutzerinformationen gesendet. Darunter zählen zum Beispiel die Namen der Arbeitsstationen von denen sich ein Benutzer anmelden darf, oder z.B. die Zeit wann ein Passwort abläuft usw. Diese erweiterten Daten werden nur in den neueren Datenbankbackends gespeichert.

4 Konfigurationsbeispiel Zum besseren Verständnis der Thematik soll jetzt ein Konfigurationsbeispiel folgen. Ziel ist es, einen Stand-Alone Samba Server an einen LDAP Server anzubinden. Als Betriebssystem dient dabei SuSE Linux Professional 9.3. Samba kommt in der Version 3.0.12 zum Einsatz und als LDAP Server dient OpenLDAP 2.2.23 mit der Berkley DB 4.3.27. Dies sind alles Versionen, die auf den Installations-CDs von SuSE 9.3 zur Verfügung stehen. Unter http://www.samba.org und unter http://www.openldap.org gibt es die jeweils aktuellen Pakete zum Download.

4.1 OpenLDAP Als erstes wird der OpenLDAP Server konfiguriert. Die notwendige Konfigurationsdatei befindet sich in /etc/openldap/ mit dem Namen slapd.conf und unterscheidet sich nur geringfügig von der Standardkonfiguration, welche in der


slapd.conf.default gesichert ist. Die wichtigesten Unterschiede bestehen beim Einbinden der Schemata, mit deren Hilfe die Daten in der Datenbank gespeichert werden und in einigen Zugriffsrechten auf bestimmte Schlüssel in der Datenbank. Die wesentlichen Unterschiede werden in gelb hervorgehoben. Die ersten Zeilen in der slapd.conf sollten folgendes enthalten: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba3.schema Außer den Standardschemata core, cosine und inetorgperson müssen noch die Schemata nis und samba3 inkludiert werden. Dies ist notwendig, da die Sambabenutzer mit Hilfe des samba3-Schemas beschrieben werden. pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args Diese beiden Zeilen geben die Dateien an, in denen die Prozess-ID und die übergebenen Argumente gespeichert werden. modulepath /usr/lib/openldap/modules Angabe des Pfades, wo mögliche Module gespeichert sind, in diesem Fall werden keine weiteren Module geladen, die Angabe dieses Verzeichnisses gehört dennoch in die slapd.conf. access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to attr=userPassword,userPKCS12,sambaLMPassword,sambaNTPassword by self write by * auth access to attr=shadowLastChange by self write by * read access to * by * read Diese Zeilen betreffen die ACLs, also die Access-Control-Lists, diese können ebenfalls nahezu unverändert übernommen werden. Hinzukommen lediglich zwei Einträge. Mit Hilfe dieser Einträge wird festgelegt, dass nur authentifizierte Benutzer


diese Hash-Werte der Passwörter einsehen können, alle anderen Einträge, die das Samba-Schema betreffen, sind öffentlich lesbar. ############################################################## # BDB database definitions # ############################################################## database bdb checkpoint 1024 5 cachesize 10000 suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw {SSHA}aLXxgEOkuFf2cAYTkKxVh62HX6Rau54y directory /var/lib/ldap index objectClass eq Die letzen Zeilen betreffen die Konfiguration der Berkley Database, auch hier wird von den Standardeinstellungen kaum abgewichen, lediglich die Benutzerspezifischen Daten werden geändert. Hierzu zählen der Domainname, sowie die Angaben zum Manager des LDAP, dieser Benutzer hat die vollen Zugriffsrechte auf die Daten im LDAP Verzeichnis. Das Passwort kann zwar auch im Klartext gespeichert werden, es wird jedoch empfohlen das Konsolenprogramm slappasswd (siehe Abbildung 4.1) zur Verschlüsselung zu benutzen. Das unter directory angegebene Verzeichnis sollte dem Benutzer ldap gehören und nur von diesem Benutzer gelesen und beschrieben werden dürfen. Dies ermöglicht man mit den Befehlen chown (chown ldap /var/lib/ldap) und chmod (chmod 700 /var/lib/ldap).

Abbildung 4.1 slappasswd Konsolenprogramm Nachdem nun die Konfiguration vorbereitet wurde, ist es an der Zeit den OpenLDAP-Server zu starten. Dies geschieht mit Hilfe von „/usr/lib/openldap/slapd –f /etc/openldap/slapd.conf -d 1“, wobei -f den Ort der Konfigurationsdatei bestimmt und -d das Debug-Level. In unserem Fall 1, d.h. es werden wenige Meldungen ausgegeben. Wer Zeit, Lust und Langeweile hat kann den slapd ja mal mit dem Debuglevel 254 starten. Im Normalfall sollte der OpenLDAP jetzt laufen und bereit sein, seine ersten Informationen aufzunehmen. Diese Informationen werden per Hand mit Hilfe des Programms ldapadd hinzugefügt. Dazu wird zuerst eine *.ldif Datei erstellt, die die grundlegenden Einträge enthält. In unserem Fall ist dies sehr minimalistisch gehalten, es sind lediglich die Grundeinträge für die Organisation, den Manager, die Container und die Admins für den Benutzer, Computer und Gruppen-Container vorhanden.


# Organisation für Samba-Basis dn: dc=my-domain,dc=com objectClass: dcObject objectClass: organization dc: my-domain o: Testldap-Org description: OpenLDAP mit Samba 3 # Organisatorische Rolle fuer Verzeichnisverwaltung dn: cn=Manager,dc=my-domain,dc=com objectClass: organizationalRole cn: Manager description: Verzeichnis Manager # Einrichten des Benutzer Containers dn: ou=People,dc=my-domain,dc=com objectClass: top objectClass: organizationalUnit ou: People # Einrichten des Admins fuer People-OU dn: cn=admin,ou=People,dc=my-domain,dc=com cn: admin objectClass: top objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: {SSHA}aLXxgEOkuFf2cAYTkKxVh62HX6Rau54y # Einrichten des Gruppen Containers dn: ou=Groups,dc=my-domain,dc=com objectClass: top objectClass: organizationalUnit ou: Groups # Einrichten des Admins fuer Gruppen-OU dn: cn=admin,ou=Groups,dc=my-domain,dc=com cn: admin objectClass: top objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: {SSHA}aLXxgEOkuFf2cAYTkKxVh62HX6Rau54y # Einrichten des Computer Containers dn: ou=Computers,dc=my-domain,dc=com objectClass: top objectClass: organizationalUnit ou: Computers # Einrichten des Admins fuer Computer-OU dn: cn=admin,ou=Computers,dc=my-domain,dc=com cn: admin objectClass: top objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: {SSHA}aLXxgEOkuFf2cAYTkKxVh62HX6Rau54y


Diese *.ldif Datei wird als initldap.ldif in /etc/openldap/ gespeichert und mit folgendem Befehl dem LDAP hinzugefügt:

ldapadd -f /etc/openldap/initldap.ldif -x -D "cn=Manager,dc=my-domain,dc=com" -W

Dabei gibt -f wieder die Datei an, -x steht für Simple Authentication, -D gibt den Benutzernamen an, mit dem auf das LDAP Verzeichnis zugegriffen werden soll und -W gibt an, dass die Passwortabfrage in der Konsole stattfindet und das Passwort nicht im Klartext bei der Befehlseingabe als Parameter übergeben wird.

Abbildung 4.2 ldapadd-Befehl in der Konsole

4.2 Samba

4.2.1 smb.conf Nachdem nun der OpenLDAP vorkonfiguriert ist, geht es nun daran, den Samba Server zu konfigurieren. Die notwendige Konfigurationsdatei smb.conf liegt im /etc/samba/ Verzeichnis. [global] # gibt den NetBIOS-Namen an netbios name = SambaLDAP # gibt den Manager des LDAP-Verzeichnisses an ldap admin dn = cn=Manager,dc=my-domain,dc=com #Verschlüsselte Verbindung zum LDAP-Server ldap ssl = on #Auswahl des Passwortbackends passdb backend = ldapsam:ldap://localhost #Entfernen des Benutzereintrages im LDAP, falls der Benutzer #entfernt wird ldap delete dn = yes ldap user suffix = ou=People ldap group suffix = ou=Groups ldap machine suffix = ou=Computers ldap suffix = dc=my-domain,dc=com domain master = No


Für einen Stand-Alone-Server mit LDAP Anbindung genügt bereits diese Konfigurationsdatei. Allerdings sind bis hierhin noch keine Freigaben vorhanden, sondern nur globale Einstellungen. Vorhanden sind hauptsächlich LDAP-spezifische Einträge, wie z.B. ldap admin dn, welcher den Namen für den Manager des LDAP-Verzeichnisses angibt oder ldap delete dn = yes, welches bewirkt, dass der User komplett aus dem LDAP-Server gelöscht wird, falls der Sambabenutzer gelöscht wird. Die restlichen Einträge sind dokumentiert oder selbsterklärend. Ein weiterer Teil der smb.conf ist der Teil der Freigaben, auch Shares genannt. Es ist durchaus möglich, diesen Teil ebenfalls per Hand einzupflegen, jedoch gibt es einige Werkzeuge, welche einem die Arbeit sehr erleichtern. Darunter zählen z.B. SWAT, das Samba Web Administration Tool, welches die Konfiguration über ein Webinterface ermöglicht. Eine weitere Möglichkeit besteht darin, KDE oder andere Desktopmanager zu benutzen. Beide Optionen stellen eine bequeme Art und Weise dar, die Freigaben zu verwalten. Dazu später noch mehr.

4.2.2 pdbedit Das Werkzeug pdbedit dient dazu, Benutzer in das OpenLDAP Verzeichnis hinzuzufügen, bevor dies jedoch geschieht muss man etwas beachten. Um in das LDAP-Verzeichnis einen Benutzer hinzuzufügen, muss dieser lokal auf der Maschine existieren, auf der der smbd läuft. Das heißt also, bevor ein Benutzer mit Hilfe von pdbedit hinzugefügt wird, muss dieser mit useradd „Benutzername“ hinzugefügt werden. Danach kann man pdbedit -a „Benutzername“ einen Benutzer erzeugen.

Abbildung 4.3 useradd und pdbedit in der Konsole


Wie in Abbildung 4.3 zu sehen ist, kann man sich mit pdbedit auch eine Liste der vorhandenen Benutzer anzeigen lassen, ebenso ist es möglich mit diesem Werkzeug Benutzereinträge zu modifizieren und natürlich auch zu löschen. Nachdem es nun möglich ist Benutzer in das LDAP-Verzeichnis hinzuzufügen, kommen wir zu dem nächsten Punkt.

4.3 Verwaltung mittels SWAT Ein sehr bequemer, übersichtlicher, aber dennoch mächtiger Weg seinen Samba-Server zu verwalten bietet das Samba Web Administration Tool, kurz SWAT genannt. Dieses Programm ist Teil des Samba Paketes und wird standardmäßig mitinstalliert. Unter SuSE 9.3 ist es standardmäßig nicht als Dienst gestartet, allerdings ist es im Kontrollzentrum unter Konfiguration der Netzwerkdienste (xinetd) zu finden und kann dort gestartet werden. Nachdem der swat-Dienst läuft ist SWAT unter http://localhost:901 verfügbar.

Abbildung 4.4 SWAT


Über den Button SHARES kommt man zum Bereich der Freigabenverwaltung. In diesem Bereich ist es möglich die Freigaben zu erstellen, zu löschen und natürlich bestimmte Parameter für die Freigaben zu ändern.

4.3.1 Parameter für Freigaben Es gibt für normale Verzeichnisfreigaben über 70 Parameter die eingestellt werden können. Der Einfachheit halber beschränke ich mich auf die Option der „Einfachen Ansicht“ unter SWAT, wo lediglich 14 Parameter festgelegt werden können. Für einfache Dateifreigaben reicht das allemal.

comment - Beschreibung/Kommentare zur Freigabe

path - Pfad im Dateisystem zur Freigabe

invalid users - Blacklist mit Benutzer- und Gruppennamen, die keinen Zugriff haben

valid users - Whitelist mit Benutzer- und Gruppennamen, die Zugriff haben sollen

admin users - Liste mit Benutzer- und Gruppennamen, die vollen Schreib/Lesezugriff als root haben

read list - Liste mit Benutzer- und Gruppennamen, die Lesezugriff haben

write list - Liste mit Benutzer- und Gruppennamen, die Schreibzugriff haben

read only - Yes/No - nur Lesezugriff für valid users

guest ok - Yes/No - Zugriff mit Gastkonto

hosts allow - Whitelist mit IP-Adressen die Zugriff zu diesem Dienst haben

hosts deny - Blacklist mit IP-Adressen, die keinen Zugriff zu diesem Dienst haben

browseable - Auflistung der Freigabe beim browsen durch die Netzwerkumgebung

avaible - Generelle Verfügbarkeit dieser Freigabe

vfs objects - mögliches Überladen der Standard I/O Operationen, z.B. Virenscanner,

Logmöglichkeiten Hier ist zu erwähnen, das die Gruppen in den Benutzerlisten (z.B. admin users oder valid users) mit einem @ angegeben werden. Die Eingabeparameter können auch komplexer sein. Ein Eintrag bei hosts allow der folgendermaßen aussieht: „192.168. EXCEPT 192.168.0.5“, würde alle Hosts aus dem 192.168.er Subnetz zulassen, außer den Host mit der IP 192.168.0.2. Ähnlich gilt es bei den Benutzer bzw. Gruppenzugriffen. Wenn z.B. allen Benutzern der Gruppe „users“ der Zugriff gestattet werden soll, bis auf den Benutzer „horst“, dann könnte ein valid users Eintrag so aussehen: „ @users EXCEPT horst“.


5 Zusammenfassung „Zwei Männer gehen eine staubige Straße entlang, als der eine plötzlich einen kleinen roten Stein lostritt. Der Stein setzt sich in seine Sandale und verletzt den Mann am Zeh. Der Mann nimmt den Stein unter zornigem Fluchen aus der Sandale und ist sehr verärgert. Der andere Mann schaut sich den Stein an und sagt: „Dies ist ein Granat, ich könnte ihn zu Schmuck verarbeiten, und eines Tages wird er einer Prinzessin viel Freude bereiten.“ Und die Moral von dieser Geschichte: Zwei Männer, zwei verschiedene Betrachtungsweisen des gleichen Steins. Mögen oder hassen. Samba ist wie dieser Stein. Behandeln Sie es richtig, so kann es Ihnen einen großen Dienst erweisen, aber wenn Sie gezwungen sind, Samba zu benutzen, ohne seine Geheimnisse zu kennen, kann es eine Quelle des Unbehagens sein.“ Quelle: [SAMBA3]


6 Quellen [SAMBAORG] http://www.samba.org How-To Sammlungen, Dokumentationen, Downloads zu Samba 3 [VOJA] http://www.voja.de/uni/samba/samba.html Guter Einstieg, vereinfachter Verbindungsaufbau Abschnitt 7.1 19.11.2006 [WIKIPEDIA] http://www.wikipedia.org Definitionen, Grundlagen [CODEFX] http://www.codefx.com/CIFS_Explained.pdf 20.11.2006 [SAMBA3] John H. Terpstra, Jelmer R. Vernooij: Samba 3 Das offizielle Handbuch, Addison-Wesley

Documents

Samba - Anwendung Rechnernetzeuheuert/pdf/Anwendung Rechnernetze... · Chris Niederhausen INF03 HS-Merseburg 1/20 Samba 3 Einführung und