Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
centos:mail_c7:dovecot_6 [30.07.2014 20:38. ] – [auth-sql.conf.ext] djangocentos:mail_c7:dovecot_6 [22.07.2019 15:04. ] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 8: Zeile 8:
   - **GID** : Gruppen-ID, die beim Anlegen des Benutzerkontos, der Unterverzeichnisse für die eMails, SIEVE-Scripte und individuellen Benutzerdaten und der eMails verwendet wird.   - **GID** : Gruppen-ID, die beim Anlegen des Benutzerkontos, der Unterverzeichnisse für die eMails, SIEVE-Scripte und individuellen Benutzerdaten und der eMails verwendet wird.
   - **Home-Verzeichnis**: Benutzerverzeichnis, in dem das Benutzerkonto, die Unterverzeichnisse für die eMails, SIEVE-Scripte und individuellen Benutzerdaten sowie der eMails verwendet wird.   - **Home-Verzeichnis**: Benutzerverzeichnis, in dem das Benutzerkonto, die Unterverzeichnisse für die eMails, SIEVE-Scripte und individuellen Benutzerdaten sowie der eMails verwendet wird.
- 
  
 ===== Authentifizierungsquellen ===== ===== Authentifizierungsquellen =====
Zeile 28: Zeile 27:
 Authentifizierungs-Anfragen, oder Neudeutsch **//lookups//**, werden von unserem Dovecot-Mailserver an verschiedenen Stellen in abwechselnden Formen benötigt. Authentifizierungs-Anfragen, oder Neudeutsch **//lookups//**, werden von unserem Dovecot-Mailserver an verschiedenen Stellen in abwechselnden Formen benötigt.
   * **passdb-lookup** : Der passdb-lookup wird von Dovecot immer dann ausgeführt, wenn die [[http://de.wikipedia.org/wiki/Autorisierung|Autorisierung]] des Benutzers gefordert wird. Im Genauen wird hierbei geprüft, ob das genannte Passwort dem Anmeldenamen/Benutzerkonto zugeordnet werden kann. Diese Autorisierungsüberprüfung ist immer dann notwendig, wenn sich ein Kunde am IMAP/POP3-Server bzw. am Managed-SIEVE-Server anmeldet. Passt Passwort und Anmeldenamen zusammen, wird dem Benutzer der Zugriff gestattet, passt das Passwort nicht, wird der Anmeldevorgang mit einer Fehlermeldung abgebrochen.   * **passdb-lookup** : Der passdb-lookup wird von Dovecot immer dann ausgeführt, wenn die [[http://de.wikipedia.org/wiki/Autorisierung|Autorisierung]] des Benutzers gefordert wird. Im Genauen wird hierbei geprüft, ob das genannte Passwort dem Anmeldenamen/Benutzerkonto zugeordnet werden kann. Diese Autorisierungsüberprüfung ist immer dann notwendig, wenn sich ein Kunde am IMAP/POP3-Server bzw. am Managed-SIEVE-Server anmeldet. Passt Passwort und Anmeldenamen zusammen, wird dem Benutzer der Zugriff gestattet, passt das Passwort nicht, wird der Anmeldevorgang mit einer Fehlermeldung abgebrochen.
-  * **userdb-lookup** : Bei einem userdb-lookup ermittelt unser Dovecot-Server die Umgebungsvariablen des genannten/benötigten Benutzerkontos. Im einfachsten Fall muss natürlich ein userdb-lookup nach einem erfolgreichen passdb-lookup erfolgen, da der Dovecotserver wissen muss, wo die Inhalte zu dem Benutzerkonto zu finden sind. \\ Ein userdb-lookup muss aber auch ausgeführt werden, wenn unser Dovecot-Server eine Nachricht, die er via **LMTP** empfängt, in das richtige Benutzerkonto mit der zugehörigen GID und UID abspeichern will. Ein weiterer Anwendungsfall ist das Thema //Shared Folders// /* link zum Kapitel shardfolders einfügen! */ FIXME. Hier muss der Dovecot-Server z.B. wo er die geteilten Mailkonto(teile) finden kann.+  * **userdb-lookup** : Bei einem userdb-lookup ermittelt unser Dovecot-Server die Umgebungsvariablen des genannten/benötigten Benutzerkontos. Im einfachsten Fall muss natürlich ein userdb-lookup nach einem erfolgreichen passdb-lookup erfolgen, da der Dovecotserver wissen muss, wo die Inhalte zu dem Benutzerkonto zu finden sind. \\ Ein userdb-lookup muss aber auch ausgeführt werden, wenn unser Dovecot-Server eine Nachricht, die er via **LMTP** empfängt, in das richtige Benutzerkonto mit der zugehörigen GID und UID abspeichern will. Ein weiterer Anwendungsfall ist das Thema [[centos:mail_c7:dovecot_7|Shared Folders und Shared Namespace]]. Hier muss der Dovecot-Server z.B. wo er die geteilten Mailkonto(teile) finden kann.
  
  
Zeile 278: Zeile 277:
 </code> </code>
  
 +=== dovecot-sql.conf.ext ===
 Bei der RPM-Installation unseres Dovecot-Servers, wurde im Verzeichnis //**/usr/share/doc/dovecot-2.2.13/example-config**// bereits eine Vorlagedatei für die nun folgende Konfiguration des SQL-Auth-Mechanismus angelegt. Diese Datei kopieren wir nun in das Dovecot-Konfigurationsverzeichnis //**/etc/dovecot**//. Bei der RPM-Installation unseres Dovecot-Servers, wurde im Verzeichnis //**/usr/share/doc/dovecot-2.2.13/example-config**// bereits eine Vorlagedatei für die nun folgende Konfiguration des SQL-Auth-Mechanismus angelegt. Diese Datei kopieren wir nun in das Dovecot-Konfigurationsverzeichnis //**/etc/dovecot**//.
-   # cp /usr/share/doc/dovecot-2.2.13/example-config/dovecot-sql.conf.ext /etc/dovecot/+   # cp /usr/share/doc/dovecot-2.2.*/example-config/dovecot-sql.conf.ext /etc/dovecot/
  
 Die wichtigsten Konfigurationsparameter in dieser Datei, die wir unseren Bedürfnissen nach anpassen müssen sind: Die wichtigsten Konfigurationsparameter in dieser Datei, die wir unseren Bedürfnissen nach anpassen müssen sind:
   * **driver** : Da wir eine mySQL-Datenbank verwenden, setzen wir den Parameter auf den Wert **mysql**.   * **driver** : Da wir eine mySQL-Datenbank verwenden, setzen wir den Parameter auf den Wert **mysql**.
 +  * **connect** : Hier wird der Datenbank-Connector beschrieben:
 +    * **//host//** Hostname oder IP-Adresse unsers mySQL-Datenbankservers
 +    * **//dbname//** Name der Datenbank
 +    * **//user//** Name unseres Datenbank-Nutzers
 +    * **//password//** Passwort des Dadenbannutzers
 +  * **default_pass_scheme** : 
 +    * **//PLAIN//** Speicherung des Passwortes in Klartext, um z.B. CRAM((**C**hallenge**R**esponse**A**uthentication**M**ethod)) nutzen zu können.
 +    * **//MD5-CRYPT//** Als mittlerweisen recht unsicher eingestufte MD5-Hashfunktion.
 +    * **//SHA256-CRYPT//** Ein als sicher geltende  kryptologischen Hashfunktionen.
 +    * **//SHA512-CRYPT//** Sehr sichere kryptologischen Hashfunktionen.
 +    * **//BLF-CRYPT//** Ein als sehr sicherer geltende Algorithmus Blowfish-Crypt.
 +  * **password_query** : SQL-Statement für den **//passwd-lookup//**
 +  * **user_query** : SQL_Statement für den **//userdb-lookup//**. Da wir für alle Postfächer die gleiche **UID** und **GID** verwenden wollen, geben wir diese beiden Werte **statisch** beim **//userdb-lookup//** vor!
  
-FIXME FIXME FIXME FIXME FIXME +In der Konfigurationsdatei //**/etc/dovecot/dovecot-sql.conf.ext**// definieren wir nun also die oben genannten Parameter für den Zugang beim mySQL-Datenbankserver wie auch die für SQL-Statements für die Abfragen.  
-===== Testen der Authentifizierung ===== +   # vim /etc/dovecot/dovecot-sql.conf.ext 
-Mit Hilfe des Befehls **doveadm** können wir sowohl den **//passdb-lookup//** wie auch den **//userdb-lookup//** testen.+<file bash /etc/dovecot/dovecot-sql.conf.ext># This file is opened as root, so it should be owned by root and mode 0600. 
 +
 +# http://wiki.dovecot.org/AuthDatabase/SQL 
 +
 +# For the sql passdb module, you'll need a database with a table that 
 +# contains fields for at least the username and password. If you want to 
 +# use the user@domain syntax, you might want to have a separate domain 
 +# field as well. 
 +
 +# If your users all have the same uig/gid, and have predictable home 
 +# directories, you can use the static userdb module to generate the home 
 +# dir based on the username and domain. In this case, you won't need fields 
 +# for home, uid, or gid in the database. 
 +
 +# If you prefer to use the sql userdb module, you'll want to add fields 
 +# for home, uid, and gid. Here is an example table: 
 +
 +# CREATE TABLE users ( 
 +#     username VARCHAR(128) NOT NULL, 
 +#     domain VARCHAR(128) NOT NULL, 
 +#     password VARCHAR(64) NOT NULL, 
 +#     home VARCHAR(255) NOT NULL, 
 +#     uid INTEGER NOT NULL, 
 +#     gid INTEGER NOT NULL, 
 +#     active CHAR(1) DEFAULT 'Y' NOT NULL 
 +# );
  
-Die Benutzereingaben sind in der Farbe <html><font style="colorrgb(00255)">blau</font></html> und die Rückmeldungen in der Farbe <html><font style="color: rgb(0, 255, 0)">grün</font></html> gekennzeichnet. +# Database drivermysqlpgsqlsqlite 
 +# Django : 2013-02-06 
 +# default: #driver  
 +driver = mysql
  
-Mit **//passdb-lookup//** können wir testen, ob unser Dovecot-Server das eingegebene Passwort beim genannten User erfolgreich überprüfen kann. +# Database connection string. This is driver-specific setting. 
-<html><pre class="code"> +
-<font style="colorrgb(00, 0)"></font><font style="color: rgb(0, 0, 255)">doveadm auth test django@nausch.org</font> +# HA round-robin load-balancing is supported by giving multiple host 
-</pre></html> +# settings, like: host=sql1.host.org host=sql2.host.org 
-<html><pre class="code"> +
-<font style="colorrgb(02550)">Password:</font><font style="color: rgb(00255)">Dj4n90_d3r_G33k!</font> +# pgsql: 
-<font style="colorrgb(02550)">passdbdjango@nausch.org auth succeeded +#   For available optionssee the PostgreSQL documention for the 
-extra fields+  PQconnectdb function of libpq. 
-  user=django@nausch.org</font></font> +#   Use maxconns=(default 5to change how many connections Dovecot can 
-</pre></html>+#   create to pgsql
 +# 
 +# mysql: 
 +#   Basic options emulate PostgreSQL option names: 
 +#     hostportuserpassworddbname 
 +
 +#   But also adds some new settings: 
 +#     client_flags        - See MySQL manual 
 +#     ssl_cassl_ca_path - Set either one or both to enable SSL 
 +#     ssl_certssl_key   - For sending client-side certificates to server 
 +#     ssl_cipher          - Set minimum allowed cipher security (defaultHIGH) 
 +#     option_file         - Read options from the given file instead of 
 +#                           the default my.cnf location 
 +#     option_group        - Read options from the given group (defaultclient) 
 +#  
 +#   You can connect to UNIX sockets by using host: host=/var/run/mysql.sock 
 +#   Note that currently you can't use spaces in parameters. 
 +
 +# sqlite: 
 +#   The path to the database file. 
 +
 +# Examples: 
 +#   connect = host=192.168.1.1 dbname=users 
 +#   connect = host=sql.example.com dbname=virtual user=virtual password=blarg 
 +#   connect = /etc/dovecot/authdb.sqlite 
 +
 +# Django : 2013-02-06 
 +# default: #connect = 
 +connect = host=mysql.dmz.nausch.org dbname=postfix user=dovecot_user password=GOMrG7l1bD74Ez81sUO
  
-Beim **//userdb-lookup//** ermittelt der Dovecot-Server die Umgebungsvariablen des genannten Benutzerkontos, also die die User-ID **$UID**, die Gruppen-ID **$GID** und **$HOME** als den Verzeichnispfad, an dem das Userkonto des Benutzers im Filespace unseres Servers zu finden ist+# Default password scheme
-<html><pre class="code"> +# 
-<font style="colorrgb(0, 0, 0)"># </font><font style="color: rgb(0, 0, 255)">doveadm user django@nausch.org</font> +# List of supported schemes is in 
-</pre></html> +# http://wiki.dovecot.org/Authentication/PasswordSchemes 
-<html><pre class="code"> +# 
-<font style="colorrgb(0, 255, 0)">field   value +# Django 2013-02-06 
-uid     10000 +# default: #default_pass_scheme = MD5 
-gid     10000 +default_pass_scheme = PLAIN
-home    /srv/vmail/nausch.org/django +
-mail</font></pre></html>+
  
-=== Speicherung von Passwörtern === +# passdb query to retrieve the password. It can return fields: 
-Bevor wir uns nun an die Konfiguration der SQL-Unterstützung an unserem Dovecot machen, wollen wir uns noch kurz überlegen, wie wir die Passworte in der Datenbank ablegenDie vermutlich vordergründigste, oft geübte und gängige Praxis ist wohl die Passworte nicht direkt in der Datenbank abzulegensondern gehashte Speicherungen vorzunehmenDie Passworte in der //**/etc/shadow**// ist eine gängige Variante dieses Vorgehends+#   password The user's passwordThis field must be returned. 
-   # grep django /etc/shadow+#   user - user@domain from the database. Needed with case-insensitive lookups. 
 +#   username and domain - An alternative way to represent the "user" field. 
 +
 +# The "user" field is often necessary with case-insensitive lookups to avoid 
 +# e.g. "name" and "nAme" logins creating two different mail directories. If 
 +# your user and domain names are in separate fieldsyou can return "username" 
 +# and "domain" fields instead of "user". 
 +
 +# The query can also return other fields which have a special meaning, see 
 +# http://wiki.dovecot.org/PasswordDatabase/ExtraFields 
 +
 +# Commonly used available substitutions (see http://wiki.dovecot.org/Variables 
 +# for full list): 
 +  %u = entire user@domain 
 +  %n = user part of user@domain 
 +#   %d = domain part of user@domain 
 +#  
 +# Note that these can be used only as input to SQL query. If the query outputs 
 +# any of these substitutions, they're not touched. Otherwise it would be 
 +# difficult to have eg. usernames containing '%' characters. 
 +
 +# Example: 
 +#   password_query = SELECT userid AS user, pw AS password \ 
 +#     FROM users WHERE userid = '%u' AND active = 'Y' 
 +
 +#password_query = \ 
 +#  SELECT username, domain, password \ 
 +#  FROM users WHERE username = '%n' AND domain = '%d' 
 +# Django : 2013-02-06 
 +# default: unset 
 +password_query = SELECT username AS user, password, 10000 AS userdb_uid, 10000 AS userdb_gid, \ 
 +  CONCAT('*:bytes=', quota) AS quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
  
-   django:$6$h6QWOPz5$053ur$Ch1kiS731nV0lLD3pPYQf1p0vk72XgPinPXjn32ZQmlTR0HRfB4aPelNJ1CFYF9pT3qt97bbSVUnxrB1:15187:0:99999:7:::+# userdb query to retrieve the user information. It can return fields: 
 +#   uid - System UID (overrides mail_uid setting) 
 +#   gid - System GID (overrides mail_gid setting) 
 +#   home - Home directory 
 +#   mail - Mail location (overrides mail_location setting) 
 +
 +# None of these are strictly required. If you use a single UID and GID, and 
 +# home or mail directory fits to a template string, you could use userdb static 
 +# instead. For a list of all fields that can be returned, see 
 +# http://wiki.dovecot.org/UserDatabase/ExtraFields 
 +
 +# Examples: 
 +#   user_query = SELECT home, uid, gid FROM users WHERE userid = '%u' 
 +#   user_query = SELECT dir AS home, user AS uid, group AS gid FROM users where userid = '%u' 
 +#   user_query = SELECT home, 501 AS uid, 501 AS gid FROM users WHERE userid = '%u' 
 +
 +#user_query = \ 
 +#  SELECT home, uid, gid \ 
 +#  FROM users WHERE username = '%n' AND domain = '%d' 
 +# Django 2013-02-06 
 +# defaultunset 
 +user_query = SELECT CONCAT('/var/spool/mail/vmail/', maildir) AS home, 10000 AS uid, 10000 AS gid, \ 
 +  CONCAT('*:bytes=', quota) AS quota_rule FROM mailbox WHERE username = '%u' AND active='1'
  
-Will nun der Server bei der Anmeldung überprüfen benötigt er was? Genau das Passwort in Klartext! denn Nur so ist er in der Lageden Passworthash des übermittelten Klartextpasswortes mit dem Hash in seiner Datenbank zu vergleichenIst nun jemand in der Lage die Übertragung zu kompromittieren, hält er unweigerlich die Anmeldedaten in HändenUnd wer will das? Keiner!+# If you wish to avoid two SQL lookups (passdb + userdb)you can use 
 +# userdb prefetch instead of userdb sql in dovecot.conf. In that case you'll 
 +# also have to return userdb fields in password_query prefixed with "userdb_" 
 +# stringFor example: 
 +#password_query = \ 
 +#  SELECT userid AS user, password, \ 
 +#    home AS userdb_home, uid AS userdb_uid, gid AS userdb_gid \ 
 +#  FROM users WHERE userid = '%u'
  
-Mit Hilfe von CRAM((**C**hallenge**R**esponse**A**uthentication**M**ethod)) haben wir nun ein Authentifizierungsverfahren an der Hand, mit der wir das Vorgenannte Problem mit der Übertragung eines Passwortes elegant umschiffenDenn beim Anmeldevorgang erzeugt der Server bei der Clientanfrage einen individuellen Sitzungsschlüssel, das //Challenge//, welches der Server zum Client überträgt. Client __und__ Server führen nun eine mathematische Operation mit dem nur ihnen bekannten Passwort durch. Das Rechenergebnis übermittelt der Client an den Server, der den empfangenen Wert mit seinem errechneten Ergebnis der zuvor angestellten Operation vergleicht. Stimmen die Ergebnisse überein, so kann der Server mit davon ausgehen, dass hat der Client das richtige Passwort kennt und verwendet! Ein Abhören der Leitung bringt nichts, da sich bei jeder Sitzung der Challenge-Wert ändert - ein abgefangenens Challenge ist für künftige Loginversuche daher völlig wertlos!+# Query to get a list of all usernames. 
 +#iterate_query = SELECT username AS user FROM users 
 +</file>
  
-<WRAP round important>Damit unser Server auch wirklich **sichere** Authentifizierungsmethoden anbieten kann, ist es notwendig die Passworte der Nutzer in der Datenbank in Klartext abzulegen.+Den notwendigen Datenbank-Systemuser legen wir nun noch auf unserem mySQL-Datenbankserver an.
  
-Nur so ist sichergestelltdass die Passworte nie über das Internet übertragen werden müssenDenn dort liegt das größte BedrohungspotentialUnser Postmaster und Netzwerkadministrator hat auch ohne Passwort jederzeit die Möglichkeit auf Daten der Nutzer zuzugreifen!</WRAP>+=== mySQL Datenbankuser anlegen === 
 +Wie bereits erwähnt, nutzen wir für die Verwaltung unserer Maildomänen und deren Nutzerkonten sowie Aliasen eine [[centos:mysql|mySQL-Datenbank]]. Was nun noch fehlt ist der notwendige Datenbanknutzermit dem wir die SQL-Anfragen von unserem Dovecot-Server aus abfragen könnenDiesen **Dovecot-Systemuser**, ein rein technische User, legen wir nun noch an, sofern dies nicht bereits bei der Installation von **[[https://dokuwiki.nausch.org/doku.php/centos:mail_c7:dovecot_6?&#auth-passwdfileconfext|postfixadmin]]** berücksichtigt wurde. 
 + 
 +Wir melden uns also als berechtigter Datenbankuser an der mySQL-Datenbank an. 
 +    # mysql -h localhost -u root -p 
 +<code>Enter password:  
 +Welcome to the MySQL monitor.  Commands end with ; or \g. 
 +Your MySQL connection id is 1942 
 +Server version: 5.1.67 Source distribution 
 + 
 +Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved. 
 + 
 +Oracle is a registered trademark of Oracle Corporation and/or its 
 +affiliates. Other names may be trademarks of their respective 
 +owners. 
 + 
 +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 
 + 
 +mysql> 
 +</code> 
 + 
 +Als erstes legen wir den Dovecot-Systemusers an. 
 +   mysql> CREATE USER 'dovecot_user'@'10.0.0.170' IDENTIFIED BY 'GOMrG7l1bD74Ez81sUO'; 
 + 
 +   Query OK, 0 rows affected (0.00 sec) 
 + 
 +   mysql> CREATE USER 'dovecot_user'@'imap.dmz.nausch.org 
 + 
 +   Query OK, 0 rows affected (0.00 sec) 
 + 
 +Dann setzen wir die Berechtigungen unseres neuen Datenbannutzers auf die Datenbank **postfix**. 
 +   mysql> GRANT ALL PRIVILEGES ON postfix.* TO 'dovecot_user'@'10.0.0.70' IDENTIFIED BY 'GOMrG7l1bD74Ez81sUO' WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0; 
 + 
 +   Query OK, 0 rows affected (0.00 sec) 
 + 
 +   mysql> GRANT ALL PRIVILEGES ON postfix.* TO 'dovecot_user'@'imap.dmz.nausch.org' IDENTIFIED BY 'GOMrG7l1bD74Ez81sUO' WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0; 
 + 
 +   Query OK, 0 rows affected (0.00 sec) 
 + 
 +Abschließend weisen wir noch die Berechtigungen zu. 
 +   mysql> FLUSH PRIVILEGES; 
 + 
 +   Query OK, 0 rows affected (0.00 sec) 
 + 
 +Zu guter Letzt melden wir uns wieder von unserem Datenbankhost ab. 
 +   mysqlquit 
 + 
 +   Bye
  
 === auth-sql.conf.ext === === auth-sql.conf.ext ===
Zeile 361: Zeile 537:
 </file> </file>
  
-=== 10-auth.conf ==+=== Speicherung von Passwörtern ==
 +Bevor wir uns nun an die Konfiguration der SQL-Unterstützung an unserem Dovecot machen, wollen wir uns noch kurz überlegen, wie wir die Passworte in der Datenbank ablegen. Die vermutlich vordergründigste, oft geübte und gängige Praxis ist wohl die Passworte nicht direkt in der Datenbank abzulegen, sondern gehashte Speicherungen vorzunehmen. Die Passworte in der //**/etc/shadow**// ist eine gängige Variante dieses Vorgehends. 
 +   # grep django /etc/shadow
  
 +   django:$6$h6QWOPz5$053ur$Ch1kiS731nV0lLD3pPYQf1p0vk72XgPinPXjn32ZQmlTR0HRfB4aPelNJ1CFYF9pT3qt97bbSVUnxrB1:15187:0:99999:7:::
 +
 +Will nun der Server bei der Anmeldung überprüfen benötigt er was? Genau das Passwort in Klartext! denn Nur so ist er in der Lage, den Passworthash des übermittelten Klartextpasswortes mit dem Hash in seiner Datenbank zu vergleichen. Ist nun jemand in der Lage die Übertragung zu kompromittieren, hält er unweigerlich die Anmeldedaten in Händen. Und wer will das? Keiner!
 +
 +Mit Hilfe von CRAM((**C**hallenge**R**esponse**A**uthentication**M**ethod)) haben wir nun ein Authentifizierungsverfahren an der Hand, mit der wir das Vorgenannte Problem mit der Übertragung eines Passwortes elegant umschiffen. Denn beim Anmeldevorgang erzeugt der Server bei der Clientanfrage einen individuellen Sitzungsschlüssel, das //Challenge//, welches der Server zum Client überträgt. Client __und__ Server führen nun eine mathematische Operation mit dem nur ihnen bekannten Passwort durch. Das Rechenergebnis übermittelt der Client an den Server, der den empfangenen Wert mit seinem errechneten Ergebnis der zuvor angestellten Operation vergleicht. Stimmen die Ergebnisse überein, so kann der Server mit davon ausgehen, dass hat der Client das richtige Passwort kennt und verwendet! Ein Abhören der Leitung bringt nichts, da sich bei jeder Sitzung der Challenge-Wert ändert - ein abgefangenens Challenge ist für künftige Loginversuche daher völlig wertlos!
 +
 +<WRAP round important>Damit unser Server auch wirklich **sichere** Authentifizierungsmethoden anbieten kann, ist es notwendig die Passworte der Nutzer in der Datenbank in Klartext abzulegen.
 +
 +Nur so ist sichergestellt, dass die Passworte nie über das Internet übertragen werden müssen. Denn dort liegt das größte Bedrohungspotential. Unser Postmaster und Netzwerkadministrator hat auch ohne Passwort jederzeit die Möglichkeit auf Daten der Nutzer zuzugreifen!</WRAP>
 +
 +=== 10-auth.conf ==
 Zur Aktivierung des Authentifizierungs-Mechanismus **SQL** müssen wir nun nur noch den richtigen **!include** in der Konfigurationsdatei //**/etc/dovecot/conf.d/10-auth.conf**// setzen. Zur Aktivierung des Authentifizierungs-Mechanismus **SQL** müssen wir nun nur noch den richtigen **!include** in der Konfigurationsdatei //**/etc/dovecot/conf.d/10-auth.conf**// setzen.
    # vim /etc/dovecot/conf.d/10-auth.conf    # vim /etc/dovecot/conf.d/10-auth.conf
-<file bash /etc/dovecot/conf.d/10-auth.conf>...+<code bash>...
  
 #!include auth-deny.conf.ext #!include auth-deny.conf.ext
 #!include auth-master.conf.ext #!include auth-master.conf.ext
  
-# Django : 2014-07-28+# Django : 2014-07-30
 # default: !include auth-system.conf.ext # default: !include auth-system.conf.ext
 # Umstellung auf den Authentifizierungs-Mechanismus SQL # Umstellung auf den Authentifizierungs-Mechanismus SQL
Zeile 380: Zeile 569:
 #!include auth-vpopmail.conf.ext #!include auth-vpopmail.conf.ext
 #!include auth-static.conf.ext #!include auth-static.conf.ext
-</file>+</code>
  
 Ferner definieren wir in der //**/etc/dovecot/conf.d/10-auth.conf**// noch welche Authentifizierungs-Mechanismen über die Option **auth_mechanisms** erlaubt sein sollen. Im Falle von **plain** **login** **digest-md5** **cram-md5** wäre das dann nachfolgender Code-Schnippsel Ferner definieren wir in der //**/etc/dovecot/conf.d/10-auth.conf**// noch welche Authentifizierungs-Mechanismen über die Option **auth_mechanisms** erlaubt sein sollen. Im Falle von **plain** **login** **digest-md5** **cram-md5** wäre das dann nachfolgender Code-Schnippsel
    # vim /etc/dovecot/conf.d/10-auth.conf    # vim /etc/dovecot/conf.d/10-auth.conf
-<file bash /etc/dovecot/conf.d/10-auth.conf>...+<code bash>...
  
 # Space separated list of wanted authentication mechanisms: # Space separated list of wanted authentication mechanisms:
Zeile 395: Zeile 584:
  
 ... ...
-</file>+</code>
  
 Somit ergibt sich folgende komplette Konfigurationsdatei  //**/etc/dovecot/conf.d/10-auth.conf**//. Somit ergibt sich folgende komplette Konfigurationsdatei  //**/etc/dovecot/conf.d/10-auth.conf**//.
Zeile 522: Zeile 711:
 #!include auth-master.conf.ext #!include auth-master.conf.ext
  
-# Django : 2014-07-28+# Django : 2014-07-30
 # default: !include auth-system.conf.ext # default: !include auth-system.conf.ext
 # Umstellung auf den Authentifizierungs-Mechanismus passwd-file # Umstellung auf den Authentifizierungs-Mechanismus passwd-file
 #!include auth-system.conf.ext #!include auth-system.conf.ext
-#!include auth-sql.conf.ext+!include auth-sql.conf.ext
 #!include auth-ldap.conf.ext #!include auth-ldap.conf.ext
-!include auth-passwdfile.conf.ext+#!include auth-passwdfile.conf.ext
 #!include auth-checkpassword.conf.ext #!include auth-checkpassword.conf.ext
 #!include auth-vpopmail.conf.ext #!include auth-vpopmail.conf.ext
 #!include auth-static.conf.ext #!include auth-static.conf.ext
 </file> </file>
- 
-=== dovecot-sql.conf.ext === 
-In der Konfigurationsdatei //**/etc/dovecot/dovecot-sql.conf.ext**// definieren wir nun die Zugangsdaten beim mySQL-Datenbankserver wie auch die für SQL-Statements für die Abfragen.  
-   # vim /etc/dovecot/dovecot-sql.conf.ext 
-<file bash /etc/dovecot/dovecot-sql.conf.ext># This file is opened as root, so it should be owned by root and mode 0600. 
-# 
-# http://wiki.dovecot.org/AuthDatabase/SQL 
-# 
-# For the sql passdb module, you'll need a database with a table that 
-# contains fields for at least the username and password. If you want to 
-# use the user@domain syntax, you might want to have a separate domain 
-# field as well. 
-# 
-# If your users all have the same uig/gid, and have predictable home 
-# directories, you can use the static userdb module to generate the home 
-# dir based on the username and domain. In this case, you won't need fields 
-# for home, uid, or gid in the database. 
-# 
-# If you prefer to use the sql userdb module, you'll want to add fields 
-# for home, uid, and gid. Here is an example table: 
-# 
-# CREATE TABLE users ( 
-#     username VARCHAR(128) NOT NULL, 
-#     domain VARCHAR(128) NOT NULL, 
-#     password VARCHAR(64) NOT NULL, 
-#     home VARCHAR(255) NOT NULL, 
-#     uid INTEGER NOT NULL, 
-#     gid INTEGER NOT NULL, 
-#     active CHAR(1) DEFAULT 'Y' NOT NULL 
-# ); 
- 
-# Database driver: mysql, pgsql, sqlite 
-# Django : 2013-02-06 
-# default: #driver =  
-driver = mysql 
- 
-# Database connection string. This is driver-specific setting. 
-# 
-# HA / round-robin load-balancing is supported by giving multiple host 
-# settings, like: host=sql1.host.org host=sql2.host.org 
-# 
-# pgsql: 
-#   For available options, see the PostgreSQL documention for the 
-#   PQconnectdb function of libpq. 
-#   Use maxconns=n (default 5) to change how many connections Dovecot can 
-#   create to pgsql. 
-# 
-# mysql: 
-#   Basic options emulate PostgreSQL option names: 
-#     host, port, user, password, dbname 
-# 
-#   But also adds some new settings: 
-#     client_flags        - See MySQL manual 
-#     ssl_ca, ssl_ca_path - Set either one or both to enable SSL 
-#     ssl_cert, ssl_key   - For sending client-side certificates to server 
-#     ssl_cipher          - Set minimum allowed cipher security (default: HIGH) 
-#     option_file         - Read options from the given file instead of 
-#                           the default my.cnf location 
-#     option_group        - Read options from the given group (default: client) 
- 
-#   You can connect to UNIX sockets by using host: host=/var/run/mysql.sock 
-#   Note that currently you can't use spaces in parameters. 
-# 
-# sqlite: 
-#   The path to the database file. 
-# 
-# Examples: 
-#   connect = host=192.168.1.1 dbname=users 
-#   connect = host=sql.example.com dbname=virtual user=virtual password=blarg 
-#   connect = /etc/dovecot/authdb.sqlite 
-# 
-# Django : 2013-02-06 
-# default: #connect = 
-connect = host=mysql.dmz.nausch.org dbname=postfix user=dovecot_user password=GOMrG7l1bD74Ez81sUO 
- 
-# Default password scheme. 
-# 
-# List of supported schemes is in 
-# http://wiki.dovecot.org/Authentication/PasswordSchemes 
-# 
-# Django : 2013-02-06 
-# default: #default_pass_scheme = MD5 
-default_pass_scheme = MD5-CRYPT 
- 
-# passdb query to retrieve the password. It can return fields: 
-#   password - The user's password. This field must be returned. 
-#   user - user@domain from the database. Needed with case-insensitive lookups. 
-#   username and domain - An alternative way to represent the "user" field. 
-# 
-# The "user" field is often necessary with case-insensitive lookups to avoid 
-# e.g. "name" and "nAme" logins creating two different mail directories. If 
-# your user and domain names are in separate fields, you can return "username" 
-# and "domain" fields instead of "user". 
-# 
-# The query can also return other fields which have a special meaning, see 
-# http://wiki.dovecot.org/PasswordDatabase/ExtraFields 
-# 
-# Commonly used available substitutions (see http://wiki.dovecot.org/Variables 
-# for full list): 
-#   %u = entire user@domain 
-#   %n = user part of user@domain 
-#   %d = domain part of user@domain 
- 
-# Note that these can be used only as input to SQL query. If the query outputs 
-# any of these substitutions, they're not touched. Otherwise it would be 
-# difficult to have eg. usernames containing '%' characters. 
-# 
-# Example: 
-#   password_query = SELECT userid AS user, pw AS password \ 
-#     FROM users WHERE userid = '%u' AND active = 'Y' 
-# 
-#password_query = \ 
-#  SELECT username, domain, password \ 
-#  FROM users WHERE username = '%n' AND domain = '%d' 
-# Django : 2013-02-06 
-# default: unset 
-password_query = SELECT username AS user, password FROM mailbox WHERE username = '%u' AND active = '1' 
- 
-# userdb query to retrieve the user information. It can return fields: 
-#   uid - System UID (overrides mail_uid setting) 
-#   gid - System GID (overrides mail_gid setting) 
-#   home - Home directory 
-#   mail - Mail location (overrides mail_location setting) 
-# 
-# None of these are strictly required. If you use a single UID and GID, and 
-# home or mail directory fits to a template string, you could use userdb static 
-# instead. For a list of all fields that can be returned, see 
-# http://wiki.dovecot.org/UserDatabase/ExtraFields 
-# 
-# Examples: 
-#   user_query = SELECT home, uid, gid FROM users WHERE userid = '%u' 
-#   user_query = SELECT dir AS home, user AS uid, group AS gid FROM users where userid = '%u' 
-#   user_query = SELECT home, 501 AS uid, 501 AS gid FROM users WHERE userid = '%u' 
-# 
-#user_query = \ 
-#  SELECT home, uid, gid \ 
-#  FROM users WHERE username = '%n' AND domain = '%d' 
-# Django : 2013-02-06 
-# default: unset 
-user_query = SELECT CONCAT('/var/spool/mail/vmail/', maildir) AS home, 97 AS uid, 12 AS gid, \ 
-  CONCAT('*:bytes=', quota) AS quota_rule FROM mailbox WHERE username = '%u' AND active='1' 
- 
-# If you wish to avoid two SQL lookups (passdb + userdb), you can use 
-# userdb prefetch instead of userdb sql in dovecot.conf. In that case you'll 
-# also have to return userdb fields in password_query prefixed with "userdb_" 
-# string. For example: 
-#password_query = \ 
-#  SELECT userid AS user, password, \ 
-#    home AS userdb_home, uid AS userdb_uid, gid AS userdb_gid \ 
-#  FROM users WHERE userid = '%u' 
- 
-# Query to get a list of all usernames. 
-#iterate_query = SELECT username AS user FROM users 
-</file> 
- 
-Den notwendigen Datenbank-Systemuser legen wir nun noch auf unserem mySQL-Datenbankserver an. 
-=== mySQL Datenbankuser anlegen === 
-Wie Eingangs erwähnt, nutzen wir für die Verwaltung unserer Maildomänen und deren Nutzerkonten sowie Aliasen eine [[centos:mysql|mySQL-Datenbank]]. Was nun noch fehlt ist der notwendige Datenbanknutzer, mit dem wir die SQL-Anfragen von unserem Dovecot-Server aus abfragen können. Diesen **Dovecot-Systemuser**, ein rein technische User, legen wir nun noch an, sofern dies nicht bereits bei der Installation von **[[https://dokuwiki.nausch.org/doku.php/centos:mail_c7:dovecot_6?&#auth-passwdfileconfext|postfixadmin]]** berücksichtigt wurde. 
- 
- 
-Wir melden uns also als berechtigter Datenbankuser an der mySQL-Datenbank an. 
-    # mysql -h localhost -u root -p 
-<code>Enter password:  
-Welcome to the MySQL monitor.  Commands end with ; or \g. 
-Your MySQL connection id is 1942 
-Server version: 5.1.67 Source distribution 
- 
-Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved. 
- 
-Oracle is a registered trademark of Oracle Corporation and/or its 
-affiliates. Other names may be trademarks of their respective 
-owners. 
- 
-Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 
- 
-mysql> 
-</code> 
- 
-Als erstes legen wir den Dovecot-Systemusers an. 
-   mysql> CREATE USER 'dovecot_user'@'10.0.0.170' IDENTIFIED BY 'GOMrG7l1bD74Ez81sUO'; 
- 
-   Query OK, 0 rows affected (0.00 sec) 
- 
-   mysql> CREATE USER 'dovecot_user'@'imap.dmz.nausch.org 
- 
-   Query OK, 0 rows affected (0.00 sec) 
- 
-Dann setzen wir die Berechtigungen unseres neuen Datenbannutzers auf die Datenbank **postfix**. 
-   mysql> GRANT ALL PRIVILEGES ON postfix.* TO 'dovecot_user'@'10.0.0.70' IDENTIFIED BY 'GOMrG7l1bD74Ez81sUO' WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0; 
- 
-   Query OK, 0 rows affected (0.00 sec) 
- 
-   mysql> GRANT ALL PRIVILEGES ON postfix.* TO 'dovecot_user'@'imap.dmz.nausch.org' IDENTIFIED BY 'GOMrG7l1bD74Ez81sUO' WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0; 
- 
-   Query OK, 0 rows affected (0.00 sec) 
- 
-Abschließend weisen wir noch die Berechtigungen zu. 
-   mysql> FLUSH PRIVILEGES; 
- 
-   Query OK, 0 rows affected (0.00 sec) 
- 
-Zu guter Letzt melden wir uns wieder von unserem Datenbankhost ab. 
-   mysql> quit 
- 
-   Bye 
  
  
 +===== Testen der Authentifizierung =====
 +Mit Hilfe des Befehls **doveadm** können wir sowohl den **//passdb-lookup//** wie auch den **//userdb-lookup//** testen.
  
 +Die Benutzereingaben sind in der Farbe <html><font style="color: rgb(0, 0, 255)">blau</font></html> und die Rückmeldungen in der Farbe <html><font style="color: rgb(0, 255, 0)">grün</font></html> gekennzeichnet. 
  
 +Mit **//passdb-lookup//** können wir testen, ob unser Dovecot-Server das eingegebene Passwort beim genannten User erfolgreich überprüfen kann.
 +<html><pre class="code">
 +<font style="color: rgb(0, 0, 0)"># </font><font style="color: rgb(0, 0, 255)">doveadm auth test django@nausch.org</font>
 +</pre></html>
 +<html><pre class="code">
 +<font style="color: rgb(0, 255, 0)">Password:</font><font style="color: rgb(0, 0, 255)">Dj4n90_d3r_G33k!</font>
 +<font style="color: rgb(0, 255, 0)">passdb: django@nausch.org auth succeeded
 +extra fields:
 +  user=django@nausch.org</font></font>
 +</pre></html>
  
 +Beim **//userdb-lookup//** ermittelt der Dovecot-Server die Umgebungsvariablen des genannten Benutzerkontos, also die die User-ID **$UID**, die Gruppen-ID **$GID** und **$HOME** als den Verzeichnispfad, an dem das Userkonto des Benutzers im Filespace unseres Servers zu finden ist.
 +<html><pre class="code">
 +<font style="color: rgb(0, 0, 0)"># </font><font style="color: rgb(0, 0, 255)">doveadm user django@nausch.org</font>
 +</pre></html>
 +<html><pre class="code">
 +<font style="color: rgb(0, 255, 0)">field   value
 +uid     10000
 +gid     10000
 +home    /srv/vmail/nausch.org/django
 +mail</font></pre></html>
  
  
  
 +Haben wir die Benutzerauthentifizierung erfolgreich abgeschlossen, vervollständigen wir die Grundkonfiguration unseres Dovecot-Servers mit der Definition von **[[centos:mail_c7:dovecot_1?&#mailbox_location_vmail-directory|Mailbox Location und vmail-Directory]]**.
  
 ====== Links ====== ====== Links ======
Zeile 751: Zeile 759:
   * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**   * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**   * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
- 
-~~DISCUSSION~~ 
  
  
  • centos/mail_c7/dovecot_6.1406752687.txt.gz
  • Zuletzt geändert: 30.07.2014 20:38.
  • von django