Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- kb [2014/03/26 08:06]
flacco [Postfix - Rücknahme und Weitergabe an Dovecot]
+++ kb [2016/03/29 08:06]
flacco
@@ Zeile 3: / Zeile 3: @@
 Diese Seite schließt eine Lücke im Wiki. Sie soll Hintergrund und Basiswissen vermitteln, welches dabei hilft sich an der Entwicklung des invis-Servers zu beteiligen bzw. genutzte Techniken und Konfigurationen zu verstehen.
-===== DNS-Server bind und LDAP =====
+===== invis-Server & Active Directory =====
+"Active Directory" ist das Herz des invis-Servers ab Version 10.0, das erklärt aber kaum was es genau ist.
+==== Microsoft Actice Directory ====
+"Active Directory" ist eine von Microsoft entwickelte Kombination aus Kerberos, LDAP-Verzeichnis und Domain-Name-Service. Dabei dient Kerberos der Benutzer-Authentifizierung und ermöglicht sogenanntes "Single-Sign-On", das LDAP-Verzeichnis dient als zentraler Informationsspeicher und DNS wird für eine Technik namens "Service Location" genutzt. Eingeführt wurde "Active Directory" mit Einführung des "Microsoft Servers 2000".{{ :active-directory_ms.png?300|}}
+Single-Sign-On (SSO) ermöglicht, dass nur eine Anmeldung am System auch als Autorisierung für alle im Netzwerk angebotenen Dienste gilt. D.h. es genügt beispielsweise sich am eigenen PC mit Benutzernamen und Passwort anzumelden um danach ohne weitere Angabe von Benutzernamen oder Passwort auch Zugriff auf Dienste wie beispielsweise einen Exchange-Server zu erhalten.
+Kerberos seinerseits verwaltet keinerlei eigenen Datenbestand. Die Daten auf die Kerberos zurückgreift werden in einem sogenannten LDAP-Verzeichnis abgelegt. Das LDAP-Verzeichnis stellt somit den zentralen Informationsspeicher des Active Directories dar. LDAP (Lightweight Directory Access Protocol) steht dabei sowohl für das Netzwerkprotokoll über welches auf die Informationen im Verzeichnis zugegriffen wird, als auch den Informationsspeicher selbst. Der Datenspeicher arbeitet "objektorientiert" und somit gänzlich anders als eine relationale Datenbank. Der objektorientierte Ansatz ermöglicht es Netzwerk- oder Organisationsstrukturen eins zu ein im Datenspeicher abzubilden.
+Die letzte Komponente "Domain Name Service" (DNS) wird neben der normalen Namensauflösung für Service Location genutzt. Service Location ist eine Technik mit der Clients im Netzwerk die Server finden können, die bestimmte Dienste anbieten. Im AD dient sie dazu den Clients mitzuteilen auf welchem Server Kerberos- und LDAP-Dienst laufen.
+Zusätzlich kann auch ein DHCP-Dienst an das AD angelagert werden. Dabei nutzt der DHCP-Dienst ebenfalls das LDAP-Verzeichnis als Informationsspeicher.
+==== Active Directory auf invis-Server ====
+{{ :active-directory_invis-server.png?350|}}Die Verwendung eines LDAP-Verzeichnisses als zentralen Informationsspeicher für Benutzerverwaltung, DNS- & DHCP-Server sowie weitere Zwecke zu nutzen ist für invis-Server nicht neu. Mit openLDAP verfügte auch der invis Classic schon immer über ein LDAP-Verzeichnis. Was fehlte waren Kerberos und Service Location.
+Mit Einführung von Samba 4.0 brachte Samba eine eigene Implementation von Microsofts Active Directory mit. Dies ermöglichte uns den Umstieg von openLDAP auf Active Directory. Um alle Informationen die der invis Classic im LDAP speicherte auch im AD speichern zu können mussten wir eigene Schemaerweiterungen einspielen und darüber hinaus auch den von uns verwendeten DHCP-Server des ISC (Internet Systems Consortium) patchen.
+Als DNS-Server verwenden wir nicht den "Samba Internal DNS", sondern weiterhin "bind" (ebenfalls vom ISC). Dies wird allerdings von Samba direkt unterstützt. Die Anbindung erfolgt hier über einen DLZ-Treiber den Samba selbst mitbringt.
+Für die Benutzerverwaltung haben sich die Vorzeichen umgekehrt. Beim invis Classic wurden im LDAP prinzipiell POSIX-kompatible Benutzerkonten angelegt, die um Windows- respektive Samba-Attribute ergänzt wurden. Mit Active Directory bilden jetzt Windows-Benutzerkonten die Basis, die um POSIX-Attribute erweitert werden. Da Microsoft dies selbst unter Verwendung der eigenen Erweiterung "Services for UNIX" (SFU) anbietet, bricht es nicht die Kompatibilität zur MS-Welt. Unter Samba wird diese Ergänzung "RFC 2307 Erweiterung" genannt.
+Die Anbindung von Linux-Clients wird über eine Kombination aus Samba und {{https://fedoraproject.org/wiki/Features/SSSD|SSSD}} (System Security Services Daemon) realisiert. Dabei wird Samba genutzt um (genau wie Windows Clients) der Domäne beizutreten und SSSD ist für die Abbildung der Benutzerkonten via PAM auf Linux-Systemen sowie die Benutzeranmeldung selbst zuständig. Selbstverständlich wird auch hier Kerberos verwendet.
+Genau wie es für Windows-Domänenmitglieder möglich ist, ermöglicht der SSSD auch für Linux-Clients Offline-Logins an der Domäne.
+Grundsätzlich beherrschen invis-Server damit auch Single Sign On, leider haben wir dass noch nicht für die Dienste des invis-Servers umgesetzt.
+==== Active Directory und Firewall ====
+Die vielen an AD beteiligten Netzwerkprotokolle erfordern ein besonderes Augenmerk auf eine zwischen geschaltete Firewall. invis-Server nutzen beispielsweise immer die "SuSEfirewall2" auch zwischen dem Server selbst und dem lokalen Netzwerk (interne Zone).
+Die folgende Tabelle gibt einen Überblick über die beteiligten Protokolle und zugehörigen Ports:
+^Protokoll  ^Transportprotokoll  ^Port  ^Bemerkung  ^
+|Kerberos  |  TCP & UDP  |  88  |    |
+|LDAP  |  TCP & UDP  |  389  |    |
+|LDAPs  |  TCP  |  636  |    |
+|DNS  |  TCP & UDP  |  53  |    |
+|GC  |  TCP  |  3268  |  Global Catalog  |
+|SMB/CIFS  |  TCP & UDP  |  445  |  Zugriff auf sysvol Freigabe  |
+|RPC  |  TCP  |  135  |Früheres Microsoft Messaging Protokoll, wird genutzt für die Replikation der sysvol Freigabe. Dies wird von Samba noch nicht unterstützt.  |
+===== DNS-Server bind und LDAP (invis Classic) =====
 Schon von Anfang an setzen wir ein LDAP-Verzeichnis als Daten-Backend für den DNS-Server //bind// ein. Der zugrunde liegende Patch, welchen wir schon seit einiger Zeit selbst in die Software-Pakete einbauen müssen, wird inzwischen kaum noch weiter entwickelt. Statt dessen gehört der sogenannte DLZ (dynamic loadable zone) Treiber seit etwa openSUSE 11.2 (oder so) fest zum Funktionsumfang der openSUSE-Pakete. Die Nutzung dieses Treibers würde uns eine Menge Arbeit ersparen, da wir keine eigenen //bind// Pakete mehr im openSUSE-Buildservice pflegen müssten.
@@ Zeile 556: / Zeile 602: @@
 ==== Letzte Etappe - Dovecot ====
-Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1 zum Einsatz. Erwähnenswert ist das, da sich an dessen Konfiguration mit Einführung von V. 2.x einiges geändert hat. Einerseits betrifft dies Namen von Konfigurationsoptionen und andererseits den Aufbau der Konfiguration an sich. Unter openSUSE wurde die Konfiguration der Übersicht halber in mehrere Dateien gesplittet. Im Verzeichnis "/etc/dovecot" ist nach wie vor eine (wenn auch stark geschrumpfte) Datei "dovecot.conf" zu finden. Sie dient quasi als Hauptkonfigurationsdatei in die alle weiteren Dateien inkludiert werden. Ähnlich wie das bereits beim Apache-Webserver der Fall ist.
+Ab invis-Server Version 7.1-R3 kommt Dovecot in Version 2.1, inzwischen schon Version 2.2 zum Einsatz. Erwähnenswert ist das, da sich an dessen Konfiguration mit Einführung von V. 2.x einiges geändert hat. Einerseits betrifft dies Namen von Konfigurationsoptionen und andererseits den Aufbau der Konfiguration an sich. Unter openSUSE wurde die Konfiguration der Übersicht halber in mehrere Dateien gesplittet. Im Verzeichnis "/etc/dovecot" ist nach wie vor eine (wenn auch stark geschrumpfte) Datei "dovecot.conf" zu finden. Sie dient quasi als Hauptkonfigurationsdatei in die alle weiteren Dateien inkludiert werden. Ähnlich wie das bereits beim Apache-Webserver der Fall ist.
 Alle weiteren Dateien sind logisch unterteilt im Verzeichnis "/etc/dovecot/conf.d" zu finden.
-===== ISC DHCP LDAP Schema nach Samba 4 LDAP überführen =====
+Bei aller Freude über Peer Heinleins neues Dovecot Buch, ist doch festzustellen, dass die Aufgabenstellung die sich für die Dovecot-Konfiguration auf einem invis-Server stellt, mit dem Buch allein nicht zu bewältigen ist. Peer trennt im Prinzip zwischen einer Installation mit lokalen Benutzern und einer Hosting-Situation mit virtuellen Benutzern. Auf einem invis-Server haben wir es zwar mit lokalen Benutzern zu tun, aufgrund der Vorzüge, die das mit sich bringt, möchte ich sie aber lieber wie virtuelle Benutzer behandeln, da dies einige Vorteile mit sich bringt.
-Suchen und ersetzen der Attributnamen und Objektklassen:
+**Definieren wir zunächst die Ziele:**
+  * Zugriff auf die LDAP-Benutzerkonten via PAM
+  * Ordner-Freigaben über IMAP-ACLs
+  * Sieve Filter und sei es nur für Abwesenheitsbenachrichtigungen
+  * Quotas, wenn auch nur zum Warnen
+  * Lokale Email-Zustellung via LMTP
+  * SASL-Auth Schnittstelle für Postfix (wird im nächsten Abschnitt beschrieben)
+==== Mailversand - SMTP-Auth mit Dovecot-SASL ====
+...to be continued.
-<code>
-linux:~ # cat README.ldap | sed /dhcp[A-Z]/s/dhcp/iscDhcp/g > ad.README.ldap
-</code>