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 [Link]/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.
[Link]
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 [Link] et pour
adresse de destination [Link]. 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/[Link]. 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 [Link], 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 :
[Link]/24 et [Link]/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/[Link]

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/[Link] 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/[Link]

Zone indirecte
#less /var/cache/bind/[Link]

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 [Link] soa [Link] [Link])
• activer l’enregistrement de NS (ip host [Link] ns [Link])
• activer l’enregistrement de type A (ip host [Link]), 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 «
[Link] » nous l’avons enregistrer en tant que « [Link] ».

Résultat sur la console d’un ping vers [Link]

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

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

Résultat à l’écran d’un ping vers « [Link] »

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
([Link]) et le secondaire DNSServer2 (IP : [Link]).
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/[Link], 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/[Link]. 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/[Link] 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/[Link].
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 [Link]

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 [Link]
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 [Link]
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.[Link] sur
[Link]

#tar -xzvf openfire_3_9_1.[Link] -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 [Link]
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.[Link] sur le site
[Link]
En suite

#tar zxvf spark_2_6_3.[Link] -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

[Link]
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.[Link] -C /var/www/

#cd /var/www/sparkweb/
#mv [Link] [Link]

Pour y accéder [Link]

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 [Link]
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
  description
 facsimileTelephoneNumber
 location (l)
for organizational units)  objectClass
 postalAddress
 seeAlso
 telephoneNumber
 businessCategory
 description
 facsimileTelephoneNumber
organization (defines entries for  o
 location (l)
organizations)  objectClass
 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: <distinguished name
objectClass: <object class
objectClass: <object class
...
<attribute type:<attribute value
<attribute type:<attribute value
...

Une entrée de type personne se présente de la manière suivante :

dn: cn= bamory SANOGO, ou= etudiants, dc=ec2lt, dc= sn

objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Bamory SANOGO
sn: SANOGO
givenName: June
mail: bamory@[Link]
userPassword: {sha}KDIE3AL9DK
uid: bamory
telephoneNumber: 2616
roomNumber: 220

Les commandes de modification ont la syntaxe suivante :

dn: distinguished name

changetype <identifier
change operation identifier
list of attributes...
...
change operation identifier
list of attributes
...
<identifier :
add (ajout d'une entrée),
delete (suppression),
modrdn (modification du RDN),
modify (modification : add, replace, delete d'un attribut)

Le caractère - spécifie le séparateur entre 2 instructions

Par exemple :
Ajouter le numéro de téléphone et le nom du manager pour la personne Alpha TRAORE :

dn: cn= Alpha TRAORE, ou= etudiant, cd=ec2lt, dc=sn

changetype: modify
add: telephonenumber
telephonenumber: (77) 690- 2468
-
add: manager
manager: cn= Lassina Ouya, ou= etudiant, cd=ec2lt, dc=sn

Pour détruire l'entrée

dn: cn= Jean PING, ou= etudiant, cd=ec2lt, dc=sn

changetype: delete

Principe de Contrôle de domaine

Un contrôleur de domaine est un serveur sur lequel on a installé un annuaire et qui s'occupe de
l'authentification des utilisateurs dans un domaine.
Un contrôleur de domaine est nécessairement implémenté dans les grandes entreprises pour bien
gérer et centraliser leurs ressources du réseau en intégrant la sécurité et la performance.
Un domaine regroupe les ordinateurs qui utilisent le même annuaire et qui partage les ressources
du réseau. Tous les serveurs d'un domaine emploient les mêmes comptes utilisateurs. Il nous suffit
alors de taper les informations relatives à un compte d'utilisateur une seule fois pour que tous les
serveurs du domaine reconnaissent ce compte.

IMPLEMENTATION d’un contrôleur de domaine basé sur LDAP avec samba3

 Installation

Dans la nouvelle version (2.4) de OpenLDAP tous les fichiers de configuration se trouve dossier
/etc/ldap/slapd.d/, pour revenir a l’ancienne méthode de configuration (donc la version 2.3) on fait :
On vérifie la version

Configuration
Editons le fichier [Link]

Redémarré le service

Maintenant nous allons renseigner l’annuaire, pour renseigner l’annuaire nous avons besoins des
fichiers ldif, on utilisera ces fichiers pour insérer la racine, l’unité organisationnelle et les
utilisateurs. Voyez cela comme organigramme d’une entreprise.
Un fichier LDIF (LDAP Data Interchange Format, ou format d'échange de données de LDAP) est
un fichier textuel portable décrivant le contenu (ou une partie de celui-ci) d'une base de données
LDAP afin de pouvoir intégrer les données dans n'importe quel autre serveur LDAP.

Le fichier [Link]

Le fichier [Link]
Le fichier [Link]
On vient de créer les utilisateurs système on aurait bien pu créer les utilisateurs simples.
Comme un utilisateur système doit être dans un groupe, créons le fichier ldif suivant
Le fichier [Link]
Les utilitaires

Les utilitaires suivants sont utilisés pour ajouter, modifier, supprimer, rechercher les enregistrements
ldif : ldapadd, ldapmodify, ldapdelete, ldapsearch

Ajoutons les fichiers ldif récemment crées (on peut fusionner ces fichiers en seul fichier qu’on
ajoutera en prenant soins de séparer les différentes entrées par une ligne).

#ldapadd -x -f [Link] -W -D ''cn=admin,dc=esp,dc=sn''

#ldapadd -x -f [Link] -W -D '' cn=admin,dc=esp,dc=sn ''
#ldapadd -x -f [Link] -W -D '' cn=admin,dc=esp,dc=sn ''
#ldapadd -x -f [Link] -W -D '' cn=admin,dc=esp,dc=sn ''

Ou les options:

-W- Demande pour l'authentification simple. Il est utilisé au lieu de spécifier le mot de passe sur la
ligne de commande.
-f- permet de spécifier du fichier ldif
-x- Utiliser l'authentification simple au lieu de SASL
-D- Utiliser le nom distinctif binddn pour se lier à l'annuaire LDAP.
-h- permet de spécifier l’adresse du serveur ldap(utile sur un client autre que le serveur)

Voici quelques exemples d’utilisations des autres utilitaires

Recherche d’information
#ldapsearch -x -D '' cn=admin,dc=ec2lt,dc=sn'' -W -b ''dc=ec2lt,dc=sn'' -s sub
Configuration du NSS
Configurons l’outil NSS pour prendre en compte les informations contenues dans LDAP (par défaut
NSS tient compte uniquement des comptes systèmes).
Le système NSS (Name Service Switch, ou multiplexeur de service de noms, est un système
modulaire pour définir ou récupérer les informations des annuaires système. Pour utiliser LDAP
comme une source de données NSS, il faut mettre en place le paquet libnss-ldap

Installation du paquet NSS

Libnss-ldap-gère les login

Libpam-ldap-gère les mots de passe
Configuration de NSS

Éditons le fichier /etc/nsswitch

Configuration de client LDAP

Pour se passer de l’option –h lors de la manipulation des utilitaires (ldapadd, ldapsearch ...) sur le
client il faut renseigner le fichier etc/ldap/[Link]

Redémarrer le service

Test

Cette section permettra aux applications d'effectuer les authentifications nécessaires à partir des
données de la base LDAP.
Configuration du PAM
PAM (Pluggable Authentication Module), ou module d'authentification enfichable) est une
bibliothèque modulaire centralisant les mécanismes d'authentification, d’initialisation de sessions et
de gestion des mots de passe.

Interface du module
Il existe quatre types d'interfaces pour les modules PAM, chacune correspondant à un aspect
différent du processus d'autorisation:
auth— Cette interface de module sert à authentifier l'utilisateur. Elle demande par exemple la saisie
d'un mot de passe pour lequel elle vérifie la validité.
account— Cette interface de module sert à vérifier que l'accès est bien autorisé. Par exemple, elle
peut vérifier si un compte utilisateur a expiré ou non, ou bien si l'utilisateur est autorisé à se
connecter à un moment donné de la journée.
password— Cette interface de module sert à définir et vérifier les mots de passe.
session— Cette interface de module sert à configurer et gérer des sessions d'utilisateurs. Les
modules ayant cette interface peuvent également effectuer des tâches supplémentaires requises pour
autoriser l'accès, comme par exemple pour monter le répertoire personnel d'un utilisateur ou activer
sa boîte aux lettres.

Indicateurs de contrôle
Lorsqu'ils sont appelés, tous les modules PAM donnent un résultat indiquant soit la réussite, soit
l'échec.
Il existe quatre types d'indicateurs de contrôle prédéfinis, à savoir :

required— Le module doit être vérifié avec succès pour que l'authentification puisse se poursuivre.
Si la vérification d'un module de type required échoue, l'utilisateur n'en est pas averti tant que tous
les modules associés à cette interface n'ont pas été vérifiés.
requisite — Le module doit être vérifié avec succès pour que l'authentification puisse se
poursuivre. Cependant, si la vérification d'un module de type requisite échoue, l'utilisateur en est
averti immédiatement par le biais d'un message lui indiquant l'échec du premier module de types
required ou requisite.
sufficient — En cas d'échec, les vérifications de modules sont ignorées. Toutefois, si la vérification
d'un module de type sufficient est réussie et qu'aucun module précédent de type required n'a échoué,
aucun autre module de ce type n'est nécessaire et l'utilisateur sera authentifié auprès du service.
optional— Les vérifications de modules sont ignorées. Un module de type optional ne devient
nécessaire que pour la réussite d'une authentification lorsqu'aucun autre module ne référence
l'interface.

Apres installation libpam-ldap, les fichiers /etc/pam.d/common-auth, /etc/pam.d/common-

password, et /etc/pam.d/common-account sont configurer par défaut mais on pourrai éventuellement
les adaptés a nos besoins.
Maintenant reste à créer et a monter automatique le répertoire de base des utilisateurs

Installation
Configuration
On édite le fichier #nano/etc/pam.d/common-session

Pour tester maintenant il reste à fermer la session sur le client et se connecter avec un compte
LDAP.

Gestion De L'annuaire Avec Une Interface Graphique

Pour cela on installe le paquet suivant :

Pour y accéder [Link]

Pour accéder, on tape sur un navigateur [Link]
CONTROLEUR DE DOMAINE SAMBA

Samba est une suite d’outils qui permettent de gérer le protocole SMB (maintenant appelé « CIFS
») sous Linux. Ce dernier est employé par Windows pour accéder aux partages réseau et aux
imprimantes partagées.
Samba sait également jouer le rôle de contrôleur de domaine NT (New Technologie).
C’est un outil extraordinaire pour assurer une cohabitation parfaite entre les serveurs sous Linux et
les machines de bureautique encore sous Windows.
Le fonctionnement de Samba repose principalement sur trois services (daemons): smbd, nmbd et
winbind. Lors de l'installation des services de Samba, votre système Ubuntu a été configuré
automatiquement pour gérer ces services dès le démarrage du système.

smbd
Ce service est celui qui permet le partage des fichiers et des imprimantes. Son paramétrage se fait
par l'intermédiaire du fichier de configuration /etc/samba/[Link].

Smbd vérifie toutes les trois minutes ce fichier pour prendre en compte les modifications ; pour une
application immédiate des changements, relancez ce service nmbd Ce service sert à l'envoi et la
découverte des noms NetBIOS (nom des machines) dans le réseau local. Il est également utilisé
pour la résolution de noms et la fonction WINS, lorsque votre serveur Samba est le serveur d'un
réseau NetBIOS. Ses paramètres sont aussi renseignés dans le fichier de
configuration /etc/samba/[Link].

Winbind

Ce service n'est utilisé que lorsqu'un serveur Samba intègre un domaine NT ou pour gérer les
relations d'approbation entre le serveur Samba et un domaine Windows /Active Directory.

Configuration du serveur SAMBA

Le paquet Debian samba contient les deux principaux serveurs (smbd et nmbd). Pour avoir les
utilitaires SAMBA il faut en plus les paquets samba-common.
Modifions /etc/samba/[Link]. Les extraits ci-dessous résument les changements effectués.

[global]
workgroup = RTN
netbios name = PDC
server string = %h server (Samba, Ubuntu)
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n
*password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
name resolve order = lmhosts host wins bcast
time server = Yes
printcap name = cups
add user script = /usr/sbin/adduser -d /home/samba/home/%u -G rtn_users -s /bin/false -m
%u
add machine script = /usr/sbin/useradd -d /dev/null -G rtn_pc -s /bin/false -M %m$
logon script = [Link]
logon path = \\%N\%U\profiles
logon drive = H:
domain logons = Yes
dns proxy = No
wins support = Yes
usershare allow guests = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
admin users = root

[homes]
comment = Home Directories
read only = No
create mask = 0700
directory mask = 0700
browseable = No

[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
write list = @rtn_admin
guest ok = Yes

[profiles]
comment = Users profiles
path = /home/samba/profiles
 create mask = 0600
directory mask = 0700
browseable = No

[printers]
comment = Printer Drivers
path = /var/lib/samba/printers
create mask = 0700
printable = Yes
print ok = Yes
browseable = No

[public]
comment = Répertoire public sur serveur
path = /home/samba/public
read only = No
guest ok = Yes

[private]
comment = Répertoire private du serveur
path = /home/samba/private
valid users = @rtn_users
read only = No

Mise en place
Création de l’administrateur du domaine (root) et le groupe

Création du groupe des utilisateurs du domaine (rtn_users), du groupe des machines (rtn_pc),
Création des répertoires de partage, N’oubliez pas pour les profils itinérants /home/samba/profiles
Et on positionne les bons droits sur les dossiers car les droits d'accès unix sont prioritaires sur les
droits samba.

Et enfin nous créons un utilisateur halimino qu'on ajoute au groupe rtn_users

Redémarrage du service

Pour vérifier que ce dernier fonctionne correctement, on s'y connectera localement, avec la
commande smbclient (pour installer l'utilitaire #apt-get install smbclient).

Test de la configuration avec un client

Editons maintenant le fichier [Link] pour monter au démarrage les partages public et private
#vim /home/samba/netlogon/[Link]
Intégration des clients dans le domaine

Les clients Windows

Xp et vista ont été intégrés sans soucis
Seven
Win7 a besoin d’un paramétrage particulier. Vous pouvez au choix demander le correctif
à Microsoft (ils le transmettent par e-mail) [Link]
Ou manuellement, vous ajoutez les valeurs de registres suivantes
HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\LanmanWorkstation\Pa
rameters
DWORD DomainCompatibilityMode = 1
DWORD DNSNameResolutionRequired = 0

Etape 1:
Lancer regedit
Etape 2:
Aller dans l’arborescence ci-dessus
Cliquer sur Paramètres puis Double Cliquez sur:
DNSNameResolutionRequired:
-- Sélectionnez Décimale puis entrez la valeur 0
– Ensuite Double cliquez sur:
DomainCompatibilityMode:
-- sélectionnez Décimal puis entrez la valeur 1
Après le redémarrage de la machine, afin de recharger la base de registre, on pourra alors joindre le
pc au domaine, comme ceci

Intégration d’une machine XP

Apres redémarrage de la machine cliente connectez-vous
Intégration d'une machine ubuntu

Sur le serveur

Il faut ajouter ce partage sur le serveur SAMBA dans /etc/samba/[Link]

Sur le client

Configuration de PAM

Les fichiers PAM permettent de gérer les connexions et autorisations qu'elles soient locales
(gdm,kdm,xdm, LightDM) ou distantes (ssh). Pour plus d'information sur PAM reportez vous à
cette page [Link]

Ici nous voulons que les utilisateurs du domaine puissent se connecter localement donc nous allons
modifier le fichier /etc/pam.d/gdm si vous êtes sous Ed/Ubuntu et si vous utilisez Kubuntu c'est
/etc/pam.d/kdm, dans notre cas /etc/pam.d/lightdm. En premier lieu faites une copie de sauvegarde
de votre fichier d'origine.

Installation de paquets

#cp /etc/pam.d/lightdm /etc/pam.d/[Link]

Puis éditez-le:
#vim /etc/pam.d/lightdm

Supprimez le contenu du fichier puis ajoutez les lignes suivantes :

#vim /etc/pam.d/lightdm-autologin

Configuration de pam_mount

Pam_mount est une extension de PAM permettant de monter un système de fichier quand un
utilisateur se connecte. On pourra par exemple lancer le montage d’un répertoire CIFS en utilisant
le mot de passe que l’utilisateur vient de rentrer. De plus, la partition sera démontée quand
l’utilisateur va se déconnecter
#vim /etc/pam.d/common-pammount (Par défaut ce fichier n'existe pas il va falloir créer
)

Maintenant il reste à monter de démonter la manière automatique les répertoires de base des
utilisateurs et éventuellement les partages (public et private).

#vim /etc/security/pam_mount.[Link]
NB: homemount et partagePublic et partagePrive sont des noms de partage, à la place de l'adresse ip
on aurait pu mettre le nom NetBIOS(PDC).

Au chargement du système Ubuntu, LightDM vous affiche une liste de comptes d'utilisateurs
existants. Par défaut, tous les comptes d'utilisateurs qui ont été créés dans votre système Ubuntu
sont présents dans cette liste des comptes. Pour que LightDM nous le choix de mettre le login et
mot de passe configurons ces quelques lignes

#vim /etc/lightdm/[Link]

Redémarrer les services smbd, nmbd, lightdm

 Contrôleur de domaine avec Samba4
Composants de PDC avec Samba4
Samba est un logiciel d'interopérabilité entre Windows et Unix et ses dérivés. Il offre la possibilité
aux ordinateurs d'un réseau d'accéder aux imprimantes et aux fichiers des ordinateurs sous Unix et
permettent aux serveurs Unix de se substituer à des serveurs Windows.
À partir de la version 3, Samba fournit des fichiers et services d'impression pour divers clients
windows et peut s'intégrer à un Domaine Active Directory, soit en tant que contrôleur de domaine
principal (Primay Domain Controller ) ou en tant que membre d'un domaine.
Dans ce rapport on utilise samba4 comme crontrôleur de domaine. Pour qu'il soit un PDC, il lui faut
trois composants à savoir :
DNS : est utilisé pour définir le contrôleur de domaine comme serveur de resolution de nom qui a
été détaillé dans le document plus haut.
LDAP : est utilisé comme système d'information (base de données) du domaine d'ailleurs c'est dans
LDAP qu'il stocke les données relatives au DNS, aux utilisateurs etc . LDAP est aussi détaillé plus
haut dans le document.
KERBEROS : est utilisé comme système d'authentification des utilisateurs et des services que nous
allons détaillé .

Kerberos a été conçu dans le but de proposer un protocole d'authentification multi- plateforme,
disposant d'un système de demande d'identification unique, et permettant de contacter ensuite autant
de services que souhaité. C'est pour ces raisons qu'il s'appuie sur le protocole de Needham –
Schroeder.

Il s'agit d'un protocole sécurisé, dans le sens où il ne transmet jamais de mot de passe en clair sur le
réseau.. Il transmet des messages cryptés à durée de vie limitée.

Le terme « single sign- on », utilisé en sous- titre de ce document, décrit le fait que l'utilisateur
final n'a besoin de s'authentifier qu'une fois pour utiliser toutes les ressources du réseau supportant
Kerberos au cours de sa journée de travail (en réalité, au cours du temps de session spécifié par
l'administrateur : environ vingt heures, en général).

Le système Kerberos repose sur un « tiers de confiance » (Trusted thirdparty), dans le sens où il
s'appuie sur un serveur d'authentification centralisé dans lequel tous les systèmes du réseau ont
confiance. Toutes les requêtes d'authentification sont ainsi routées au travers de ce serveur Kerberos
centralisé.

Le système d'authentification mutuelle utilisé permet non seulement de prouver que l'utilisateur
derrière son clavier est bien qui il prétend être, mais aussi que le service qu'il tente d'utiliser
correspond également. De cette manière, la communication instaurée assure la confidentialité des
données sensibles. Les trois concepts définis ci- dessus permettent de décrire les bases du service
d'authentification réseau Kerberos.

Présentation de l'authentification avec Kerberos

Kerberos s'appuie donc sur ces bases lorsqu'un utilisateur du réseau souhaite utiliser un service. Les
trois entités présentées ici, le client, le service et le serveur d'authentification, sont définies en tant
que « principals » dans Kerberos.

Le service a besoin de savoir qui est l'émetteur de la requête. C'est pour cela que l'utilisateur lui
présente un ticket, qui lui a été remis par le centre de distribution des clés Kerberos, ou KDC
(Kerberos Key Distribution Center). Le ticket doit donc contenir des informations permettant
d'identifier clairement l'utilisateur. Il doit montrer que l'émetteur détient une information que lui
seul peut connaître, comme par exemple un mot de passe.

Kerberos nécessite que l'utilisateur et le service bénéficient de clés enregistrées auprès du KDC, et
requiert la synchronisation des horloges des clients et des serveurs du réseau. La clé de l'utilisateur
est dérivée d'un mot de passe que lui- seul connaît, tandis que celle du service est générée
aléatoirement (personne ne peut taper de mot de passe dans ce cas).

A partir de ce point, le déroulement est très similaire au protocole décrit précédemment.

Le client émet une requête auprès du KDC, précisant son nom ainsi que celui du service souhaité.
Lorsque le KDC reçoit ce message, il crée deux copies d'une clé générée, la clé de session, qui sera
utilisée au cours de la communication entre le client et le service.
Le KDC envoie un message comportant deux « boîtes », l'une contenant une copie de la clé de
session ainsi que le nom du service, cryptée à l'aide de sa clé privée ; la seconde contenant la
deuxième copie de la clé de session, ainsi que le nom de l'utilisateur, et cryptée à l'aide de la clé du
serveur d'application. Cette deuxième clé est appelée « ticket ».

L'utilisateur ouvre la première boîte avec sa clé et récupère le nom du service. Il ne peut pas ouvrir
la seconde, puisqu'elle a été« fermée » avec la clé du serveur d'application. Il va alors composer un
nouveau message contenant non seulement cette deuxième boîte, mais aussi une boîte contenant son
nom et l'heure d'envoi et cryptée à l'aide de la clé de session. Cette troisième boîte est appelée «
authenticator » dans le jargon Kerberos. Le serveur d'application reçoit ce message, ouvre la
deuxième boîte à l'aide de sa clé privée, obtient ainsi la clé de session qu'elle contient et peut enfin
ouvrir la troisième boîte qui lui était destinée. Le service connaît ainsi le nom de son interlocuteur,
et l'heure de son poste de travail. Cette information est très importante, puisqu'elle permet de
s'assurer que personne n'a copié le ticket. Comme les horlo ges ne sont pas toujours en parfaite
synchronie, une marge de cinq minutes est autorisée par défaut. De plus, le service maintient une
liste des « authenticator » envoyés, afin de s'assurer qu'ils ne soient pas ré- émis.
En général, l'« authenticator » contient beaucoup plus d'informations que celles que nous exposons
ici, comme par exemple un « checksum » pour valider l'intégrité des données, ou une clé de
cryptage pour assurer la confidentialité des communications futures entre le client et le service.

Parfois, l'utilisateur souhaite que le service s'authentifie à son tour. Pour cela, le service récupère
l'heure de la troisième boîte (« authenticator »), le met dans une quatrième boîte avec son nom, et la
crypte à l'aide de la clé de session. Quoi qu'il en soit, cette boîte doit contenir l'heure contenue dans
la troisième, pour assurer au client la provenance du message, car lui- seul est en mesure de valider
cette information.

TGS / TGT
Les échanges décrits jusqu'ici sont nécessaires à chaque fois qu'un utilisateur tente d'atteindre un
service, et à chaque fois qu'il doit entrer un mot de passe (qui permet de décrypter la première
boîte). Une solution consisterait à stocker la clé dérivée du mot de passe, mais cela engendrerait un
problème de sécurité : une copie de ces clés permettrait de se faire passer pour l'utilisateur.

Kerberos offre une solution à ce problème, en répartissant les fonctionnalités du KDC : d'un côté le
serveur d'authentification (« Authentication Server ») ; de l'autre, le serveur d'obtention de ticket («
Ticket- Granting Server »). Le serveur d'authentification est chargé de produire les tickets pour le
TGS.

Le client fourni un mot de passe, en échange duquel le TGS lui donne un ticket (« Ticket- Granting
Ticket ») et la clé de session associée (cf Figure 4.2). Celui- ci est valable en général pendant huit
heure. Il s'agit de la seule communication entre le client et le serveur d'authentification. Comme le
TGT est le premier ticket obtenu, il est aussi appelé « ticket initial ». Ensuite, quel que soit le
service dont voudra bénéficier le client, il enverra le TGT au TGS afin d'obtenir un ticket ordinaire
(cf Figures 4.3 et 4.4). Il n'aura donc plus besoin d'entrer son mot de passe, puisque le KDC et lui-
même partagent la clé de session. L'utilisateur peut donc simplement adresser un message au TGS,
contenant le TGT ainsi qu'un nouvel « authenticator », ce qui l'identifiera immédiatement.

Mon royaume pour Kerberos

Jusqu'à présent nous n'avons considéré qu'un seul serveur d'authentification et un seul TGS,
installés ou non sur la même machine. Cependant, dans une grande entreprise, il n'est pas rare de
décomposer le réseau en « royaumes » ou « realm ». En effet, avec une augmentation des requêtes
d'authentification sur le réseau, le KDC deviendrait un goulot d'étranglement pour le processus, ce
qui n'est pas permis pour un système distribué comme Kerberos.

Les royaumes correspondent généralement aux zones DNS. Par conséquent, le nom du royaume est,
dans ce cas, le nom de domaine DNS en majuscule. Pour permettre a un utilisateur d'un royaume
d'atteindre un service situé dans un autre, le royaume de l'utilisateur doit s'authentifier auprès du
TGS distant (« Remote TGS »). Les deux royaumes échangent alors une paire de clés, qu'ils
utiliseront uniquement lors de la phase d'authentification entre royaumes. En fait, cette procédure
est transparente pour l'utilisateur. Le programme Kerberos se charge de contacter le serveur
d'authentification pour accéder au TGS, puis il contacte le TGS pour atteindre le TGS distant, et
enfin le service.

Kerberos V5 propose même une structure hiérarchique des royaumes, car il n'est pas toujours utile
de tous les traverser pour atteindre le service. En fait, l'ensemble des royaumes à traverser est
enregistré dans les tickets.

Le cas d'un client voulant atteindre un service au travers d'un routeur mais dont l'adresse est
translatée (NAT) pose une difficulté, car l'adresse IP de la machine émettant la requête apparaît dans
les tickets. La solution consiste soit à paramétrer chaque client du réseau NAT afin qu'il utilise
l'adresse interne du routeur pour les demandes de tickets, soit à utiliser l'option « - A » de
l'application kinit , pour préciser une demande de tickets sans adresse IP. Il est aussi possible de
modifier le fichier /etc/[Link] en y ajoutant, dans la section « libdefaults », la ligne :
noaddresses = true

Toutes ces procédures vous semblent sans doute bien compliquées, mais aux yeux de l'utilisateur,
tout ceci est transparent : les programmes Kerberos se chargent de contacter le bon royaume, et
l'utilisateur n'a plus qu'à simplement utiliser le service qu'il désire.

IMPLEMENTATION
Lors de l'intallation de samba4 il vient avec les trois comportants à savoir : DNS, LDAP et
KERBEROS donc il faut s'assurer que la machine sur laquelle nous allons utiliser qu'il y'ait pas ces
composants là et supprimer les fichiers suivants :

Supprimer aussi le contenu du repertoire /var/lib/samba/private/ car le contenu de ce dernier sera

généré :

Installation et Configuration du PDC

Pour l'installation exécuter la commande suivante :

ensuite renseigner votre nom de domaine DNS (exemple : realm : [Link] et le dns forwarding
mettez l'addresse IP de votre passerelle) et les autres options prenez les celles par defaut ou
proposées.
Configuration du kerberos
on crée un lien symbolique du fichier [Link] dans /etc :

Pour tester le fichier de configuration, utiliser la commande testparm. Lorsque le programme

testparm s'execute, il affiche les sections définissant les partages, puis vous demande d'appuyer sur
entrée pour visualiser la définition des services.

Maintenant nous allons tester le fonctionnement du DNS qui a été installé :

renseigner le client DNS de votre machine en pointant sur la machine qui héberge votre DNS.

vim /etc/[Link]
Tester de bon fonctionnement du serveur Kerberos :

Teste de fonctionnement du serveur LDAP :

Tester le compte de l'administrateur du domaine

kinit administrator@[Link]

Intégration de machine Windows dans le domaine

Pour intégrer un poste Windows à un domaine AD, il faut obligatoirement une version
professionnelle, les versions familiales n'étant pas prises en charge. Que ce soit en IP fixe ou en
DHCP, le poste client devra parvenir à résoudre votre zone DNS. Enfin, et ceci est une contrainte
inhérente au protocole Kerberos, il ne doit pas y avoir un décalage d'horloge de plus de cinq
minutes entre le KDC et le client.
Pour intétégrer une machine, on modifie les paramétres de la carte réseau en précisant le serveur
DNS qui est le contrôleur :

Cliquer sur ok et il vous demande de redémarrer la machine.

Intégration de machine Linux dans le domaine

Pour intégrer une machine linux dans le domaine il faudrait installer les paquets suivants et ensuite
paramètrer :
 apt-get install samba winbind libnss-winbind krb5-user libpam-winbind

configuration du fichier /etc/samba/[Link]

Configuration du client Kerberos

Dans la section [libdefaults] préciser votre domaine tout en majuscule et ajouter aussi dans la
section [realms] ajouter le nom de votre controleur de domaine comme sur la capture ci-dessous :
Pam permet l’authentification. L’installeur Debian/Ubuntu a déjà préconfiguré les modules
PAM pour utiliser winbind. Il reste néanmoins quelques fichiers à modifier.
Modifiez tout d’abord le fichier /etc/[Link] pour ajouter l’authentification winbind:

Il faut activer le module pam_mkhomedir qui va créer le répertoire home automatiquement

à partir d’un squelette, auquel cas l'utilisateur n'arrive pas à se loguer avec ces comptes
dynamiques. Modifiez le fichier pam common-session (/etc/pam.d/common-session) en ajoutant
la ligne suivante après le pam_winbind.so.

Il ne reste qu'a joindre la machine au domaine avec la commande suivante, pointer la machine
d'abord vers le DNS du contrôleur :

net ads join -U Administrator

Démarrer le winbind :

service winbind start

Si tout est correctement configuré la commande wbinfo -u devrait retourner l’ensemble des
utilisateurs du domaine :
wbinfo -u

Ce qui dit avec comptes utilisateurs nous pouvons ouvrir des sessions avec ces derniers.
 Outils d'administration du PDC avec samba-tool
Comme tout bon programme Unix, Samba 4 est entièrement administrable en ligne de commandes.
La commande samba-tool permet de réaliser l'ensemble des tâches courantes d'administration d'un
réseau Microsoft Windows. La syntaxe de la commande est très bien détaillée dans l'aide
contextuelle. Les paramètres additionnels sont documentés en indiquant le paramètre -H ou –help à
la sous-commande désirée sans indiquer de paramètre.

Gestion des utilisateurs du PDC avec samba-tool :

La capture ci-dessus montre les différentes actions qu'on peut appliquer aux
utilisateurs du domaine à savoir :

• ajouter ou créer un nouveau utilisateur

• supprimer un utilisateut

• activer un utilisateur
• désactiver un utilisateur
• changer le mot de passe d'un compte utilisateurs
• spécifier la date d'expiration d'un compte utilisateur
• définir un mot de passe pour un utilisateur
• lister les utilisateurs du domaine

Voici la liste des utilisateurs disponibles sur le domaine :

Création un nouveau compte utilisateur

Spécifier la date d'expiration d'un compte utilisateur par exemple le compte sera expiré dans toto
dans 20 jous.

Executer la commande suivante pour avoir toutes les informations de la maniére on peut appliquer
des conditions d'expiration d'un compte :