Version du 20 octobre 2021 à 15:23

Présentation générale

• Nom du projet : SEMail: Système de messagerie global mais individualisé
• Réalisé par : Souleymane SOW
• Superviseur du projet : Xavier REDON
• Durée : 06 SEP 2021 - 24 JAN 2022

Objectif

L’objectif du projet sera de mettre en place un système de messagerie qui va gérer plusieurs utilisateurs et une boîte à lettres par utilisateur. Le système devra permettre à chaque utilisateur d’avoir un contrôle important sur sa messagerie grâce à un système de conteneur par utilisateur. Afin d’éviter des failles de sécurité, la solution à mettre en place devra assurer un contrôle facile sur ses différentes composantes et cela grâce à sa simplicité.

Description

Au niveau global, le système de messagerie se compose des éléments suivants :

• une machine virtuelle qui va contenir le système de messagerie ;

• un serveur DNS permettra de gérer les enregistrements MX liés aux adresses de courriels ;

• un serveur Web permettra de créer de nouvelles boites pour chaque utilisateur et d’en supprimer ;

• un serveur SMTP accessible d’Internet permet de stocker les messages reçus par les utilisateurs locaux dans les systèmes de fichiers liés aux utilisateurs ;

• un serveur SMTP accessible uniquement de la machine virtuelle permet d’envoyer les courriels vers Internet ;

• pour chaque utilisateur un conteneur Docker sera créé.

"Architecture global du système de messagerie"

Au niveau individuel, chaque conteneur permet :

• un accès en lecture et écriture au système de fichiers dans lequel sont stockés les courriels pour cet utilisateur par le serveur SMTP entrant Storage;

• un accès SSH dans le conteneur en utilisant un rebond par la machine virtuelle VM SEMail ;

• un accès réseau au serveur SMTP sortant SendMail permettant d’envoyer des courriels ;

• la possibilité d’installer des logiciels comme des lecteurs de messagerie suivant le choix de l’utilisateur.

Dans un but de prévenir les failles, les deux serveurs SMTP sont écrits à partir de zéro en respectant les consignes suivantes :

• Respect de la RFC 5321 mais avec des simplifications (pas d’implantation des commandes VRFY et EXPN, pas de routage et avec un système optionnel de gestion des messages non transmis avec succès) ;

• écriture en langage C avec la bibliothèque des sockets ;

• utilisation de bibliothèques dynamiques pour la gestion des connexions, une méthode pour la connexion sans chiffrement (ports 25 et 587) et une méthode pour la connexion avec chiffrement (port 465), ne pas implanter la commande STARTTLS ;

• chaque connexion est gérée par un processus léger (Threads) ;

• utilisation de bibliothèques dynamiques pour la gestion des commandes SMTP, chaque commande est gérée par une fonction à laquelle est passée une structure représentant l’état du dialogue entre le client et le serveur ;

• prévoir un système optionnel pour le serveur SMTP sortant permettant de mettre en file d’attente les messages non remis à destination pour cause d’erreur transitoire du serveur SMTP cible ;

• gérer les enregistrements MX ainsi qu’IPv4 et IPv6 pour contacter les serveurs SMTP cibles ;

• les deux types de serveurs SMTP ne diffèrent que par la méthode de distribution finale (stockage dans un système de fichiers ou envoi à un serveur SMTP cible) ;

Le stockage des courriels doit se faire ainsi que décrit ci-dessous :

• le format de stockage doit être le format « mbox » ;

• chaque message entrant est ajouté au dossier de réception INBOX mais aussi à un dossier dont le nom est constitué de l’adresse de destination de l’enveloppe et de l’adresse source de l’enveloppe ;

• les courriels sont stockés dans un système de fichiers propre à l’utilisateur destination, ces systèmes de fichiers peuvent être implantés via des fichiers images ou via LVM ;

• les systèmes de fichiers contenant les courriels sont montés dans les conteneurs ad hoc.

Lors de la création d’une boîte aux lettres, les éléments suivants sont mis en place :

• précisons que l’utilisateur doit être identifié pour avoir le droit de créer son unique boîte aux lettres, cela se fera par un serveur LDAP, par défaut le serveur LDAP de la machine virtuelle est utilisé mais il doit être possible d’en utiliser un autre sur Internet ;

• soit l’utilisateur précise un nom de domaine externe pour son adresse de courriel auquel cas il doit insérer l’enregistrement MX lui même, soit il choisit un sous-domaine libre du domaine géré par le système, auquel cas le champ MX est ajouté automatiquement ;

• c’est l’utilisateur qui précise un identifiant pour son adresse de courriel qui vient compléter l’adresse Internet, le serveur SMTP entrant ne laissera passer que les courriels à destination de « id@domaine » ;

• le système de fichiers de stockage des courriels est créé avec une taille par défaut spécifié par l’administrateur et automatiquement formaté et peuplé ;

• le conteneur lié à l’adresse de courriel est créé automatiquement et lancé en mode persistant.

Un client de messagerie de type SquirrelMail est installé sur la machine virtuelle et permet aux utilisateurs qui ne veulent pas se compliquer la vie avec leur conteneur de gérer leur boîte aux lettres.

Préparation du projet

Cahier des charges

CahierDesChargesSEMail.pdf

Cahier des Spécifications

CahierDesSpecifications.pdf

Choix techniques : matériel et logiciel

Liste des tâches à effectuer

• Installation de la machine virtuelle de type Xen: Système d’exploitation Debian ou Devuan et SqWebmail comme système de messagerie

• Mis en place du serveur LDAP: Installation et remplissage de l’annuaire qui va contenir les utilisateurs de la messagerie

• Mis en place du serveur Web: Authentification des utilisateurs pour leur permettre de créer une nouvelle boîte unique et leur attribuer un conteneur de type Docker

• Programmation des 2 serveurs SMTP: Réalisé en langage C et avec la bibliothèque des sockets

• Configuration du serveur DNS: On utilisera le serveur DNS du réseau 172.26.145.0 de la salle informatique

• Tests: Après chaque tâche effectuée, des tests seront réalisés à la fin pour pouvoir être validés et passés à la tâche suivante

Calendrier prévisionnel

"Planning du projet"

Réalisation du Projet

Semaine 1

Systéme de messagerie

Un système de messagerie électronique est l'ensemble des éléments contribuant à transmettre un courriel de l'émetteur au récepteur. Il y a quatre éléments fondamentaux. Ce sont:
• le Mail Transfert Agent ou MTA
• le serveur du protocole entrant
• le Mail Delivery Agent ou MDA
• le Mail User Agent ou MUA
Les différents éléments du système de messagerie sont agencés selon une architecture logique, pour en assurer le fonctionnement. Nous représentons cette architecture par le schéma suivant:

"Architecture d'un systéme de messagerie"

Ce schéma présente le transfert d'un courriel d'un expéditeur à un destinataire.
1 - L'expéditeur communique son courriel via le MUA.
2 - Le MUA transmet ce courriel au MTA (la plupart des MUA intègre des clients SMTP).
3 et 4- Le MTA du système de l'émetteur établit un canal de transmission avec le MTA du système du destinataire, par émissions successives de requêtes bidirectionnelles .
5 - Une fois le canal établit, le courriel est transmis d'un système à un autre par les MTA.
6 - Dans le système du destinataire, Le MTA transmet le courrier reçu au serveur IMAP ou POP3.
7, 8 et 9 - Le MDA récupère le courriel du serveur IMAP / POP 3, et le met à disposition du MDA.
10 - Le MDA dépose le courriel dans la boîtes aux lettres du destinataire qui pourra le consulter à tout moment, sur authentification.

• Mail Transfert Agent ou MTA

C'est un agent qui permet d'acheminer le courriel d'un serveur à un autre. Le MTA de l'émetteur route le mail sur le MTA du récepteur. Il implémente un protocole sortant. Notons que les protocoles sortants permettent de gérer la transmission du courrier entre les systèmes de messagerie. Le protocole sortant généralement utilisé est le Simple Mail Transfert Protocol ou SMTP .
SMTP peut être traduit comme protocole simple de transfert de courriel . Il est de la famille des protocoles basés sur TCP/IP. Il utilise généralement le port 25. Le mécanisme de fonctionnement de SMTP est qu'il commence d'abord par vérifier l'existence de l'expéditeur et du ou des destinataire (s), indiqués dans l'entête du message, puis il transmet le contenu. La transmission s'effectue sur un canal de communication établi entre l'émetteur et le destinataire par émission bidirectionnelle de requêtes basées sur des commandes. Il existe plusieurs serveurs MTA qui implémentent SMTP. Parmi les plus connus, il y a Postfix, Exim, Qmail et Sendmail.
Dans le cas de notre projet, on aura à coder en partant de zéro notre MTA qui sera un serveur SMTP en langage C en utilisant la bibliothéque des sockets.

• Serveur du protocole entrant
  

Les protocoles entrants permettent la réception et la distribution du courriel. Les plus généralement utilisés sont : Post Office Protocol version 3 (POP3) et Internet Message Access Protocol (IMAP), qui sont tous deux basées sur TCP/IP . Dans son fonctionnement, POP3 va récupérer le courriel sur un serveur de messagerie.IMAP est une version améliorée de POP3.
Dans le cas de notre projet, notre serveur de protocole entrant sera un serveur SMTP qui va stocker les messages reçus au dossier de réception Maildir qui sera propre à chaque utilisateur.

• Mail Delivery Agent ou MDA
  

Il s'agit d'un agent qui est en charge de la gestion des boîtes aux lettres . Il est chargé de livrer le courriel dans la boîte à messages du destinataire. Pour cela, il est souvent considéré comme le point final d'un système de messagerie . Dans le MDA , on peut filtrer les courriels; et même supprimer les spams par des anti-spams (comme spamassassin) et contrôler les virus par des antivirus. Il existe plusieurs serveurs MDA, les plus courants sont procmail, maildrop et cyrus.
Ici notre serveur SMTP de réception va jouer le role du MDA

• Mail User Agent ou MUA
  

Le MUA est un logiciel client de messagerie qui fournit un environnement pour la gestion du courriel (envoi, saisie, réception, suppression, etc.). Il est très proche du MDA. Tout comme les autres agents, il existe également plusieurs MUA . Un MUA avec une interface Web, est appelé Webmail.
On utilisera SqWebmail pour la gestion de courriels par les utilsateurs.

Installation de la machine virtuelle avec Xen

• Xen c'est quoi?
  

Xen est un logiciel de (para)virtualisation de type hyperviseur. Il permet donc de faire tourner plusieurs systèmes d'exploitation (OS) sur une même ressource matérielle (PC, Serveur,…). Xen permet de faire fonctionner plusieurs systèmes d'exploitation virtuels (invités) sur une seule machine hôte. Les choses ont beaucoup changé puisque le kernel Linux, à partir de la version 3, intègre nativement Xen. Le principe de l'hyperviseur est de faire tourner les OS dans le noyau (kernel) même, et non-pas de les émuler, ce qui permet de conserver des performances proches des natives.

• Installation du paquet

On vérifie si les paquets Xen-Hypervisor et Xen-tools(Gestion des machines virtuelles) sont déja installés ou pas:

  sudo apt -qq list xen-hypervisor-4.11-amd64
  sudo apt -qq list xen-tools

"Vérification de l'installation de l'hyperviseur Xen sur la machine"

On voit que nos packets ne sont pas encore installés donc on les installe avec la commande:

  apt-get install xen-hypervisor-4.11-amd64 xen-tools

Pour configurer xen-tools, on édite /etc/xen-tools/xen-tools.conf qui contient les valeurs par défaut que le script xen-create-image utilisera. Pour donner un chemin différent où les images domU sont enregistrées et activer le mot de passe superutilisateur dans la construction initiale, nous allons éditer le fichier /etc/xen-tools/xen-tools.conf et décommenter ces lignes :

 dir=/home/xen
 passwd = 1

Ensuite, on peut créer notre machines virtuelle avec la commande :

  xen-create-image --hostname Webmail --bridge bridge --ip 172.26.145.230 --vcpus 2 --pygrub --dist buster

On a utilisé le bridge déja existant sur la machine hote pour l'accés réseau de notre machine virtuelle et on lui attribue une adresse ip appartenant au réseau de l'hote. Pour démarrer la VM créée, on exécute la commande :

  xl create /etc/xen/Webmail.cfg

Pour se connecter sur la console de notre vm on lance la commande:

  xen console Webmail

"Console de notre machine virtuelle créée"

Configuration de la machine virtuelle

Pour avoir accés aux autres réseaux on rajoute une route par défaut pour notre machine virtuelle:

   ip route add default via 172.26.145.254

Ensuite on fait une mis à jour de notre systéme:

    apt-get update && apt-get upgrade

Installation de l'annuaire LDAP

LDAP signifie Lightweight Directory Access Protocol. C’est le standard de fait pour accéder à un annuaire. Un annuaire est une base de données qui va contenir des informations sur des personnes, des machines, des groupes ou toute autre catégorie. Un annuaire se distingue d’une base de données relationnelle par le fait qu’il a une structure hiérarchique et qu’il est très rapide pour chercher et lire des éléments mais plus lent pour les modifier. Les annuaires sont couramment employés pour stocker les données d’authentification (login et mot de passe) ou pour obtenir des informations sur des personnes (email, téléphone, etc.) ou des objets (localisation, marque, modèle, etc.). Toutes les applications de votre entreprise (site web, e-mail, comptes système des ordinateurs, etc.) peuvent par exemple utiliser ce service d’annuaire pour valider les identifiants de connexion.

• Comment ça fonctionne?

Tout d’abord, un annuaire LDAP est une organisation hiérarchique d’entrées. Cette organisation constitue un arbre appelé DIT (Directory Information Tree) dont une des entrées est la racine.

"Structure d'un annuaire LDAP"

Chaque entrée peut contenir des attributs auxquels on assigne des valeurs. Chaque entrée appartient au moins à une classe d’objet qui définit les attributs de l’entrée. Par exemple, la classe d’objet “Employés” pourrait définir qu’un “élément” appartenant à cette classe doit contenir les attributs obligatoires :
• nom de famille
• prénom
et peut contenir les attributs facultatifs :
• e-mail
• téléphone
• date de naissance
Chacun des attributs de cet élément aura une valeur. Par exemple, “nom de famille=Dupond”. De nombreux attributs et classes d’objets sont prédéfinis mais il est possible de définir les nôtres si besoin. L’ensemble des classes d’objets et attributs utilisés est défini dans le schéma. Certains attributs sont particulièrement courants et intéressants à connaître :

"Attributs et classes d'objets d'un annuaire LDAP"

Un attribut particulier est le dn (distinguished name), c’est à dire le nom distinct. C’est un attribut qui identifie de manière unique un élément dans le DIT. Il reprend les noms de tous les éléments depuis la racine jusqu’à l’élément et indique ainsi un “chemin” unique pour trouver l’élément.
Par exemple, le dn de “Marie Dupond” qui travaille chez “mon-entreprise.com” pourrait être “cn=Marie Dupond,ou=Personnes,dc=mon-entreprise,dc=com”. On appelle RDN, pour Relative Distinguished Name, la partie “finale” propre à Marie. Ici le RDN serait “cn=Marie Dupon”. Lui, ne garantit pas l'unicité dans le DIT.

• Installation OpenLDAP:

OpenLDAP est un des annuaires les plus répandus. Pour l’installer, on doit installer le paquet slapd . Installez également le paquet ldap-utils qui contient les utilitaires clients pour pouvoir interroger ou modifier notre annuaire.

   sudo apt-get install slapd ldap-utils

Nous allons maintenant utiliser l’outil de configuration debconf de Debian pour définir la configuration de base de notre annuaire :

   dpkg-reconfigure slapd

Nous allons indiqué :
• No pour la première question afin de pouvoir utiliser l’outil de configuration
• pour nom DNS : semail.com
• pour nom d’organisation : semail
• le mot de passe administrateur x2
• No pour savoir si la base doit être supprimée quand slapd est purgé
• Yes pour déplacer l’ancienne base de données
Comme notre DNS est semail.com, la racine de notre DIT a été configurée à “dc=semail,dc=com”, nous pouvons utiliser la commande ldapsearch suivante pour visualiser notre DIT :

   ldapsearch -Q -L -Y EXTERNAL -H ldapi:/// -b dc=semail,dc=com

"DIT de notre annuaire"

La commande ldapsearch sert, comme son nom l’indique à chercher dans un annuaire LDAP. Voici le détail des options utilisées :
-Q active le mode silencieux pour l’authentification SASL
-Y indique le mode SASL choisi pour l’authentification. Normalement, EXTERNAL implique une authentification par certificat client mais dans ce cas là ça signifie que l’authentification se fera par l’UID et le GID du compte système. C’est pour ça que nous devons lancer la commande avec “sudo”. L’utilisateur root a des passe-droits pour accéder à la base locale LDAP
-L indique d’afficher le résultat au format LDIF. On aurait pu indiquer -LLL pour avoir la même chose sans toutes les lignes commentées.
-H indique l’URI qu’on veut utiliser pour se connecter. Ici ldapi:/// dit de se connecter à la socket Unix en local (la communication passe par un fichier local plutôt que par le réseau).
-b indique le nœud à partir duquel on veut faire notre recherche. Ici dc=semail,dc=com est la racine donc nous recherchons dans tout le DIT. À la suite du nœud, on aurait pu indiquer des filtres pour notre recherche mais sans filtre on a l’affichage le plus complet.

• Format LDIF:

LDIF signifie “LDAP Directory Interchange Format”. C’est un format créé pour décrire les ajouts ou les modifications à réaliser dans un annuaire LDAP. Le format d’une entrée dans un fichier LDIF est toujours de la forme suivante :

"Format d'une entrée dans un fichier LDIF"

Dans la sortie de la commande précédente, on voit que notre DIT contient en tout et pour tout 2 entrées :
La première est la racine. On la reconnaît au fait qu’elle appartient à la classe d’objet dcObject. On voit qu’elle appartient aussi à 2 autres classes d'objets. Chacune décrit une série d’attributs que l’entrée peut ou doit contenir. On a ensuite deux attributs : o et dc , deux types que nous connaissons déjà.
La deuxième est le compte administrateur LDAP, comme l’indique l’attribut description . Il appartient notamment à la classe d’objet simpleSecurityObject qui représente les comptes d’authentification.

Gestion de l'annuaire LDAP

Notre annuaire contient un deuxième DIT! En effet, dans les anciennes versions de slapd, la configuration se faisait en modifiant des fichiers dans /etc/ldap/ et imposait de redémarrer le serveur pour être prises en compte. Cette méthode est toujours possible mais il est maintenant recommandé d’utiliser la nouvelle méthode dite de “configuration à chaud” (en anglais OLC pour On-Line Configuration) qui permet de ne pas avoir à redémarrer le serveur pour actualiser.

• OLC

    ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

"Entrées de l'arbre"

Cette configuration contient donc des informations sur les modules, le schéma, les classes d’objets intégrées par défaut. La configuration propre à notre DIT dc=semail,dc=com se trouve dans olcDatabase={1}mdb,cn=config
Comme cette configuration est stockée sous forme de DIT, on peut la modifier au moyen de fichiers LDIF. Pour tester ça, on va modifier la quantité de logs générée par slapd. Par défaut, slapd ne génère aucun log et nous aimerions peut-être avoir plus d’informations sur l’activité de notre serveur. L’attribut qui gère ça est directement un attribut de cn=config appelé olcLogLevel

"olcLogLevel désactivé"

Ici j’ai rajouté l’option -s base pour indiquer le scope , c'est-à-dire l’étendue de la recherche. base effectue la recherche uniquement au niveau du DN indiqué alors que par défaut le scope est subtree pour rechercher sur toutes les entrées inférieures également.

"Options lors d'une recherche"

On va faire passer le niveau de logs à stats . Ça générera peut-être beaucoup de messages mais ce sera parfait pour le débugage. Pour cela, enregistrons un fichier logLevel.ldif contenant :
dn: cn=config le DN à modifier
changetype: modify le type de modification de l’objet à effectuer
replace: olcLogLevel l’attribut à modifier
olcLogLevel: stats la nouvelle valeur de l’attribut
On peut appliquer ce changement par la commande :

   ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logLevel.ldif

Les options sont les mêmes que pour ldapsearch sauf le -f qui indique le fichier LDIF à appliquer.
À partir de maintenant, notre serveur slapd va générer des logs mais ils seront renvoyés vers le fichier général /var/log/syslog. Pour indiquer au daemon rsyslog qui gère les logs d’avoir un fichier de log séparé, on va créer le fichier /etc/rsyslog.d/10-slapd.conf contenant :

  # Logs du serveur OpenLDAP slapd
  local4.* /var/log/slapd.conf

Puis on redémarre rsyslog par la commande :

    systemctl restart rsyslog

Ajout de nouveaux noeuds

Pour ajouter de nouveaux nœuds et de nouveaux utilisateurs à notre arbre, on va utiliser un fichier LDIF. Créons donc le fichier structure.ldif contenant :

   dn: ou=Personnes,dc=semail,dc=com
   objectclass: organizationalUnit
   ou: Personnes
   description: Utilisateurs de la messagerie

   dn: cn=Souleymane Sow,ou=Personnes,dc=semail,dc=com
   objectClass: inetOrgPerson
   givenName: Souleymane
   sn: Sow
   cn: Souleymane Sow
   uid: ssow
   userPassword: ssow

La structure du fichier est la même mais comme on rajoute plusieurs entrées, on doit sauter une ligne entre chaque DN. Ce fichier rajoute d’abord l’ ou  : une pour inventorier les utilisateurs. Il rajoute ensuite une personne avec la classe d’objet inetOrgPerson . On avait déjà vu les autres attributs, à l’exception du mot de passe à la fin (qui sera chiffré par slapd) et de l’ uid qui correspond au login ou à un uid numérique suivant l’usage qui est fait de ce champ.
On remarque aussi que dans ce fichier, on n’utilise pas l’attribut changetype pour préciser qu’il s’agit d’un ajout car nous allons utiliser la commande ldapadd qui précise ça par elle-même :

   ldapadd -x -W -D “cn=admin,dc=semail,dc=com” -H ldap://localhost -f structure.ldif

Par défaut l’utilisateur root système a les droits de modification sur le DIT cn=config mais pas sur notre DIT. Sauf à changer ces droits, nous devons donc passer par le compte administrateur de notre DIT. Voici le détail des options:
-x  : indique une authentification simple par mot de passe
-W  : affiche une invite interactive pour taper le mot de passe du compte
-D  : pour indiquer le DN du compte à connecter
-H  : indique toujours la méthode de connexion choisie mais cette fois-ci ldap://localhost initie une connexion par le réseau sur le port TCP 389.
Pour ajouter plus d'utilisateurs, on va mettre en place un script SHELL addldap.sh pour créer plus facilement et plus rapidements de nouveaux utilisateurs et remplir notre annuaire.

#!/bin/bash
if [ $# = 0 ];
then   echo "Usage: ./addldap nom_fichier_ldif"
      exit
fi
touch $1.ldif
trap "ldapadd -x -W -D "cn=admin,dc=semail,dc=com" -H ldap://localhost -f $1.ldif && exit " 2 3
while [ 1 ];
do
   echo "prenom nom uid"
   read prenom nom uid 
   if [ $? -eq 0 ]; 
   then
       echo "dn: cn=$prenom $nom,ou=Personnes,dc=semail,dc=com
objectClass: inetOrgPerson
givenName: $prenom
sn: $nom
cn: $prenom $nomuid: $uid
userPassword: $uid 
">>$1.ldif
    cat $1.ldif
   fi
done

Migration de notre machine virtuelle sur le serveur Brisban

Pour des raisons de sécurité et de disponibilité de notre infrastructure, on va migrer notre machine virtuelle déja crée sur le serveur Brisban.
On a crée d'abord un nouveau fichier de configuration /etc/xen/webmail_P20.cfg et on copie le contenu du fichier de configuration de notre machine virtuelle avant de le modifier pour l'adapter au nouveau hote de destination Brisban.

#
# Configuration file for the Xen instance Webmail, created
# by xen-tools 4.8 on Mon Oct  4 16:55:25 2021.
#
#
#  Kernel + memory size
#
bootloader = 'pygrub'
vcpus       = '2'
memory      = '256'
#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [  
                 'file:/usr/local/xen/domains/Webmail/disk.img,xvda2,w',
                 'file:/usr/local/xen/domains/Webmail/swap.img,xvda1,w',
             ]
#
#  Physical volumes
#
#
#  Hostname
#
name        = 'webmail_P20'
#
#  Networking
#
 vif         = [ 'mac=00:16:3E:F5:AD:B8,bridge=alternateBridge' ]
#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

Ensuite on copie notre fichier de stockage /usr/local/xen/domains/webmail dans notre nouveau répertoire de stockage dans Brisban /usr/local/xen/domains/webmail_P20. On crée ensuite notre machine virtuelle qui est ainsi dupliquée avec la commande:

   xl create /etc/xen/webmail_P20.cfg

On peut ainsi utiliser notre machine virtuelle qui est dorénavant sur le serveur Brisban. On procéde ensuite à la configuration réseau et on va pouvoir bénéficier d'une adresse IP routée. Ensuite on supprime les configurations des proxys avec la commande unset {http,https}_proxy et sur les fichiers /etc/apt/apt.conf. Puis on configure le DNS dans /etc/resolv.conf.

Authentification LDAP pour l'accés à notre serveur web

On installe d'abord notre serveur Web Apache. Ensuite on édite le fichier de configuration d'apache2, afin d'autoriser les fichiers .htaccess, sur l'ensemble du serveur web (depuis sa racine) :

   nano /etc/apache2/apache2.conf

"Configuration de l'apache pour autoriser .htaccess"

On changer la valeur de None -> All, afin que les fichiers .htaccess/.htpasswd soient pris en compte !
On procéde ensuite à l'activation du mode LDAP pour apache2 avant de redémarrer notre service apache:

    a2enmod authnz_ldap 
    systemctl restart apache2

On crée un dossier test/ à la racine de notre serveur web, afin de procéder aux différents tests :

    mkdir /var/www/html/test
    chown www-data:www-data /var/www/html/test -R

On crée un fichier d'exemple et le fichier .htaccess. Nous allons éditer celui-ci par la suite :

     cd /var/www/html/test
     touch file.txt
     touch .htaccess

• Authentification avec LDAP

Nous allons créer 3 fichiers pour mettre en place un formulaire d'authentification avec html et php-ldap : login.php verification.php principale.php Dans notre fichier login.php on va mettre en place notre formmulaire pour récupérer le login et le mot de passe que l'on va vérifier dans verification.php si l'utilsateur appartient à notre annuaire ldap. Si c'est le cas il accédera à la page principale.php qui sera la page ou il pourra céer une nouvelle boite mail sinon on lui renvoie au niveau du formulaire d'authentification.

"Page d'authentification"

Semaine 2

Résolution du problème d'authentification

On a rencontré un problème lors des tests d'authentification. En effet lorsqu'on essaye de s'authentifier avec les utilisateurs crées avec le script SHELL, l’accès est refusé surement parce qu'il n'arrive pas à retrouver les utilisateurs dans l'annuaire. Mais lorsqu'on vérifie au niveau de la base de données LDAP avec la commande LDAPSEARCH on retrouve bien ces utilisateurs. Il n'y a que l'utilisateur initial crée avec le premier fichier LDIF qui arrive à se connecter.

Le problème a pu être résolu en réinstallant le serveur ldap et lors de a création des utilisateurs, pour chaque fichier LDIF on attribue une entrée de l'annuaire. Le problème était lié aux droits d’accès des utilisateurs crées dans un même fichier LDIF. En effet, il n'y avait que le premier utilisateur qui avait accès en recherche à l'annuaire par contre les autres voyaient leur accés refusé.

Création ou Suppression d'une boite aux lettres

Pour savoir si l'utilisateur a déja une boite aux lettres, j'effectue une recherche lors de son authentification et je vérifie si l'attribut mail correspondant à son entrée dans l'annuaire existe ou pas. Si c'est le cas je le redirige sur la page de création d'une nouvelle boite sinon sur celle de suppression.
Pour la création d'une boite, on va demander à l'utilisateur via un formulaire de renseigner son identifiant de courriel et son nom de domaine. S'il choisit un domaine autre que semail.com il devra renseigner l'enregistrement MX du domaine choisi.

"Page de création d'une nouvelle boite de courriels"

Documents Rendus