Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente | |||
mails:sasl:mta-serveur [2018/11/26 14:58] – [Les binds LDAP] cdrom1 | mails:sasl:mta-serveur [2018/12/17 09:55] (Version actuelle) – supprimée cdrom1 | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== SASL pour l' | ||
- | Le MTA est postfix, ce service est accessible via le protocole SMTP. | ||
- | Certaines de ses fonctions comme la transmission de mails de l' | ||
- | Cependant, d' | ||
- | Il faut remarquer que la couche de sécurité qu'on va décrire dans cette page ne fait qu' | ||
- | * On peut mettre en place des logs permettant de voir qui a utilisé quelle adresse | ||
- | * Picasoft est une petite association donc on peut se faire confiance. | ||
- | A titre indicatif, la même politique est en vigueur à l'UTC: une fois qu'on a utilisé son login pour se connecter au serveur SMTP, on peut demander à ce dernier d' | ||
- | |||
- | Cette couche de sécurité sera appelée SASL serveur, puisqu' | ||
- | |||
- | Nous utilisons Postfix installé sous debian avec la bibliothèque saslauthd (Cyrus). A chaque fois qu'un démon postfix (smtp pour nous) a besoin de vérifier un couple (login;mot de passe), il utilise un socket pour les cpmmuniquer à un démon saslauthd. Ce démon effectue un certain nombre d' | ||
- | |||
- | Dans notre cas, on a connecté saslauthd au serveur LDAP de Picasoft. A la place de saslauthd, on aurait pu utiliser ldapdb, mais cette bibliothèque garde un cache des hashs de mot de passe, ce qui est contraire à la politique de sécurité en vigueur. D' | ||
- | |||
- | Ils ont tous des avantages respectifs: | ||
- | * Une auth PAM permet de contrôler localement des utilisateurs, | ||
- | * Une auth IMAP permet de rendre l' | ||
- | * Une auth LDAP permet de contrôler finement qui a accès à quoi, cependant l' | ||
- | |||
- | Pour le moment, nous avons opté pour une auth LDAP, mais pour ne pas se fermer des portes ou faciliter le debug, nous avons également mis en place des auth PAM et IMAP qu'on peut tester avec sasl-test en spécifiant en argument le paramètre ldap, pam ou imap. | ||
- | |||
- | ===== Les fichiers de config de saslauthd ===== | ||
- | Le remplissage des fichiers de config est automatisé avec les dockerfiles, | ||
- | |||
- | Sous debian, le fichier de config saslauthd pour postfix est dans < | ||
- | |||
- | On indique dans le main de Postfix un lien vers ce fichier de config de Cyrus: | ||
- | < | ||
- | #/ | ||
- | smtpd_sasl_path = smtpd | ||
- | </ | ||
- | Il est important que smtpd porte le même nom que le fichier de config Cyrus (sans le .conf). | ||
- | |||
- | ===== Le démon saslauthd ===== | ||
- | Ce démon crée un socket UNIX et attend qu'on lui demande de valider des authentifications. La config par défaut de saslauthd veut que ce démon soit dans : | ||
- | < | ||
- | Cependant, Postfix est // | ||
- | Debian recommande de créer des processus saslauthd séparés et spécifiques (nous en créons donc un pour postfix). Pour plus de détails, [[https:// | ||
- | Le socket de saslauthd-post sera finalement dans < | ||
- | |||
- | Pour donner à Postfix l' | ||
- | < | ||
- | pwcheck_method: | ||
- | mech_list: PLAIN LOGIN | ||
- | </ | ||
- | On voit que le login est transmis en PLAIN, c'est dû au protocole SMTP. Il faut rajouter une couche de chiffrement pour que ce soit sécurisé. Sur une prod, il faut interdire l'auth PLAIN sur du SMTP non sécurisé. (En revanche, une connexion sans authentification peut se faire en SMTP non sécurisé (typiquement pour de la réception de mails du reste du monde)). | ||
- | ==== Le processus saslauthd-postf ==== | ||
- | On crée un processus saslauthd spécifique qui ne sera accessible qu'à Postfix. | ||
- | Pour cela, on copie le processus par défaut et on l' | ||
- | < | ||
- | < | ||
- | DESC=" | ||
- | NAME=" | ||
- | # Option -m sets working dir for saslauthd (contains socket) | ||
- | OPTIONS=" | ||
- | (repris du [[https:// | ||
- | Il faut faire d' | ||
- | === PAM === | ||
- | Rien de plus simple, la config par défaut de saslauthd sous debian le fait. Il suffit d'un: | ||
- | < | ||
- | MECHANISMS=" | ||
- | </ | ||
- | Éventuellement, | ||
- | === LDAP === | ||
- | < | ||
- | MECHANISMS=" | ||
- | </ | ||
- | Il faut également modifier / | ||
- | < | ||
- | ldap_servers: | ||
- | ldap_search_base: | ||
- | ldap_filter: | ||
- | etc... | ||
- | </ | ||
- | Pour la configuration du bind LDAP, voir plus bas. | ||
- | === IMAP === | ||
- | < | ||
- | MECHANISMS=" | ||
- | MECH_OPTIONS=" | ||
- | </ | ||
- | Le nom d' | ||
- | saslauthd tentera de faire un AUTH IMAP standard, et dès qu'il a une réponse il se déconnecte. | ||
- | ===== Les binds LDAP ===== | ||
- | Si on choisit la solution LDAP, il faut configurer des binds au niveau du serveur. Ces binds sont préalables au challenge SASL: d' | ||
- | Cette configuration se fait dans / | ||
- | < | ||
- | ldap_servers: | ||
- | ldap_bind_dn: | ||
- | ldap_bind_pw: | ||
- | ldap_search_base: | ||
- | ldap_filter: | ||
- | </ | ||
- | * ldap_servers : On peut en mettre plusieurs, séparés par des virgules. Le SSL est supporté, il faut rajouter des paramètres pointant vers les certificats (voir la doc complète, la référence est ci-dessous). | ||
- | * ldap_bind_dn et ldap_bind_pw: | ||
- | * ldap_search_base: | ||
- | * ldap_filter: | ||
- | La doc de ce fichier de config se trouve dans / | ||