Services Reseaux Avances [PDF]

Zitiervorschau

Sommaire Chapitre 1 : Introduction au réseau WIFI Chapitre 2 : Le service DHCP Chapitre 3 : Le service DNS Chapitre 4 : Le service messagerie classique Chapitre 5 : Le service messagerie instantanée Chapitre 6 : Annuaire et controleur de domaines

Avant-propos Le système d’information constituant la dorsale de l’entreprise regorge différentes applications au bon fonctionnement de celle-ci. Le contexte des applications et services sont généralement utilisés pour désigner un usage au sein de l’entreprise. Ce cours s’adresse aux étudiants en informatique et télécoms leur permettant de maîtriser les concepts des services déployés dans les réseaux d’entreprise. Ce document constitue un support de cours pour ces derniers et un mémento pour un administrateur système, ainsi que les ingénieurs systèmes. Le cours sera abordé sur deux environnements, sous Linux et également en environnement Cisco. Ce cours est organisé en chapitres afin d’appréhender les différents concepts des services déployés dans les réseaux d’entreprise. Des études de cas pour appuyer les scénarii.

La norme 802.11 définie la norme des réseaux locaux sans fil dont les supports de communication sont basés sur les faisceaux hertziens. Un client wi-fi est immobile dans la cellule où il se trouve (une cellule est une zone géographique délimitée où l’on peut capter les signaux d’une antenne et émettre des signaux vers cette antenne). Les réseaux Wi-Fi travaillent à une vitesse de 11Mbits/s à 54Mbits/s avec une fréquence de 2,4GHz. Cette possibilité de communication par voie hertzienne donne lieu à des communications directe station à station, ou en passant par un point d’accès (AP, Access Point). Dans un réseau sans fil, pour qu’un signal soit reçu correctement, sa portée ne doit pas dépasser 50m (donnée théorique) dans un environnement de bureau ou 500m dans un vide (sans obstacle), soit sur plusieurs kilomètres avec une antenne directive. En générale, la station peut capter le signal sur 20m (dans les faits) dans un environnement de bureau.

Architecture d’un réseau Wi-Fi Les topologies des réseaux Wi-Fi Les réseaux sans fil de type Wi-Fi exploitent deux modes de connexion : •

Le mode Ad-Hoc

•

Le mode Infrastructure

Le mode Ad-Hoc L’exploitation des voies hertziennes a été à l’origine des architectures des réseaux sans fil, donnant naissance à la notion des cellules. Un réseau Ad-Hoc est un ensemble de terminaux (stations) directement reliés entre eux formant une cellule appelé IBSS (Independent Basic Set Service). Le mode ad-hoc permet aux stations de communiquer sans l’intervention d’une infrastructure quelconque telle qu’un point d’accès. Chaque terminal peut ainsi établir une communication avec un autre dans un IBSS.

Mode AdHoc

Le mode Infrastructure Un réseau en mode infrastructure est un ensemble de terminaux reliés entre eux par l’intermédiaire d’un AP. les communications entre les stations ne sont pas directes. Le mode infrastructure est utilisé dans un environnement de bureau. Ce mode est défini pour offrir aux différentes stations des services spécifiques sur une zonne donnée. L’ensemble composé par les stations et l’AP forme une cellule appelée BSS (Basic Set Service).

Mode Infrastructure Etude de cas 1 : Mise en place d’un réseau Wi-Fi sous Linux De manière générale, pour se connecter à un réseau Wi-Fi, il faut connaitre : •

Le nom du réseau (SSID)

•

Le mode de fonctionnement de la radio

Il ya plusieurs modes de fonctionnement de la radio : •

Le mode AdHoc

•

Le mode Manage

•

Le mode Master

•

Le mode Monitor

Cette étude de cas montre le déploiement d’un réseau Wi-Fi sous Linux à travers la ligne de commande. Les ordinateurs sont équipés à la fois d’une interface Ethernet et d’une interface supportant le Wi-Fi. Avant de mettre en place ce réseau, il faut s’assurer que votre ordinateur supporte le mode Wi-Fi. Linux dispose de l’outil ‘’iwconfig’’ (interface wireless configuration) qui affiche les informations à propos de l’interface wifi. Voici un etrait du résultat de cette commande sur une station Linux.

L’exécution de la commande ‘’iwconfig’’ affiche les informations contenues dans les paramètres suivants : •

IEEE 802.11bgn : Norme Wi-Fi supportant les technologies b et g

•

ESSID (off/any) : Ce paramètre renseigne sur le nom du réseau (SSID)

•

Mode : Le mode utilise

•

Access Point (Associated/Not-Associated): il n’ya pas de point d’accès auquel la station a communiqué (Not-Associated)

•

Encryption key (on/off): Paramètre indiquant si le réseau est protégé ou non.

Pour scruter les réseaux avoisinants, on peut se servir de l’outil ‘’iwlist’’. La commande ‘’iwlist’’ exécutée sur la station terminale, donne la liste des réseaux avoisinant ainsi que les puissances d’émissions. Un extrait de la commande ‘’iwlist’’ est donné dans le tableau ci- dessous.

Nous allons maintenant configurer un réseau Wi-Fi en mode Ad Hoc pour deux stations terminales. Nous avons de deux outils : iwconfig (pour créer le réseau) et ifconfig Il faut tout d’abord commencer à désactiver l’interface wifi pour vous rassurer que votre station ne tente pas de se synchroniser avec un point d’accès dans.

Etude de cas 2 : Mise en réseau (Filaire) Dans ce cas de figure, nous allons montrer comment mettre en réseau deux stations terminales sous Linux. Tous les paramétrages sont manuels. Nous allons considérer l’architecture suivante avec comme adresse réseau 10.10.1.0/24.

Nous allons configuer chacune des stations terminales en ligne de commande c’est-à-dire leur donner les éléments TCP/IP (adresse IP, masque, passerelle, DNS, ...). Pour configuer less éléments TCP/IP sur une station terminale sous linux, on utilise la commande ‘’ifconfig’’. Cette commande prend en argument le nom de l’interface sur laquelle on veut fixer les éléments TCP/IP, l’adresse IP, et le masque de sous réseau. Elle peut s’employer sans option pour consulter toutes les interfaces présentes sur le système. Extrait de configuration de la station terminale PC1.

Le processus de configuration sur PC2 et PC3 sera le même à la limite de changer les adresse IP pour éviter un éventuel conflit. Après ses configurations, vous pouvez tester la connectivité par un ping. Nous envisageons ajouter une route par défaut (passerelle par défaut). Pour ajouter une route par défaut, nous allons manœuvre la commande ''route'' comme suit :

Nous allons utiliser les ACLs pour interdire tout ping vers la station PC1

Toutes ces manipulations sont basiques et ne nécessite pas de connaissance approndies. Nous allons introduire les services réseaux. Quand on parle de services réseaux, on pense aux services qu’on déploie en réseau. Lorsqu’on service est déployé, c’est pour une utilisation précise. Mais la question pendante ici est comment se connecter à un service en réseau ? Pour se connecter à un service en réseau, il faut préciser les paramètres suivants : •

L’adresse IP du service

•

Le port d’écoute du service

•

Le protocole de transport utilisé.

Mais en général, on ne précise pas tous ces paramètres pour accéder à un service. Prenons par exemple l’accès à un serveur web. L’accès à un service web se fait via le protocole http. http://ip_serveur Nous accédons au serveur alors qu’on n’a pas précisé tous les paramètres. Ceci fonctionne, car sous Linux il ya un fichier appelé ‘’/etc/services’’ qui contient toutes les informations à propos des services, les ports d’écoute ainsi que les protocoles de transport utilisés. Extrait du fichier /etc/services

Etude de cas 3 : Connexion à distante La connexion à distance sur des systèmes UNIX/Linux se fait par le biais des protocoles ‘’Telnet’’ ou SSH. Le protocole Telnet a montré ses limites (connexion non sécurisée) face aux mécanises de sécurité (envoie de mot de passe en clair), c’est pourquoi sous Linux, on empêche au super utilisateur (root) de se connecter à distance. Pour pallier aux insuffisances de telnet, SSH (Secure Shell) permet de se connecter à distance via un shell sécurisé. Nous allons montrer dans cette étude de cas comment se connecter sur un système distant par SSH. Nous allons reconsidérer l’architecture de l’étude de cas 2 pour notre scénario.

Syntaxe # ssh nom_user@ip_disant

Nous utilisons le compte ‘’ec2lt’’ pour se connecter sur la station PC2 à partir de PC1

Appliquons quelques règles d’ACLs pour empêcher toute connexion SSH sur PC2.

Observons ce qui suit lorsque PC1 tente une connexion par SSH sur PC2.

Nous allons interdire cette fois-ci la connexion à la station PC3

Le protocole DHCP (Dynamic Host Control Protocol), protocole défini dans les RFC 1531, 1534, 2131 et 2132 décrit les processus par lesquels une station terminale procède pour avoir les éléments TCP/IP et se mettre en réseau. DHCP écoute sur le port 67 (coté serveur) et sur le port 68 (coté client). Il est implémenté dans l’ancienne version du protocole (IPv4) et dans la version 6 appelé DHCPv6. L’intérêt d’utiliser le protocole est de permettre aux stations terminales d’obtenir les éléments TCP/IP de façon automatique et dynamique. Fonctionnement du service DHCP Pour comprendre le fonctionnement du service DHCP, nous allons étudier les scénarii suivants : Scénarion1 : Première découverte du client A sa première connexion sur le réseau, une station terminale émet des requêtes sur le réseau pour obtenir les éléments de connexion.

Un client envoie par diffusion sur le réseau un message appelé ‘’DHCPDISCOVER’’. N’ayant pas encore d’éléments de connexion, ce message a pour adresse source 0.0.0.0 et pour adresse de destination 255.255.255.255. Voici le format d’un paquet DISCOVER.

Scénario 2 : réponse du serveur

Un serveur DHCP se trouvant dan le réseau répond par diffusion avec un message DHCP OFFER.

Scénario 3 : Première réponse du client

Le client répond par diffusion avec un message DHCP REQUEST pour notifier aux autres serveurs dont les offres n'ont pas été retenues de ne plus tenter de proposer des offres.

Scénario 4 : Confirmation de l’offre Le serveur envoie de nouveau un message d’accusé de réception au client pour lui confirmer l’utilisation des éléments de connexion reçus dans un message ‘’DHCP ACK’’.

Jusque là, le client n'a pas encore tous les éléments possibles. C'est dans ce paquet que le client recevra le masque du sous-réseau, les adresses des serveurs DNS, et celle de la passerelle ainsi que d’autres paramètres.

NB: Les éléments TCP/IP fournis par un serveur DHCP a un client porte le nom de bail. Les baux ont une durée minimale et maximale de validité. Un client DHCP qui a épuisé les 50% de la durée maximale de validité de son bail se doit de le renouveler auprès du serveur DHCP. Sous Linux, le système conserve les informations sur les dernières utilisations des baux dans le fichier /var/lib/dhcp.lease. Voici un extrait du fichier d’une station de travail.

Etude de cas 2.1 : Mise en œuvre du service DHCP sous Cisco Cette étude de cas est consacrée à la mise en place d’un serveur DHCP sur un routeur Cisco. Nous allons monter un LAB sous GNS3. Une documentation montrant l’installation et les premiers pas avec GNS3 se trouve sur le site www.ec2lt.sn, consulter l’onglet « Rapports ». Voici l’architecture que nous avons montée dans le LAB0.

La présence du nuage dans le LAB permet de relier le réseau monté dans le LAB à un réseau local. Pour tester l’attribution des éléments TCP/IP, nous avons relié par un câble la station sur laquelle le LAB a été monté à une autre station terminale. Nous allons commencer par configurer notre serveur.

Avec cette configuration, les hôtes du réseau peuvent déjà émettre des requêtes DHCP et obtenir les éléments TCP/IP. Cette configuration minimale est trop basique. Il faut préciser une plage. Pour définir une plage, il faut créer une classe.

Nous allons préciser l’adresse de la passerelle en utilisant la commande « default routeur @IP_PASSERELLE.

Il faut aussi préciser l’adresse des serveurs DNS s’il y’en a beaucoup, sinon préciser l’unique que vous disposez par la commande « dn server @IP_DNS »

Etude de cas 2.2 : Configuration des stations terminales Nous avons transformé des routeurs en stations terminales. Pour obtenir les éléments de mise en réseau automatiquement, nous allons exécuter la commande « ip address dhcp » sur les stations terminales. #PC1

# PC2

Etude de cas 2.3 : Mise en œuvre d’un relais DHCP Cette étude de cas illustre des principes de fonctionnement d’un relais DHCP. Peut-on se poser la question pourquoi avoir un relais alors qu’un serveur DHCP suffirait ? Il s’agit ici de contourner certaines difficultés en réseaux. Admettant que le réseau a été segmenté (sous- réseaux) et que ces sous-réseaux sont séparés par des routeurs. Or, un routeur limite les domaines de diffusion. Pour cela, les requêtes DHCP envoyés depuis les clients n’atteindront pas les serveurs DHCP, car ceux-ci sont injoignables. La solution idéale ici est de mettre en place un relais DHCP sur chaque segment du réseau. Celui-ci va écouter les requêtes et les relaye au serveur DHCP dédié. Nous allons monter deux sous-réseaux Rx1 (réseau de l’EC2LT) et Rx2 (réseau de l’ESMT) qui ont respectivement les adresses suivantes : 192.168.2.0/24 et 172.16.1.0/24. Notre architecture sera montée dans GNS3.

SYSTEME DE NOM DE DOMAINE PRINCIPE Sur les réseaux de données, les périphériques sont étiquetés par des adresses IP numériques, ce qui leur permet de participer à l’envoi et à la réception de messages via le réseau. Cependant, la plupart des utilisateurs mémorisent très difficilement ces adresses numériques. Pour cette raison, des noms de domaine ont été créés pour convertir les adresses numériques en noms simples et explicites. Le protocole DNS (Domain Name System) a été créé afin de permettre la résolution des adresses pour ces réseaux. Le système DNS utilise un ensemble distribué de serveurs de base de données pour convertir les noms associés à ces adresses en numéros. Le DNS transforme les noms d’hôte en adresses IP : c’est la résolution de nom. Il transforme les adresses IP en noms d’hôte : c’est la résolution inverse. Il permet de regrouper les machines par domaines de nom. Il fournit des informations de routage et de courrier électronique. Les noms sont organisés selon une structure arborescente hiérarchique (arbre inversé) appelée espace de nommage (figure 1), composé de : La racine (root), sommet de l'arbre, qui est notée par un point «.» •

Des noeuds, identifiés par un label (com, org, sn, etc.), dont les informations sont stockées dans une base de données propre à chacun des noeuds

•

Des bases de données (avec une base de données par noeud)

•

L'ensemble de ces bases de données constitue le système d'information hiérarchique et distribué du DNS

Figure 1 : Structure de l’espace de nommage Le serveur DNS stocke différents types d’enregistrements de ressource utilisés pour résoudre des noms. Ces enregistrements contiennent le nom, l’adresse et le type d’enregistrement. Certains de ces types d’enregistrements sont les suivants : SOA : Permet de décrire la zone, Il permet également à un DNS secondaire de dialoguer avec le primaire et fournit sept types d'informations (voir plus bas). Il renferme 7 informations à savoir: •

nom du serveur DNS primaire du domaine

•

l'adresse e-mail de l'administrateur du domaine:

•

le numéro de série d'information stockée

•

durée de rafraichissement (indique au serveur secondaire quand est-ce qu’il va revenir pour copier des informations de mise a jour

•

durée de réessaie (indique au serveur secondaire le nombre de fois il doit revenir pour prendre des infos)

•

durée d'expiration: somme des durées de réessaie (retry) pour indiquer au serveur secondaire de ne plus essayer de venir.

•

durée minimale de validité des informations: temps pendant lequel le secondaire doit continuer à servir pendant que le serveur principal n'est pas disponible.

Voici un extrait des premières lignes d’un fichier de zone pour le serveur DNS du domaine EC2LT.

A : une adresse de périphérique final. NS : un serveur de nom autorisé. CNAME : le nom canonique (ou nom de domaine complet) d’un alias ; utilisé lorsque plusieurs services comportent une adresse réseau unique mais que chaque service comporte sa propre entrée dans DNS. MX : enregistrement d’échange de courriel ; associe un nom de domaine à une liste de serveurs d’échange de courriel pour ce domaine. PTR : Pointer. Dans une zone de résolution inverse, fait pointer une IP sur un nom d’hôte.1

Fonctionnement du client : le resolver Le resolver permet de communiquer avec les serveurs DNS. il y a 2 modes d'interrogation de serveur: Récursif : Le client envoie une requête à un serveur, ce dernier devant interroger tous les autres serveurs nécessaires pour renvoyer la réponse complète au client (mode utilisé par les machines clientes en général) • Itératif : Le client envoie une requête à un serveur, ce dernier renvoyant la réponse si il la connaît, ou le nom d'un autre serveur qu’il suppose plus renseigné pour résoudre cette question (mode utilisé par le resolver des serveurs en général) IMPLEMENTATION EN ENVIRRONEMENT LINUX

Installation Installation des paquets bind9 (serveur DNS) et bind9utils (utilitaires)

Configuration Tous les fichiers de configuration du serveur DNS se trouvent dans le répertoire /etc/bind/. Pour chaque domaine ou sous domaine, on définit deux sections zone. La première contient les informations de résolution de nom (nom vers IP) et la seconde les informations de résolution inverse (IP vers Nom)

Déclaration des zones (directe et indirecte) #vim /etc/bind/named.conf.local

Création des fichiers de zones Zone directe

ÿþ

Zone indirecte

Redémarrage du service

Configuration d’un client sous ubuntu et test On indique l’adresse du serveur DNS dans le fichier /etc/resolv.conf l'adresse IP du serveur DNS.

Test

Configuration du DNS Secondaire Les serveurs DNS (Domain Name System) secondaires assurent l’équilibrage de la charge et la tolérance de panne. Les serveurs DNS secondaires conservent une copie en lecture seule des données de zone qui sont transférées régulièrement à partir du serveur DNS principal pour la zone. Vous pouvez configurer les clients DNS pour qu’ils interrogent les serveurs DNS secondaires au lieu de ou en plus du serveur DNS principal d’une zone, ce qui réduit la demande vis-à-vis du serveur principal et garantit une réponse aux requêtes DNS pour la zone même si le serveur principal n’est pas disponible.

NB : Cela suppose qu’on a déjà un serveur primaire fonctionnel Déclaration de zones sur le serveur secondaire

Le paramètre masters précise l'adresse IP du serveur Primaire. Redémarrage du serveur

Configuration supplémentaire du DNS Primaire Dans les fichiers de zones du serveur primaire on ajoute le serveur secondaire.

Fichier de zone directe

Fichier de zone indirecte

NB : Après toutes modifications ultérieures des enregistrements de zones dans DNS primaire, initialiser la valeur (en mettant une valeur supérieure) du paramètre Serial du type d’enregistrement SOA dans les deux zones et redémarrer le service DNS Vérification Vérifions que le serveur primaire à bien transférer les enregistrements vers le serveur secondaire.

#less /var/cache/bind/rnt.sn

Zone indirecte #less /var/cache/bind/rnt.nv

IMPLEMENTATION EN ENVIRRONEMENT CISCO Etude de cas : Mise en œuvre du service DNS sous Cisco Nous allons dans cette étude de cas montrer comment mettre en place un service de résolution de nom en environnement Cisco (routeurs Cisco). Nous allons monter une

architecture expérimentale avec un serveur de nom. Ensuite nous allons prolonger cette étude de cas en combinant le service DNS et le service DHCP.

Nous allons monter cette architecture dans notre LAB sous GNS3 Comment fait-on pour transformer un routeur Cisco en un serveur de noms ? Voici quelques étapes de mise en œuvre : • activer le routeur en tant que serveur de nom (ip dns-server) • indiquer l’adresse IP du serveur DSN (ip name-server @IP) • activer le routeur en tant que serveur de nom principal avec les enregistrements de type SOA (ip dns primary en2lt.sn soa dns.ec2lt.sn yvan.ec2lt.sn) • activer l’enregistrement de NS (ip host ec2lt.sn ns dns.ec2lt.sn) • activer l’enregistrement de type A (ip host dns.ec2lt.sn), idem pour les hôtes centos et ldap. Voici un extrait de la configuration du serveur DNS primaire. Nous ne gérons pas encore le serveur secondaire du domaine EC2LT (plus tard).

Etude de cas 3.2 : Configuration du client hôte nommé centos Avec cette configuration, seul le serveur a l’habilité de résoudre les noms d’hôtes, car tous les enregistrements sont faits à son niveau. Pour que cela soit pris en compte coté clients, il faut ajouter la configuration du serveur au niveau de chaque hôte. Vous remarquerez qu’on donné un autre FQDN à la machine « centos » au lieu de « centos.ec2lt.sn » nous l’avons enregistrer en tant que « msg.ec2lt.sn ».

Résultat sur la console d’un ping vers ldap.ec2lt.sn

Etude de cas 3.3: Configuration du client « ldap » Idem comme pour l’hôte centos, le FQDN de l’hôte « ldap » est « ldap.ec2lt.sn »

Nous allons aussi ajouter le serveur DNS à l’hôte ldap

Résultat à l’écran d’un ping vers « msg.ec2lt.sn »

Etude de cas 3.4 : Mise en œuvre d’un DNS secondaire Dans l’étude de cas 3.1, nous avons montré comment mettre en œuvre un serveur DNS primaire pour la résolution directe. Pour des raisons de disponibilité en réseau, nous allons prévoir un serveur de secours pour le domaine principal. Dans le LAB que nous avons monté, le serveur DNS primaire est appelé DNSServer1 (192.168.1.250) et le secondaire DNSServer2 (IP : 192.168.1.251).

Ensuite, il faut ajouter le DNSServer2 dans la liste des serveurs DNS à contacter au niveau du client.

Pour tester, nous allons arrêter le serveur primaire (DNSServer) et tenter de joindre un hôte par son nom.

Nous voyons bien la station terminale a envoyer les requêtes de résolution vers son serveur principal, puis vers le secondaire.

PRINCIPE Le courriel, le service réseau le plus répandu, par sa simplicité et sa vitesse d’exécution, a révolutionné la manière dont nous communiquons. Mais pour s’exécuter sur un ordinateur ou autre périphérique final, une messagerie nécessite plusieurs applications et services. Les protocoles POP (Post Office Protocol) et SMTP (Simple Mail Transfer Protocol). Comme illustré dans la figure suivante :

architecture de fonctionnement Quand un client (un utilisateur) envoie un message, il utilise un MUA (Mail User Agent), par exemple Outlook Express, Thunderbird, Evolution, Kmail, Mutt, etc. Le MUA envoie le message au MTA (Mail Transport Agent). Le MTA étudie l’adresse électronique pour isoler l’utilisateur et le domaine de destination. Puis il vérifie les informations DNS de type MX (Mail eXchanger) pour le domaine choisi, pour savoir à quel serveur transmettre le courrier. Si aucun MTA n’est disponible, le message est placé en file d’attente et relance la distribution plus tard (le délai dépend de la configuration du MTA). Le MX peut être soit un autre MTA, qui jouera le rôle de routeur (cas d’une redirection vers un sous domaine par exemple) (voir figure 3), soit un MDA (Mail Delivery Agent). Le MDA place le message dans un fichier temporaire, peut faire

l’analyse antivirus, le filtrage du courrier indésirable et la gestion des accusés de réception, etc. À ce niveau, le destinataire reçoit le message : soit il le récupère en lisant directement le fichier temporaire (cas de la commande mail par exemple) soit il passe par un protocole de type POP (qui télécharge les courriels sur le poste client pour lire) ou IMAP (qui télécharge juste l'entête des courriels et lit de manière interactive les courriels). Le protocole de transport de messages est le SMTP (Simple Mail Transfer Protocol) sur le port 25. Les protocoles de réception de messages soit POP (Post Office Protocol) sur le port 110, soit IMAP (Internet Message Access Protocol). Deux suites de courrier électronique se partagent l’essentiel du marché sur Unix : sendmail et Postfix. La suite libre sendmail est la plus connue et la plus utilisée mais plus difficile à configurer. Postfix est le serveur SMTP que nous utiliserons. Il existe plusieurs suites pour gérer POP et IMAP. Une suite se nomme cyrusimap et est en principe réservée aux grosses structures et aux serveurs 100% dédiés au courrier. Une autre solution se nomme dovecot, que nous allons mettre en place.

Architecture de fonctionnement détaillé Le format des messages Il existe deux types de format de message: maildir Si on utilise le format maildir il y a un dossier nommé Maildir, qui est crée dans le répertoire de base de chaque utilisateurs au niveau du serveur, ce dernier contient des sous dossiers à savoir :

• new : contient les courriels non consultés • cur : contient les courriels déjà consultés • tmp : stocke les courriels de façon temporaire mailbox Dans ce format les courriels de chaque utilisateur au niveau du serveur sont concaténés dans un fichier portant le nom de chaque utilisateur.

IMPLEMENTATION Installation et configuration de Postfix

La configuration de Postfix se fait dans le fichier /etc/postfix/main.cf, mais lors de l'installation du paquet postfix, il nous a affiché un prompt suivant: Il y a trois façons de configurer postfix ; soit par l'interface graphique a travers le prompt, soit en ligne de commande par postconf, soit en éditant le fichier /etc/postfix/main.cf. Dans notre cas, nous y avons choisi la troisième option.

Redémarrage du service postfix

Test d’envoi de courriel Certaines des commandes spécifiées dans le protocole SMTP sont les suivantes :

helo : identifie le processus client SMTP pour le processus serveur SMTP. ehlo : est une version plus récente de la commande HELO et comprend des extensions de services. Mail from : identifie l’expéditeur. Rcpt to : identifie le destinataire. data: identifie le corps du message. quit : mettre fin a la session

Pour lire le mail envoyé à abdel, #cd /home/abdel/Maildir/new/

Installation et Configuration de dovecot #apt-get install dovecot-pop3d dovecot-imapd Éditez le fichier /etc/dovecot/dovecot.conf pour vérifier les protocoles supportés, autoriser l’authentification en texte clair(en supposant que la communication est sécurisée) et indiquer le format des messages.

Redémarrer le service /etc/init.d/dovecot restart Teste de réception de courriel Certains des commandes spécifiées dans le protocole POP sont les suivantes: user - il s'agit de l'identifiant du titulaire du compte. pass - Le mot de passe stat - Donne le nombre de messages présents dans la file d'attente, ainsi que le volume total des messages en octets. list - Donne la liste des messages en attente, avec pour chaque message: * Son numéro d'ordre dans la file * Sa taille en octets retr n - Permet de récupérer la totalité du message “n” dans la file d'attente. dele n - Détruit le message “n” dans la file d'attente. Le numéro d'ordre des messages suivants demeure inchangé jusqu'à la fin de la session rset – Cette commande permet d’annuler toutes les commandes de destruction de messages

envoyées pendant la session. En fait, les commandes DELE ne sont rendues effectives que si la session a proprement été fermée (commandes QUIT acceptée). Cette méthode permet donc d’annuler les opérations d’effacement dans la session en cours. quit – Clôture la session en cours. Le serveur ferme alors la session TCP et “fait le ménage” dans la file d’attente, en fonction des ordres DELE qui on été donnés

Utilisation de clients lourds de messagerie Nous allons paramétrer quelques clients de messageries à savoir : Evolution et Outlook Paramétrage d’Evolution Paramétrage d’un compte de messagerie et l’adresse du serveur SMTP et POP(ou IMAP)

Paramétrage d’Outlook

Anti relais Internet etait un reseau amical au depart, mais maintenant il est important de contrôler les échanges avec les serveurs SMTP ouverts (Open Relay). Ces serveurs sont utilisés pour envoyer des messages électroniques non sollicités, connus sous le nom de spam. On peut donc demander à Postfix de consulter une listes d’adresses avant d’accepter un message entrant. Ceci est réalisé grâce à la directive smtpd_client_restrictions dans le fichier /etc/postfix/main.cf. Enfin pour éviter que notre serveur devienne lui-même ouvert, il faut limiter les accès de façon très stricte. Par exemple, on peut rejeter la mail si les en-têtes sont incomplètes, si le message est mal formé, ... Par contre, mes messages provenant des réseaux connus (my_networks) seront toujours acceptés.

WEBMAIL Un webmail, courriel web ou messagerie web est un client de messagerie qui s'exécute sur un serveur web ; il sert d'interface entre un serveur de messagerie et un navigateur web contrairement au client lourd qui permet les mêmes opérations à partir d’un logiciel installé localement sur un ordinateur personnel. Il est utilisé par les utilisateurs pour consulter leurs courriers électroniques depuis un navigateur. Les avantages du webmail pour l'utilisateur sont de ne pas avoir à installer un logiciel spécialisé sur sa ou ses machines, de ne pas avoir à faire la configuration de base pour envoyer et recevoir le courrier et de déporter la responsabilité de la sécurité de l'installation vers le serveur. Les inconvénients de cette solution sont d'être dépendant en performance de la rapidité du réseau, en particulier si le nombre de messages est grand ou s'il y a des pièces jointes de taille importante dans les messages Exemple : Squirrelmail, Roundcube, Horde, Outlook Web Access, etc …

SQUIRRELMAIL Prérequis : Un serveur web Installation

Configuration Nous allons utiliser la méthode d’hébergement par dossier pour héberger squirrelmail

Maintenant donnons au webmail l’adresse ou le FQDN de notre serveur SMTP et POP/IMAP

Ces modifications ci-dessus peuvent être effectuées en mode dialogue en lançant

Nous pouvons éventuellement changer la langue (par défaut en anglais) en français (la partie en surbrillance), et reconfigurer le « locales » pour ajouter les français aux jeux de paramètres régionaux.

Test Pour accéder au web mail taper dans le navigateur http://domaine_ou_@_ip/mail

ROUNDCUBE Installation Prérequis : Un serveur web et un serveur de base de données en occurrence mysql

Etape1: Téléchargement de roundcube et création d’une base de données pour

roundcube On télécharge le paquet ici http://roundcube.net/download/ Création de la base de données roundcube et un utilisateur de la base :

Etape3: Décompression du fichier dans /var/www

Etape4: Configuration de roundcube Choisissez un navigateur et lancer http://@i_serveur_web/installer Rassurez-vous que toutes les dépendances sont installées avant de passer à la configuration

Paramétrage de la Base de données IMAP

SMTP

Télécharger les deux fichiers et copier les dans le répertoire /var/www/roundcube/config/

Test

Principe Une messagerie instantanée est une solution logicielle permettant à des utilisateurs inscrits et connectés de voir quels sont les autres utilisateurs connectés et de communiquer avec eux par envoi de petits messages. A l’inverse du mail, l’intérêt des messageries instantanées est de fonctionner en « temps réel ». C’est à dire qu’à l’instant même où une personne se connecte ou se déconnecte, les autres utilisateurs sont avertis, et les messages que vous envoyez arrivent immédiatement. Afin de participer à des discussions instantanées, il est indispensable de rejoindre un réseau de messagerie instantanée. Les réseaux sont gérés par des acteurs de diverses envergures (parfois des particuliers, parfois des entreprises) qui mettent à disposition l'infrastructure permettant les échanges de messages. Ceux-ci sont nombreux dans Internet : parmi les plus mondialement connus tel que OSCAR (AIM, ICQ), YMSG (Yahoo! Messenger) et XMPP (Jabber, Google Talk). Tout comme la messagerie classique on peut utiliser soit un client lourd soit un client web pour se connecter au serveur. Parmi les clients il y a les clients multi-protocoles comme : Empathy (Ubuntu, Xubuntu) Kopete (Kubuntu) Jitsi (Linux, Mac OS, windows) Blink(Linux, Mac OS, Windows) Pidgin (Linux, Windows) Finch, un client en mode terminal Nous allons mettre en œuvre deux serveurs de messagerie instantanée OPENFIRE ET EJABBERD

OPENFIRE Openfire (anciennement connu sous le nom de Wildfire et auparavant de JiveMessenger) est un serveur Jabber/XMPP (est un ensemble de protocoles standards ouverts de l’IETF) pour la messagerie instantanée) écrit en Java et sous double Licence publique générale GNU et propriétaire

Implémentation Prérequis Un serveur web et un serveur de base de données en occurrence mysql Installation #apt-get install openjdk-7-jre

Etape1: Téléchargement de l’openfire

Télécharger le fichier openfire_3_9_1.tar.gz sur http://www.igniteraltime.org/downloads/index.jsp #tar -xzvf openfire_3_9_1.tar.gz -C /usr/local

Etape3: création d’une base de données pour openfire #mysql –u root –p >create database openfire; > grant all privileges on openfire.* to 'openfire'@'localhost' identified by 'passer'; >flush privileges; >quit;

Etape4: lancement d’Openfire et poursuite de la configuration #cd /usr/local/openfire/bin/ #. /openfire start

Une fois openfire lancé, on peut poursuivre la configuration de l’openfire sur l’interface web, il écoute sur port 9090. Choisissez un navigateur et lancer http://192.168.1.20:9090 Sélection de la langue

Création du compte d’administration

Création des comptes utilisateurs

Nous utilisons les clients Spark et Jitsi Sous Ubuntu Installation de Spark Télécharger le fichier spark_2_6_3.tar.gz sur le site http://www.igniterealtime.org/downloads/index.jsp

En suite #tar zxvf spark_2_6_3.tar.gz -C /usr/local #cd /usr/local/Spark #./Spark

Installation de Jitsi #dpkg –i jitsi_2.2.4603.9615-1_i386.deb

Lancement de jitsi $jitsi Configuration de l’utilisateur sylla

Sous Windows Télécharger le client spark_2_6_3.exe sur le site http://www.igniterealtime.org/downloads/index.jsp

Installation du CLIENTS WEB SPARKWEB Sparkweb est un client-web Jabber/XMPP, la configuration d’un tel client léger simplifiera le travail en éliminant le besoin de diffuser, puis d'installer un logiciel client sur les machines des utilisateurs. #tar -xzvf sparkweb_0_9_0.tar.gz -C /var/www/ #cd /var/www/sparkweb/ #mv sparkweb.html index.html Pour y accéder http://@_ip_webserveur/sparkweb

Voici est exemple d’échange de message:

Ejabberd Etape 1 - Installer ejabberd

Étape 2 – Création du compte administrateur

Donner des privilèges d'administrateur Par défaut, le nom d'hôte utilisé par ejabberd est 'localhost', qui peut être modifié à partir du fichier de configuration. Pour notre exemple, nous allons appeler notre utilisateur admin "admin @ localhost" et modifier les lignes suivantes dans le fichier

Redémarrage de serveur ejabberd

Maintenant, vous pouvez accéder à votre interface Web Admin ejabberd En utilisant http://192.168.1.20:5280/admin

Dans l'interface d'administration Web, vous pouvez modifier tous les paramètres:

Ajout de nouveaux utilisateurs Partir de l'interface web d'administration, cliquez sur Hôtes virtuels -> localhost -> Users

Vous pouvez également ajouter un utilisateur à partir de la ligne de commande:

Installation de clients Sous Ubuntu Maintenant, vous pouvez installer un client comme Pidgin, jitsi, etc. pour se connecter au

serveur XMPP:

N’oublier pas d’utiliser le port 5222:

Ajout d'utilisateurs à votre liste d'amis De Pidgin vous pouvez soit appuyer sur CTRL + B ou à

partir du menu " Amis " -> " Ajouter un contact " :

Sous Windows Jitsi

Principe de l’annuaire LDAP Un annuaire électronique est une base de donnée spécialisée, dont la fonction première est de retourner un ou plusieurs attributs d'un objet grâce à des fonctions de recherche multicritères. Contrairement à un SGBD, un annuaire est très performant en lecture mais l'est beaucoup moins en écriture. Sa fonction peut être de servir d'entrepôt pour centraliser des informations et les rendre disponibles, via le réseau à des applications, des systèmes d'exploitation ou des utilisateurs. Lightweight Directory Access Protocol (LDAP) est né de la nécessaire adaptation du protocole DAP (protocole d'accès au service d'annuaire X500 de l'OSI) à l'environnement TCP/IP. Les concepts de LDAP LDAP est un protocole d'annuaire standard et extensible. Il fournit : 

un protocole permettant d'accéder à l'information contenue dans l'annuaire,



un modèle d'information définissant le type de données contenues dans l'annuaire,



un modèle de nommage définissant comment l'information est organisée et référencée,



un modèle fonctionnel qui définit comment on accède à l’information,



un modèle de sécurité qui définit comment données et accès sont protégés,



un modèle de duplication qui définit comment la base est répartie entre serveurs,



des APIs pour développer des applications clientes,



LDIF, un format d'échange de données.

Le Directory Information Tree Les données LDAP sont structurées dans une arborescence hiérarchique qu'on peut comparer au

système de fichier Unix. Chaque nœud de l'arbre correspond à une entrée de l'annuaire ou directory service entry (DSE) et au sommet de cette arbre, appelé Directory Information Tree (DIT), se trouve la racine ou suffixe.

Les entrées

correspondent à des objets abstraits ou issus du monde réel, comme une personne, une imprimante, ou des paramètres de configuration. Elles contiennent un certain nombre de champs appelés attributs dans lesquelles sont stockées des valeurs. Le schéma L'ensemble des définitions relatives aux objets s'appelle le schéma. Le schéma décrit les classes d'objets, leurs types d'attributs et leur syntaxe. Les attributs Une entrée de l'annuaire contient une suite de couples types d'attributs - valeurs d'attributs. Les attributs sont caractérisés par : 

Un nom qui l'identifie



Un Object Identifier (OID) qui l'identifie également



S'il est mono ou multi-valué



Une syntaxe et des règles de comparaison



Un indicateur d'usage



Un format ou une limite de taille de valeur qui lui est associée

Les attributs décrivent généralement des caractéristiques de l'objet, ce sont des attributs dits normaux qui sont accessibles aux utilisateurs (ex : attribut givenname). Certains attributs sont dits opérationnels car ils ne servent qu'au serveur pour administrer les données (ex : attribut modifytimestamp). Une entrée est indexée par un nom distinct (DN, distinguished name) permettant d’identifier de manière unique un élément de l’arborescence. Un DN se construit en prenant le nom de l’élément, appelé Relative Distinguished Name (RDN, c'est-à-dire le chemin de l’entrée par rapport à un de ses parents), et en lui ajoutant l’ensemble des noms des entrées parentes. Il s’agit d’utiliser une série de paires Attribut/valeur permettant de repérer une entrée de manière unique Les classes d'objets Les classes d'objets modélisent des objets réels ou abstraits en les caractérisant par une liste d'attributs optionnels ou obligatoires. Une classe d'objet est définie par : 

Un nom qui l'identifie



Un OID qui l'identifie également



Des attributs obligatoires



Des attributs optionnels



Un type (structurel, auxiliaire ou abstrait)

Le type d'une classe est lié à la nature des attributs qu'elle utilise. 

Une classe structurelle correspond à la description d'objets basiques de l'annuaire : les personnes, les groupes, les unités organisationnelles... Une entrée appartient toujours au moins à une classe d'objet structurelle.



Une classe auxiliaire désigne des objets qui permettent de rajouter des informations complémentaires à des objets structurels. Par exemple l'objet mailRecipient rajoute les attributs concernant la messagerie électronique d'une personne.



Une classe abstraite désigne des objets basiques de LDAP comme les objets top ou alias.

Les classes d'objets forment une hiérarchie, au sommet de laquelle se trouve l'objet top. Chaque objet hérite des propriétés (attributs) de l'objet dont il est le fils. On peut donc enrichir un objet en créant

un

objet

fils

qui

lui

rajoute

des

attributs

supplémentaires.

On précise la classe d'objet d'une entrée à l'aide de l'attribut objectClass. Il faut obligatoirement

indiquer la parenté de la classe d'objet en partant de l'objet top et en passant par chaque ancêtre de l'objet. Par exemple, l'objet inetOrgPerson a la filiation suivante : objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson L’objet person a comme attributs : commonName, surname, description, seeAlso, telephoneNumber, userPassword L'objet fils organizationalPerson ajoute des attributs comme : organizationUnitName, title, postalAddress... L'objet petit-fils inetOrgPerson lui rajoute des attributs comme : mail, labeledURI, uid (userID), photo ... Une entrée peut appartenir à un nombre non limité de classes d'objets. Les attributs obligatoires sont dans ce cas la réunion des attributs obligatoires de chaque classe. Exemples de classes d'objets Entry Type Required Attributes Optional Attributes  businessCategory  carLicense  departmentNumber  description  employeeNumber  facsimileTelephone  Number  givenName  mail  commonName (cn)  manager inetOrgPerson (defines entries for a  surname (sn)  mobile person)  objectClass  organizationalUnit (ou)  pager  postalAddress  roomNumber  secretary  seeAlso  telephoneNumber  title  labeledURI  uid organizationalUnit (defines entries  ou  businessCategory

for organizational units)

organization (defines organizations)

 objectClass

entries

for  o  objectClass

 description  facsimileTelephoneNumber  location (l)  postalAddress  seeAlso  telephoneNumber  businessCategory  description  facsimileTelephoneNumber  location (l)  postalAddress  seeAlso  telephoneNumber

Le Distinguish Name Chaque entrée est référencée de manière unique dans le DIT par son distinguished name (DN). Le DN représente le nom de l'entrée sous la forme du chemin d'accès à celle-ci depuis le sommet de l'arbre. On peut comparer le DN au path d'un fichier Unix. Par exemple, le DN de ALLIER (prof) correspondant à l'arbre de la figure 1 est : uid=ALLIER,ou=professeurs,dc=ec2lt,dc=sn Le DN représente le chemin absolu d'accès à l'entrée. Comme pour le système de fichier Unix, on peut utiliser un relative distinguished names (RDNs) pour désigner l'entrée depuis une position déterminée de l'arbre. Par exemple, à partir de la position ou=professeurs,dc=ec2lt, dc=sn uid=ALLIER=>RDN LDIF LDAP Data Interchange Format (LDIF) permet de représenter les données LDAP sous format texte standardisé, il est utilisé pour afficher ou modifier les données de la base. Il a vocation à donner une lisibilité des données pour le commun des mortels. LDIF est utilisé dans deux optiques : •

faire des imports/exports de base

•

faire des modifications sur des entrées.

•

La forme générale est :

dn: