Interop

Authentifizieren von Linux-Clients bei Active Directory

Gil Kirkpatrick

 

Auf einen Blick:

• Funktionsweise der Authentifizierung in Windows und Linux
• Verwenden von Samba und Winbind
• Implementierungsstrategien
• Erläuterung der Integration von Linux und Active Directory

Inhalt

Windows-Authentifizierung
Linux-Authentifizierung
Samba und Winbind
Drei Authentifizierungsstrategien
Unser Implementierungsplan
Finden der richtigen Software
Erstellen von Samba
Konfigurieren des Linux-Netzwerks
Konfigurieren der Linux-Zeitsynchronisierung
Konfigurieren von PAM und NSS
Installieren und Konfigurieren von Samba
Das Problem der ID-Zuordnung
Beitritt zur Domäne und Anmeldung
Was tun bei Problemen?
Es funktioniert – mit welchem Ergebnis?
Drittanbieterlösungen

Republikaner und Demokraten. Zahnpasta und Orangensaft. Linux und Windows. Einige Dinge gehen einfach nicht zusammen, stimmt’s? Jeder IT-Laden, mit dem ich je zu tun hatte, war in zwei Lager gespalten: das Windows-Team und das Linux-Team. Die Teams konkurrieren zwar nicht ernsthaft miteinander, von Zusammenarbeit kann aber auch keine Rede sein. Einige gehen sogar so weit, eine gelbe Linie auf dem Boden zu ziehen, um unangebrachte Verbrüderungen zwischen den beiden Gruppen zu verhindern.

Ich gehöre zum Windows-Lager, aber obgleich ich mich ab und zu über meine Linux zugeneigten Kollegen lustig mache, ist eines klar: Wir verfolgen ein und dasselbe Ziel, nämlich die Bereitstellung qualitativ hochwertiger und kostengünstiger IT-Dienste für Organisationen. Eine Möglichkeit, dies zu erreichen, besteht in der gemeinsamen Nutzung zentraler Softwareinfrastruktur wie Active Directory. Beinahe alle IT-Organisationen verwenden heute Active Directory für die Bereitstellung von Authentifizierungsdiensten für Windows-Desktops und Server. Für die Linux-Umgebung existiert eine separate Authentifizierungsinfrastruktur (einschließlich separater Benutzernamen und Kennwörter). Wäre es nicht besser, wenn die Linux-Computer ebenfalls Active Directory verwenden würden? Ich denke ja. Im folgenden Artikel wird erläutert, wie dies erreicht werden kann.

Windows-Authentifizierung

Windows wird seit geraumer Zeit mit integrierter Netzwerkauthentifizierung und einem System für einmaliges Anmelden ausgeliefert. Vor Windows 2000 stellten Windows NT-Domänencontroller (DCs) Authentifizierungsdienste für Windows-Clients mithilfe des NTLM-Protokolls (NT LAN Manager) bereit. Obwohl NTLM nicht so viel Sicherheit bot wie ursprünglich angenommen, war es sehr nützlich, weil damit die Notwendigkeit entfiel, doppelte Benutzerkonten auf mehreren Servern im Netzwerk zu unterhalten.

Ab Windows 2000 stellte Microsoft von NTLM auf Active Directory und seine integrierten Kerberos-Authentifizierungsdienste um. Kerberos bot nicht nur wesentlich mehr Sicherheit als NTLM, sondern auch bessere Skalierung. Außerdem war Kerberos ein Branchenstandard, der bereits von Linux- und UNIX-Systemen verwendet wurde, wodurch es möglich wurde, diese Plattformen in Windows zu integrieren.

Linux-Authentifizierung

Bei der Entwicklung von Linux (und den darauf ausgeführten GNU-Tools und Bibliotheken) stand die Frage eines einzigen Authentifizierungsmechanismus nicht im Vordergrund. Infolgedessen gewöhnten sich Linux-Anwendungsentwickler an, ihr eigenes Authentifizierungsschema zu erstellen. Hierzu haben sie entweder Namen und Kennworthashes aus „/etc/passwd“ (der traditionellen Textdatei mit Anmeldeinformationen der Linux-Benutzer) abgerufen oder eine vollkommen andere (und separate) Methode verwendet.

Die resultierende Vielzahl von Authentifizierungsmechanismen war nicht zu beherrschen. Im Jahre 1995 schlug Sun eine Methode namens PAM (Pluggable Authentication Modules) vor. PAM stellte einen allgemeinen Satz von Authentifizierungs-APIs bereit, den alle Anwendungsentwickler verwenden konnten, zusammen mit einem vom Administrator konfigurierten Back-End, das mehrere austauschbare Authentifizierungsschemas ermöglichte. Mithilfe der PAM-APIs für die Authentifizierung und der NSS-APIs (Name Server Switch) zum Abrufen der Benutzerinformationen war es Linux-Anwendungsentwicklern möglich, weniger Code zu schreiben. Linux-Administratoren stand ein einziger Ort für die Konfiguration und Verwaltung des Authentifizierungsprozesses zur Verfügung.

Die meisten Linux-Distributionen werden mit mehreren PAM-Authentifizierungsmodulen ausgeliefert, einschließlich Modulen, die die Authentifizierung bei einem LDAP-Verzeichnis und die Authentifizierung mithilfe von Kerberos unterstützen. Sie können diese Module für die Authentifizierung bei Active Directory verwenden, müssen aber einige wichtige Einschränkungen beachten, die an späterer Stelle in diesem Artikel besprochen werden.

Samba und Winbind

Samba ist ein Open-Source-Projekt, das auf die Integration zwischen Windows- und Linux-Umgebungen abzielt. Samba enthält Komponenten, die Linux-Computern Zugriff auf Datei- und Druckdienste von Windows gewähren sowie Linux-basierte Dienste bereitstellen, die Windows NT 4.0-DCs emulieren. Mithilfe der Samba-Clientkomponenten können Linux-Computer Windows-Authentifizierungsdienste nutzen, die von Windows NT- und Active Directory-DCs zur Verfügung gestellt werden.

Der Teil von Samba, der für dieses Projekt am interessantesten ist, heißt Winbind. Winbind ist ein Daemon (in der Sprache von Windows ein Dienst), der auf Samba-Clients ausgeführt wird und als Proxy für die Kommunikation zwischen PAM und NSS (auf dem Linux-Computer ausgeführt) und Active Directory (auf einem DC ausgeführt) fungiert. Winbind verwendet Kerberos zur Authentifizierung bei Active Directory und LDAP, um Benutzer- und Gruppeninformationen abzurufen. Winbind bietet darüber hinaus zusätzliche Dienste, z. B. die Möglichkeit der Lokalisierung von DCs mithilfe eines Algorithmus ähnlich DCLOCATOR in Active Directory sowie die Möglichkeit, Active Directory-Kennwörter durch Kommunizieren mit einem DC mithilfe von RPC zurückzusetzen.

Mit Winbind werden einige Probleme gelöst, die sich durch Verwendung von Kerberos mit PAM nicht lösen lassen. Statt beispielsweise einen DC hartzucodieren, um die Authentifizierung wie durch das PAM-Kerberos-Modul durchzuführen, wählt Winbind einen DC aus, indem es DNS-Locator-Datensätze durchsucht, ähnlich wie das DC LOCATOR-Modul in Microsoft.

Drei Authentifizierungsstrategien

Bei Verfügbarkeit von LDAP, Kerberos und Winbind auf Linux-Computern gibt es drei verschiedene Implementierungsstrategien, die eingesetzt werden können, um dem Linux-Computer die Verwendung von Active Directory für die Authentifizierung zu ermöglichen.

Verwenden der LDAP-Authentifizierung Die einfachste, aber am wenigsten zufriedenstellende Möglichkeit, Active Directory für die Authentifizierung zu verwenden, besteht darin, PAM für die Verwendung der LDAP-Authentifizierung zu konfigurieren (siehe Abbildung 1). Obwohl Active Directory ein LDAPv3-Dienst ist, verwenden Windows-Clients Kerberos (und als Ausweichmöglichkeit NTLM) und nicht LDAP zu Authentifizierungszwecken.

Bei der LDAP-Authentifizierung (genannt LDAP-Bindung) werden der Benutzername und das Kennwort in Klartext über das Netzwerk übermittelt. Diese unsichere Methode ist für die meisten Zwecke inakzeptabel.

Abbildung 1 Authentifizierung bei Active Directory mit LDAP (zum Vergrößern auf das Bild klicken)

Die einzige Möglichkeit, das Risiko der Übergabe von Anmeldeinformationen in Klartext zu verringern, besteht darin, den Kommunikationskanal zwischen Client und Active Directory zu verschlüsseln, z. B. mittels SSL. Dies ist zwar möglich, bedeutet aber zusätzlichen Aufwand: Die SSL-Zertifikate müssen auf dem DC und auf dem Linux-Computer verwaltet werden. Außerdem ist es bei Verwendung des PAM-LDAP-Moduls nicht möglich, zurückgesetzte oder abgelaufene Kennwörter zu ändern.

Verwenden von LDAP und Kerberos Eine weitere Strategie der Nutzung von Active Directory für die Linux-Authentifizierung besteht darin, PAM für die Verwendung der Kerberos-Authentifizierung und NSS für die Verwendung von LDAP zu konfigurieren, um Benutzer- und Gruppeninformationen abzurufen (siehe Abbildung 2). Dieses Schema hat den Vorteil vergleichsweise höherer Sicherheit und nutzt die standardmäßigen Funktionen von Linux. Es macht aber keinen Gebrauch von den Datensätzen der DNS-Dienstidentifizierung (SRV), die von Active Directory-DCs veröffentlicht werden. Daher sind Sie gezwungen, einen bestimmten Satz von DCs auszuwählen, bei denen Sie sich authentifizieren. Außerdem fehlt eine wahrhaft intuitive Methode zur Verwaltung ablaufender Active Directory-Kennwörter oder (bis vor kurzem) zur Suche nach Gruppenmitgliedschaften.

Abbildung 2 Authentifizierung bei Active Directory mit LDAP und Kerberos (zum Vergrößern auf das Bild klicken)

Verwenden von Winbind Die dritte Möglichkeit, Active Directory für die Linux-Authentifizierung zu verwenden, besteht darin, PAM und NSS so zu konfigurieren, dass sie den Winbind-Daemon aufrufen. Winbind übersetzt die verschiedenen PAM- und NSS-Anforderungen in die entsprechenden Active Directory-Aufrufe und verwendet hierzu entweder LDAP, Kerberos oder RPC (je nach Eignung). Abbildung 3 zeigt diese Strategie.

Abbildung 3 Authentifizierung bei Active Directory mit Winbind (zum Vergrößern auf das Bild klicken)

Unser Implementierungsplan

Wegen der verbesserten Integration in Active Directory habe ich mich entschieden, Winbind auf Red Hat Enterprise Linux 5 (RHEL5) für mein Projekt der Integration von Linux in Active Directory zu verwenden. RHEL5, die aktuelle Version der kommerziellen Red Hat Linux-Distribution, ist in Unternehmensdatencentern recht beliebt.

Die Konfiguration von RHEL5 für die Authentifizierung bei Active Directory erfordert die folgenden fünf separaten Schritte:

1. Lokalisieren und Herunterladen der entsprechenden Samba-Komponenten und anderer abhängiger Komponenten.
2. Erstellen von Samba.
3. Installieren und Konfigurieren von Samba.
4. Konfigurieren von Linux, insbesondere PAM und NSS.
5. Konfigurieren von Active Directory.

In den folgenden Abschnitten dieses Artikels werden diese Schritte ausführlicher beschrieben.

Finden der richtigen Software

Einer der größten Unterschiede zwischen Linux und Windows ist der, dass Linux aus einem kleinen Betriebssystemkernel und einer riesigen Sammlung von Komponenten besteht, die separat heruntergeladen und installiert werden können. Dadurch ist es möglich, spezifische, für bestimmte Aufgaben optimierte Linux-Konfigurationen zu erstellen. Andererseits kann dies dazu führen, dass sich die Konfiguration und Verwaltung eines Servers äußerst kompliziert gestaltet. Verschiedene Distributionen gehen auf unterschiedliche Weise damit um. Red Hat (und sein nicht kommerzieller Verwandter Fedora) verwendet RPM (Red Hat Package Manager) zur Installation und Verwaltung dieser Komponenten.

Linux-Komponenten für Red Hat gibt es in zwei Formaten. RPM-Dateien enthalten Binärdateien, die vorkompiliert und für eine bestimmte Kombination aus Komponentenversion, Linux-Distribution und CPU-Architektur erstellt wurden. So könnten Sie beispielsweise die 1.3.8-5-Version von CUPS (Common UNIX Printing System), die für Fedora, Version 10, auf einer Intel x86-Architektur-CPU erstellt wurde, herunterladen und installieren. Angesichts eines Dutzends verschiedener CPU-Architekturen, der mehr als 100 Linux-Distributionen und Tausender von Paketen und Versionen wird schnell klar, dass Sie aus einer unglaublichen Zahl binärer RPMs wählen können.

RPM-Quelldateien hingegen enthalten den eigentlichen Quellcode für ein bestimmtes Paket. Es wird davon ausgegangen, dass Sie die Quellen herunterladen und installieren, die Buildoptionen konfigurieren und die Binärdateien eigenhändig kompilieren und verknüpfen. Der Gedanke, eigene Betriebssystemkomponenten zu erstellen, ist ein wenig einschüchternd für einen Windows-Benutzer, der daran gewöhnt ist zu installieren, was immer Microsoft auf der Windows-Installations-CD bereitstellt. Dank des Paket-Managers verläuft der Prozess aber ziemlich problemlos und erstaunlich zuverlässig. Die Samba-Gruppe veröffentlicht Updates und Sicherheitspatches in rasendem Tempo. Allein im Juli und August 2008 wurden vier Versionen von Samba 3.2 mit insgesamt mehr als 100 Fehlerbehebungen und Sicherheitsfixes veröffentlicht. Für dieses Projekt habe ich die Quelldateien für die aktuelle stabile Version von Samba heruntergeladen, Version 3.0.31.

Warum habe ich die Samba-Quelldateien statt eines vorkompilierten Satzes von Binärdateien heruntergeladen? Zuerst habe ich durchaus versucht, mit den Binärdateien zu arbeiten. Nach etlichen Stunden Arbeit mit einem Debugger entdeckte ich jedoch, dass die heruntergeladenen Binärdateien nicht mit den richtigen Optionen für die Unterstützung der Active Directory-Authentifizierung erstellt wurden. Der Code, der die Linux-ID-Zuordnung in Active Directory unterstützt, war nämlich in den Standardbuilds deaktiviert. Daher musste ich Samba mit den passenden Buildoptionen neu erstellen. Auf die ID-Zuordnung werde ich später noch genauer eingehen.

Trotz des standardmäßig kleinen Kernels von Linux wird die Red Hat Enterprise-Distribution mit vielen vorinstallierten Paketen ausgeliefert. Normalerweise erleichtert dies die Arbeit, weil Sie mit einem vollständigen und funktionsfähigen Betriebssystem beginnen. Die vorinstallierten Pakete verursachen aber mitunter Konflikte mit Software, die Sie später installieren möchten.

Ich habe Samba bei der Installation von Red Hat nicht einbezogen (normalerweise wird Samba standardmäßig installiert), weil ich eine aktuellere Version verwenden wollte. Die neuere Version von Samba erfordert jedoch neue Versionen mehrerer anderer Bibliotheken und Dienstprogramme, die bereits installiert waren. Diese Abhängigkeitsprobleme sind recht ärgerlich, lassen sich aber sehr einfach mit RPM lösen.

Es gibt viele Websites, die binäre RPM-Pakete hosten. Die von mir verwendete (aus dem einfachen Grund, dass es die erste war, die ich gefunden habe) heißt PBONE, zu finden unter rpm.pbone.net. Sie bietet eine praktische Methode zum Suchen nach Paketen sowie alle Binärdateien, die ich für meine CPU-Architektur (i386) und Betriebssystemdistribution (Red Hat Enterprise Linux 5/Fedora 7&8) benötigte.

Ich musste die in Abbildung 4 aufgelisteten Pakete herunterladen und aktualisieren, um die aktuelle 3.0-Version von Samba zu erstellen und zu installieren (es gibt eine noch aktuellere Struktur der Version 3.2, die ich nicht ausprobiert habe). Beachten Sie, dass diese Pakete für die Fedora Core-Distribution (fc) bestimmt sind. Red Hat basiert auf denselben Quellen, die auch Fedora verwendet, und ist damit vollständig interoperabel. Für Fedora Core 7 und höher erstellte Pakete können auf RHEL5 ohne Änderung ausgeführt werden. Speichern Sie die heruntergeladenen RPM-Dateien im Verzeichnis „/usr/src/redhat/RPMS“.

Abbildung 4 Für das Erstellen und Installieren von Samba 3.0.31 erforderliche Pakete

samba-3.031-0.fc8.src.rpm	RPM-Quelle für Samba 3.0.31
gnutls1.6.3-3.fc7.i386	GNU TLS-Bibliotheken (Transport Layer Security)
gnutils-devel-1.6.3-3.fc7.i386	GNU TLS-Entwicklungsdateien
popt-1.12-3.fc8.i386	Bibliotheken für Analyse der Befehlszeilenargumente
popt-devel-1.12-3.fc8.i386	Entwicklungsdateien für Analyse der Befehlszeilenargumente
cups-libs-1.2.12-11.fc7.i386	Bibliotheken für Common UNIX Printer System
cups-devel-1.2.12-11.fc7.i386	Entwicklungsdateien für Common UNIX Printer System
cups-1.2.12.11.fc7.i386	Binärdateien für Common UNIX Printer System

Erstellen von Samba

Der erste Schritt beim Erstellen von Samba besteht darin, die richtige RPM-Quelle herunterzuladen. Ich habe die RPM-Quelldatei für Samba 3.0.31 von der PBONE-Website heruntergeladen. Als Nächstes wird die heruntergeladene RPM-Quelldatei im Verzeichnis „/usr/src/redhat/SRPMS“ gespeichert. Dies ist das Standardverzeichnis für RPM-Quelldateien während des Erstellungsprozesses.

Öffnen Sie eine Terminalsitzung (in der Sprache von Windows ist dies ein Befehlszeilenfenster), und wechseln Sie zum SRPMS-Ordner. Installieren Sie anschließend das Quellpaket mit dem entsprechenden Befehl (siehe Abbildung 5).

Abbildung 5 Installieren der RPM-Quelle für Samba (zum Vergrößern auf das Bild klicken)

Sollte der Fehler „user mockbuild does not exist – using root“ angezeigt werden, ist dies kein Grund zur Besorgnis. Dieser Fehler zeigt an, dass die Mockbuild-Dienstprogramme nicht installiert sind. Für den Erstellungsprozess sind diese Programme nicht erforderlich.

Wechseln Sie als Nächstes in das Verzeichnis „usr/src/redhat/SPECS“, und bearbeiten Sie die Datei SAMBA.SPEC, die die Samba-Buildoptionen enthält. Suchen Sie nach der Zeile, die mit „CFLAGS=“ beginnt, und vergewissern Sie sich, dass die Option „--with-shared-modules=idmap_ad,idmap_rid“ vorhanden ist. Diese Option stellt sicher, dass der Erstellungsprozess den Code einschließt, der Linux-UIDs (Unique Identifiers) korrekt in Active Directory überträgt. Abbildung 6 zeigt diese Option.

Abbildung 6 Die Buildoption „with-shared-modules“ (zum Vergrößern auf das Bild klicken)

Als Nächstes müssen Sie eventuell einige der Bibliotheken auf Ihrem Computer aktualisieren, um Samba korrekt erstellen und installieren zu können. Dies hängt davon ab, welche Versionen der Bibliotheken installiert sind. In meinem Fall musste ich die in Abbildung 4 aufgeführten Pakete mit dem Befehl „rpm --install“ installieren. In manchen Fällen war es erforderlich, die Option „--force“ zu verwenden, um einige der Abhängigkeitsprobleme zu überwinden.

Um Samba zu erstellen, wechseln Sie in das Verzeichnis „/usr/src/redhat“, und führen Sie den Befehl „rpmbuild –bb SPECS/samba.spec“ aus (siehe Abbildung 7). Im Ergebnis dieses Vorgangs wird eine neue samba-3.0.31-0.i386-RPM-Datei im Verzeichnis „/usr/src/redhat/RPMS“ abgelegt. Wir installieren diese RPM-Datei an späterer Stelle im Projekt.

Abbildung 7 Erstellen der RPM-Binärdatei für Samba (zum Vergrößern auf das Bild klicken)

Konfigurieren des Linux-Netzwerks

Wenn die Authentifizierung mit Active Directory funktionieren soll, muss der Linux-Computer mit einem DC kommunizieren können. Hierfür müssen drei Netzwerkeinstellungen konfiguriert werden.

Erstens ist es wichtig sicherzustellen, dass die Netzwerkschnittstelle für Ihren Linux-Computer richtig konfiguriert ist, entweder mithilfe des DHCP-Protokolls (Dynamic Host Configuration) oder durch Zuweisen einer geeigneten IP-Adresse und Netzmaske mithilfe des ifconfig-Befehls. Unter RHEL5 konfigurieren Sie das Netzwerk durch Auswahl der Option „Network“ unter „System“ | „Administration“ (siehe Abbildung 8).

Abbildung 8 Konfigurieren des Netzwerks (zum Vergrößern auf das Bild klicken)

Stellen Sie als Nächstes sicher, dass die DNS-Auflösung für den Linux-Computer so konfiguriert ist, dass sie denselben DNS-Namenserver verwendet wie die DCs. Meist ist dies ein DC in der Domäne, der der Linux-Computer beitreten soll (vorausgesetzt, Sie verwenden ein in Active Directory integriertes DNS). Konfigurieren Sie die DNS-Auflösung auf der DNS-Registerkarte desselben Dienstprogramms für die Netzwerkkonfiguration, das Sie zur Konfiguration des Netzwerks verwendet haben (siehe Abbildung 9).

Abbildung 9 Festlegen der primären DNS-Auflösung (zum Vergrößern auf das Bild klicken)

Nach Ausführung dieser Schritte müssen Sie abschließend den Hostnamen des Linux-Computers festlegen, sodass er seinem Namen in der Domäne entspricht. Sie können den Hostnamen zwar mit der Anwendung für die Netzwerkkonfiguration festlegen, aber dies scheint nicht immer zu funktionieren.

Bearbeiten Sie stattdessen die Datei „/etc/hosts“ direkt, und fügen Sie unterhalb des Eintrags „localhost.localdomain“ einen Eintrag im Format <IP-Adresse> <FQDN> <Hostname> hinzu. (Ein Beispiel wäre „10.7.5.2 rhel5.linuxauth.local linuxauth“.) Wenn Sie dies versäumen, wird nach dem Beitritt des Linux-Computers zur Domäne ein inkorrektes Computerobjekt im Verzeichnis erstellt.

Konfigurieren der Linux-Zeitsynchronisierung

Das Kerberos-Protokoll ist davon abhängig, dass die authentifizierenden Systeme über Uhren verfügen, die innerhalb einer relativ kleinen Spanne synchronisiert sind. Standardmäßig erlaubt Active Directory eine maximale Zeitabweichung von fünf Minuten. Um sicherzustellen, dass Ihre Linux-Systeme und die Systemuhren der DCs diesen Wert nicht überschreiten, sollten Sie die Linux-Systeme für die Verwendung des NTP-Diensts (Network Time-Protokoll) eines DC konfigurieren.

Führen Sie als Nächstes auf dem Linux-Server das Dienstprogramm „Date & Time“ unter „System“ | „Administration“ aus, und klicken Sie dann auf die Registerkarte „Network Time Protocol“. Aktivieren Sie das Kontrollkästchen „Enable Network Time Protocol“, und fügen Sie dann die IP-Adresse des DC hinzu, den Sie als Quelle für die Netzwerkzeit verwenden möchten. Dies sollte in der Regel der DC in der Domäne mit der FSMO-Rolle (Flexible Single Master Operations) des PDC-Emulators (primärer Domänencontroller) sein. Abbildung 10 zeigt ein Beispiel für das Einstellen der Quelle für die Linux-Netzwerkzeit.

Abbildung 10 Konfigurieren des NTP (Network Time-Protokoll (zum Vergrößern auf das Bild klicken)

Konfigurieren von PAM und NSS

PAM und NSS halten eine Linux-Anwendung (z. B. den Desktop) und Winbind zusammen. Wie viele Linux-Dienste werden auch PAM und NSS über Textdateien konfiguriert. Als Erstes widmen wir uns der Konfiguration von PAM.

PAM bietet Anwendungen vier für die Authentifizierung relevante Funktionen. Die Authentifizierungsfunktion ermöglicht einer Anwendung zu bestimmen, vom wem sie verwendet wird. Die Kontofunktion bietet Kontoverwaltungsfunktionen, die nicht speziell auf die Authentifizierung bezogen sind, z. B. die Beschränkung der Anmeldungszeit. Die Kennwortfunktion bietet Verfahren für das Anfordern und Verwalten von Kennwörtern. Die Sitzungsfunktion führt benutzerbezogene Setup- und Abbauaufgaben für die Anwendung aus, z. B. das Protokollieren oder Erstellen von Dateien in einem benutzerspezifischen Verzeichnis.

Unter Red Hat werden die PAM­Konfigurationsdateien im Verzeichnis „/etc/pam.d“ gespeichert. Dieses Verzeichnis enthält eine Textdatei für jede Anwendung, von der PAM für die Authentifizierung verwendet wird. Die Datei „/etc/pam.d/gdm“ enthält beispielsweise die PAM-Konfigurationsinformationen für Gnome Desktop Manager (GDM), die standardmäßige Desktopumgebung für Red Hat. Jede PAM-Konfigurationsdatei enthält mehrere Zeilen, wobei jede Zeile einen Aspekt des PAM-Authentifizierungsprozesses definiert. Abbildung 11 zeigt den Inhalt der PAM-Konfigurationsdatei für GDM.

Abbildung 11 PAM-Konfigurationsdatei für Gnome Desktop Manager (zum Vergrößern auf das Bild klicken)

Jeder Eintrag in einer PAM-Konfigurationsdatei hat das Format <Verwaltungsgruppe> <Steuerung> <Modul> <Parameter>, wobei <Verwaltungsgruppe> der Funktion entspricht, auf die sich der Konfigurationseintrag bezieht: „auth“, „account“, „password“ oder „session“. Die in Abbildung 12 beschriebenen Steuerungsschlüsselwörter weisen PAM an, wie der Konfigurationseintrag zu verarbeiten ist. Die dritte Spalte der Datei enthält den Namen einer freigegebenen PAM-Bibliothek im Verzeichnis „/lib/security“. Freigegebene Bibliotheken enthalten ausführbaren Code, der dynamisch geladen werden kann, ähnlich wie DLLs in Windows. Zusätzliche Begriffe nach dem Modulnamen sind Parameter, die PAM an die freigegebene Bibliothek weitergibt.

Abbildung 12 PAM-Steuerungsschlüsselwörter

Schlüsselwort	Beschreibung
Required	Ist das Modul erfolgreich, setzt PAM die Evaluierung der übrigen Einträge für die Verwaltungsgruppe fort, und die Ergebnisse werden von den Ergebnissen der übrigen Module bestimmt. Ist das Modul nicht erfolgreich, setzt PAM die Evaluierung fort, gibt aber einen Fehler an die aufrufende Anwendung zurück.
Requisite	Ist das Modul erfolgreich, setzt PAM die Evaluierung der Verwaltungsgruppeneinträge fort. Ist das Modul nicht erfolgreich, kehrt PAM ohne weitere Verarbeitung zur aufrufenden Anwendung zurück.
Sufficient	Ist das Modul erfolgreich, gibt PAM eine Erfolgsmeldung an die aufrufende Anwendung zurück. Ist das Modul nicht erfolgreich, setzt PAM die Evaluierung fort, aber die Ergebnisse werden von nachfolgenden Modulen bestimmt.
Optional	PAM ignoriert die Ergebnisse des Moduls, sofern es nicht das einzige Modul ist, das für die Verwaltungsgruppe angegeben wurde.
Include	PAM bezieht den Inhalt der referenzierten PAM-Konfigurationsdatei ein und verarbeitet die darin enthaltenen Einträge.

Sie sehen, dass jede Verwaltungsgruppe mehrere Einträge umfasst. PAM verarbeitet die Einträge der Reihenfolge nach durch Aufrufen des benannten Moduls. Das Modul meldet dann entweder den Erfolg oder einen Fehler, und PAM führt alle weiteren Schritte entsprechend dem Steuerungsschlüsselwort aus.

Sicher fällt Ihnen auf, dass die PAM-Konfigurationsdatei für GDM in allen Verwaltungsgruppen „system-auth“ enthält. So richtet PAM das standardmäßige Authentifizierungsverhalten für GDM ein. Durch Ändern von „system-auth“ können Sie das Authentifizierungsverhalten für alle Anwendungen ändern, deren PAM-Konfiguration die Datei „system-auth“ enthält. Die Standarddatei „system-auth“ wird in Abbildung 13 gezeigt.

Abbildung 13 PAM-Datei „system-auth“ (zum Vergrößern auf das Bild klicken)

Das NSS-Modul (Name Service Switch) verbirgt die Einzelheiten der Systemdatenspeicherung vor dem Anwendungsentwickler, ähnlich wie PAM die Details der Authentifizierung verbirgt. NSS ermöglicht dem Administrator zu bestimmen, in welcher Weise Systemdatenbanken gespeichert werden. Insbesondere kann der Administrator angeben, wie Benutzername und Kennwortinformationen gespeichert werden. Da wir möchten, dass Anwendungen mithilfe von Winbind Benutzerinformationen in Active Directory abrufen, müssen wir die NSS-Konfigurationsdatei entsprechend ändern.

Red Hat enthält ein kleines grafisches Applet zum Konfigurieren von PAM und NSS namens „system-config-authentication“. Dieses Applet kümmert sich um die meisten (aber nicht alle) Änderungen, die Sie an den Dateien „system-auth“ und „nss.conf“ vornehmen müssen.

Wenn Sie die Anwendung „system-config-authentication“ ausführen, wird ein Dialogfeld wie das in Abbildung 14 angezeigt. Aktivieren Sie auf den Registerkarten „User Information“ (zur Konfiguration der Datei „nss.conf“) und „Authentication“ (zur Änderung der Datei „system-auth“) die Option „Winbind“.

Abbildung 14 Das Dialogfeld von „system-config-authentication“

Wenn Sie auf die Schaltfläche „Configure Winbind“ klicken, wird das in Abbildung 15 dargestellte Dialogfeld angezeigt. Geben Sie den Namen der Domäne, bei der sich Benutzer authentifizieren sollen, im Feld „Winbind Domain“ ein, und wählen Sie unter „Security Model“ den Eintrag „ads“ aus. Geben Sie im Feld „Winbind ADS Realm“ den DNS-Domänennamen der Active Directory-Domäne ein. Geben Sie im Feld „Winbind Domain Controllers“ entweder den Namen eines DC ein, bei dem sich dieses Linux-System authentifizieren soll, oder ein Sternchen. Damit geben Sie an, dass Winbind durch Abfragen von DNS-SRV-Datensätzen einen DC auswählen soll.

Abbildung 15 Dialogfeld zum Konfigurieren von Winbind

Wählen Sie die passende Standardbefehlsshell für Ihre Active Directory-Benutzer aus. In diesem Fall habe ich die Bourne Again Shell bzw. BASH ausgewählt. Klicken Sie an dieser Stelle nicht auf die Schaltfläche „Join Domain“. Der Beitritt des Computers zur Domäne erfolgt später.

Es gibt noch eine weitere Änderung, die Sie an der Datei „/etc/pam.d/system-auth“ vornehmen müssen, nachdem Sie sie so geändert haben, dass sie Winbind unterstützt. Wenn sich ein Linux-Benutzer anmeldet, erfordert das System, dass dieser Benutzer ein Basisverzeichnis hat. Das Basisverzeichnis enthält viele benutzerspezifische Einstellungen und Konfigurationselemente, ähnlich wie die Windows-Registrierung. Das Problem besteht darin, dass Linux das Basisverzeichnis des Benutzers nicht automatisch erstellt, weil Sie Ihre Benutzer in Active Directory erstellen. Glücklicherweise können Sie PAM so konfigurieren, dass dieser Schritt im Rahmen der Sitzungskonfiguration ausgeführt wird.

Öffnen Sie die Datei „/etc/pam.d/system-auth“, führen Sie einen Bildlauf nach unten durch, und fügen Sie vor der letzten Zeile im Sitzungsabschnitt die folgende Zeile ein: „session optional map_mkhomedir.so skel=/etc/skel umask=0644“ (siehe Abbildung 16). Diese Zeile konfiguriert PAM so, dass ein Basisverzeichnis für Benutzer erstellt wird, wenn keines existiert. Hierzu wird das Verzeichnis „/etc/skel“ als „Gerüst“ oder Vorlage verwendet. Dem neuen Ordner wird die Berechtigungsmaske 0644 zugewiesen (Lese- und Schreibzugriff für Besitzer, Lesezugriff für die primäre Gruppe und Lesezugriff für alle anderen Benutzer).

Abbildung 16 Erstellen eines Basisverzeichnisses für Benutzer (zum Vergrößern auf das Bild klicken)

Installieren und Konfigurieren von Samba

Wechseln Sie zum Installieren der soeben erstellten Samba-Binärdateien in das Verzeichnis „/usr/src/redhat/RPMS“. Alle vom rpmbuild-Befehl erstellten RPM-Dateien werden in diesem Verzeichnis angezeigt. Sicher erinnern Sie sich: Samba enthält Binärdateien, die einem Linux-Client ermöglichen, auf eine Windows-Dateifreigabe (oder Samba-Dateifreigabe) zuzugreifen, sowie Code, der einem Linux-System ermöglicht, wie ein Windows-Dateiserver, ein Windows-Druckerserver und ein DC im Stil von Windows NT 4.0 zu agieren.

Um Linux die Authentifizierung bei Active Directory zu ermöglichen, ist dies nicht alles erforderlich. Für unsere Zwecke sind die gemeinsamen Samba-Dateien und Samba-Clientbinärdateien ausreichend. Diese Dateien sind praktischerweise in zwei RPM-Dateien aufgeteilt: samba-client-3.0.31-0.i386.rpm und samba-common-3.0.31-0.i386.rpm. Installieren Sie die RPM-Dateien mithilfe des Befehls „rpm --install“. Hier ein Beispiel: rpm --install samba-common-3.0.31-0.i386.rpm. (Beachten Sie, dass Sie zuerst die –common-RPM-Datei installieren müssen.)

Nach der Installation der Samba-Clientbinärdateien müssen Sie die standardmäßige Samba-Konfiguration ändern, um zu gewährleisten, dass Winbind die Authentifizierung bei Active Directory korrekt handhabt. Alle Konfigurationsinformationen für Samba (für Client und Server) befinden sich in der Textdatei „smb.conf“, die standardmäßig im Verzeichnis „/etc/samba“ abgelegt ist. Die Datei „smb.conf“ kann eine enorme Zahl an Konfigurationsoptionen enthalten. Eine detaillierte Besprechung ihres Inhalts würde den Rahmen dieses Artikels sprengen. Auf der Website „samba.org“ und den Linux-Manpages finden Sie ausführlichere Informationen zu „smb.conf“.

Der erste Schritt besteht darin, Winbind für die Verwendung von Active Directory für die Authentifizierung zu konfigurieren. Sie müssen für das Sicherheitsmodell in „smb.conf“ die Option „ads“ festlegen. Das Dienstprogramm „system-config-authentication“ sollte diese Aufgabe bereits für Sie erledigt haben. Zur Sicherheit können Sie die Einstellung aber überprüfen. Bearbeiten Sie die Datei „smb.conf“, und suchen Sie nach dem Abschnitt mit der Bezeichnung „Domain Member Options“. Suchen Sie die Zeile, die mit „security“ beginnt, und vergewissern Sie sich, dass sie „security = ads“ lautet. Vom nächsten Konfigurationsschritt wird bestimmt, wie Winbind den Linux-IDs die Windows-Sicherheitsprinzipale wie Benutzer und Gruppen zuordnet. Dies erfordert eine umfassendere Erklärung.

Das Problem der ID-Zuordnung

Ein größeres Problem im Zusammenhang mit der Authentifizierung von Linux-Benutzern bei Active Directory wurde noch nicht erwähnt, nämlich das Problem von UIDs für Benutzer und Gruppen. Intern wird weder in Linux noch Windows durch Benutzernamen auf Benutzer verwiesen. Stattdessen wird eine eindeutige interne ID verwendet. Windows verwendet die Sicherheits-ID (SID). Dabei handelt es sich um ein Gebilde variabler Länge, das jeden Benutzer innerhalb einer Windows-Domäne eindeutig identifiziert. Die SID enthält außerdem einen eindeutigen Domänenbezeichner, sodass Windows zwischen Benutzern in verschiedenen Domänen unterscheiden kann.

Linux verwendet ein viel einfacheres Schema. Jedem Benutzer auf einem Linux-Computer ist eine UID zugewiesen. Diese UID ist einfach eine 32-Bit-Ganzzahl. Der Geltungsbereich der UID ist aber auf den Computer selbst beschränkt. Es besteht keine Garantie, dass der Benutzer mit der UID 436 auf einem Linux-Computer mit dem Benutzer mit der UID 436 auf einem anderen Linux-Computer identisch ist. Folglich muss sich ein Benutzer an jedem Computer, auf den er zugreifen will, anmelden – keine wünschenswerte Situation.

Linux-Netzwerkadministratoren lösen dieses Problem meist durch Bereitstellung der Netzwerkauthentifizierung mithilfe von NIS (Network Information System) oder mithilfe eines freigegebenen LDAP-Verzeichnisses. Das System zur Netzwerkauthentifizierung stellt die UID für den Benutzer bereit, und alle Linux-Computer, die dieses Authentifizierungssystem verwenden, verfügen über dieselben Benutzer- und Gruppen-IDs. In dieser Situation verwende ich Active Directory, um die eindeutigen Benutzer- und Gruppen-IDs bereitzustellen.

Zur Lösung dieses Problems stehen zwei Strategien zur Verfügung. Die erste (und naheliegendste) Strategie besteht darin, eine UID für jeden Benutzer und jede Gruppe zu erstellen und diese ID mit dem jeweiligen Objekt in Active Directory zu speichern. Auf diese Weise kann Winbind bei der Authentifizierung eines Benutzers die UID für den Benutzer nachschlagen und für Linux als interne ID des Benutzers bereitstellen. In Winbind wird dieses Schema als Active Directory-ID-Zuordnung oder idmap_ad bezeichnet. Abbildung 17 zeigt den Prozess der Active Directory-ID-Zuordnung.

Abbildung 17 Active Directory-ID-Zuordnung (zum Vergrößern auf das Bild klicken)

Der einzige Nachteil der Active Directory-ID-Zuordnung besteht darin, dass wir eine Methode bereitstellen müssen, mit der sichergestellt wird, dass jedem Benutzer und jeder Gruppe eine ID zugewiesen wird und dass diese IDs in der Gesamtstruktur alle eindeutig sind. Weitere Informationen finden Sie in der Randleiste unter „Konfigurieren von Active Directory für die Active Directory-ID-Zuordnung“.

Zum Glück gibt es noch eine andere Strategie der ID-Zuordnung, die mit viel weniger Verwaltungsaufwand verbunden ist. Sicher erinnern Sie sich, dass die Windows-SID den Benutzer innerhalb einer Domäne sowie die Domäne selbst eindeutig identifiziert. Der Teil der SID, die den Benutzer innerhalb der Domäne eindeutig identifiziert, wird als Relative Identifier (RID) bezeichnet und ist eigentlich eine 32-Bit-Ganzzahl. Daher kann Winbind einfach die RID aus der SID extrahieren, wenn der Benutzer sich anmeldet, und die RID dann als eindeutige interne UID verwenden. In Winbind wird diese Strategie als RID-Zuordnung oder idmap_rid bezeichnet. Abbildung 18 zeigt, wie RID-Zuordnung funktioniert.

Abbildung 18 RID-Zuordnung (zum Vergrößern auf das Bild klicken)

RID-Zuordnung hat den Vorteil, dass dabei keinerlei Verwaltungsaufwand anfällt, lässt sich aber nicht in einer Umgebung mit mehreren Domänen verwenden. Grund dafür ist die Wahrscheinlichkeit, dass Benutzer in verschiedenen Domänen denselben RID-Wert haben. Wenn aber nur eine einzige Active Directory-Domäne existiert, empfiehlt sich die RID-Zuordnung.

Um die Strategie der Winbind-ID-Zuordnung zu konfigurieren, bearbeiten Sie erneut die Datei „/etc/samba/smb.conf“. Fügen Sie die Zeile „idmap backend = ad“ hinzu, um die Active Directory-Zuordnung zu verwenden. Wenn Sie die RID-Zuordnungsstrategie verwenden möchten, fügen Sie die Zeile „idmap backend = rid“ hinzu. Stellen Sie sicher, dass die Datei keine anderen Zeilen enthält, in denen die Zuordnungsstrategie definiert ist.

Es gibt noch einige andere Konfigurationsoptionen, die der Datei „smb.conf“ für Winbind hinzugefügt werden müssen. Obwohl wir PAM so konfiguriert haben, dass das Basisverzeichnis für jeden Benutzer bei der Anmeldung eingerichtet wird, müssen wir Winbind mitteilen, wie der Name dieses Basisverzeichnisses lautet. Hierzu fügen wir der Datei „smb.conf“ die Zeile „template homedir = /home/%U“ hinzu (siehe Abbildung 19). Dadurch wird Winbind mitgeteilt, dass das Basisverzeichnis für jeden Benutzer, der sich mithilfe von Active Directory authentifiziert, „/home/<Benutzername>“ lautet. Das /home-Verzeichnis muss im Voraus erstellt werden.

Abbildung 19 Festlegen des Namens für das Basisverzeichnis (zum Vergrößern auf das Bild klicken)

Beitritt zur Domäne und Anmeldung

Netzwerk, PAM, NSS und Samba Winbind sind nun korrekt konfiguriert. Jetzt kann der Linux-Computer der Domäne beitreten. Hierzu verwenden Sie den NET-Befehl in Samba. Führen Sie an einer Shelleingabeaufforderung „net ads join –U <Administratorname>“ aus. Ersetzen Sie <Administratorname> durch den Namen eines Kontos, das über ausreichende Berechtigungen verfügt, um den Beitritt eines Computers zu einer Domäne festzulegen.

Der NET-Befehl fordert Sie zur Eingabe des Benutzerkennworts auf. Wenn alles ordnungsgemäß funktioniert, tritt der Computer nach Ausführung des NET-Befehls der Domäne bei. Sie können „Active Directory-Benutzer und -Computer“ verwenden, um das neu erstellte Computerkonto zu suchen.

Den Status des Beitritts können Sie mithilfe des Winbind-Testtools „wbinfo“ überprüfen. Durch Ausführen von „wbinfo –t“ testen Sie die Vertrauensstellung zwischen Computer und Domäne. Durch Ausführen von „wbinfo –u“ listen Sie alle Benutzer in der Domäne auf. Mit „wbinfo –g“ werden alle Gruppen aufgelistet.

Wenn der Linux-Computer der Domäne beigetreten ist, versuchen Sie im nächsten Schritt, sich mit einem Active Directory-Benutzerkonto und -Kennwort anzumelden. Melden Sie sich beim Linux-Computer ab, und melden Sie sich unter Verwendung eines Active Directory-Benutzernamens an. Wenn alles richtig funktioniert, dürfte die Anmeldung gelingen.

Konfigurieren von Active Directory für die Active Directory-ID-Zuordnung

Diese Informationen sind nur von Belang, wenn Sie die Active Directory-ID-Zuordnung verwenden. Wenn Sie sich für die RID-Zuordnung entschieden haben, können Sie diese Randleiste überspringen.

Bevor Sie sich mithilfe eines Active Directory-Kontos bei Ihrem Red Hat-Server anmelden können, müssen Sie einige Änderungen an Active Directory selbst vornehmen. Erstens muss das Active Directory-Schema die Attribute berücksichtigen, die von Winbind zum Speichern von Benutzerinformationen verwendet werden. Wenn Sie Windows Server 2003 R2 ausführen, ist das Schema einsatzbereit. Benutzer einer früheren Version des Active Directory-Schemas müssen dieses mithilfe des Microsoft Services for UNIX-Pakets (SFU) erweitern.

Weitere Informationen finden Sie unter Services for UNIX auf TechNet. SFU enthält außerdem eine zusätzliche Eigenschaftenseite für das MMC-Snap-In (Microsoft Management Console) „Active Directory-Benutzer und -Computer“, mit deren Hilfe Sie die von Linux benötigten Benutzer-ID- und Gruppen-ID-Informationen verwalten können.

Nach dem Einrichten des Schemas müssen Sie Linux-IDs für alle Benutzer (und die Gruppen, zu denen sie gehören) bereitstellen, die sich an Ihrem Linux-Computer anmelden könnten. Dies bedeutet, dass Sie Werte für die uidNumber- und gidNumber-Attribute für die Benutzer und Gruppen definieren müssen, die sich bei den Linux-Computern anmelden könnten. Berücksichtigen Sie aber einige Anforderungen für diese Attribute:

1. Linux erfordert eine UID für jeden Benutzer, der sich authentifiziert. Da Sie Benutzerinformationen in Active Directory verwalten möchten, muss jedes Benutzerkonto, das sich an einem Linux-Computer anmeldet, über ein eindeutiges uidNumber-Attribut verfügen. Welchen spezifischen Wert Sie für ein uidNumber-Attribut verwenden, ist nicht wichtig. Der Wert muss aber für alle Benutzer, die sich am Linux-Computer anmelden könnten, eindeutig sein.
2. Jedem Linux-Benutzer muss außerdem eine standardmäßige Gruppen-ID zugeordnet sein. Daher benötigt jeder Active Directory-Benutzer, der sich an einem Linux-Computer anmeldet, auch einen Wert für das gidNumber-Attribut. Dieser Wert muss unter Benutzern nicht eindeutig sein, muss aber die Gruppe eindeutig identifizieren.
3. Jeder Gruppe in Active Directory sollte ein eindeutiger Wert für ihr gidNumber-Attribut zugeordnet sein. Streng genommen muss dem gidNumber-Attribut von Gruppen nicht unbedingt ein Wert zugeordnet sein, aber Winbind erwartet bei der Authentifizierung eines Benutzers, dass jede Gruppe, der dieser Benutzer angehört, über einen eindeutigen gidNumber-Wert verfügt. Am einfachsten ist es wahrscheinlich, dafür zu sorgen, dass jede Gruppe über einen eindeutigen gidNumber-Wert verfügt.
4. Winbind erwartet, dass jeder Benutzer, den es in Active Directory nachschlägt, ein Mitglied der Domänenbenutzergruppe ist. Daher wird auch erwartet, dass die Domänenbenutzergruppe über einen Wert für das gidNumber-Attribut verfügt.

Was tun bei Problemen?

Das Einrichten eines Linux-Computers zur Authentifizierung mit Active Directory mithilfe von Winbind ist keine einfache Aufgabe. Viele Konfigurationsschritte sind erforderlich, und Vieles kann schiefgehen. Die Tatsache, dass sich alle Versionen von Linux und alle Versionen von Samba ein klein wenig unterscheiden, ist dabei nicht hilfreich. Sie können aber mithilfe einiger Komponenten herausfinden, was genau vor sich geht.

Da wäre zum Ersten das Linux-Systemprotokoll, das Sie unter „/var/log/messages“ finden. Samba legt in dieser Datei Meldungen ab, die wichtige Ereignisse wie fehlende Dateien oder eine ungültige Konfiguration betreffen. Außer der Systemprotokolldatei gibt es die Protokolldateien für Samba und Winbind. Diesen Dateien, zu finden unter „/var/log/samba“, können Sie zusätzliche Informationen entnehmen.

Die Detailliertheit (und den Umfang) der von Winbind ausgegebenen Protokollmeldungen können Sie erhöhen, indem Sie das Startskript ändern und die Debugebene festlegen. Bearbeiten Sie das Shellskript „/etc/init.d/winbind“, und fügen Sie dem winbindd-Befehl „-d 5“ hinzu. Dadurch wird die Debugebene auf 5 erhöht (zulässige Werte sind 1 bis 10), was Winbind veranlasst, ausführlichere Fehlermeldungen zu generieren.

Wenn Winbind mit einem DC kommuniziert, können Sie ein Dienstprogramm zur Aufzeichnung von Netzwerkpaketen wie Netmon 3.1 ausführen. Damit lässt sich die Vorgehensweise von Winbind genau analysieren. Außerdem können Sie das Windows-Sicherheitsprotokoll auf dem DC überprüfen. Dort werden die Authentifizierungsversuche erfasst.

Es funktioniert – mit welchem Ergebnis?

Wenn alles funktioniert, haben Sie jetzt die Möglichkeit, sich bei Ihrem Linux-System mit den Anmeldeinformationen anzumelden, die Sie in Active Directory verwalten. Im Vergleich zur lokalen Verwaltung von IDs auf dem Linux-Computer oder zur Verwendung eines nicht sicheren Systems wie NIS ist dies ein riesiger Fortschritt. Sie können nun die Benutzerverwaltung in einem Identitätsspeicher zentralisieren: Active Directory.

Allerdings ist diese Lösung nicht rundum perfekt – einige Dinge fehlen. Erstens: Technischen Support zu bekommen, ist mehr oder weniger Glückssache. Die meisten Linux-Organisationen tappen ein wenig im Dunkeln, wenn es um Active Directory geht, und welche Unterstützung Sie von der Linux-Community erhalten, hängt einzig und allein davon ab, wer Ihren Beitrag liest und wie diese Person an diesem Tag gelaunt ist.

Außerdem stehen für Samba keine Migrations- oder Bereitstellungstools zur Verfügung. Bei vorhandenen Linux-Konten mit zugeordneten Benutzer-IDs und Berechtigungen müssen Sie manuell sicherstellen, dass diese bei der Migration zu Active Directory ihre UIDs beibehalten.

Schließlich muss erwähnt werden, dass eine der wichtigsten Active Directory-Anwendungen, die Gruppenrichtlinien, noch nicht in Samba verfügbar ist (obgleich in Arbeit). Sie können zwar ein Linux-System mithilfe von Samba mit Active Directory verknüpfen, aber die Verwaltung über Gruppenrichtlinien ist nicht möglich.

Drittanbieterlösungen

Die Möglichkeit der Authentifizierung von Linux-Computern mit Active Directory ist ein klarer Fortschritt. Die Implementierung einer eigenen Lösung mithilfe von Samba Winbind ist jedoch mühsam, wenn nicht gar qualvoll. Wenn Sie nun vermuten, dass einige innovative Softwarehersteller mit einer einfacheren Lösung auf den Plan treten, haben Sie Recht.

Vier Softwarehersteller haben einfach zu installierende und benutzerfreundliche Versionen der Komponenten entwickelt, die in diesem Artikel vorgestellt wurden. Sie stellen den Code und die Migrationstools für fast jede gängige Version von Linux, UNIX und Apple Macintosh sowie Unterstützung für die Verwaltung von Linux-Computern mittels Gruppenrichtlinien bereit.

Die vier Unternehmen sind Centrify, Likewise Software, Quest Software und Symark. Alle vier Hersteller bieten ähnliche Funktionen, einschließlich Gruppenrichtlinienverwaltung, für ein breites Spektrum von Linux-Distributionen. Likewise Software stellte seine Implementierung kürzlich als Open-Source-Anwendung unter dem Namen „Likewise Open“ zur Verfügung. Die Gruppenrichtlinienkomponente bleibt allerdings ein kommerzielles Produkt. Likewise Open ist für mehrere gängige Linux-Distributionen verfügbar. (Nachtrag: Während der Arbeit an diesem Artikel wurde mein Unternehmen, NetPro, von Quest Software übernommen.)

Ist es sinnvoll, ein eigenes Authentifizierungssystem mit Samba und Winbind zu erstellen, wenn kommerzielle Produkte verfügbar sind? Wenn das Budget keine Ausgaben für Integrationssoftware vorsieht, ist die Open-Source-Variante mit Samba eine kostenlose Alternative. Damit bekommen Sie außerdem den gesamten Quellcode, was ein verlockender Vorteil sein kann. Die Migration vorhandener Linux-Computer und ihrer vorhandenen UIDs ist aber ein sehr kniffliges Problem.

Wenn Sie andererseits Installations- und Implementierungszeit sparen möchten, vorhandene Linux-Computer migrieren müssen oder gern einen Ansprechpartner hätten, der Ihnen eine verbindliche Antwort auf Ihre Fragen geben kann, ist eine der kommerziellen Lösungen sinnvoll. Wenn Sie die Gruppenrichtlinienverwaltung benötigen, müssen Sie zur kommerziellen Alternative greifen.

Wofür auch immer Sie sich entscheiden, durch Integration der Linux-Authentifizierung in Active Directory verringern Sie den Aufwand der Verwaltung mehrerer Benutzerkonten, erhöhen die Systemsicherheit und profitieren von einem einzigen Identitätsspeicher zur Verwaltung und Überwachung. Dies alles sind zwingende Gründe, die dafür sprechen, dass Sie einen Versuch wagen.

Gil Kirkpatrick entwarf oder entwickelte im Laufe seiner 30-jährigen Karriere Dutzende erfolgreicher kommerzieller Softwareprodukte. Darüber hinaus ist er Gründer der Directory Experts Conference (heute bekannt als The Experts Conference). Gil Kirkpatrick ist Autor von Active Directory Programming und verfasst häufig Beiträge für Windows IT Pro und das TechNet Magazin. In seiner derzeitigen Rolle als hauseigener Experte bei NetPro (jetzt Teil von Quest Software) wirkt er als Berater bei verschiedenen Sicherheits-, Identitäts- und Marketingprojekten und ist als Referent auf Technologieseminaren und -konferenzen auf der ganzen Welt tätig.