Inhalt

F  ÜR DIE COMPANY GROUP  1

DOMINIK  HEINZ  1

INHALT   3

1  LINUX - DISTRIBUTIONEN  5

1.1  Debian / Gnu Linux  5

1.1.1  Allgemeine Informationen  5

1.1.2  Kompatibilität  5

1.1.3  Support  5

1.2  Mandrake Linux  6

1.2.1  Allgemeine Informationen  6

1.2.2  Kompatibilität  7

1.2.3  Administration  7

1.3  Red Hat Linux  8

1.3.1  Allgemeine Informationen  8

1.3.2  Kompatibilität  8

1.3.4  Administration  9

1.3.5  Support  9

1.4  S..US.E. Linux  10

1.4.1  Allgemeine Informationen  10

1.4.2  Kompatibilität  10

1.4.3  Administration  11

1.5  Kundenrelevante Distribution  12

2  EINMALAUFWÄNDE  13

2.1  Neuinstallation eines Linux - Servers  13

2.1.1  Die Kickstart Datei  13

2.1.2  Erstellung einer Kickstart Boot - Disk  13

2.1.3  Bereitstellung der Daten:  14

2.2  Datei - und Druckserver  15

2.2.1  Installation der Samba Software  15

2.2.2  Samba Status und Aktivierung  15

2.2.3  Konfiguration des Servers  15

2.2.4  Vertrauensstellung  16

2.2.5  Einbindung weiterer Server der Domäne  16

2.2.7  Konfiguration des Windows Clients  16

2.2.8  Printserver Samba / Cups  16

2.3  Single Sign - On in einem heterogenen Netzwerk  17

2.3.1  Traditionelle Benutzerverwaltung unter UNIX  17

2.3.2  NIS - Network Information Service  18

2.3.3  NSS - Name Service Switch  18

2.3.4  PAM - Pluggable Authentication Module  18

2.3.5  LDAP - Lightweight Directory Autentication Protocol  18

3

2.3.6 Kerberos v5 2.3.7 SSL / TLS 2.3.8 SASL / GSSAPI 2.3.9 Authentication via NSS/PAM/LDAP - Lösungsansatz 1

2.3.10 2.3.11 2.3.11

2.4 Benutzerverwaltung 2.4.1 Benutzerverwaltung im heterogenen Einsatz (Samba) 2.4.2 Benutzerprofile und Login Scripte (Samba) 2.4.3 Anlegen von Benutzergruppen / Importieren der NT Sicherheitsdatenbank (Samba) 2.4.4 root - Rechte ohne root - Account (Linux OS) 2.4.5 Administratorenverwaltung mit Hilfe des RhEN

3 REGELMÄßIGE AUFWÄNDE 24

Virenschutz und -Bedrohung unter Linux 3.1 3.1.1 3.1.2 Virenscanner unter Linux 3.1.3 Virenscanner im heterogenen Einsatz 3.1.4 Virenscanner für Email Server

3.2 Updates / Patches - Red Hat Enterprise Network 3.2.1 Funktion des RhEN: 3.2.2 Zusatzfunktionen 3.2.3 Im Lieferumfang befinden sich folgende Produkte: Softwareverteilung - RhEN Software Delivery Module 3.3 3.3.1 RPM Packages 3.3.2 RhEN Hostet Model (Enterprise Entitlement) 3.3.3 RhEN Mixed Mode (Proxy Server) 3.3.4 RhEN: On - Site Model (Satellite Entitlement) 3.3.5 Notification 3.3.6 Dependency Check 3.3.7 Installation Monitoring - RhEN 3.4 3.3.1 Infrastructure Monitoring 3.3.2 End User Experience Monitoring 3.3.3 Monitoring Module Beispiele 3.5 Backup / Restore (IBM Tivoli) 34 3.5.1 Unterstützung für die Sicherung eines logischen Datenträgers als Einzelobjekt (Imagesicherung) auf

einem Linux86 - Client 3.5.2 Clientumgebung bei Linux für X86 3.5.3 Linux86 - Client installieren (Quelle: IBM.com) 3.5.4 weitere IBM Tivoli Produkte

3.6 Remote Administration

3.6.1 Fernadministration per Konsole (Telnet / ssh) 3.6.1 Administrationsoberfläche Webmin 4 KONFIGURATIONSVORSCHLAG 37

4.1 Schichtenmodell der Konfiguration 37

5 QUELLENANGABEN 38 4

1 Linux - Distributionen

1.1 Debian / Gnu Linux

1.1.1 Allgemeine Informationen

x Empfohlene Linux Version: es gibt nur eine (stable, newest) 3.0 revl „Woody“ x Releasedatum der Version: 19. Juli 2002 x Releasecycle: ca. 2 Jahre x Hauptmerkmale der Distribution: CEO: Gründung: 1993 Beschreibung:

GNU steht für „Gnu is Not Unix“ und ist das Markenzeichen einer großen internationalen Linux Gemeinde, die ohne die Organisation oder Geldmittel einer großen Firma ihre Version des Freien Betriebssystems entwickelt. Neben GNU Linux entwickelt die Gruppe eine Vielzahl weitere Applikationen für Firmen. Vor allem ERP (Enterprise Resource Planing) - Projekte zielen auf Platzhirsche wie SAP.

1.1.2 Kompatibilität

Um Hard - und Software Kompatibilität von Debian feststellen zu können ist es notwendig, sich durch die Dokumentationen der verschiedenen Webseiten zu suchen. Eine offizielle Treiberliste mit Zertifizierung steht nicht zur Verfügung.

1.1.3 Support

x Werden Schulungen für Linux - Administratoren angeboten?

keine

x Steht ein Call - Center zur Verfügung? nein

x 24/7 Service (Telefon, Email)

Mitglieder der Debian Community können jederzeit über irc (irc.debian.org) im Channel #debian erreicht werden. Außerdem stehen Foren und Mailinglisten zur Verfügung, wo Fragen sehr schnell beantwortet werden. Ein Telefonisches Call - Center gibt es nicht.

- 12/5 Service (Telefon, Email)

- 8/5 Service (Telefon, Email)

x Welche Support - Level werden angeboten?

Keine

5

1.2 Mandrake Linux

1.2.1 Allgemeine Informationen Name der Distribution: Mandrake Linux Adresse:

43, rue d´Abouchin 75002 Paris www.mandrake.com

x Empfohlene Linux Version: Corporate Server 2.1 x Releasedatum der Version: x Voraussichtliches Releasedatum nächsten Version: x Hauptmerkmale der Distribution: CEO: Jaques Le Marois Gründung: 1998 Zielgruppe:

Mandrake, ursprünglich ein Ableger von Red Hat, wurde mit dem Ziel gegründet, Privatnutzern eine Linux -Version zu bieten, die nicht nur leicht zu bedienen, sondern auch leicht zu installieren sei. Produkte von Mandrake präsentieren sich mit einer sehr schönen GUI und lassen sich (wenn auch auf manchem Labtop etwas holprig) so einfach wie etwa Windows XP installieren.

6

1.2.2 Kompatibilität

1.2.2.1: Welche spezielle Hardware wird unterstützt?

x Im Bereich Prozessoren (Unterstützung auch für nicht x86 - Architekturen?):

In der Kompatibilitätsliste des Corporate Server 2.1 finden sich ausschließlich x86 Prozessoren bis ca. 1200 MHz Taktraten

x Im Bereich SCSI/RAID Systeme:

Hier steht einer große Liste an unterstützter Hardware zur Verfügung

1.2.2.2: Welche Serverplattformen werden Unterstütz?

x Im Bereich Storage:

Keine näheren Angaben zur Skalierbarkeit dieser Systeme.

x Im Bereich Applicationserver:

Keine näheren Angaben zur Skalierbarkeit dieser Systeme

1.2.3 Administration

x Welche Software wird für die Remote - Administration empfohlen?

Keine eigene Monitoring Software

x Wird IBM Tivoli für Linux unterstützt?

Nicht zertifiziert

1.2.4 Support

x Werden Schulungen für Linux - Administratoren angeboten?

Mandrake bietet Kurse über die Linux Campus Organisation:

Linux - Campus bietet Kurse sowohl für Einsteiger als auch für Experten (System - & Netzwerkadministratoren) an. Die Administrator - Kurse führen bis hin zu dem technischen Linux -Zertifikat des LPI (Linux Professional Institute). Das LPI ist ein internationaler Zertifizierungsprozess für Linux - Wissen und Anerkennung der Software.

MandrakeSoft's Kursangebot ist derart gestaltet, daß die Linux auf jede Distribution anwendbar ist.

x Steht ein Call - Center zur Verfügung?

Nein. Mandrake bietet Online - Support, Mailinglisten und eine Dokumentation. Ausserdem kann man sich von Mandrake als „Mandrake Expert“ zertifizieren lassen und anderen Mandrake Kunden dann als Supporter zur Verfügung stehen.

- 24/7 Service (Telefon, Email)

- 12/5 Service (Telefon, Email)

- 8/5 Service (Telefon, Email)

x Welche Support - Level werden angeboten?

Keine Angabe

7

1.3 Red Hat Linux

1.3.1 Allgemeine Informationen

x Name der Distribution: Red Hat Linux www.Red Hat.de Adresse: Hauptstätterstrasse 58 70178 Stuttgart www.Red Hat.de Tel: 0711 - 96437 - 0 Fax: 0711 - 96437 - 111

x Empfohlene Linux Version: Enterprise Linux 2.1 ES (Kosten ca. 700 €)

x Releasedatum der Version: keine Angabe x Voraussichtliches Releasedatum nächsten Version: Releasecycle wird beim Enterprise Server mit 12 - 18 Monate angegeben. x Hauptmerkmale der Distribution: CEO: Matthew J. Szulik Geschäftsführer: Dirk Haaga Gründung: 1993 / 1994

Zielgruppe: Fachgebiet sind für Red Hat Linux Enterprise Operating und Service Solution.

Red Hat entwickelt Software, die vor allem Großskalierte Systeme stabil betreiben soll. Mit Application Server, Storage und Security Systeme mit einem professionellen Service und Support versucht Red Hat vor allem Großkunden und Firmen eine Rundum - Lösung zu bieten.

1.3.2 Kompatibilität

1.3.2.1: Welche spezielle Hardware wird unterstützt?

x Im Bereich Prozessoren (Unterstützung auch für nicht x86 - Architekturen?): auch nicht x86 Architekturen wie Intels Itanium werden unterstützt AS: multi - CPU SMP und viel Speicher (bis 16 GB) ES: 1 - 2 CPUs Speicher bis 4 GB

x Im Bereich SCSI/RAID Systeme:

Hier steht einer große Liste an unterstützter Hardware zur Verfügung

1.3.2.2: Welche Serverplattformen werden Unterstütz?

x Im Bereich Storage:

AS ist geeignet für besonders große Datenbanken

Um die Kompatibilität zu bestimmten Server - Systemen herauszufinden bietet Red Hat eine umfangreiche Liste mit allen Geräten, die zertifiziert unterstützt werden. HP Proliant Server finden sich beispielsweise alle gängige Modelle.

8

x Im Bereich Applicationserver: AS: Corporate Applications (CRM, ERP, SCM) ES: Mail/File/Print/Web - Server

1.3.4 Administration

x Welche Software wird für die Remote - Administration empfohlen?

Veritas Foundation Suite, VCS, NetBackup Red Hat Network für Monitoring und Softwareverteilung

x Wird IBM Tivoli für Linux unterstützt?

Ja, in den Versionen 7.1 und 7.2

1.3.5 Support

x Werden Schulungen für Linux - Administratoren angeboten?

Es besteht ein umfangreiches Schulungsangebot:

Der Red Hat Certified Engineer ist derzeit die beste und am weitesten verbreitete Ausbildung / Zertifizierung für einen Linux Administrator. Karriere: Operator - > Administrator - > Senior Administrator Schulungsbeispiel:

x Steht ein Call - Center zur Verfügung?

- 24/7 Service (Telefon, Email) - nur bei AS; Reaktionszeit mit 1 Stunde angegeben (bei Email)

- 12/5 Service (Telefon, Email)

- 8/5 Service (Telefon, Email) Außerdem bietet RH den Zugang zum RH Network

x Welche Support - Level werden angeboten?

Support Services: 1 Jahr mit RHEN Support Lifetime: 5 - 7 Jahre

9

1.4 S.U.S.E. Linux

1.4.1 Allgemeine Informationen x Name der Distribution: SuSE Linux x Adresse:

Deutschherrnstrasse 15 - 19 90429 Nürnberg www.SuSE.de Tel: 0911 - 740530 Fax: 0911 - 7417755 Mail: SuSE@SuSE.de

x Empfohlene Linux Version: Enterprise Server 8 (SLES) x Releasedatum der Version: x Voraussichtliches Releasedatum nächsten Version: Release - Cycle 12 - 18 Monate x Hauptmerkmale der Distribution: CEO: Richard Seibt Gründung: Zielgruppe:

SuSE bietet für den professionellen Einsatz die wohl bekannteste Linux Server - Version: SuSE Linux Enterprise Server (SLES).

SuSE ist Mitglied der Initiative D21. Dieser Zusammenschluß von Unternehmen und Unternehmerpersönlichkeiten hat sich zum Ziel gesetzt, den Wandel von der Industrie - zur Informationsgesellschaft in Deutschland zu beschleunigen. Dadurch soll der aktuelle Rückstand Deutschlands im Vergleich zu anderen Ländern aufgeholt und die Chancen der Informationsgesellschaft bezüglich Wettbewerbsfähigkeit, Wachstum und Beschäftigung besser genutzt werden.

Das Engagement von SuSE richtet sich im Rahmen der Initiative D21 vor allem auf die verstärkte Nutzung von Opensource - Software an Schulen und öffentlichen Bildungseinrichtungen.

1.4.2 Kompatibilität

1.4.2.1 Welche spezielle Hardware wird unterstützt?

x Im Bereich Prozessoren (Unterstützung auch für nicht x86 - Architekturen?): Intel Itanium IBM I/P Series AMD 64

Bis zu 32 Prozessoren im Multiprozessorbetrieb werden unterstützt Bis zu 64 GB Hauptspeicher werden unterstützt

x Im Bereich SCSI/RAID Systeme:

Bis zu 600 Festplatten werden unterstützt

Eine Liste mit zertifiziert unterstützter Hardware findet man in der SuSE Dokumentation

10

1.4.2.2 Welche Serverplattformen werden Unterstütz? x Im Bereich Storage:

Um die Kompatibilität zu bestimmten Server - Systemen herauszufinden bietet SuSE Eine umfangreiche Liste mit allen Geräten, die zertifiziert unterstützt werden.

x Im Bereich Applicationserver:

1.4.3 Administration

x Welche Software wird für die Remote - Administration empfohlen?

Für Aufgaben wir Installation und Backup von Clients per Netzwerk und zur Softwareverteilung bietet SuSE den „SuSE Smartclient“. Allerdings zielt dieses System auf die Versorgung von Desktop Systemen und Workstations. Eine Übertragbarkeit auf eine Serverfarm müsste noch untersucht werden. x Wird IBM Tivoli für Linux unterstützt? Möglich aber nicht zertifiziert

1.4.4 Support

x Werden Schulungen für Linux - Administratoren angeboten?

SuSE bietet ein breites Schulungsangebot zu fast allen Themen Beispielschulung:

SLES Administration für Fortgeschrittene II Dauer: 3 Tage Kosten: 1392 €

x Steht ein Call - Center zur Verfügung?

- 24/7 Service (Telefon, Email) - Premium Support Paket - Reaktionszeit 2 Stunden (bei Email)

- 12/5 Service (Telefon, Email)

- 8/5 Service (Telefon, Email) - Standart Support Packet - Reaktionszeit 4 Stunden (bei Email) Außerdem Zugriff auf das SuSE Linux Maintenance Programm.

x Welche Support - Level werden angeboten?

Level 1 - 3

11

1.5 Kundenrelevante Distribution

Für die Integration von Linux Server - Software in die Windows - Dominierte Infrastruktur der Company eignet sich am besten der Enterprise Server v2.1 ES von Red Hat.

x Für Red Hat werden die meisten IBM Tivoli Produkte für x86 Systeme unterstützt. Somit können beispielsweise Backup und Restore Verfahren mit den vorhandenen TSM Servern durchgeführt werden. x Red Hat hat eine größere Niederlassung in Stuttgart

x Red Hat pflegt eine enge Zusammenarbeit mit HP, was die Kompatibilität von Red Hat zu der Serverfarm der Company Lebensversicherungs AG, die von HP Proliant Server dominiert wird garantiert. Mehr unter: http://www.Red Hat.de/news/article/135.html x Red Hat bietet ein Service - Center, das auch große Firmen betreuen kann. x Einfach Installationsroutine mit der Kickstart Datei

x Einfache Updatefähigkeit durch die Nutzung von RPM - Paketen (Mandrake und SuSE unterstützen dieses Format auch mittlerweile, bieten jedoch keinen derartigen Updateservice wie das RhEN) x Einfachere Installation von Softwarepaketen und Programmen, da praktisch alle Applikationen die für Red Hat Linux angeboten werden ein einheitliches RPM - Format vorweisen. Es ist nicht notwendig zusätzliche Installationsscript zu entwerfen. Reduziert administrativen Aufwand x Keine Lizenzkosten für das Betriebssystem oder die Zusatzprogramme.

12

2 Einmalaufwände

2.1 Neuinstallation eines Linux - Servers

2.1.1 Die Kickstart Datei

Um auf einen Server Red Hat Enterprise Linux neu zu installieren werden mit der richtigen Vorarbeit und Konfiguration genau zwei Operationen benötigt:

1. Bootdiskette einlegen

2. Befehl „boot: linux ks=floppy“ eingeben.

Fertig. Der Rest läuft voll automatisch bis zum „schlüsselfertigen“ Server.

Die Abkürzung „ks“ steht für „Kickstart“ und ist ein Red Hat - speziefisches Verfahren für die automatisierte Installation einer Red Hat Linux - Umgebung. Kern des Verfahrens ist eine Textdatei im ASCII Format, welches alle Informationen über die

- Sprache der Installation,

- Konfiguration der Maus / Tastatur,

- Konfiguration eines Boot - Loader (falls notwendig),

- Informationen über Festplattenpartitionierungen,

- Konfiguration der Netzwerkeinstellungen,

- Konfiguration der NIS, LDAP, Kerberos, Hesiod und Samba Authentifizierung,

- Konfiguration der Firewall,

- Auswahl der Software Pakete,

- Konfiguration der GUI,

enthält. Obwohl diese Angaben für eine komplette Installation ausreichen, gibt es die Möglichkeit pre - installation und post - installation Skripts einzubauen.

Vor allem der zweitletzte Punkt hebt dieses System deutlich von seinem Windows - Pendant ab. Um auf einen Windows - Server zusätzliche Software zu installieren ist es meistens notwendig für jedes dieser Tools ein zusätzliches Script zu entwerfen. Da bei Linux fast die komplette angebotene Server Software als OpenSource Software Lizensiert ist, wird sie zusammen mit dem Linux Betriebssystem angeboten. Es muss lediglich das entsprechende RPM - Paket aus der Liste gewählt und installiert werden. (mehr zu RPM - Paketen unter Kapitel 3.4.4)

Allerdings sind die meisten Pakete nicht autonom. Viele Pakete bauen auf anderen Auf oder bilden die Grundlage für noch kommende Pakete. Red Hat bietet hier einen Dienst, der automatisch die „packet dependencies“ prüft und dann entsprechend notwendige Pakete mitinstalliert.

2.1.2 Erstellung einer Kickstart Boot - Disk

Red Hat bietet ein Tool, mit dem über eine komfortable GUI, das einem der vielen Microsoft - Wizards ähnelt eine Kickstart - Datei erstellt werden kann. Die erstellte Datei kann mit einem Texteditor verändert werden. Erfahrene Benutzer konnen die Datei auch komplett in einem Editor erstellen. Diese Datei muss - wenn dies nicht schon der Fall ist - als „ks.cfg“ benannt und in das Grundverzeichnis der Floppy abgelegt werden. Da Linux - Disketten mit dem MS - DOS Dateisystem formatiert werden, kann man die Datei ohne Probleme von Windows aus kopiert werden.

13

2.1.3 Bereitstellung der Daten:

x Installieren via NFS:

In der Kickstart Datei werden die Angaben über den NFS - Server eingetragen. Dabei benötigt man den Domainnamen oder die IP - Adresse und den Pfad der Red Hat Programmdateien. x Installieren via FTP:

In der Kickstart Datei werden die Angaben über den FTP - Server eingetragen. Dabei benötigt man den Namen oder die IP - Adresse und den Pfad der Red Programmdateien. x Installieren via HTTP:

In der Kickstart Datei werden die Angaben über den HTTP - Server eingetragen. Dabei benötigt man den Namen oder die IP - Adresse und den Pfad der Red Programmdateien.

Man kann Red Hat Linux auch mit Hilfe von iso - Images installieren. Hier gibt’s es einige Tricks, mit denen der Installationsaufwand minimiert werden kann.

14

2.2 Datei - und Druckserver

SAMBA (v. 2.2.0) ist ein Server - Dämon, der einen Windows NT 4.0 Server vollständig ersetzen kann. Er bietet angefangen von File - Services, über Print - Services und den PDC Mechanismus alles, was Windows NT ebenfalls kann. SAMBA benutzt als Protokoll NETBIOS/TCP/IP, welches ursprünglich für OS/2 entwickelt wurde. SAMBA ist in zwei Dämonen aufgeteilt, dem SMB Dämon und dem NMB Dämon. Ersterer bietet File - Servives, letzterer bietet die WINS Name - Services an. Beide Dämonen werden stets zusammen gestartet. Print - Services werden vom SMB Dämon übernommen und an den lokalen Printer - Dämon unter LINUX, dem LPD weitergeleitet. Als weiteres Paket enthält SAMBA noch ein Client - Programm, damit sich LINUX auch als Workstation an einem Windows NT Server anbinden läßt.

SAMBA ist auf vielen Betriebsystemen verfügbar, darunter alle UNIXe, Windows NT (ja, auch dort), OS/2, Apple OS X, SUNOS, HP - UX, IRIX, NOVELL 3.11 - 5.0, und natürlich LINUX. Daher eignet sich dieses Protokoll hervorragend zur heterogenen Vernetzung. SAMBA ist aus einem reengineering Projekt des Windows NT Fileserverprotokolls entstanden, welches Microsoft lange versuchte, geheim zu halten. SAMBA besitzt also auch alle Fehler, die NT besitzt.

2.2.1 Installation der Samba Software

Die RPM - Packete der Samba - Software werden zusammen mit dem Betriebssystem installiert. Ein entsprechender Vermerk in der Kickstart - Datei bindet die Pakete von Samba und alle abhängigen Pakete ein.

2.2.2 Samba Status und Aktivierung

Abgesehen von diversen GUIs, die Abfragemöglichkeiten für den Samba - Status bieten kann dieser auch direkt über einen Befehl in der Konsole angefragt werden: /etc/rc.d/init.d/smb status

Kommt dann die Meldung „smbd (pid: xxxx) is running; nmbd (pid: xxxx) is running“ ist Samba aktiv. Sollte dies nicht der Fall sein, hilft ein Neustart des Prozesses mit den Befehlen „smb stop“ und „smb start“. Ein Neustart des Betriebssystems ist nicht nötig.

2.2.3 Konfiguration des Servers

Alle Einstellungen der Samba - Software finden sich in der Datei smb.conf wieder. Dort werden alle wichtigen Angaben gespeichert; wie zum Beispiel:

- Name der Arbeitsgruppe / Domäne

- Name des Servers

- IP und Subnetz des Servers

- Druckprotokoll

- Ort der Passwortspeicherung

- Erlaubte IP - Adressen der Clients usw..

Es stehen eine ganze Liste an grafischen Oberflächen zur Verfügung, mit denen diese Config - Datei per Mausklick editiert werden kann.

15

2.2.4 Vertrauensstellung

Falls der Samba - Server als PDC betrieben wird, muss eine Vertrauensstellung zur NT - Domäne geschaffen werden. Hierzu muss für jede NT - Maschine der Domäne (auch andere Samba - Server) ein Maschinenkonto auf dem Samba PDC eingerichtet werden. Ein Maschinenkonto ist aus der Sicht des Linux - Systems nichts anderes als ein gewöhnlicher Benutzer - Account. Für den in diesem Zusammenhang angestrebten Zweck wird es jedoch in einer speziellen Form angelegt und verwaltet.

2.2.5 Einbindung weiterer Server der Domäne

Alle anderen Samba Server werden der Domäne als Member Server hinzugefügt. Dafür werden einige Zeilen in der Konfigurationsdatei des Member Servers verändert, damit dieser in Zukunft alle Authentifizierungsinformationen vom PDC bezieht.

Handelt es sich bei der Arbeitsstation um ein System vom NT/2000/XP - Typ, muss zuvor auch für diese Station ein Maschinenkonto auf dem Samba - PDC angelegt werden. Für Windows - 9x/Me - Clients ist das nicht erforderlich. Eine Client - Station, die unter Windows XP Professional läuft, benötigt zusätzlich die Einstellung »Domänen - Mitglied: Daten des sicheren Kanals digital verschlüsseln oder signieren (immer) = Deaktiviert« unter »Systemsteuerung/ Verwaltung/lokale Sicherheitsrichtlinie /lokale Richtlinien«.

2.2.7 Konfiguration des Windows Clients

Der Windows Client muss sich im gleichen Subnetz befinden wie der Server. Ein einzelner Samba - Server kann immer nur ein Subnetz auf einmal bedienen. Ausserdem muss die IP des Samba - Servers als DNS und als Gateway des Windows Clients eingetragen werden und als Freigabeebene wird „Freigabe auf Passwort - Ebene“ eingegeben.

Als Domäne wird die Domäne angegeben, die auf dem Samba - Server definiert wurde. Nach einem Neustart (des Betriebssystems) wird der Windows Benutzer nach Benutzernamen und Passwort gefragt. Hier wird der Benutzername gewählt, der zuvor im Samba erstellt wurde. Vorerst bekommt man die Meldung „kein Domainserver verfügbar“, jedoch erscheint die Meldung nur beim ersten Login, da noch ein User - Verzeichnis mit dem User - Profil angelegt werden muss.

Bei Windows XP sind zusätzlich noch einige kleine Änderungen in der Registry notwendig.

2.2.8 Printserver Samba / Cups

Linux unterstützt grundsätzlich alle Drucker die Postscript - oder PCL - fähig sind. Lediglich im Bereich der GDI -Drucker, dass sind speziell für Microsoft - Technologien entwickelte lowcost - Drucker, existieren nicht unterstützte Modelle. Allerdings ist auch im Bereich der Druckerhersteller ein klarer Trend in Richtung Linux erkennbar.

16

2.3 Single Sign - On in einem heterogenen Netzwerk

In einem heterogenen Netzwerk gibt es die Möglichkeit Benutzerinformationen und Benutzerdaten zentral wahlweise auf einem Linux - basierten Server oder auf einem Windows - basierten System zu verwalten ohne, dass der Benutzer etwas davon merkt. Dabei ist der „Single Sign - On“ sehr wichtig - der Benutzer soll mit nur einer Anmeldung gleichzeitig auf Linux - als auch auf Windows - Maschinen authentifiziert werden. In diesem Beispiel soll ein Linux - Rechner in ein Windows - zentrisches Netzwerk integriert werden, in dem die Authentifizierung via Active Directory durchgeführt wird und passwd und group Informationen ebenfalls von Active Directory verwaltet werden. Folgende Punkte sind besonders wichtig:

x zentrale Administration (Userdaten sollen nur an einer Stelle gepflegt werden) x einfache Nutzbarkeit aus Benutzersicht (Daten sollen konsistent und nicht doppelt gehalten werden, d.h. nur ein Passwort für sämtliche Dienste) x Sicherheit (Passwörter sollen nicht für Angreifer lesbar sein)

Bevor weiter auf die Lösung dieses Problems eingegangen wird, hier einige technische Grundlagen:

2.3.1 Traditionelle Benutzerverwaltung unter UNIX

Um die Probleme bei der Integration besser verstehen zu können, zunächst eine kurze Darstellung klassischer Authentifizierungsmechanismen unter UNIX. x /etc/passwd

Die traditionelle Benutzerverwaltung unter UNIX stammt aus der Ära von Mainframes und Terminals, d.h. aus einem Umfeld, in dem eine gemeinsame Basis auf verschiedenen vernetzten Rechnern nicht in das Konzept integriert war. Userdaten werden nach diesem Modell in den Dateien /etc/passwd und /etc/group gehalten. Beide Dateien sind für jedermann lesbar. /etc/passwd enthält eine Zeile pro Benutzer mit folgenden Daten: x login_name: Kennung des Benutzers x password: Das verschlüsselte Passwort x UID: Die numerische Benutzernummer x GID: Die primäre Gruppennummer des Benutzers

x user_name: Ein Feld mit frei wählbaren Informationen, häufig für den vollen Namen des Benutzers und weitere Informationen genutzt. Wird auch als GECOS - Feld bezeichnet x directory: Das Home - Verzeichnis des Benutzers x shell: Der Pfad zur Shell des Benutzers

Die Authentifizierung eines Benutzers erfolgt bei Beginn einer Terminal - Session durch login(1), das sich den Eintrag des anmeldenden Users mittels getpwent(3) o.ä. holt, das vom Benutzer eingegebene Passwort mittels crypt(3) verschlüsselt und mit dem Eintrag aus /etc/passwd vergleicht. Diese Art der Benutzerverwaltung wird auch heute noch genutzt, jedoch in geänderter Form, um diversen Problemen dieses Ansatzes abzuhelfen. x /etc/shadow

Wie oben erwähnt, ist die Datei /etc/passwd für jedermann lesbar und enthält das verschlüsselte Passwort jedes Benutzers. Um es Angreifern schwerer zu machen, Dictionary - Attacken durchzuführen, wurde das Passwort aus /etc/passwd nach /etc/shadow (bzw. von /etc/group nach /etc/gshadow) verlagert und nur noch für root und die Gruppe shadow lesbar gemacht.

Programme, die auf die Passwort - Daten zugreifen (wie z.B. passwd(1)) müssen in diesem Modell suid root oder sgid shadow laufen.

17

2.3.2 NIS - Network Information Service

Um mehrere Rechner auf eine zentrale Instanz mit den Informationen aus /etc/passwd und /etc/group zugreifen lassen zu können, wurde von Sun das System NIS (Network Information System, vormals Sun Yellow Pages) erfunden.

Bei NIS werden die Daten im selben Format wie in /etc/passwd und /etc/group bzw. /etc/shadow und /etc/gshadow zentral in einer Datenbank gehalten und via RPC von den dezentralen Rechnern abgeholt. Nach diesem Ansatz sind keine Änderungen an den Applikationen notwendig, lediglich die C - Library muß angepaßt werden.

2.3.3 NSS - Name Service Switch

Um die Quelle der Informationen aus /etc/passwd usw. möglichst flexibel konfigurieren zu können, wurde ebenfalls von Sun das Verfahren "Name Service Switch" (NSS) eingeführt.

Bei diesem Verfahren wird die Quelle (der Name Service) für eine bestimmte Art von Informationen (z.B. passwd - Informationen, aber auch hosts - Informationen analog zu /etc/hosts) in einem Konfigurationsfile /etc/nsswitch.conf gehalten. Dieses wird von der C - Library gelesen und dann entschieden, woher die Informationen geholt werden (files, nis, etc.).

Dieses Verfahren ist so flexibel, dass mittels dynamischer Libraries beliebige Quellen implementiert werden können, so z.B. auch die Generierung der Daten aus einem LDAP - Verzeichnis mittels nss_ldap. Rel. Link: http://www.padl.com/OSS/nss_ldap.html

2.3.4 PAM - Pluggable Authentication Module

Alle oben beschriebenen Verfahren haben das Problem, dass die Authentifizierungsinformationen stets nur durch das alte mittels crypt(3) verschlüsselte Passwort gegeben waren.

Um hier Flexibilität zu schaffen, wurde PAM ersonnen. Mit dieser Library ist es möglich, viele unterschiedliche Authentifizierungsvarianten bereitzustellen, z.B. via smart cards, Fingerabdruckscanner usw. Allerdings ist es hierzu notwendig, dass alle authentifizierenden Applikationen geändert werden, d.h. nicht mehr mittels getpwent(3) und crypt(3) authentifizieren, sondern die PAM - Library benutzen. Für nahezu alle verbreiteten Applikationen, die eine Authentifizierung vornehmen, existiert jedoch eine PAM - Version. Rel Link: http://www.padl.com/OSS/pam_ldap.html

2.3.5 LDAP - Lightweight Directory Autentication Protocol

LDAP stammt ursprünglich von X.500 ab, welches das Directory Access Protocol DAP definiert. DAP läuft über den gesamten OSI - Stack. LDAP ist ein Verzeichnisdienst - Protokoll das direkt über TCP/IP läuft und die meisten Funktionalitäten von X.500 unterstützt. In einem LDAPVerzeichnisdienst können Entitäten, die verschiedene Attribute und einen eindeutigen Namen, haben, abgespeichert werden. Die Einträge sind hierarchisch in einer Baumstruktur angeordnet, welche typischerweise zum Beispiel die Organisationsstruktur einer Firma repräsentiert

Der LDAP Verzeichnis Dienst basiert auf einem Client/Server Modell. LDAP ist Plattformübergreifend, die Implementierung für Linux nennt sich OpenLDAP.

2.3.6 Kerberos v5

Kerberos ist ein Netzwerk Authentifizierungsprotokoll, das durch eine starke Verschlüsselung eine sehr sichere Authentifizierung ermöglicht. Es gibt eine kostenlose Version, die vom Massachusetts Institute of Technology (MIT) entwickelt wurde. Die OpenKerberos Version trägt den Namen krb5. Inzwischen sind auch viele kommerzielle Versionen auf dem Markt. Win2000 benutzt beispielsweise Kerberos - Authentication innerhalb von Active Directory.

18

2.3.7 SSL / TLS

SSL (Secure Socket Layer) ist ein Protokoll, welches Verschlüsselung und Authentizität einer Client-Server Kommunikation erlaubt. TLS (Transport Layer Security) ich nichts anderes als die nachfolgende Generation von SSL 3.0. Zu Authentifizierung benötigt SSL X.509 Zertifikate, die bereitgestellt werden müssen.

2.3.8 SASL / GSSAPI

(SASL) Simple Authentication and Security Layer - Absicherung einer Authentifizierungsverbindung (GSSAPI) weitere Möglichkeit zur Absicherung einer Authentifizierungsverbindung

2.3.9 Authentication via NSS/PAM/LDAP - Lösungsansatz 1

Auf Linux - Seite werden die Libraries nss_ldap und pam_ldap eingesetzt, um mit dem Active Directory Server via LDAP zu kommunizieren und als Schnittstelle zu NSS und PAM zu dienen. Beide sind in den meisten Distributionen bereits vorhanden. Um die Sicherheit bei der Passwortübergabe zu gewährleisten wird zischen dem Linux und dem Active Directory Server eine Verbindung über SSL erstellt.

Auf der Windows Seite ist es notwendig, das vorhandene Active Directory Schema abzuändern, um es zu dem Linux/_Unix passdw - Format kompatibel zu machen. (Konform zu RFC 2307) Eine Step - by - Step Anleitung für dieses Vorhaben findet sich hier:

http://jaxen.ratisle.net/~jj/nss_ldap - AD_Integration_how - to.html

Ist dies erledigt muss noch ein Software Paket auf Seiten von Linux installiert und konfiguriert werden: x Die Bibliotheken nss_ldap und pam_ldap, die mit dem Active Directory Server zusammenarbeiten sollen und die Schnittstelle zu NSS und PAM darstellen. Diese Bibliotheken sind bei den meisten Distributionen bereits enthalten (so auch bei Red Hat) x Die NSS Software einrichten:

Die Einrichtung von NSS erfolgt über /etc/nsswitch.conf. Änderungen hieran haben sofortige Auswirkung, d.h. es ist Vorsicht geboten, will man sich nicht ungewollt selber aussperren, wenn z.B. die Verbindung zum ADS noch nicht funktioniert. Dazu ist es ratsam, während der Testphase immer eine root-Shell offen zu haben, um im Notfall fehlerhafte Einstellungen wieder rückgängig machen zu können.

Die Konfiguration des NSS in /etc/nsswitch.conf besteht aus jeweils einer Zeile pro Name Service, zuerst der Name des Service, dann die Reihenfolge, in der Lookups durchgeführt werden. Sinnvollerweise sollte dort für nss_ldap Folgendes stehen:

passwd: files ldap group: files ldap shadow: files ldap

Zuerst wird in lokalen Files nachgeschaut, dann erst im LDAP. So gehen lokale Einstellungen vor, z.B. lokale root-Accounts.

x PAM kann entweder in einer Datei für alle Applikationen oder mit einem separaten Verzeichnis mit je einer Datei pro Applikation konfiguriert werden. Eine Funktion von PAM ist beispielsweise, dass bei der Erstanmeldung eines Benutzers seine Home - Directory automatisch von PAM angelegt wird. x Um eine Authentifizierung durchzuführen, führt pam_ldap ein LDAP - bind aus, und überträgt dabei das vom Benutzer eingegebene Passwort im Klartext. Um Angreifern die Möglichkeit zu nehmen, dies mittels Protokoll - Sniffern auszunutzen, sollte die Verbindung zwischen Active Directory und nss_ldap bzw. pam_ldap über SSL/TLS laufen. (hierzu müssen x.509 Zertifikate bereitstehen) Zusätzliche Domumenationen und eine Anleitung finden sich hier: http://jaxen.ratisle.net/~jj/nss_ldap-AD_Integration_how-to.html

2.3.10 Authentication via Kerberos v5 - Lösungsansatz 2

Ein weiterer Lösungseinsatz baut auf einer anderen Softwarekonfiguration auf. Auf Seiten von Windows muss wieder das Active Directory User - Schema erweitert werden um dem RFC 2307 Standart konform zu werden. Auf Seiten von Linux wird ein ganzes Bündel an Software installiert und konfiguriert. Die Kombination aus nss und pam übernimmt die Kommunikation mit der Active Directory. Allerdings wird die Sicherheit nicht von SSL/TLS sondern SASL und GSSAPI übernommen. Die Authentifizierung übernimmt Kerberos selbst, wie bei einer Windows - Maschine. Zum Einsatz kommt das vom MIT entwickelte openSource Pendant zu Kerberos v5: krb5. (krb5 ist als rpm Package verfügbar)

20

2.3.11 Einfügen von Samba 3.0 in eine Active Directory - Lösungsansatz 3

Da Samba (v2.2.x) unsprünglich als WinNT Domänen Controller gedacht war, gibt es seit der Einführung von Windows 2000 und der Active Directory Technologie einige Probleme. Man benötigt um Samba als Domain Controller weiter betreiben zu können eine Art gemischt Win2000 Domäne, in der alte NT Domänen vorhanden sind. Zusätzlich benutzen Windows 2000 und XP die Kerberos Authentifizierung, was die Interoperabilität nicht gerade vereinfacht.

Hier ein kurzes HOWTO, wie man mit der Samba 3.0 Alpha Version einen Linux - Server dazu bringt, sich an einem Win2000 AD Domänen Kontroller zu authentifizieren: Man benötigt:

x Einen Win2000 Server als Domänen Kontroller x Die aktuellen OpenLDAP Bibliotheken für Linux x Die MIT Kerberos Bibliotheken für Linux (krb5) x Die neueste Samba 3.0 Alpha

Zuerst werden Samba und Kerberos auf der Linux - Maschine konfiguriert, was sich je nach Distribution und Gui sehr verschieden gestalten kann. Allerdings sind nicht besonders viele Einstellungen notwendig - Der Zeitaufwand hält sich in Grenzen. Um den Samba - Server der AD hinzuzufügen müssen von der Windows -Maschine aus zwei Befehle auf der Linux - Maschine eingegeben werden, welche den Linuxrechner einbinden. Hat alles bis hierhin funktioniert, findet sich der Linux - Rechner als Eintrag in der Active Directory. Um die Konfiguration zu testen, kann die Standart - Freigabe der Windows - Maschine (c$) von Linux aus ohne Passwort

- Eingabe (dank Kerberos) geöffnet werden.

Der Zugriff von Windows auf die Linux - Maschine ist mit dieser alpha - Release noch nicht möglich. Bis zum final

- Release von Samba 3.0 möchte das Entwickler - Team dieses Problem gelöst haben.

2.3.11 kommerzielle Produkte

- SCO Authentication:

Diese Softwarelösung verfolgt den Lösungsansatz 2

- CoreBiz Directory Server:

Lösung mit Linux als Authenticationserver: Samba für Windows - und PAM für Linux - Clients

21

2.4 Benutzerverwaltung

2.4.1 Benutzerverwaltung im heterogenen Einsatz (Samba)

Die Integration eines Samba Servers in eine NT - Domäne ist unkompliziert. Der Samba Server muss in eine Vertrauensstellung zu der NT - Domäne stehen. In der Praxis richtet man auf dem NT - Domänen - Kontroller einen Account ein. Diese Einrichtung geschieht mit dem üblichen Verwaltungswerkzeug. Samba kann die Funktion des PDC (Primary Domain Controller) in einer NT - Domäne übernehmen. In dieser Eigenschaft verwaltet der Server alle Benutzer - Accounts der Domäne und auch die Browse - Listen mit den IP -Adressen der Windows - und Samba - PCs in verschiedenen Teilnetzen einer Router - gekoppelten Struktur. Hierzu weist er die folgenden Eigenschaften auf:

Sicherheit auf Benutzerebene (er fragt keinen anderen Server nach Authentisierungs - Informationen), - verschlüsseltePasswortübertragung - Domain- Master - Browser (er führt alle Browse - Listen der Teilnetze zusammen) - WINS- Server (er sammelt alle IP - Adressen und NetBIOS - Namen) - dieFähigkeit, Domain - Logon - Anforderungen zu bedienen - einspezielles Verzeichnis für den Domain - Anmeldedienst. - 2.4.2Benutzerprofile und Login Scripte (Samba)

Samba unterstützt zentral gespeicherte und lokal auf den Windows Clients ausgeführte Login Scripte und Benutzerprofile. Benutzerprofile sind eine Reihe von Daten, die Aussehen und Verhalten der Arbeitsumgebung eines Benutzers beschreiben, etwa Gestaltung des Desktops und Inhalt des Startmenüs. In Windows NT und Nachfolgesystemen besitzt jeder Benutzer ein solches Profil, in den Windows - 9x/Me -Systemen kann es durch nachträgliche Konfiguration eingerichtet werden. Im Unterschied zu lokalen Profilen, die auf den einzelnen Arbeitsstationen abgelegt sind, werden Server - gespeicherte Profile (Roaming Profiles) unabhängig von der sich anmeldenden Arbeitsstation zentral gespeichert und verwaltet. Für den Benutzer hat dies den Vorteil, dass er überall seine gewohnte Arbeitsumgebung vorfindet, egal von wo aus er sich anmeldet. Das Hin - und Herkopieren der Profil - Informationen funktioniert automatisch, von dem Benutzer mehr oder weniger unbemerkt. In der Samba - Konfigurationsdatei werden hierzu eine Direktive im »[global]« - Abschnitt sowie eine gesonderte Freigabe »[profile]« benötigt. Listing 3 zeigt die erforderlichen Ergänzungen.

Der Begriff »logon path« ist nicht zu verwechseln mit dem »path« in der Freigabe »[netlogon]«. Das letztere Verzeichnis dient allgemein dem Anmeldevorgang, es gehört »root« und enthält die Logon - Skripte aller Benutzer. Die Unterverzeichnisse von »/home/samba/profiles« hingegen gehören jeweils einem Benutzer, können nur von diesem gelesen und beschrieben werden und dienen zur Speicherung der Profildaten. Achtung: Der root - Account unter Samba entspricht nicht dem root - Account des Linux - Rechners auf dem Samba betrieben wird! Hier gibt es einen gesonderten Samba - root.

2.4.3 Anlegen von Benutzergruppen / Importieren der NT Sicherheitsdatenbank (Samba)

Linux und Windows pflegen einen unterschiedlichen Umgang mit Benutzergruppen. Zur Integration beider Welten dienen der seit Samba 2.2.2 eingeführte »winbindd« - Serverprozess und die damit verbundenen Direktiven in der »smb.conf« (Abschnitt »Winbind options« im »Advanced View« von Swat). Ebenfalls in diese Richtung zielen die Direktiven »domain admin group« und »domain guest group« in der Datei »smb.conf«. Damit man nicht alle vorhandenen NT Benutzer manuell auf dem Samba Server einrichten muss, kommt mit der Samba - Version 3.0 das Tool Net hinzu, das unter anderem mit dem Aufruf »net rpc vampire« die Migration einer kompletten NT - Sicherheitsdatenbank auf einen Samba - PDC bewerkstelligt. Das erste beta - Release der Samba Version 3.0 kam bereits am 7.Juni 2003.

22

2.4.4 root - Rechte ohne root - Account (Linux OS)

Bei größeren Betrieben ist es nicht möglich nur einen einzigen Mitarbeiter als root zu definieren, da eine Vielzahl an Konfigurations - und Installationsvorgängen root - Rechte voraussetzen. Allerdings hat man als root uneingeschränkte Rechte und Möglichkeiten auf dem entsprechenden Rechner. Deutlich mehr als zum Beispiel als Administrator unter Windows. Ein als root angemeldeter Mitarbeiter könnte

- versehentlichden Server fehlkonfigurieren oder noch schlimmer, unbewusst Sicherheitslöcher öffnen.

- unsichereAnwendungen starten: Benutzer mit root - Zugang könnten FTP - oder Telnet Dienste starten, die möglicherweise Benutzerkonten und -passwörter von aussen zugänglich machen.

- Sicheinen Virus einfangen: Eine Bedrohung, die von den zwar seltenen Linux - Viren ausgeht ist nur dann existent, wenn der Virus als root ausgeführt wird. (siehe auch Kapitel Virenschutz) Man muss also einen Mittelweg finden. Mit sogenannten „setuID“ Programmen kann man kurzzeitige root -Privilegien erlangen, ohne sich als root anzumelden. Setuid (Set User ID) ist ein spezielles Attribut einer Datei, das zur Wirkung hat, dass beim Ausführen der Datei, die Userkennung auf den Dateieigentümer geändert wird (meist root). Allerdings gibt es bei Programmen, die diese Funktion nicht unterstützen mögliche Sicherheitsrisiken.

2.4.5 Administratorenverwaltung mit Hilfe des RhEN

Multiple Administrators: Mit RhEN können verschiedene Sicherheitslevel für verschiedene Administratoren eingerichtet, sowie für Administratoren der Zugang zu bestimmten Bereichen beschränkt werden. Mit den Richtlinien im RhEN wird festgelegt, wer auf welches System wann Zugriff und welchen Administrationslevel er dort hat.

23

3 regelmäßige Aufwände

3.1 Virenschutz und -Bedrohung unter Linux

Fast die komplette Linux Community schwört auf die Grundsätzliche Immunität von Linux gegen Viren jeglicher Art. Auch Red Hat verweist auf ein Dokument, welches die Gründe hierfür nennt. Aufgrund des besonderen Aufbaus von Linux (multi - User System) sei es Viren grundsätzlich nicht - möglichsich zu verbreiten oder besonders schwerwiegenden Schaden anzurichten. Da Microsoft die ein beinahe - Monopol an Client PCs geniest hat ein Windows - basiertes Virus viel - größereErfolgschancen und Verbreitungsmöglichkeiten.

3.1.1 Warum soll Linux unverwundbar sein?

Schauen wir uns erst die Arbeitsweise und die Funktionen eines Viruses näher an. Ein Virus muss ich der Lage sein, sich 1. selbst auszuführen 2. selbst zu replizieren (zu vermehren)

3. einen „payload“ zu besitzen, der den eigentlichen Schaden anrichten soll

Linux ist ein Multiuser System, bei dem jeder einzelne Ordner und jede einzelne Datei eigene Berechtigungen besitzt. Wenn zum Beispiel ein beliebiger Benutzer einen Virus einfängt und dieser Versucht Systemdateien oder wichtige Programme des Systems anzugreifen oder zu ändern um sich selbst zu replizieren, so hat er hierfür dieselben Rechte, wie der Benutzer selbst. Will zum Beispiel der Benutzer die Datei „/bin/ls“ ändern, so erhält er die Meldung „Permission Denied.“ Diese Benutzerrechte sind unumgänglich!

Folglich kann sich der Schaden, den ein solches Virus anrichtet, nur auf die Dateien beschränken, für welche dieser Benutzer als Besitzer eingetragen ist. Dies wirft aber zwangsläufig die Frage auf: Was passiert, wenn root (der Super - User, der auf sämtliche Dateien alle Berechtigungen besitzt) einen solchen Virus ausführt? Natürlich könnte ein als root ausgeführter Virus erheblichen Schaden anrichten, weswegen man hier die Verantwortung an den Administrator übergibt, welcher dazu aufgefordert wird, nur 100% saubere Programme zu verwenden.

Red Hat selbst bietet daher keine speziellen Anti - Virus Pakete an, da die oben genannten Argumente und die bisherige Erfahrung gegen einen besonderen Focus auf dieses Gebiet sprechen. „... doesn’t even know anyone, that has ever been infacted with a linux virus.“

Es gibt sogar einen Windows - Virus (Namens W32.Prolin.Worm), der u.A. fogende Auswirkungen hat: [...]

x Der Wurm verschiebt dann alle .mp3 - , .jpg - und .zip - Dateien in das Hauptverzeichnis. Er benennt jede dieser Dateien um und ergänzt die Erweiterung jeder Datei um den Text: change atleast now to LINUX

x Der Wurm kopiert die Datei Messageforu.txt in das Hauptverzeichnis des Laufwerks C. Die Datei enthält diesen Text:

Hi, guess you have got the message. I have kept a list of files that I have infected under this. If you are smart enough just reverse back the process. i could have done far better damage, i could have even completely wiped your harddisk. Remember this is a warning & get it sound and clear... - The Penguin

24

3.1.2 Virenscanner unter Linux

Es gibt dennoch einige Produkte der Opensource Gemeinde und namhafter Firmen, die Virenschutz für Linux gewährleisten sollen:

H+B EDV AntiVir/Linux 5.15.0.0 (30.09.1998) / 5.16.01 - NetworkAssociates VirusScan 4.0.2 beta 2 - SophosSweep für Linux 3.18 - TrendFile Scanner 1.0 / - TrendInterScan VirusWall 3.01 - CyberSoftVFind Security ToolKit (Professional) 147 - KasperskyLabAntiViral Toolkit Pro (AVP) 3.0 - DataFellowsF - Secure AntiVirus - DieseTools bieten ähnliche Funktionen wie ihre Windows Pendants. Allerdings erweist sich die Installation bei einigen als sehr schwer.

Das von der Company eingesetzte Tool „Norton AV Corporate Edition“ gibt es nur für Windows und wird für Windows - fremde Betriebssysteme nicht angeboten. Will man Symantec trotzdem treu bleiben empfiehlt sich die Verwendung des „Symantec AV Command Line Scanner“ für Linux, welcher mit der gleichen Engine arbeitet und die gleichen Updates erhält wie Norton AV CE.

3.1.3 Virenscanner im heterogenen Einsatz

Es ist möglich, von Linux aus Windows Partitionen auf der lokalen Maschine oder im Netzwerk auf Viren zu überprüfen. Denkbar wäre der Einsatz eines reinen Linux - basierten Virenscanners für die Windows Umgebung, der selbst unverwundbar ist. Als weitere Einsatzmöglichkeit könnte ein Linux - basierter Virenscanner auch Windows - Shares auf einem Samba Server überwachen

3.1.4 Virenscanner für Email Server

Es gibt die Möglichkeit, Virenscanner für Microsoft Clients auf Linux - Basis laufen zu lassen, welche bereits Windows - Viren Serverseitig filtern sollen. Hauptaugenmerk liegt hierbei auf der Überwachung von Linuxbasierten Mailservern für beispielsweise Lotus Notes/Domino, Microsoft Exchange oder simplen Sendmail/pop3. (Auszug von Symantec.com):

„Norton AntiVirus 2.5 für Lotus Notes/Domino bietet jetzt umfassenden Schutz unter allen Plattformen Ratingen, 23. Juli 2002 - Symantec, weltweit führender Anbieter von Produkten für die Internetsicherheit, stellt mit Norton AntiVirus 2.5 für Lotus Notes/Domino für Linux die erste Virenschutzlösung für Lotus Notes/Domino für Linux vor. Norton AntiVirus 2.5 für Lotus Notes/Domino bietet damit jetzt umfassenden automatischen Virenschutz für sämtliche Lotus Notes/Domino Plattformen wie Solaris, AIX, OS/400, OS/390 und jetzt auch Linux.

25

3.2 Updates / Patches - Red Hat Enterprise Network

3.2.1 Funktion des RhEN:

Red Hat bietet Bugfixes und Errata - Patches direkt über das RhEN - Red Hat Enterprise Network. Dabei handelt es sich um eine Netzwerklösung, die Systemadministratoren einen direkten Weg bietet ihre Installationen mit Updates und Patches zu versorgen. Um aus der Vielzahl an angebotenen Patches die für das vorhandene System relevanten zu filtern kann der Systemadministrator ein Profil seines Servers anlegen. Empfohlen ist zum Beispiel der Bezug von nur sicherheitsrelevanten Betriebssystem - Patches, die erfahrungsgemäß alle drei Monate erscheinen.

3.2.2 Zusatzfunktionen

Besonders interessant machen das RhEN die Zusatzfunktionen, die fast alle über eine Web - basierte Oberfäche erreicht werden können. So gibt es

Softwareverteilungs - Funktionen (mehr dazu unter Kapitel 3.3) - Monitoring- Funktionen von Hardware und Traffic (mehr dazu unter Kapitel 3.4) - Benutzer- / Administratorenverwaltung (mehr dazu unter Kapitel 2.4.5) - 3.2.3Im Lieferumfang befinden sich folgende Produkte:

x Der Red Hat Update Agent

Der Update Agent ist ein für ein x - Window System (grafische Oberfläche von Linux) entwickeltes Tool, welches den Zugriff auf des RhEN ermöglicht. Mit dem Update Agent können Rechner - Profile erstellt und registriert werden und Software Updates vom RhEN bezogen werden. Die Funktionen des Update Agent kann man auch per Commandozeile nutzen. x Die Red Hat Network Website

Die RhEN Website bildet das Web - basierte Frontend des RhEN. Sie übernimmt primär die Funktionen des Update Agent. Hier werden nicht nur alle Systeme mit ihrem aktuellen Stand und Status gelistet sondern auch einige Tools zur Softwareverwaltung und -Beschaffung geboten. Des weiteren gibt es einen Terminplan welcher nötige Updates oder laufende Vorgänge hervorhebt.

Abgerundet wird der Funktionsumfang von der User - Verwaltung, die einen Überblick über alle Benutzer und Administratoren verschafft und deren Zugriffs - und Administrationsrechte für die im System integrierten Maschinen definiert. So können Beispielsweise Administrationshierarchien erstellt werden um x Der Red Hat Network Dämon

Dieser Dienst setzt sich in regelmäßigen Zeitabständen (default sind 120 Minuten) mit den Master Servern von Red Hat in Verbindung und sucht nach verfügbaren Updates. Den Red Hat Dämon kann man per Kommando Zeile oder mit dem Update Agent konfigurieren. x Der Red Hat Network Registration Client Kleines Tool zur Registrierung der Benutzer und der Server.

26

3.3 Softwareverteilung - RhEN Software Delivery Module

Als einzige Konkurrenz zu den Produkten unter dem Label „IBM Tivoli“ bietet Red Hat eine integrierte Softwareverteilungs - Lösung an. Da bei Red Hat Software Updates sowie komplette Programme gebündelt in RPM Paketen vorliegen ist es nicht besonders aufwendig, die Softwareverteilung - Techniken der Patches auf andere Programme auszuweiten. Das RhEN und somit auch das „Software Delivery Module“ kann in drei verschiedenen Architekturen betrieben werden, die hier beschrieben werden. Doch zuvor einige Grundlagen zu den PRM - Paketen:

3.3.1 RPM Packages

Da die verschiedenen Linux Distributionen zueinander nicht voll kompatibel sind war es bisher notwendig, neue Software vor der Installation entsprechend für das vorhandene Linux System zu kompilieren. Hierfür gab es passende „Make - Files“ die in einer Stapelverarbeitung den Quellcode entsprechend abarbeiteten. Da diese Vorgehensweise zwar performantere Ergebnisse jedoch einen sehr hohen Qualifizierungsgrad des Benutzers voraussetzt wurde von Red Hat der RPM - Standart entwickelt. Es handelt sich hierbei um binäre Software Pakete, die nach dem Download direkt installiert werden können. Andere große Distributionen wie Mandrake und SuSE haben diesen Standart übernommen.

In der Praxis erweist es sich als sehr schwierig in der riessigen OpenSource Gemeinde RPM Pakete zu finden, die für eigene Zwecke und Sicherheitsbedüftnisse relevant sind. Diese Aufgabe übernimmt Red Hat und bietet neue, von Red Hat verifizierte Pakete über das RHEN direkt zum Download an. Es gibt drei Möglichkeiten, diesen Dienst zu nutzen:

- Über den Red Hat Update Agent

- Per Command Line

- Über die Red Hat Network Website

3.3.2 RhEN Hostet Model (Enterprise Entitlement)

(enthalten in jedem RhEL Abonnement)

Hier wird lediglich ein Zugang zu den Corporate Servern von Red Hat angeboten, die die Funktionen und Dienste des RhEN bieten. Jeder einzelne Rechner verbindet sich via Internet mit den zentralen RhEN Servern um Informationen und Softwarepakete auszutauschen Funktionen:

- System Grouping: Es ist möglich mehrere identische Systeme in Gruppe zusammenzufassen und dieser kompletten Gruppe ein Software - Update zuzuweisen anstatt jeder einzelnen Maschine.

- Update Sheduling: Oft haben Unternehmen Stosszeiten, in welchen die Server unter „Peak - Load“ stehen. Mit „Update Sheduling“ wird die Startzeit der Installation festgelegt und somit Zeiten gewählt, in denen ausserhalb der Stosszeiten Patches und Updates installiert.

- Package Profile Comparison: Es ist möglich die installierten Pakete zweier System leicht miteinander zu vergleichen.

3.3.3 RhEN Mixed Mode (Proxy Server)

Das RhEN wird als Intranet zur Verfügung gestellt. Der Administrator verbindet sich nur mit den Server von Red Hat um bestimmte Informationen oder kleine Patches herunterzuladen. Andere Dienste und Funktionen werden von direkt von den Applikation - Servern geliefert, die intern hinter einer Firewall gehostet werden. Funktionen von Enterprise Entitlement, jedoch zusätzlich:

27

- Bandwidth Reduction: Der Proxy - Server bietet die Möglichkeit die herutergeladene RPM Updates zwischenzuspeichern um sie auf die Client - Server zu verteilen zu können.

- Custom Content & Channel Management: Es ist möglich verschiedene Kanäle für eigene Errata oder Errata Dritter zu erstellen, die sich nahtlos in die bestehende Red Hat Enterprise Network Plattform einfügen lassen. Technische Voraussetzungen (Proxy Server):

- RhEL AS 2.1

- Hdd: 3 GB per Freigabe

- Speicher 512 MB

3.3.4 RhEN: On - Site Model (Satellite Entitlement)

Der Betrieb des kompletten RhEN als Intranet - Lösung wird derzeit noch von Red Hat entwickelt. Funktionen wie Proxy Entitlement, jedoch zusätzlich:

- Off Network Updates: Mit dem „Satellite Server“ kann das gesamte RhEN als Intranet und somit hinter einer Firewall oder komplett offline betrieben werden.

- Custom Errata Management: Es ist möglich eigene Errata - Nachrichten, Mitteilungs - Richtlinien und Updatepakete für großskalierte Prozesse zu generieren. Technische Voraussetzungen (Satellite Server - empfohlen):

- RhEL AS 2.1

- Hdd: 3 GB für Basisinstallation, 3 GD Freigabe

- Speicher: 1 GB

- Oracle: >4 GB Tablespace

3.3.5 Notification

Ist ein neues Paket verfügbar, so bekommt der Administrator eine Nachricht wahlweise auf seinen Desktop oder als Email. Er kann dann online in einer Liste alle Pakete einsehen und nach Notwendigkeit auswählen. Dabei werden nur die Pakete angeboten, die für das Angegebene System relevant sind. Hierfür muss ein Profil des vorhandenen Systems angelegt werden. Die neuen Pakete kann man wahlweise lokal oder im Netzwerk ablegen, auf einem Proxy zur Verfügung stellen oder direkt automatisch installieren.

3.3.6 Dependency Check

RPM Pakete sind keine autonomen Programme sondern Objekte, die in einem Netzwerk von Abhängigkeiten stehen. RPM Pakete bilden oftmals die Grundlage für andere Programmteile die wiederum zusätzliche Bibliotheken verlangen, die wieder in anderen RPM Paketen abgelegt wurden. In diesem Wirrwarr von Abhängigkeiten ist es sogar für Benutzer, die mit dem Pinguin perDu sind extrem zeitaufwendig immer die passenden Pakete zusammnzufinden. Nicht zuletzt deswegen ist diese Methode in Teilen der Linux Gemeinde (v.a. Debian - Fraktion) nicht gerade populär.

Um dieses Problem zu umgehen unterstützt das Red Hat Network den sog. „dependency check“, welcher jedes RPM Paket auf über eine Million Abhängigkeiten überprüft. Die benötigten abhängigen Updates werden dann automatisch mitinstalliert.

3.3.7 Installation

Die Installation der Pakete ist unproblematisch. Nach der Verteilung der Software auf die entsprechenden Geräte (mehr dazu Kapitel „Software Delivery Module“) werden die Updates Scriptgesteuert installiert und die betroffenen Dienste ggf. neu gestartet. Ein Neustart des Betriebssystems ist fast nie notwendig.

28

3.4 Monitoring - RhEN

Das RhEN Monitoring Module ist eine Methode um die eigene heterogene Infrastruktur zu überwachen. Das Modul vereint integriertes Netzwerk, System, Applikations und Tansaktionsmonitoring mit Report und Notifikationsfunktion. Basierend auf einem Web - interface teilt sich das Monitoring Module in zwei Komponenten auf: Infrastruktur - Monitoring und end - user Monitoring.

3.3.1 Infrastructure Monitoring

Eine Komplettübersicht der Infrastruktursoperationen werden von einem Red Hat Local Scout TM monitored, der vor Ort beim Kunden installiert wird.

- Unterstützte Betriebsysteme: Linux, Solaris, Windows, IRIX, FreeBSD und HPUX

- Darstellung der Hardware - Auslastung der inneren Infrastruktur, beispielsweise Festplatten - , CPU - und Portbenutzung

- Unterstützte Anwendungen: BEA Weblogic, ATG Dynamo, iPlanet, Macromedia Cold Fusion, Oracle, mySQL, LogAgent, RealServer, Microsoft Commerce Server, Microsoft Exchange, Microsoft IIS, Microsoft SQL Server, Windows Media Unicast Service und weitere

- Netzwerk - Geräte: Verkäufer wie Cisco, Alteon, F5, Foundry und weitere

3.3.2 End User Experience Monitoring

Ansicht der Anwendungen aus der Perspektive des Verbrauchers. Red Hat Remote Scouts TM, welche im Backbone des Internet plaziert werden überwachen die Web - Schnittstellen. Das End - User Monitoring beinhaltet:

- URL Monitoring: Überwacht Antwortzeiten, DNS - lookup, Verbindungszeiten und Durchsatzzeiten des öffentlichen Backbone.

- Transaction Monitoring: Überwacht die Performance von jedem einzelnen Schritt einer web - basierten Transaktion wie beispielsweise ein online - Bestellvorgang.

Diese Art von Monitoring ist für Web - Hoster interessant, jedoch für einen internen Application - Server nicht brauchbar.

29

3.3.3 Monitoring Module Beispiele x System Monitoring

Überwacht alle Hosts und Services

x Application Monitoring

Unterstützt alle gängigen Web-Applikationen (Apache, Oracle, SQL Server)

x Netzwerk Monitoring

Unterstützt gängige Netzwerkschnittstelllen. Gibt Info über spezielle Nodes oder das gesamte Netz

x Transaction Monitoring

Monitoring von web Applikationen

Ausserdem:

Historical and Time Series Reporting Inventory Management Automated Notification and Escalation Quelle: www.redhat.com

33

3.5 Backup / Restore (IBM Tivoli)

IBM bietet mit Tivoli Storage Management eine Lösung an, mit der man Daten sichern kann. Auch Linux wird als Client von IBM TSM unterstützt.

3.5.1 Unterstützung für die Sicherung eines logischen Datenträgers als Einzelobjekt (Imagesicherung) auf einem Linux86 - Client

Der Linux86 - Client unterstützt die Imagesicherung eines logischen Datenträgers von Dateisystemen und unformatierten Datenträgern. Der Tivoli Storage Manager - Server verfolgt keine einzelnen Dateien im Dateisystemimage. Dateisystemimages werden als individuelle Objekte verfolgt, und die Verwaltungsklassenmaßnahme wird auf das Dateisystemimage als Ganzes angewandt. Weitere Informationen finden Sie in „Eine Imagesicherung ausführen” auf Seite 76. Unterstützung für die Onlineimagesicherung von Dateisystemen und unformatierten logischen Datenträgern auf einem Linux86 - Client Die traditionelle Offlineimagesicherung verhindert während der Operation den Zugriff auf den Datenträger durch andere Systemanwendungen. Nur für Linux86: Tivoli Storage Manager kann eine Onlineimagesicherung der Dateisysteme, die sich auf einem vom Logical Volume Manager von Linux erstellten logischen Datenträger befinden, ausführen, während der Datenträger für andere Systemanwendungen verfügbar ist. Weitere Informationen finden Sie in „Eine Imagesicherung ausführen” auf Seite 76.

3.5.2 Clientumgebung bei Linux für X86

Softwarevoraussetzungen.

Der Client für Sichern/Archivieren erfordert das Ausführen folgender Software: x Linux kernel 2.4.0 oder höher x glibc 2.2 x libstdc++2.9.0 oder höher x X Window System X11R6 (nur für Endbenutzer - GUI x RPM 3.0.0 oder höher, 4.0

Der Red Hat Enterprise Server 2.1 erfüllt diese Anforderungen. Zusatz:

Nur für Linux86 : Der Tivoli Storage Manager kann eine Onlineimagesicherung von Dateisystemen auf einem logischen Datenträger, der vom Linux Logical Volume Manager erstellt wurde, ausführen, während der Datenträger anderen Systemanwendungen zur Verfügung steht.

3.5.3 Linux86 - Client installieren (Quelle: IBM.com)

Aktuelle Informationen zu

Tivoli Storage Manager, zu unterstützten Plattformen und zur Dokumentation können über die folgende Website abgerufen werden: http://www.tivoli.com/support/storage_mgr/tivolimain.html Die folgenden Installationsoptionen sind in nicht komprimierten Paketen auf der CD verfügbar: tsmcli/linux86/TIVsm - BA

Installiert den Client für Sichern/Archivieren (Befehlszeile und GUI), den Client mit Verwaltungsfunktionen (Befehlszeile) und den Webclient. tsmcli/linux86/TIVsm - API Installiert die API.

Wenn ein früherer Linux - Client installiert ist, der nicht unterstützt wird, muss dieser deinstalliert werden. Zum Löschen von früher installierten Tivoli Storage Manager - Clientpaketen müssen Sie sich als Root anmelden und folgendes eingeben: Rpm -e TIVsm-BA

34

und für die API: rpm -e TIVsm-API

Anmerkung: Für die Deinstallation wird die Versionsnummer des Pakets nicht benötigt. Führen Sie folgende Prozedur aus, um die Tivoli Storage Manager - Clients zu installieren:

1. Melden Sie sich als Root an und hängen Sie die CD - ROM bei /cdrom an.

2. Geben Sie den folgenden Verzeichnispfad an, da sich die Installationspakete auf der CD in diesem Pfad befinden: /cdrom/tsmcli/linux86

3. Geben Sie den folgenden Befehl ein, um die englischen Versionen des Client für Sichern/Archivieren (Befehlszeile und GUI), des Client mit Verwaltungsfunktionen (Befehlszeile) und des Webclient zu installieren: rpm - i TIVsm - BA.i386.rpm

Soll zusätzliche Sprachenunterstützung installiert werden, folgenden Befehl eingeben: rpm - i TIVsm -BA.msg.lang.i386.rpm Ersetzen Sie dabei lang durch den geeigneten Sprachencode aus Tabelle 5 auf Seite 20. Anmerkung: Verwenden Sie die Option - - nodeps, um die Prüfung von Abhängigkeiten zu umgehen. Sie müssen die Abhängigkeiten manuell überprüfen.

4. Geben Sie den folgenden Befehl ein, um die englische Version der API zu installieren: rpm - i TIVsm - API.i386.rpm

Soll zusätzliche Sprachenunterstützung installiert werden, folgenden Befehl eingeben: rpm - i TIVsm -API.msg.lang.i386.rpm

Ersetzen Sie dabei lang durch den geeigneten Sprachencode aus Tabelle 5 auf Seite 20. Anmerkung: Verwenden Sie die Option - - nodeps, um die Prüfung von Abhängigkeiten zu umgehen. Sie müssen die Abhängigkeiten manuell überprüfen.

3.5.4 weitere IBM Tivoli Produkte

Unterstützung von IBM Tivoli Systems Management Produkten:

- Tivoli Business Systems Manager - kein Linux Support

- Tivoli Gateway Configuration Manager - Red Hat 7.1 (ix86) Red Hat 7.2 (ix86) SuSE 7.2 (ix86)

- Tivoli License Manager - kein Linux Support

- Tivoli Monitoring - Linux Support (keine spez. Distribution angegeben)

- Tivoli Service Level Advisor - Linux Support (keine spez. Distribution angegeben) Unterstützung von IBM Tivoli Storage Management Produkten:

- Tivoli Storage Manager Extendet Version (v5.2 Client) - Linux x86 2.4 kernel (Red Hat 7.2, 7.3, 8, und Advanced Server 2.1; SuSE 7.3, 8.0, 8.1, und SLES 7 und 8; TurboLinux 7.5, und 8.0)

- Tivoli Storage Resource Manager - Red Hat Linux 6.2, 7.1, 7.2

- Tivoli SAN Manager - Linux Support (keine spez. Distribution angegeben) Unterstützung von IBM Tivoli Security Produkten:

- Tivoli Access Manager for Business Integration - kein Linux Support

- Tivoli Access Manager for e-Business - SLES 7 for S/390 and zSeries Red Hat Linux 7.1, 7.2

- Tivoli Identity Manager - kein Linux Support

35

3.6 Remote Administration

3.6.1 Fernadministration per Konsole (Telnet / ssh)

Anders als bei Windows kann man bei Linux - wie bei jedem anderen Unix - ähnlichen Betriebssystem - sämtlicheEinstellungen, Systembefehle, Systemressourcen und Infos über eine Konsole verwalten. Remote oder Lokal. Da bei Linux jedes Programm und jeder Treiber per Konfig - Datei editiert werden kann, existiert der konsolenbasierte Texteditor „vi“ auf jedem Unix - System. Somit ist eine text - basierte Shell ausreichend für die Administration einer Linux - Maschine.

Der Remote - Zugriff von einer Windows - Maschine über Telnet ist denkbar einfach:

- Klicken auf Start -> Ausführen

- Eingabe: „telnet

- Login

Da jedoch bei Telnet sämtliche Daten und somit auch Passwörter unverschlüsselt übermittelt werden, ist es hier ratsam eine verschlüsselte Verbindung via „Secure Shell“ (SSH) herzustellen. Für den Windows - Client kann das kostenlose Tool „Putty“ verwendet werden. Der Linux - Server ist bereits in der basis - Konfiguration mit einem shh - Server ausgestattet.

Die Administration per Konsole setzt allerdings sehr gute Kenntnisse über die Linux im allgemeinen und den vorhandenen Rechner voraus. Dokumentationen finden sich beispielsweise unter www.linuxdoc.org

3.6.1 Administrationsoberfläche Webmin

Webmin ist ein web - basiertes Interface für die Administration von Unix - Systemen. Webmin ist modular aufgebaut und besteht im Grunde nur aus einer handvoll CGI - Scripten und einem kleinen Web - Server. Programmiert wurde das System mit Perl Version 5. Die Lizenz - Bestimmungen und der modulare Aufbau Webmins lassen für Firmen die Möglichkeit offen eigene, maßgeschneiderte Module zu erstellen. Webmin unterstützt fast alle Releases von Red Hat, darunter auch den Enterprise Server 2.1 ES Unter http://www.webmin.com/standard.html findet man eine Liste mit den Modulen, die „by default“ bei Webmin enthalten sind. Einige Relevante vorweg:

- Volle Apache Konfigurationsmöglichkeiten

- DHCP konfigurieren

- File Manager (Windows - ähnlicher File - Browser)

- NIS Konfiguration (Client/Server)

- PAM Authentication

- SSH Server / Tunnel - Konfiguration

- Benutzer und Gruppen (lokale)

36

4 Konfigurationsvorschlag

4.1 Schichtenmodell der Konfiguration

Linux Server für die Umgebung bei der Company - COMPANY als Active Directory und TSM - Client mit Shared Verzeichnissen für Windows Clients (NT, 2000, XP).

5 Quellenangaben

Computerwoche Nr. 12 - 5.2003

Linux Magazin 5.2003 Linux Magazin 2.2003 Linux Magazin 5.2001 Linux User 5. 2003 IBM.com Redbook Tivoli Monitoring 5.1 IBM.com Redbook Tivoli Web Health Console IBM.com Tivoli TSM for Unix Handbook IBM.com Linux Facts Sheet Red Hat.de Enterprise Network Whitepapers Red Hat.de Enterprise Linux Whitepapers Red Hat.de Migration Whitepapers SuSE.de Enterprise Linux Whitepapers SuSE.de Smartclient Whitepapers SuSE Sonderdruck Linux Enterprise Debain.org Dokumentation Mandrake.com Dokumentation David Lechnyr - The unofficial Samba HOWTO Samba.org Dokumentation SCO.com Dokumentation

Diverse Studien:

Join a Linux server to Active Directory with Samba 3.0 by Scott Lowe - Testresults of Kerberos interoperability with Windows 2000 Active Directory by Tim Fredrick, National Center - forAtmospheric Research

Creating an MIT Kerberos server that can authenticate Active Directory clients by Tim Fredrick, National - Centerfor Atmospheric Research

interoperability Win2k/Linux, june 2002, kerberos mailing list - Linux-Serveram MPI für Festkörperforschung - Clientstudieder Landeshauptstadt München - DETEcon - Linuxoder Windows Print - DETEcon - Linuxund Microsoft im Unternehmen - Cnet.ASIA- Join a Linux server to Active Directory with Samba -

38