IDENTIFICATION DES MEMBRES DU JURY

Dédicace

A ma Famille

III
 Remerciements

La réalisation de ce rapport n'a été possible que grâce au concours de plusieurs personnes
à qui je voudrais témoigner toute ma reconnaissance. Il m’est ainsi agréable d’exprimer ma
gratitude en adressant mes sincères remerciements:

Au Pr NNEME NNEME Léandre, Directeur de l’ENSET pour avoir permis d’accéder a

cette formation et n’avoir ménagé aucun effort pour la qualité des enseignements au sein de
cet établissement dont il a la charge;

Au président et tous les membres du jury, pour avoir accepté d'évaluer ce travail,
malgré leurs multiples occupations;

Au Dr Jerry Garvin LONLAC KONLAC, chef de département informatique de

l'ENSET de Douala pour son encadrement durant cette année académique;

Au Dr PAUNE Felix, pour l’encadrement et la supervision de ce travail ;

A M. NNEME Oswald Jordan, pour sa disponibilité à nous encadrer pendant la

réalisation de ce travail.

A tous les enseignants du département Informatique de l'ENSET de Douala pour

m’avoir transmis leur savoir et leur passion tout au long de cette année académique;

A M. EKONG EKONG Charles Guy, déjà pour avoir accepté m'accueillir au sein de sa
structure, en suite pour sa patience, sa disponibilité et surtout ses judicieux conseils, qui ont
contribué à alimenter ma réflexion;

A Tous mes promotionnaires, pour différents échanges et écoutes tout au long de la

réalisation de ce travail;

A M. Ganael LAPLANCE, expert samba pour ses conseils et sa disponibilité à répondre

aux différents mails d'assistance;

IV
 Avant-propos
L’Ecole Normale Supérieure d’Enseignement Technique (ENSET) de Douala, créée
par arrêté présidentiel N° 260 / CAB / PR du 10 aout 1979, est un établissement
d’enseignement supérieur, située à Douala et ayant pour missions :
 La formation des enseignants destinés aux Lycées d’Enseignement Technique du
Cameroun ;
 Le recyclage et le perfectionnement du personnel enseignant dans le cadre de la
formation continue ;
 La recherche appliquée pédagogique.

Cependant, en tant qu’école technologique et au regard de sa vocation régionale en

matière de nouvelles technologies, l’ENSET adopte le système LMD (Licence-Master-
Doctorat) en 2007. Ce système s’articule autour du savoir, du savoir-faire, du faire-savoir et
du savoir-être. Ainsi, à l’ENSET un accent particulier a été mis une fois de plus sur la
professionnalisation et la qualité des enseignements afin de donner l’opportunité à
l’enseignant d’être non seulement un spécialiste de l’enseignement, mais aussi de répondre de
manière efficace et efficiente aux exigences des nouvelles technologies dans le milieu
industriel. L’ENSET de Douala fonctionne en cours du jour (Formation Initiale) et en cours
du soir (Formation Continue ou CPS : Cours de Promotion Sociale).
À l’issue de la formation en cours du soir, chaque apprenant doit présenter :
 Un rapport de stage pour la fin de ses études de 3eme année, études sanctionnées par
l’obtention d'une Licence ;
 Un rapport de stage pour la fin de ses études de 4eme année, études sanctionnées par
l’obtention d'un Master 1 ;
 Un mémoire pour la fin des études de 5eme année, études sanctionnées par l’obtention
d'un Master 2.

C’est dans cette optique que nous avons effectué un stage en entreprise sous le thème
« Mise sur Pied d’un Contrôleur de Domaine SAMBA avec Authentification via un
Annuaire LDAP et Gestion des Quotas de Disque » et présentons ce rapport en vue de
l’obtention du Master 1.

V
 Résume
Pour la clôture de l'année académique du Master 1 à l'ENSET de Douala, les étudiants
sont appelés à faire un stage en entreprise et produire un rapport. A cet effet, j'ai effectué un
stage dans la société NIS SYSTEMS, qui fait dans la prestation des services informatiques.
Pendant ce stage j'ai travaillé sur le projet d'un établissement de formation. Il était
question de mettre en place un contrôleur de domaine, un annuaire et la gestion de l'espace de
stockage (disque dur) entre les différents utilisateurs. Le travail a été fait sous Linux avec la
distribution Redhat. Nous avons ainsi travaillé avec SAMBA comme contrôleur de domaine,
LDAP comme annuaire et les quotas disque ont été configurés.
La livraison de la commande du client a été faite en ajoutant l'ensemble des postes de
travail au domaine, la création des comptes des différents utilisateurs et des tests ont été faits
sur le respect des quotas disque par utilisateurs.

Mots clés : Annuaire, LDAP, contrôleur de domaine, quota, SAMBA, OpenLDAP.

VI
 Abstract
For the closing of the academic year of the Master 1 at the ENSET of Douala, students are
asked to do an intership in compagny and produce a report. For this purpose, I did an intership
in the NIS SYSTEMS company, which is involved in the delivery of IT services.
During this intership, I worked on the project of a training institute. There was talk of
setting up a domain controller, a directory and storage space management (hard disk) among
the different users. The work was done on Linux with the redhat distribution. We worked with
SAMBA as a domain controller, LDAP as a directory, and disk quotas have been configured.
The delivery of the customer's order was by adding all workstations to the domain,
creating the accounts of different users and testing was done on compliance with disk quotas
per user.

Keywords : Directory, LDAP, domain controller, quota, SAMBA, OpenLDAP.

.

VII
 Liste des tableaux
Tableau 1.1:Les standards de la norme X.500............................................................................9

Tableau 1.2:Evolution de LDAP...............................................................................................11

Tableau 1.3:Modèles LDAP.....................................................................................................12

Tableau 1.4:Comparaison entre LDAP et une base de données..........................................13-14

Tableau 1.5:Comparaison entre LDAP et NIS..........................................................................14

Tableau 1.6:Les principaux paramètres de Samba..............................................................18-19

Tableau 4.1:Gestion des comptes sans annuaire.......................................................................54

Tableau 4.2:Gestion des comptes avec annuaire.................................................................54-55

VIII
 Liste des figures

Figure 1.1:Organigramme de NIS SYSTEMS Sarl....................................................................4

Figure 1.2:Hiérarchisation des données d'un annuaire électronique...........................................5

Figure 1.3:Application X.500 et LDAP sur le LAN.................................................................11

Figure 1.4:Architecture LDAP..................................................................................................13

Figure 1.5:Communication client/serveur LDAP.....................................................................14

Figure 1.6:Echange de données au format LDIF......................................................................15

Figure 1.7:Fonctionnement de Samba......................................................................................18

Figure 1.8:Fonctionnement du DNS.........................................................................................21

Figure 3.1:Architecture réseau existant.....................................................................................28

Figure 3.2:Démarrage de l'installation de Redhat.....................................................................28

Figure 3.3:Choix de langue.......................................................................................................29

Figure 3.4:Création des partitions.............................................................................................30

Figure 3.5:Ecran de connexion.................................................................................................31

Figure 3.6:Arborescence de l'annuaire......................................................................................36

Figure 3.7:Ajout d'un poste Windows au domaine...................................................................43

Figure 3.8:Bienvenue dans le domaine Foadweb.cm...............................................................43

Figure 4.1:Interface d'administration phpLDAPadmin.............................................................55

Figure 4.3:SAMBA et OpenLDAP en UN...............................................................................56

Figure 4.3:Architecture finale...................................................................................................57

Figure 4.4:Architecture Samba et LDAP avec réplication........................................................57

IX
Sigles et abréviations
ACL: Access Control List

BDC: Backup Domain Controller

CA: Certificate Authority

CCITT : International Telegraph and Telephone Consultative Committee

CIFS : Common Internet File System

DC: Domain Controller

DIT: Directory Information Tree.

DN: Distinguished Name

DNS: Domain Name Service

ENSET: Ecole Normale Supérieure de l'Enseignement Technique

FTP: File Transfer Protocol

GID: Group Identifier

IETF : Internet Engineering Task Force

ITU : International Telecommunications Unions

ISO : International Organization for Standardization

LDAP: Lightweight Directory Access Protocol

LDIF: Lightweight Data Interchange Format

MBR: Master Boot Record

NDS : Novell Directory Service

NetBIOS: Network Basic Input/Output System

NFS: Network File System

NIS: Network Information Service

NTIC : Nouvelles Technologies de l'Information et de la Communication

X
NSS: NSSwitch, Name Service Switch

PAM: Pluggable Authentication Module

PABX: Private Automatic Branch Exchange

PDC: Primary Domain Controller

RFC: Request For Comments

RPC: Remote Procedure Call

RPM: Redhat Packet Manager

SAM: Security Account Manage

SGBD : Système de Gestion de Base de Données

SID: Security Identifier

SMB : Server Message Block

TCP/IP: Transport Control Protocol / Internet Protocol

TLS: Transport Layer Security

UID: User Identifier

VSAT: Very Small Aperture Terminal

XI
TABLE DES MATIERES

Dédicace ................................................................................................................................... III

Remerciements ......................................................................................................................... IV
Avant-propos ............................................................................................................................. V
Résume ..................................................................................................................................... VI
Abstract ...................................................................................................................................VII
Liste des tableaux .................................................................................................................. VIII
Liste des figures ....................................................................................................................... IX
Sigles et abréviations ................................................................................................................. X
Introduction Générale ................................................................................................................. 1
Chapitre 1 : Présentation de la structure d'accueil et l'état de l'art ............................................ 2
1.1- Présentation de la structure d'accueil .............................................................................. 2
1.2- Etat de l'art. ..................................................................................................................... 5
1.2.1- Annuaires électroniques. .......................................................................................... 5
1.2.1.1- Caractéristiques des annuaires électroniques .................................................... 6
1.2.1.2- Différence entre annuaire et base de données ................................................... 6
1.2.1.3- Les annuaires en exploitation............................................................................ 7
1.2.1.3a - Novell NDS ................................................................................................ 7
1.2.1.3b - Système d'exploitation Windows ............................................................... 7
1.2.1.3c - NIS (Network Information Service) ........................................................... 7
1.2.2- Les standards ............................................................................................................ 8
1.2.2.1- La norme X.500 ................................................................................................ 9
1.2.2.2 - LDAP (Lightweight Directory Access Protocol) ........................................... 10
1.2.2.2a - Les Modèles LDAP .................................................................................. 12
1.2.2.2b- Architecture LDAP ................................................................................... 12
1.2.2.2c- LDAP contre les autres technologies ........................................................ 13
1.2.2.2d- Organisation client/serveur ....................................................................... 14
1.2.3- Contrôleurs de domaine ......................................................................................... 15
1.2.3.1 - Les avantages d'un contrôleur de domaine. ................................................... 16
1.2.3.2 - Les inconvénients d'un contrôleur de domaine. ............................................. 16
1.2.3.3 - Choix d'un contrôleur de domaine ................................................................. 17
1.2.3.3a - Contrôleur de domaine SAMBA .............................................................. 17
1.2.3.3b - Samba 4 et Active Directory .................................................................... 19
1.2.3.3c - Les contraintes de Samba 4 ...................................................................... 19
1.2.4- Serveur DNS .......................................................................................................... 20
1.2.4.1- Fonctionnement du service des noms de domaine .......................................... 20
1.2.5 - Gestion des quotas de disque et sécurisation des échanges avec TLS .................. 21
1.2.6 - Communication TLS avec le serveur LDAP ........................................................ 22
1.2.6.1 - Pourquoi Tls ? ................................................................................................ 22
1.2.6.2- Les clefs et les certificats ................................................................................ 22
Chapitre 2 : Les outils utilisés dans le cadre du projet ............................................................. 24
2.1- Système d’exploitation.................................................................................................. 24
2.1.1- choix du système .................................................................................................... 24
2.1.2- Choix de la distribution .......................................................................................... 25
2.1.3- Configuration matérielle requise ............................................................................ 25
2.2 - Annuaire LDAP ........................................................................................................... 25
2.3 - SAMBA ....................................................................................................................... 27
2.4 - Quota de disque et sécurisation des échanges .............................................................. 27
Chapitre 3: Implémentation de la solution ............................................................................... 28
3.1- Installation du système RedHat Enterprise Linux 7.7 .................................................. 28
3.2- Configuration du serveur DNS ..................................................................................... 32

XII
TABLE DES MATIERES

3.2.1- Edition du fichier /etc/named.conf ......................................................................... 32

3.2.1.1- Description des principales options d’un fichier named.conf. ........................ 32
3.2.1.2- Contenu de notre fichier /etc/named.conf ....................................................... 33
3.2.2- Edition du fichier /var/named/foadweb.cm ............................................................ 33
3.2.2.1- Types d’enregistrements associés à la définition d’une zone ......................... 33
3.2.2.2- Contenu de notre fichier /var/named/foadweb.cm .......................................... 34
3.2.3- Edition du fichier /var/named/named.local ............................................................ 34
3.2.4- Edition du fichier /var/named/foadweb.inv ........................................................... 35
3.2.5- Edition du fichier /etc/resolv.conf .......................................................................... 35
3.2.6- Lancement et Test du serveur ................................................................................ 35
3.3- Installation d’OpenLDAP ............................................................................................ 35
3.3.1- Construction de notre arborescence ....................................................................... 35
3.3.2- Téléchargement, recompilation et installation de openldap .................................. 36
3.3.3- Configuration de Openldap .................................................................................... 37
3.3.4- Installation et configuration de smbldap-tools ....................................................... 39
3.4- Installation de SAMBA ................................................................................................ 39
3.4.1- Téléchargement, recompilation et installation de samba ....................................... 39
3.4.2- Configuration de samba : smb.conf ....................................................................... 40
3.4.3- Premiers tests ......................................................................................................... 42
3.5- TLS entre client et le serveur LDAP ............................................................................ 44
3.5.1- Génération des clefs et du certificat ....................................................................... 44
3.5.2- Mise en place côté serveur ..................................................................................... 45
3.5.3- Mise en place côté client ........................................................................................ 46
3.5.4- Test de connexion sécurisée ................................................................................... 46
3.5.5- Mise en place pour Samba .................................................................................... 46
3.6- Gestion des quota de disque ......................................................................................... 47
3.6.1- Configuration de /etc/fstab ..................................................................................... 47
3.6.2- Création des structures nécessaires au fonctionnement des quotas ....................... 48
3.6.3- Attribution et vérification des quotas ..................................................................... 48
3.6.3.1- Fixer des quotas .............................................................................................. 48
3.6.3.2- Fixer un délai .................................................................................................. 49
3.6.3.3 - Dépassement de quotas : que se passe-t-il ? .................................................. 50
3.6.3.4- Vérification et affichage des quotas ................................................................ 51
Chapitre 4 : Les résultats obtenus ............................................................................................ 54
4.1 - Résultats techniques ..................................................................................................... 54
4.2 - Résultats économiques ................................................................................................. 55
4.3 - Perspectives .................................................................................................................. 57
Conclusion Générale ................................................................................................................ 58
Bibliographie ............................................................................................................................ 59

XIII
 Introduction Générale
Un poste de travail peut être utiliser par plusieurs personnes, chacun disposant d'un
compte (login et mot de passe). Ce compte est valable uniquement lorsque l'utilisateur se
connecte sur le poste de travail en question. Pour avoir accès à un autre poste, un nouveau
compte devra être crée sur ce dernier. Il se pose rapidement un problème de gestion
d'authentification des utilisateurs sur les postes de travail au sein d'une entreprise ou une
structure, d'où la nécessité de mettre en place un système permettant aux utilisateurs de
changer de poste, se loger sur leur compte personnel et récupérer leurs données, mais sans
avoir à créer un nouveau compte pour chaque changement de poste. Pour cela, nous devons
avoir un système avec une gestion centralisée des comptes. Le système doit être assez flexible
pour pouvoir incorporer par la suite d'autres services. Nous avons donc le choix d'utiliser un
Annuaire libre pour les serveurs Linux ou propriétaire comme Active Directory pour les
serveurs Windows. Le logiciel Samba s'appuyant sur le protocole SMB/CIFS et permettant le
partage de fichiers, d'imprimantes et de faire office de contrôleur de domaine servira à mettre
en place un domaine.
LDAP est un protocole d'accès à un annuaire, normalisé à la fin des années 1990.
LDAP comme annuaire, permet de stocker des données organisées selon des classes
particulières et présentées dans un arbre. On peut y stocker bien de choses telles que : des
comptes Unix, des données personnelles, des données sur des objets plus ou moins abstraits,
comme des données d'identification, des certificats, un parc matériel, et plus généralement
tout ce qui peut être nommé et à qui on peut attacher des informations.
Depuis la version 2.2.5, Samba permet de stocker ses utilisateurs dans un annuaire
LDAP. Ceci offre un intérêt majeur : une gestion simplifiée et centralisée des comptes Samba.
Ainsi, le fichier smbpasswd, dans lequel sont habituellement stockés les comptes utilisateurs,
est complètement remplacé par des accès à l'annuaire LDAP (sauf pour le stockage du mot de
passe du serveur LDAP qui se fait toujours dans ce fichier). Les avantages d'une telle
architecture sont nombreux : robustesse accrue, souplesse d'utilisation, grande disponibilité,
etc...
Pour parvenir à une solution efficace et durable au problème, notre travail se déroulera en
quatre grandes parties:
 Un premier chapitre, présentera la structure d'accueil ainsi qu'un état de l'art des
annuaires électroniques et contrôleurs de domaine.
 Il sera présenté dans le second chapitre, les outils à utiliser dans le cadre du
projet
 Un troisième chapitre portera sur l'implémentation de la solution
 Dans le quatrième chapitre, une présentation des résultats obtenus sera faite.

1
Chapitre 1 : Présentation de la structure d'accueil et l'état de l'art

Après la présentation de la structure où le stage a été effectué, nous ferons une revue
de littérature des annuaires électroniques, des contrôleurs de domaines ainsi que la gestion des
espaces de stockage.

1.1- Présentation de la structure d'accueil

Networks Intelligent Services Systems est une entreprise camerounaise fortement
expérimentée en NTIC et en Communications par Satellite avec des années d’expériences
dans la conception, la fourniture et la mise en œuvre des solutions clés en main en IT, en
Communications et en sécurité au Cameroun et en Afrique Centrale. Elle se spécialise dans le
service aux entreprises à travers des prestations de Conseil, d’Assistance et la fourniture des
Solutions Informatiques à forte valeur ajoutée, fourniture Internet. Sa vocation est d'assister sa
clientèle dans l'implémentation et la sécurisation de leur parc informatique. Elle crée de la
valeur pour ses clients à travers un ensemble complet de services et solutions, qui leur
permettent d’optimiser leur gestion informatique. Ses équipes constituées de professionnels
expérimentés, et le soutien de ses multiples partenaires garantissent des services de très
grande qualité. NIS SYSTEMS Sarl a son siège à Douala au CAMEROUN.

Câblage réseaux structuré pour la convergence Voix, Vidéo Et Data :

 Etude et conception des schémas de câblage informatique moderne (LAN/MAN

/WLAN)

 Câblage réseaux électriques ondulées pour protections des périphériques réseaux et

serveurs

 Installations des onduleurs de grandes capacités

 Fournitures des équipements réseaux

 Audit, mise à niveau du réseau existant et normalisations

 Fibre optique

Systèmes de vidéo et visioconférence :

 Etude, installation et mise en service des systèmes de Visio et vidéoconférence sur IP

Domotique (maison intelligente) :

2
  Etude et conception

 Site Survey

 Installation et mise en service de notre solution de domotique professionnelle qui

intègre la gestion d’énergie, les alarmes d’intrusion, détection de mouvement, capteurs
d’ouverture et de fermeture de porte et fenêtre, capteur de température intérieur,
caméra de vidéosurveillance…

 Services de maintenance

Système de téléphonie pour entreprise :

 Téléphonie standard privée (PABX) : système analogique

 Système téléphonique moderne (IPPBX) et téléphone IP

 Mise à niveau du réseau téléphone existant au standard moderne

 Solutions Call Center

 Audit et Maintenance

Services par satellite :

 Site Survey VSAT

 Installation et mise en services des terminaux VSAT en bande C, Ku et Ka

 Vente de la bande passante par satellite

 Vente et Location des terminaux VSAT et accessoires

 Diagnostic et services de maintenance

 Liaison spécialisées et VPN

 Installation Onshore et Offshore

Services wireless et interconnexion:

 Fournitures et ventes équipements radio professionnels pour Interconnexion des sites

(solutions point-to-point, point-to-multipoint)

 Site Survey et Installation des liaisons radio

 Etude et installations des solutions couverture Wifi professionnelles pour les

entreprises, hôpitaux, hôtels et écoles

 Construction et Maintenance Pylônes de télécoms

3
  Solution d’amplification de signaux GSM

Sécurité électronique et gestion du temps :

 Fournitures et installation des équipements moderne de contrôles d’accès et de gestion

du temps (pour domicile et entreprises)

 Lecteur d’empreinte biométrique et RFID pour contrôle d’accès

 Lecteur Biométrique pour Pointage et gestion du temps des employés

 Doorphone / interphone Vidéo

vidéosurveillance & camera de sécurité :

 Fournitures et ventes des équipements de vidéosurveillance (Camera de sécurité,

NVR, DVR, Serveur de stockage, câble data et accessoires)

 Etude et conception de solutions de vidéosurveillance

 Installations de systèmes de vidéosurveillance

 Camera IP Motoriser

Directeur
général
Direction

Responsable Responsable Administratif Responsable

Technique et financier Commercial

Equipe Equipe
Technique Commerciale
RH Comptable

Figure 1.1 : Organigramme de NIS SYSTEMS Sarl

4
1.2- Etat de l'art.
1.2.1- Annuaires électroniques.
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 multi
critères. Les annuaires électroniques sont un type de base de données spécialisées permettant
de stocker des informations de manière hiérarchique et offrant des mécanismes simples pour
rechercher l'information, la trier, l'organiser selon un nombre limité de critères.

Figure 1.2 : Hiérarchisation des données d'un annuaire électronique.

L'utilisation d'annuaire ne se limite pas à la recherche de personnes ou de ressources. En effet,

un annuaire peut servir à :

 Constituer un carnet d'adresse

 Authentifier des utilisateurs (grâce à un mot de passe)

 Définir les droits de chaque utilisateur recenser des informations sur un parc matériel
(ordinateurs, serveurs, leurs adresses IP et adresses MAC, ...)

 Décrire les applications disponibles

5
1.2.1.1- Caractéristiques des annuaires électroniques
Les annuaires électroniques possèdent un grand nombre d'avantages sur leurs:

 Ils sont dynamiques : la mise à jour d'un annuaire électronique est beaucoup plus
simple (et nettement moins coûteuse) à réaliser que celle d'un annuaire papier. Ainsi
un annuaire en ligne (disponible sur le réseau) sera à jour beaucoup plus rapidement,
d'autant plus que les personnes recensées dans l'annuaire peuvent elles-mêmes
modifier les informations les concernant (si elles sont habilitées à le faire).

 Ils sont sûrs : les annuaires en ligne disposent de mécanismes d'authentification des
utilisateurs grâce à un mot de passe et un nom d'utilisateur ainsi que des règles d'accès
permettant de définir les branches de l'annuaire auxquelles l'utilisateur peut accéder

 Ils sont souples : ils permettent ainsi de classer l'information selon des critères
multiples contrairement aux annuaires papiers, imprimés une fois pour toute pour
permettre de rechercher selon un critère figé (en général l'ordre alphabétique selon le
nom)

1.2.1.2- Différence entre annuaire et base de données

Un annuaire est un type de base de données spécifique, c'est-à-dire qu'il s'agit d'une
sorte de base de données ayant des caractéristiques particulières :

 Un annuaire est prévu pour être plus sollicité en lecture qu'en écriture. Cela signifie
qu'un annuaire est conçu pour être plus souvent consulté que mis à jour.

 Les données sont stockées de manière hiérarchique dans l'annuaire, tandis que les
bases de données dites "relationnelles" stockent les enregistrements de façon tabulaire.

 Les annuaires doivent être compacts et reposer sur un protocole réseau léger

 Un annuaire doit comporter des mécanismes permettant de rechercher facilement une

information et d'organiser les résultats

 Les annuaires doivent pouvoir être répartis. Cela signifie qu'un serveur d'annuaire doit
comporter des mécanismes permettant de coopérer, c'est-à-dire d'étendre la recherche
sur des serveur tiers si jamais aucun enregistrement n'est trouvé

 Un annuaire doit être capable de gérer l'authentification des utilisateurs ainsi que les
droits de ceux-ci pour la consultation ou la modification de données

6
Ainsi, un annuaire est généralement une application se basant sur une base de données afin d'y
stocker des enregistrements, mais surtout un ensemble de services permettant de retrouver
facilement les enregistrements à l'aide de requêtes simples. Une base de données par contre
n'est pas forcément un annuaire... .

1.2.1.3- Les annuaires en exploitation

1.2.1.3a - Novell NDS

Novell à rendu son système d'annuaire indépendant du système d'exploitation (Netware).
Novell Directory Service est un annuaire disponible sur Netware, Solaris et Windows. Il
supporte le standard LDAP v3 et les données au format LDIF ( Ldap Data Interchange
Format, format texte de données d'import/export dans un annuaire LDAP ).

1.2.1.3b - Système d'exploitation Windows

Windows NT: l'information est disséminée dans plusieurs outils et bases de données
(gestionnaires de serveurs, gestionnaire wins, gestionnaire des utilisateurs ...). L'ensemble est
regroupé dans un annuaire propriétaire qui est Active Directory, mais compatible avec le
protocole LDAP, il sera donc possible d'y accéder en lecture/écriture via LDAP grâce
notamment à l'interface de programmation ADSI.

1.2.1.3c - NIS (Network Information Service)

Dès 1985 Sun à introduit le Network Information Service, déjà destiné à centraliser
l'administration des informations système. Les informations sont stockées sous forme de map
(table de correspondance entre une clé et une valeur: clé titan , valeur 192.163.12.43) dans de
simples bases indexées (db, dbm ...), accessibles par des appels RPC (Remote Procedure
Call). Ses objectifs :

A. Centraliser les connexions sur un réseau local

‐ Se connecter à un serveur de fichier sous un compte centralisé : simplifier la gestion

des comptes, des mots de passe et les tâches d’administration dans le monde UNIX

‐ Ne pas définir de compte machine par machine : il suffit de créer un utilisateur sur le
serveur NIS pour que chaque machine client NIS ait accès aux informations de login
de cet utilisateur

B. Réseau homogène Linux

‐ Connexion et authentification grâce au service NIS

7
 ‐ Accès aux répertoires partagés grâce à NFS

‐ Pour utiliser des stations Windows : serveur SAMBA

Sun réagit aux défauts de NIS par l'introduction dans Solaris 2 de NIS+. Il introduit une
propagation des données entre maître-esclave de manière incrémentale, en ajoutant la notion
de root domain master en haut de l'arbre hiérarchique sous lequel de trouvent des subdmain
master pouvant eux-mêmes être au-dessus d'autres subdomain-master. Enfin la notion de
``certificat, identité'' (credential) via une paire de clé privée/publique vient combler le
problème de sécurité. L'imposition d'une architecture hiérarchique de haut en bas des NIS+
qui implique une coopération entre les administrateurs systèmes des différents départements
d'une organisation, ainsi que la gestion des paires clé privée/public fut finalement un frein au
passage des NIS aux NIS+. Pourtant ces derniers préfigurent beaucoup de concepts utilisés
par la suite dans LDAP.

1.2.2- Les standards

Les premiers annuaires électroniques sont apparus avec les premiers ordinateurs. Ils avaient
des tâches ciblées : authentification, contrôle des accès, information de type contacts.
Néanmoins il n'existait aucune unification, ni standard. Chaque système possédait sa propre
méthode pour gérer ses utilisateurs. Unix possédait déjà son fameux /etc/passwd. À partir du
milieu des années 70, l'utilisation des réseaux commence à se généraliser. Les systèmes
deviennent distribués et les besoins sont ceux d'une authentification sur une base distante et
commune. De plus, la multiplication des LAN fait apparaître de nouveaux types de services,
que l'on apparente à des annuaires: Les serveurs DNS et le protocole Whois.

On assiste à partir de la fin des années 80 et dans les années 90 à une multiplication des
annuaires spécifiques. Il y a tout d'abord les annuaires inclus dans des logiciels ou des suites
logiciels (mail et groupware): Lotus Notes, Novell Groupwise Directory, Microsoft Exchange
Directory, Sendmail UNIX et son /etc/aliases. Il y a aussi les Annuaires Internet comme
Yahoo. C'est aussi à la fin des années 90 qu'apparaissent des Network operating system. Il
s'agit d'applications fournissant des services à des clients et des serveurs à travers un réseau.
Ces services permettent le partage de ressources comme des fichiers ou des imprimantes. Ils
incluent évidemment des annuaires électroniques (Novell NDS, MS Active Directory). Suite à
l'apparition dans les années 80 d'annuaires généraux et multi-usage, non limités à une

8
application, ni à un système spécifique, la nécessité de standardiser les annuaires
électroniques s'est faite sentir.

Deux organismes se sont mis à travailler en parallèle sur ce projet de standardisation :

CCITT (International Telegraph and Telephone Consultative Committee)
devenu ITU (International Telecommunications Unions) et l'ISO (International Organization
for Standardization). Les deux projets ont finalement fusionné pour donner naissance à la
norme annuaire X500. La première version de la norme en 1988. La deuxième version de
1993.

1.2.2.1- La norme X.500

L'objectif de la norme était de pouvoir être utilisée par tout type d'applications. Elle devait
être un standard ouvert indépendant de tout système et de tout fabriquant. Techniquement, elle
devait fournir de nombreuses possibilités de recherches. Les annuaires devaient pouvoir être
distribués à très grande échelle. La norme X500 devait donc être capable de faire dialoguer et
cohabiter tous les annuaires. La norme X500 est constituée de plusieurs standards.

Tableau 1.1 : Les standards de la norme X.500

X500 Concepts, modèles, services

X501 Modèles associés aux annuaires X500

X509 Identification et authentification

X511 Détails des services offerts

X518 Les services distribués entre plusieurs annuaires

X519 Protocoles de communication entre clients/serveurs

X520 Attributs d'enregistrement prédéfinis

X521 Classes d'objets prédéfinies

X525 Réplication sur les serveurs

9
La mise en place de la norme X500 apparait comme un modèle de réussite dans la création
d'un standard réalisé par des acteurs divers. En effet le critère d'indépendance vis à vis des
éditeurs et le critère d'interopérabilité ont été respectés. Mais rapidement, cette norme a été
jugé trop lourde et trop complexe à mettre en œuvre. Des problèmes de performance sont
constatés à cause de la modélisation OSI des protocoles réseau. La norme LDAP s'est nourrie
de tous ces constats afin de ne pas connaitre le sors de la norme X.500.

1.2.2.2 - LDAP (Lightweight Directory Access Protocol)

L'implémentation d'un annuaire pouvant être totalement différente d'un serveur à un autre, il a
été nécessaire de définir une interface normalisée permettant d'accéder de façon standard aux
différents services de l'annuaire. C'est le rôle du protocole LDAP (Lightweight Directory
Access Protocol), dont le rôle est uniquement de fournir un moyen unique (standard ouvert)
d'effectuer des requêtes sur un annuaire (compatible LDAP). Le système d'information
implique un nombre important d'annuaires. Ce peut être la liste du personnel pour les
applications RH (payes, congés ...), une liste de compte pour l'accès aux ressources
informatiques, se déclinant souvent en une liste par type de service (comptes Unix, comptes
NT/2000, comptes RAS ...) chacun faisant référence à une base propre ( respectivement, Nis,
SAM/Active Directory, radius ...), ou encore des informations pour l'autocommutateur,
répertoriâtes de ressources immeubles, salles, prises ..., meubles: mobilier, matériels
informatique ... On le voit les besoins sont immenses et souvent redondants. Des solutions
existent, elles sont souvent propriétaires et dépendantes des services. Face à ces faits, des
standards ont été érigées, c'est notamment le cas de la norme X.500, normalisation ISO
dédiées aux annuaires électroniques. Elle reste cependant très lourde à mettre en œuvre et
n'est pas adaptée aux réseaux TCP/IP. C'est ici qu'intervient LDAP, qui comme son nom
l'indique apporte de la souplesse aux normes X.500. L'objectif est le même: fédérer les
informations dans une base unique dont l'accès est normalisé et indépendant de tout
constructeur. Il apporte essentiellement une solution exploitable sur des réseaux que nous
utilisons ( technologies Internet) et une mise en œuvre abordable. Bien qu'il puisse répondre à
l'ensemble des besoins d'un système d'information complexe, il n'est pas de notre volonté
d'aboutir directement à ce point. Il conviendra avant tout de concrétiser son utilisation sur des
services limités et déjà bien adaptés. Ce sera le cas, par exemple, de l'authentification des
utilisateurs sur les différentes ressources informatiques de l'établissement.

10
Le protocole LDAP en est actuellement à la version 3 depuis de développement par
l'université de Michigan en 1993 et a été normalisé par l'IETF (Internet Engineering Task
Force). Ainsi, il existe une RFC pour chaque version de LDAP, constituant un document de
référence (tableau ci-dessous)

Tableau 1.2 : Evolution de LDAP

Version RFC Année de sortie

LDAPv1 1487 1993

LDAPv2 1777 1995

LDAPv3 2251 1997

Figure 1.3 : Application X.500 et LDAP sur le LAN

11
 1.2.2.2a - Les Modèles LDAP
LDAP est défini par 5 modèles qui permettent de décrire différents aspects de l'annuaire:
nommage, structure de stockage et structure hiérarchique, sécurisation et échange des
données. Certains de ces modèles sont définis dans la norme comme le modèle d'échange de
données ou de nommage. D'autres doivent être définis dans chaque annuaire comme le
modèle d'authentification et le modèle d'information.

Tableau 1.3 : Modèles LDAP

Modèle Fonction

Modèle d’information définis la nature des données: classe, attribut, types..., l'arbre de
données.

Modèle de nommage organise et définis des règles de nommages des éléments de

l'annuaire. Exemple; l'annuaire dispose d'un schéma, une classe
d'objet doit être unique dans l'annuaire, elle est identifiée par un
OID.

Modèle fonctionnel définis les services offerts, comment accéder aux informations
et comment les mettre à jours

Modèle de sécurité définis les droits d'accès et l'identification

Modèle de duplication Définis comment répartir les données entre serveurs

1.2.2.2b- Architecture LDAP

 le modèle d'information de LDAP est basé sur un "schéma"

 un schéma est une collection de types d'entrées ou classes d'objets que l'on peut
rencontrer

 chaque entrée fait référence à une classe d'objets, définie par u nom et une listes
d'attributs (obligatoires ou optionnels)

 les attributs sont définis par un nom d'attribut, une syntaxe et des règles de
comparaison.

 LDAP organise les entrées dans une structure logique hiérarchique (D.I.T).

12
  l'identification d'une entrée se fait à l'aide du Distinguished Name(DN). exemple :
uid=fkigmo, ou=people, dc=foadweb, dc=cm

 il y'a pas de distinction entre nœuds et feuilles de l'arbre

 toutes les intersections sont des entrées.

Figure 1.4 : Architecture LDAP

1.2.2.2c- LDAP contre les autres technologies

 Tableau comparatif LDAP et Base se données

Tableau 1.4 : Comparaison entre LDAP et une base de données

Critères LDAP Base de données

Rapport Lecture/Ecriture Optimisé en lecture Equivalent

Extensibilité Facile Difficile

Distribution des tables Hiérarchique Complexe

Réplication Possible Possible

Modèle transactionnel Simple Avancé

13
Standard Oui Non (SGBD)

 Tableau comparatif LDAP et NIS (Network Information Services)

Tableau 1.5 : Comparaison entre LDAP et NIS

Critères LDAP NIS

Port Spécifique (389/636) Arbitraire (RPC)

Chiffrement Possible Impossible

Contrôle d'accès Oui Non

Distribution des tables Oui Non

Réplication Oui (totale ou partielle) Oui (totale)

Sémantique des recherches Avancée Simple

1.2.2.2d- Organisation client/serveur

Ce modèle transpose simplement le principe d'une communication entre un client susceptible
d'utiliser l'annuaire et le serveur contenant les données sécurisées. Ce modèle est basé sur le
protocole réseau TCP/IP et fonctionne comme un mécanisme de message client-serveur. Le
protocole définit comment s'établit la communication client-serveur. Un client transmet une
requête au serveur à l'aide des éléments de protocole LDAP. Le serveur est alors responsable
de l'exécution de la requête. Lorsque celle-ci est terminée, le serveur renvoie une réponse
contenant les résultats de la requête ou les erreurs éventuelles.

Figure 1.5 : Communication client/serveur LDAP

14
Les données LDAP peuvent être représentées sous forme de fichier texte standardisé au
format LDIF (LDAP Data Interchange Format). Il est utilisé pour afficher ou modifier les
données de la base. Il a vocation à donner une lisibilité des données pour l'homme.

LDIF est utilisé dans deux optiques :

 Faire des imports/exports de base

 Faire des modifications sur des entrées.

Figure 1.6 : Echange de données au format LDIF

1.2.3- Contrôleurs de domaine

Un domaine est une entité logique, désignant l’ensemble de machines réseau (stations,
imprimantes,…) et les comptes utilisateurs qui sont autorisés à se connecter. Le domaine
permet à l’administrateur réseau de gérer plus efficacement les utilisateurs des stations
installées au sein de l’entreprise car toutes ces informations sont centralisées dans une même
base de données et stockées sur un serveur particulier appelé contrôleur de domaine. Dans ce
contexte, nous pouvons citer plusieurs familles des contrôleurs des domaines existants sur le
marché comme Active Directory pour les systèmes Windows, NIS pour les systèmes Open
Source et Samba pour les réseaux hétérogènes et ce qui est le cas dans notre projet. Toutefois,
Samba doit être couplé avec un annuaire LDAP afin d’organiser les données et les centraliser
dans un annuaire séparé. Le contrôleur de domaine permet donc d’organiser et de sécuriser
toutes les données. Le contrôleur de domaine est le coffret qui contient les "clefs du
royaume". Si les hackers disposent de toutes sortes d’astuces pour élever leurs droits d’accès
sur les réseaux et attaquer le contrôleur de domaine lui-même, vous pouvez non seulement
protéger vos contrôleurs de domaine contre les hackers mais également les utiliser pour
détecter les cyber attaques en cours.

15
1.2.3.1 - Les avantages d'un contrôleur de domaine.
Les contrôleurs de domaine ont des avantages remarquables pour assurer la sécurité des
informations et une bonne gestion des ressources réseau.

- La sécurité des informations : La sécurité est parfaitement intégrée au niveau de chaque

contrôleur de domaine. Et se diffère selon les plates formes et les constructeurs. Le contrôle
d'accès peut être défini sur chaque propriété de chacun des objets. Une stratégie de sécurité
peut assurer des informations de compte, tels que des restrictions de mot de passe applicables
sur l'ensemble du domaine ou des droits pour des ressources de domaine spécifiques.

- Administration basée sur les stratégies : Le service de l'annuaire pour les contrôleurs de
domaines comprend à la fois un magasin de données et une structure logique hiérarchique.

- Extensibilité : Lorsqu'on parle d'un contrôleur de domaine est extensible, c'est à dire que les
administrateurs peuvent ajouter de nouvelles classes d'objets au schéma et de nouveaux
attributs aux classes d'objets existantes.

- Supporte la Flexibilité : On peut inclure un ou plusieurs domaines, chacun avec un ou

plusieurs contrôleurs de domaine, qui permettent de faire évoluer l'annuaire en fonction des
besoins du réseau.

- Réplication des informations : La réplication garantit la disponibilité des informations, la

tolérance de panne, l'équilibre de la charge et de meilleures performances pour l'annuaire.

- Souplesse des recherches : Les utilisateurs et les administrateurs peuvent rechercher

rapidement un objet sur l'ensemble de réseau à l'aide des propriétés des objets. Par exemple,
on peut rechercher un utilisateur par le prénom, le nom, l'adresse de messagerie,
l'emplacement du bureau ou toute autre propriété du compte d'utilisateur de cette personne. La
recherche d'informations est optimisée par l'utilisation du catalogue global.

- Gestion centralisée des utilisateurs : L'avantage majeur si on peut dire, c'est la

centralisation de la gestion des utilisateurs et des machines.

1.2.3.2 - Les inconvénients d'un contrôleur de domaine.

- Cible pour les cyber attaques : le contrôleur de domaine centralisant l'ensemble des
informations du réseau reste une grosse cible pour les pirates.

- Nécessité de gérer les utilisateurs et le système d’exploitation pour assurer leur stabilité,
leur sécurité et les garder à jour

- Réseau dépendant du temps de disponibilité du contrôleur de domaine.

16
- Exigences en termes de matériel / logiciel

1.2.3.3 - Choix d'un contrôleur de domaine

Dans l'optique de prendre en charge les postes fonctionnant avec divers systèmes
d'exploitation (Windows, linux, etc..), nous opterons pour un contrôleur de domaine
hétérogène à l'instar de SAMBA.

1.2.3.3a - Contrôleur de domaine SAMBA

Samba est un logiciel libre qui permet de connecter à un Serveur Linux, des machines
fonctionnant sous différents systèmes tels que Windows, OS/2, Mac, ...

Le serveur Linux sera en mesure de répondre entant qu'un serveur de fichiers capables d'offrir
les services habituels sur un réseau.

Samba fonctionne sur les plates-formes Unix, mais parle à des clients Windows comme un
indigène. Il permet à un système Unix de se déplacer dans un voisinage réseau de Windows
sans causer des difficultés. Les utilisateurs Windows peuvent joyeusement avoir accès aux
fichiers et services d'impression sans connaître ou prendre soin que ces services sont offerts
par un hôte Unix.

Le serveur Linux est en mesure de se conduire comme un serveur de fichiers capables d'offrir
les services habituels sur un réseau :

 partage de fichiers et de répertoires,

 partage d'imprimantes,

 respect des comptes utilisateurs

 gestion des permissions d'accès

 exécution de scripts de connexion personnalisés

Samba fonctionne avec démons suivants :

smbd : il permet le partage de ressources fichiers et d'imprimantes et gère

l'authentification et les droits de partage des utilisateurs qui accèdent aux ressources.

nmbd : Le démon serveur nmbd comprend et répond à toutes les requêtes de service de nom
NetBIOS telles que celles produites par SMB/CIFS dans des systèmes basés sur Windows.

Le fonction de Samba est conforme au schéma suivant.

17
 Figure 1.7 : Fonctionnement de Samba

Chaque demande de connexion par Samba, d'une station au serveur Linux, laisse une trace
stockée dans un fichier log.%m, situé dans le répertoire /var/log/samba ( %m désigne le nom
de la station). Toute connexion pourra donc être identifiée de manière précise puis examinée
sur une ligne de ce fichier : nom d'utilisateur, nom de la machine, date, heure de début, heure
de fin, services utilisés...

Samba peut implémenter la sécurité au niveau de l'utilisateur, (ce qui est recommandé) et non
au niveau des ressources comme c'est le cas dans les réseaux de type WorkGroup.

Tableau 1.6 : Les principaux paramètres de Samba

valeur par
paramètre description
défaut
path = chemin du répertoire à partager
comment = texte visible dans le voisinage réseau client
guest ok = yes|no
(ancien nom : no partage en accès libre sans authentification
public)
valid users = tous liste des users autorisés à se connecter à la ressource
printable = partage d'un service d'impression et non de
false
true|false répertoire.
permet ou non l'écriture sur le répertoire, contraire
writeable = yes|no no
de read only
tous les
write list = liste des users autorisés à écrire
utilisateurs
visibilité du partage par tous, même les users non
browseable = yes
autorisés
droits maxi accordés à un fichier créé dans la
create mode | mask ressource
0744
= ces droits seront en intersection (and) avec les droits
Linux (umask)

18
 droits maxi accordés à un répertoire créé dans la
directory mode | ressource
0755
mask = ces droits seront en intersection (and) avec les droits
Linux (umask)
force directory droits imposés lors de la création du répertoire.
000
mode = composé par un opérateur OR avec les droits usuels
Impose un groupe propriétaire d'un fichier lors de sa
force group =
création dans le partage
cache les fichiers cachés au sens Linux, commençant
hide dot files = yes
par un point
toutes les
hosts allow ressource réservée | interdite à la liste des stations
stations
hosts deny = (adresses IP)
aucune
max connections = 0 nb de connexions à la ressource illimité, sinon maxi

1.2.3.3b - Samba 4 et Active Directory

Alors que la branche 3 de Samba peut assurer la fonction de contrôleur de domaine type NT,
Samba 4.0 implémente la partie serveur de l'environnement Active Directory utilisé par
Windows 2000 et les versions suivantes. Il est donc maintenant possible de joindre un
domaine Samba 4 avec toute version de Windows à partir de Windows NT4, et de profiter des
fonctionnalités de l'Active Directory correspondantes. Afin de fournir un ensemble
pleinement compatible, cette version inclut sa propre implémentation de serveur LDAP, un
serveur Kerberos, un serveur DNS, un serveur RPC, un serveur NTP ainsi qu'un serveur de
fichiers basé sur Samba 3. L'ensemble fonctionne sous un seul service nommé samba. Il est
donc possible d'utiliser Samba 4 pour mettre à disposition des clients Windows, entre autres,
des profils itinérants ou des stratégies de groupes.

1.2.3.3c - Les contraintes de Samba 4

La compatibilité de Samba 4 avec Active Directory est assurée dans la mesure où :

 Il n'y a qu'un seul domaine dans la forêt.

 Il n'y a pas d'approbation inter-forêt (samba4 peut être approuvé par un domaine mais
ne peut pas en approuver)

 Samba est le seul contrôleur de domaine de son domaine.

Ces limites seront levées dans les prochaines versions de samba, notamment avec le support
des systèmes de réplications nécessaires au bon fonctionnement des contrôleurs principaux et

19
secondaires. Cette limite concernant la réplication nous fera implémenter plutôt samba dans sa
version 3.

1.2.4- Serveur DNS

Chaque ordinateur connecté sur Internet ou dans un réseau d'entreprise
possède une adresse propre. Il échange les données avec le s autres par
l’intermédiaire du protocole IP (Internet Protocol). Pour communiquer sur
Internet, nous devons connaître les adresses des machines que nous vo ulons
joindre. Mais retenir ces adresses n’est pas chose évidente et c’est là qu’entre
en jeu le DNS.
Un serveur DNS transformera ainsi une adresse du t ype
http://www.foadweb.cm/ en adresse IP(19.10.33.126) et inversement. Les
raisons pour lesquelles on peut avoir besoin d’un serveur DNS dans une
entreprise peuve nt être les suivantes :
 Simplifier l’adressage des machines internes de l’entreprise. Ainsi, un

utilisateur interne n’est pas obligé de taper l’adresse IP de la machine

qu’il veut joindre, mais qu’il puisse y arriver avec un nom symbolique.

 Disposer d’un s erveur cache DNS, afin d’accélérer les requêtes.

1.2.4.1- Fonctionnement du service des noms de domaine

Pour expliquer le fonctionnement du service DNS, prenons le cas concret d’un

internaute qui veut atteindre le site d’adresse http://www.foadweb.cm.
Il lance son browser et tape l’adresse ci-dessus dans la barre d’adresse puis appuis sur la
touche Entrée. Le browser prend d’abord contact avec le serveur DNS local (généralement
celui du fournisseur d’accès) pour déterminer l’adresse IP de http://www.foadweb.cm (a).
Ce serveur cherche l’adresse dans son cache (b). Si le serveur n’a jamais eu de requête sur ce
site, le cache ne contiendra pas cette adresse. Le serveur DNS local établit un contact avec un
autre DNS (généralement avec un DNS racine) pour obtenir l’adresse IP du serveur DNS
responsable du domaine foadweb.cm (c). Si l’adresse http://www.foadweb.cm existe, le
DNS racine renvoie l’adresse du DNS pour ce domaine. Le DNS local demande alors au DNS
du domaine de lui renvoyer l’adresse du site http://www.foadweb.cm (d). Enfin le DNS local
renvoie cette adresse au browser (e) et la stocke dans son cache pour des utilisations
futures(f). La figure ci-contre décrit ce fonctionnement.

20
 Figure 1.8 : Fonctionnement du DNS

1.2.5 - Gestion des quotas de disque et sécurisation des échanges avec TLS
Parfois sur des serveurs accessibles et utilisés par plusieurs utilisateurs qui y laissent
leurs données, notamment le cas d'un serveur NFS, on a besoin de mettre en place un système
de quota pour éviter que la ressource disque dur soit abusivement utilisée pour stocker des
films par exemple. En gros, il s'agit de se fixer des limites en espace disque à ne pas dépasser;
au-delà ces limites, l'utilisateur ayant atteint son quota ne peut plus écrire sur le disque. Il sera
également question d'implémenter une sécurisation des différents échanges entre les différents
postes utilisateur et le serveur LDAP.
 Qu'est-ce qu'un quota
L'attribution de quotas dans un système de fichiers est un outil qui permet de maîtriser
l'utilisation de l'espace disque. Les quotas consistent à fixer une limite d'espace pour un
utilisateur ou un groupe d'utilisateurs. Pour la création de ces quotas, on définit deux types de
limites :
 La limite douce (ou soft limit) : indique la quantité maximale d'espace qu'un
utilisateur peut occuper sur le système de fichiers. Si cette limite est atteinte,
l'utilisateur reçoit des messages d'avertissement quant au dépassement du quota qui lui
a été attribué. Si son utilisation est combinée avec les délais (ou grace period), lorsque

21
 l'utilisateur continue à dépasser la soft limite après que ce soit écoulé le délai de grâce,
alors il se retrouve dans le même cas que dans l'atteinte d'une limite dure.
 La limite dure (ou hard limit) définie une limite absolue pour l'utilisation de l'espace.
L'utilisateur ne peut pas dépasser cette limite. Passée cette limite, l'écriture sur ce
système de fichiers lui est interdite.

De plus ces limites sont exprimées en blocs et en inodes. Le bloc est une unité d'espace, les
quotas exprimés en nombre de blocs représentent donc une limite d'espace à ne pas dépasser.
En ce qui concerne les quotas exprimés en nombre d'inodes, ils représentent le nombre
maximum de fichiers et répertoires que l'utilisateur pourra créer. Pour mémoire, les délais (ou
grace period) fixent une période de temps avant que la limite douce ne se transforme en limite
dure. Elle est fixée dans les unités suivantes : second, minute, hour, day, week.

1.2.6 - Communication TLS avec le serveur LDAP

1.2.6.1 - Pourquoi Tls ?

Vous le savez peut-être, par défaut les communications avec notre serveur LDAP se
font en clair. Une personne mal intentionnée pourrait donc intercepter toutes les informations
qu'elle désire, y compris les mots de passe de nos utilisateurs (même chiffrés, ceux-ci sont
précieux... On trouve de nombreux outils pour les "casser"...) ! Une manière simple de
sécuriser nos transactions est de passer par TLS (Transport Layer Security), qui assurera le
chiffrement des données. Nous n’allons pas rentrer dans les détails d'une communication via
TLS. Sachons simplement que TLS repose sur la couche 4 (Transport) du modèle OSI, ce qui
lui permet de sécuriser les communications réseau de manière transparente pour les
applications. Il repose sur l'utilisation de clefs symétriques et asymétriques, et introduit la
notion de certificat délivré par un tiers, qui assure alors l'authenticité des clefs.

1.2.6.2- Les clefs et les certificats

Une paire de clefs est composée d'une clef privée et d'une clef publique. Elles ont la
particularité d'être inséparables, car ce que chiffre l'une, l'autre peut la déchiffrer. Voilà
pourquoi on parle de clefs asymétriques. La clef privée est destinée à être gardée
précieusement par son propriétaire, alors que la clef publique pourra être diffusée. Le principe
général consiste alors à chiffrer les données avec la clef publique du destinataire afin qu'il
puisse la déchiffrer avec sa clef privée et être ainsi le seul à pouvoir comprendre le message.

22
Le certificat vient juste introduire la notion d'authenticité des clefs. Comment être sûr qu'une
clef publique est bien celle de la personne à qui l'on veut envoyer des données ? Le certificat
nous offre une réponse : une société tierce (de confiance, une autorité de certification : CA) va
certifier que la clef publique appartient bien à cette personne. Ainsi, plus de doute, la clef est
la bonne... nous évitons ainsi de nous faire piéger par une personne qui voudrait intercepter
nos données. .

Nous notons que plusieurs solutions sont disponibles pour une gestion centralisée des
ressources dans un réseau. Les solutions propriétaires comme Active Directory de Microsoft
ou les solutions libres comme NIS de SUN. Les premières solutions ayant été développées
sans un standard ou norme, ont conduit à la naissance de la norme X.500 et LDAP par la
suite. Ainsi, pour la suite de notre travail, nous utiliserons des outils basés sur la norme LDAP
et une préférence sera fait sur des solutions libres afin de limiter le budget actuel et future
qu'impose les solutions propriétaires avec les licences généralement très couteux.

23
Chapitre 2 : Les outils utilisés dans le cadre du projet

Nous utiliserons cette partie pour présenter les outils qui seront utiliser dans le cadre
de ce projet. Il est à noter tout de même que cette présentation concernera les outils les plus
indispensables.

2.1- Système d’exploitation

2.1.1- choix du système
Linux est le système qui connaît actuellement le plus grand développement sur Internet
principalement pour des raisons suivantes:

Le logiciel Samba qui lui permet d'être serveur de fichier et d'impression en

environnement Microsoft
La stabilité et la sécurité que lui confère le développement de son architecture et de ses
modules au sein de la communauté Open Source.
Le large choix d'applications dans de très nombreux domaines.
Moins d'interruptions de service grâce à une gestion intelligente de l'installation des
logiciels. Un serveur sous Linux ne doit être redémarré que lors d'une modification
matérielle comme l'ajout d'un disque ou d'une carte.
Logiciel Libre : Linux est gratuit et libre.
Accès aux sources des logiciels. Tous les utilisateurs peuvent modifier le fonctionnement
des programmes ou engager un programmeur pour le faire.
Linux est plus efficace et consomme moins de ressources CPU et mémoire que Windows :
On peut par exemple faire un serveur d'impression avec un vieux 486.
Si des problèmes surviennent, un support adéquat doit être disponible.
Le nombre de « clients » sera élevé, on doit donc penser aux coûts des licences qui sont
généralement, directement proportionnels avec ce nombre.
Les services doivent être disponibles en permanence.
Linux est le système de prédilection pour l'installation de trois logiciels serveurs leaders
sur l'Internet : Apache en serveur Web, postfix en serveur courrier et Bind en serveur
DNS.
Pour ces raisons nous avons choisi le système d’exploitation GNU/Linux car il possède bien
plus de caractéristiques que la plupart des variantes commerciales d'Unix ; Linux possède

24
dont les caractéristiques idéales pour implémenter un serveur Internet stable, performant,
sécurisé et flexible.

2.1.2- Choix de la distribution

Quand on parle d'un système Linux, c’est en fait un abus de langage. En effet Linux
désigne seulement le kernel (encore appelé Noyau), une distribution englobe à la fois le
kernel et les programmes permettant à l'utilisateur d'interagir avec le ce dernier. Chaque
distribution a donc une certaine liberté dans la façon de présenter les commandes et sur le
fonctionnement général du système. En particulier les programmes d'installation et de
configuration sont souvent spécifiques à une distribution. Néanmoins un administrateur formé
sur une distribution sera à même d'utiliser une autre distribution sans aucun problème majeur.
Les distributions les plus connues sont :
RedHat, Debian, Mandrake, SuSE, Ubuntu …
Nous portons notre choix sur la distribution RedHat Enterprise Linux 7.7 (RHEL 7.7), pour
son fonctionnement stable et son niveau de sécurité assez avancé. De plus nous avons
préalablement une certaine maitrise des commandes de cette distribution.

2.1.3- Configuration matérielle requise

Un serveur est un ordinateur puissant, partageant ses ressources avec d’autres
ordinateurs du réseau. C’est sa raison d’être. Son installation est très délicate et doit être
réalisé avec beaucoup d’attention.
A cet effet, un serveur doit disposer d’un processeur puissant, parfois plusieurs, et autant de
mémoire que possible. Bien qu’elles soient importantes, la vitesse du processeur et la
mémoire ne sont pas les seuls critères à prendre en compte. La vitesse de la carte réseau est
aussi l’une des caractéristiques très importante pour un serveur. La vitesse à laquelle les
données sont transmises est déterminée par le type de réseau. Ainsi le matériel pour notre
serveur est un ordinateur ayant les caractéristiques suivantes :
 Un processeur de type Intel Core i7, CPU 2,20 GHz
 Une mémoire vive de 8 giga octets
 Un disque Dur de 1 Tera Octets.
 Une carte réseau à bus PCI à 1000 Mbits/s.

2.2 - Annuaire LDAP

Plusieurs outils existent pour la mise en place d’un annuaire LDAP. Nous citons ici quelques-
uns des plus connus.

25
 Intégré aux systèmes d’exploitation
Sun Directory Server Enterprise Edition
Novell Directory Server
Microsoft Active Directory
 Généralistes
OpenLDAP Server
TinyLDAP
Apache Directory Server
IBM Tivoli Directory
Oracle Internet Directory
Sun Java System Directory Server
Nous travaillerons avec l’outil OpenLDAP car intégré dans la distribution linux à utiliser et
comme son nom l’indique, cet outils est libre. La version utilisée sera : openldap-2.4.39-
3.el7.x86_64.rpm.
Il faut installer plusieurs librairies et outils pour permettre l'authentification via LDAP :
nscd : Name service cache daemon, fournit un cache pour différentes requêtes de noms,
accélère les requêtes.
libnss-ldap : Permet d'ajouter la gestion de LDAP à nsswitch. Nsswitch sert d'interface pour
la résolution de noms de plusieurs services (les groupes utilisateurs, les noms de machines,
etc...). Il permet d'indiquer au système où chercher les informations. Il faut ici le configurer
afin d'indiquer à la machine que les utilisateurs et groupes peuvent être situés sur l'annuaire
LDAP. Ceci sera utile notamment pour pouvoir effectuer des modifications de droits avec des
groupes ou utilisateurs présents dans l'annuaire LDAP (en complétant le pool d'utilisateurs et
de groupes déjà présents dans les fichiers /etc/password et /etc/group lors d'un chown, chmod,
chgrp, getent...).
Modules LDAP pour pam: Pam sert à l'authentification des utilisateurs. Il offre aux
applications une couche transparente qui permet de gérer, via des modules, n'importe quelle
méthode d'authentification (de la carte à puce, aux fichiers password, en passant par la
biométrie...). Il faut lui indiquer, dans notre cas, d'utiliser l'annuaire LDAP pour s'authentifier
sur le système Unix. Ceci n'est nécessaire que si l'on souhaite pouvoir s'authentifier sur le
système Unix avec les comptes LDAP. Le RPM utilisé sera : nss-pam-ldapd-0.9.6-
3.gf.el7.x86_64.rpm

26
smbldap-tools : sont des outils développés par idealx permettant de gérer des comptes Samba
de manière très simple en lignes de commandes. Nous utiliserons à cet effet le RPM smbldap-
tools-0.9.11-6.el7.noarch.rpm.

2.3 - SAMBA
A partir de la version 2.2.5 de samba, il est possible d’intégrer LDAP qui est un annuaire des
utilisateurs. Ainsi avec samba 3 nous pouvons configurer un PDC qui va intégrer des
utilisateurs LDAP dans notre serveur. Apres configuration de l'annuaire LDAP et des
librairies nécessaires à samba on peut installer notre serveur samba. La qui sera utilisée est la
samba-3.0.1-5sls.src.rpm

2.4 - Quota de disque et sécurisation des échanges

L'attribution de quotas dans un système de fichiers est un outil qui permet de maîtriser
l'utilisation de l'espace disque. Les quotas consistent à fixer une limite d'espace pour un
utilisateur ou un groupe d'utilisateurs. Pour la création de ces quotas, nous utiliserons le RPM
suivant : quota-4.01-11.el7.x86_64.rpm.
Les communications par défaut avec notre serveur LDAP se faisant en clair, nous
implémenterons une sécurité afin d'éviter les actions de hackers. le RPM qui sera utilisé est :
openssl-1_1_0-1.1.0f-52.1.x86_64.rpm

Les modules supplémentaires suivants seront également utilisés:

 Httpd pour le serveur web apache
 Les modules PHP pour apache et LDAP
 Les modules PERL
 Bind pour le serveur de nom de domaine (DNS).
Nous avons ainsi mis en avant les principaux outils qui nous seront utiles pour mener ce
projet, allant sur choix du système d'exploitation et les caractéristiques physiques du serveur à
la présentation des outils logiciels nécessaires. la suite consistera à implémenter cet ensemble
pour avoir la solution préconisée.

27
Chapitre 3: Implémentation de la solution
Nous allons dans cette partie procéder aux différentes installations et paramétrages
nécessaires pour le système souhaité. le schéma suivant présente l'architecture existante, où
chaque poste dispose sa base d'authentification. Chaque utilisateur a un compte en local sur
chaque poste où il travaille généralement.

Utilisateur 1
Utilisateur 2
Utilisateur 3

Poste B

Utilisateur 1
Utilisateur 2 Utilisateur 2
Utilisateur 4 Utilisateur 3
Utilisateur 6 Utilisateur 4
Poste A
Switch Utilisateur 6
Poste C

Utilisateur 1
Utilisateur 3
Utilisateur 5
Poste D
Utilisateur 6

Figure 3.1 : Architecture réseau existant

3.1- Installation du système RedHat Enterprise Linux 7.7

Notre installation se fait à partir du fichier image du système d'exploitation.
Les étapes d'installation sont les suivantes:

Figure 3.2 : Démarrage de l'installation de Redhat

28
 Figure 3.3 : Choix de langue

 Le type de clavier, puis le type de souris

 Choix du type d'installation
Le système nous propose le choix entre quatre types d'installation
1. installation bureau personnel
2. poste de travail
3. serveur
4. personnalisée
Nous avons utilisé une installation serveur dans le cadre de notre projet.
 Configuration et partitionnement du disque.
Nous avons le choix entre le partitionnement automatique et celui avec l'utilitaire Disk Druid.
Nous choisissons le partitionnement manuel avec Disk Druid.
Disk Druid est un utilitaire de partitionnement nous donnant la possibilité de créer,
modifier ou supprimer les partitions.
Les partitions indispensables pour le système linux sont les suivantes:
 La partition racine (/) qui est la partition où sont montés tous les systèmes de fichier.
 La partition Boot (/boot) qui contient les informations de démarrage
 La partition Var (/var) contenant les informations sur les variables d'environnement
 La partition Usr (/usr) où sont installés tous les programmes

29
  La partition Home (/home) contenant les répertoires personnels des utilisateurs du
système
 La partition Root (/root) qui est la partition du super utilisateur responsable de
l’administration du système (utilisateur Root)
 La partition SWAP pour le swap

Figure 3.4 : Création des partitions

Pour créer une partition à l'aide de Disk Druid, sélectionner le périphérique (/dev/hda1 pour la
première partition du disque IDE, /dev/hdb pour le périphérique SCSI), et aller à nouveau,
choisir le point de montage, le système de fichier, la taille de la partition et d'autres options.
 choix du chargeur de démarrage : Notre choix portera sur le chargeur GRUB.
Après le choix du chargeur de démarrage, la fenêtre de configuration apparaît en nous
demandant de choisir l'étiquette de démarrage et la partition à démarrer. Ensuite nous avons le
choix sur l'endroit où installer le chargeur de démarrage. Notre choix portera sur le bloc de
démarrage maître car ce serait le cas du premier secteur de la partition de démarrage si un
autre chargeur était déjà installé dans le MBR.

30
  Après nous avons une interface de configuration de la carte réseau permettant de
spécifier l'adresse IP, le masque réseau, la passerelle par défaut et les DNS.
 Ensuite nous avons la configuration du niveau de pare-feu, puis le support de langue.
 Après réglage de l'horloge, on est invité à saisir le mot de passe ROOT.
 Le choix des paquetages est une étape importante pour notre installation. Il vaut mieux
installer le strict minimum des paquetages et faire des mises à jour si nécessaire au
lieu d’installer des modules inutiles qui ne seront jamais utilisés sur le serveur et qui
rendront notre serveur lent à la limite. Parmi les paquetages à sélectionner, voici ceux
dont nous aurons besoins :
 Httpd pour le serveur web apache ;
 Les modules PHP pour apache et LDAP ;
 Le module OpenLDAP pour la configuration de l’annuaire LDAP ;
 Les modules PERL ;
 Bind pour le serveur de nom de domaine ;
 Samba pour le contrôleur de domaine ;
A la fin de l'installation, le système redémarre et l'écran ci -dessous nous
donne la possibilité de se connecté. Nous utiliserons ici les paramètres définis
pour le root pendant l'installation.

Figure 3.5 : Ecran de connexion

31
3.2- Configuration du serveur DNS
Le logiciel nécessaire à installer et configurer sous Linux Redhat est BIND (Berkeley
Internet Name Domain). Il a été installé au cours de l’installation du système. La
configuration DNS à faire dépend de la zone à créer et des machines à faire la
correspondance. Dans notre cas, nous voulons créer un serveur DNS maître du domaine
foadweb.cm et qui fera la correspondance directe et inverse des postes du réseau.
Les fichiers à configurer sont :
 Le fichier /etc/named.conf contient les paramètres généraux ;
 /var/named/named.local résolution locale des adresses loopback ;
 On crée et on édite le fichier /var/named/foadweb.cm comme fichier de zone. (ce
fichier peut porter n’importe quel nom)

3.2.1- Edition du fichier /etc/named.conf

3.2.1.1- Description des principales options d’un fichier named.conf.

Options : définit les options du serveur dans son ensemble. Ses principales propriétés sont
les suivantes :
Directory indique le répertoire où se trouve les fichiers.
forward peut avoir plusieurs options (first, only) first redirige les requêtes aux serveurs se
trouvant dans la liste forwarders, si les hôtes ne répondent pas, le serveur tentera de répondre.
only redirige sans réponse aux serveurs se trouvant dans la liste forwarders.
forwarders indique les serveurs vers lesquelles les requêtes sont envoyées.
query-source : indique que le port 53 est le port d'échange (source et destination) entre les
serveurs DNS, très utile lorsqu'un firewall est utilisé.
allow-query : contient une liste des adresses dont le serveur acceptera ou refusera les
requêtes
allow-transfert : interdit les transferts de requête de zone. Par défaut cela est autorisé de
partout.
allow-update : refuse les instructions de mises à jour de la base de données de zone. Par
défaut les mises à jour sont refusées.
listen-on port 53 : indique le port en écoute pour les clients et les interfaces. Indiquer * pour
écouter sur toutes les interfaces, ou l'adresse IP de la carte.

32
Zone : définit les options s'appliquant à des zones particulières.
La zone 0.0.127.in-addr.arpa crée une zone pour le réseau loopback. Cette option possède des
attributs qui sont les suivants :
Directory : indique le répertoire ou se trouvent les fichiers de la zone.
Forward : pareil à la définition plus haut
Forwarders : pareil à la définition plus haut
notify no : pour ne pas informer les autres serveurs s'il y a des changements dans la zone.

3.2.1.2- Contenu de notre fichier /etc/named.conf

En créant la zone foadweb.cm ayant pour fichier /var/named/foadweb.cm et une zone
inverse ayant pour fichier /var/named/foadweb.inv, notre fichier de configuration est
comme ci-dessous. Pour notre configuration il suffit d’ajouter à la configuration par défaut la
définition de notre fichier de zone et le fichier de résolution inverse. Pour cela il faut ajouter
ceci :
zone "foadweb.cm" IN {
type master;
file "foadweb.cm"; // ici nous mettons le nom de notre fichier de zone
allow-update { none; };
};

zone "103.168.192.in-addr.arpa" IN {
// 103.168.192 représente la partie réseau des adresses du domaine.
type master;
file "foadweb.inv"; // nom de notre fichier de résolution inverse.
allow-update { none; };
};
NB : Les lignes précédées de « //» sont des commentaires.

3.2.2- Edition du fichier /var/named/foadweb.cm

Les enregistrements associés à la zone foadweb.cm définie dans le fichier
/etc/named.conf sont contenus dans le fichier /var/named/foadweb.cm

3.2.2.1- Types d’enregistrements associés à la définition d’une zone

 Enregistrement SOA (Start Of Autority)
Désigne l’autorité pour le domaine, c’est le premier enregistrement du fichier. Cet
enregistrement désigne que ce serveur de noms est la source primaire d'information sur les
hôtes de ce domaine. Notre serveur de noms, que nous nommerons mail, est autorité sur le
domaine foadweb.cm du fait de l'enregistrement SOA.

33
  Enregistrement NS (Name Server)

Ces enregistrements indiquent le nom du serveur de nom du domaine ou les noms des
serveurs de domaine lorsqu’il y en a plusieurs.

 Enregistrement d'adresses (A)

Cet enregistrement fait la correspondance entre les noms des machines et les adresses
IP.
 Enregistrement canonique (CNAME) :
Ces enregistrements font les translations entre les noms officiels (alias) et les noms des
machines
 Enregistrement pointeur (PTR) :
Correspondent aux enregistrements par hôte. Ils permettent la résolution inverse
(retrouver un nom de domaine à partir de l'adresse IP). Les adresses sont inversées, puis "in-
addr.arpa" est ajouté.

3.2.2.2- Contenu de notre fichier /var/named/foadweb.cm

$TTL 86400
@ IN SOA kigmoserver.foadweb.cm. root.foadweb.cm. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
IN NS kigmoserver.

localhost IN A 127.0.0.1
kigmoserver IN A 192.168.103.211
www IN CNAME kigmoserver

3.2.3- Edition du fichier /var/named/named.local

Ce fichier est utilisé pour la résolution inverse du loopback. Le contenu du notre est le
suivant :
$TTL 86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400) ; Minimum
1 IN PTR localhost

34
3.2.4- Edition du fichier /var/named/foadweb.inv
Ce fichier est utilisé pour la résolution inverse des serveurs du domaine. Le contenu du
notre est le suivant :
$TTL 86400
@ IN SOA kigmoserver.foadweb.cm. root.kigmoserver.foadweb.cm. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400) ; Minimum
211 IN PTR kigmoserver
//211 est la partie hôte de l’adresse IP de notre serveur et kigmoserver le hostname de celui-ci.

3.2.5- Edition du fichier /etc/resolv.conf

Il est nécessaire d’éditer le fichier/etc/resolv.conf et y ajouter les lignes :
; generated by /sbin/dhclient-script
search foadweb.cm
nameserver 192.168.103.211

3.2.6- Lancement et Test du serveur

Le lancement du serveur se fait en démarrant le démon named par la commande
# service named start
L’arrêt du démon named se fait par la commande
# service named stop
Et le redémarrage par la commande
# service named restart
Le test du serveur peut se faire via la commande nslookup, dig ou la commande host.

3.3- Installation d’OpenLDAP

3.3.1- Construction de notre arborescence
Nous voulons construire un annuaire permettant de stocker les informations relatives aux
individus (nom, prénom, téléphone, mail). Pour cela, nous avons besoin des attributs tels que
le nom, le prénom, le numéro de téléphone, le compte mail, la boite aux lettres (chemin où le
serveur de messagerie va stocker les mails). Les classes objet que nous allons utiliser sont les
suivants :
 organization pour spécifier le nom de la société

35
  organizationUnit pour spécifier les unités d’organisation des données dans la base
(ex : comptes personnels, ordinateurs …).
 inetOrgPerson pour les champs uid (user id), nom, prénom, téléphone, mot de passe et
 mailCourierMailAccount que nous allons créer comme nouvelle classe étendue dans le
fichier courier.schema qui contiendra les attributs suivants : boite aux lettres,
répertoire personnel, numéro d’utilisateur, numéro de groupe.

Figure 3.6 : Arborescence de l'annuaire

3.3.2- Téléchargement, recompilation et installation de openldap

L'installation d’Openldap se fait de manière classique.
 On télécharge la version openldap-2.4.39-3.el7.x86_64.rpm à cette adresse :
http://rpm.pbone.net/index.php3/stat/4/idpl/55096805/dir/redhat_el_7/com/openldap-
2.4.39-3.el7.x86_64.rpm.html
 On lance la commande: rpm -ivh openldap-2.4.39-3.el7.x86_64.rpm
 Déplacez-vous dans le répertoire /usr/src/redhat/SPECS/ où se trouve le fichier
openldap.spec

36
  Puis on compile avec la commande : rpmbuild -ba openldap.specs. La compilation
peut prendre plusieurs minutes. (Le paquetage rpmbuild doit être installé)
 Après cette compilation, déplacez-vous dans le répertoire
/usr/src/redhat/RPMS/i386 où vous trouverez les paquets à installer. Pour installer
tous les paquets créer, faites ceci : rpm -ivh openldap-*.rpm

3.3.3- Configuration de Openldap

 Fichier /etc/openldap/slapd.conf
include /usr/share/openldap/schema/core.schema
include /usr/share/openldap/schema/cosine.schema
include /usr/share/openldap/schema/inetorgperson.schema
include /usr/share/openldap/schema/nis.schema
include /usr/share/openldap/schema/samba.schema
pidfile /var/run/ldap/slapd.pid
argsfile /var/run/ldap/slapd.args

# Gestion des droits sur l'annuaire ACL

access to attrs=userPassword
by self write
by * auth
access to dn="dc=foadweb.cm,dc=cm"
by self write
by dn="cn=Manager,dc=foadweb,dc=cm" write
by users auth
by anonymous read
access to * by
self write
by * read

###########################################################
# ldbm and/or bdb database definitions #
###########################################################

database ldbm
suffix "dc=foadweb,dc=cm"
rootdn "cn=Manager,dc=foadweb,dc=cm"
rootpw mot_de_passe_admin
directory /var/lib/ldap
index objectClass,uid,uidNumber,gidNumber,ou eq
index cn,mail,surname,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq,pres
index default sub

37
  Fichier /etc/ldap.conf

host kigmoserver.foadweb.cm
base dc=foadweb,dc=cm
ldap_version 3
binddn cn=Manager,dc=foadweb,dc=cm
# Le mot de passe à utiliser pour s'authentifier sur le serveur LDAP (si binddn est défini)
bindpw password
rootbinddn cn=Manager,dc=foadweb,dc=cm
port 389
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_password exop
nss_base_passwd ou=Users,dc=foadweb,dc=cm?one
nss_base_shadow ou=Users,dc=foadweb,dc=cm?one
nss_base_group ou=Groups,dc=foadweb,dc=cm?one

 Fichier /etc/nsswith.conf

passwd: files ldap

shadow: files ldap
group: files ldap

 Fichier /etc/pam.d/system-auth

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so
account required /lib/security/pam_unix.so
account [default=bad success=ok user_unknown=ignore service_err=ignore
system_err=ignore]
/lib/security/pam_ldap.so
password required /lib/security/pam_cracklib.so retry=3 type=
password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/pam_ldap.so use_authtok
password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so
session optional /lib/security/pam_ldap.so

38
3.3.4- Installation et configuration de smbldap-tools
Les smbldap-tools sont des outils développés par idealx permettant de gérer des
comptes Samba de manière très simple en lignes de commandes. Nous les utiliserons dans le
fichier smb.conf pour ajouter certains comptes automatiquement, mais ils facilitent également
le travail quotidien de l'administrateur système. Une fois que nous avons téléchargé smbldap-
tools, nous créons le répertoire où seront installés les fichiers de configuration. Le répertoire
en question est /etc/smbldap-tools. La commande rpm –ivh smbldap-tools-0.9.11-
6.el7.noarch.rpm, permet d’installer le paquetage. Après installation nous aurons deux
fichiers crées dans le répertoire /etc/smbldap-tools à savoir smbldap.conf et
smbldap_bind.conf que nous devons éditer. La configuration de ces fichiers est très explicite
et simple. Une fois ces fichiers édités, nous tapons la commande suivante
/usr/share/doc/smbldap-tools.pl qui permet de faire correspondre notre fichier de
configuration de samba smb.conf à celle de smbldap-tools smbldap.conf. Nous pouvons à
présent peupler notre annuaire avec la commande suivante : smbldap-populate et nous
devons avoir un résultat comme ceci :
Using builtin directory structure
adding new entry : dc=foadweb,dc=cm
adding new entry : ou=Users,dc=foadweb,dc=cm
adding new entry : ou=Groups,dc=foadweb,dc=cm
…
…
…

L'annuaire est opérationnel à ce niveau et prêt à l'utilisation. Nous pouvons désormais y

stocker nos utilisateurs, ordinateurs et autres. Ainsi pour l'ensemble des utilisateurs de notre
domaine, les paramètres d'authentification seront désormais centralisés au niveau de
l'annuaire.

3.4- Installation de SAMBA

3.4.1- Téléchargement, recompilation et installation de samba
L'installation de samba 3 se fait de manière classique à la seule différence qu'il faut
préciser à samba de prendre en compte ldap.
 On télécharge la version samba-3.0.1-5sls.src.rpm à cette adresse :
http://rpm.pbone.net/index.php3?stat=26&dist=0&size=8477647&name=samba-3.0.1-
5sls.src.rpm
 On lance la commande: rpm -ivh samba-3.0.1-5sls.src.rpm

39
  On édite le fichier /usr/src/redhat/SPECS/samba.spec.
 Dans ce fichier on définit les options de configuration de notre fichier samba.
 On ajoute la ligne -- with - ldapsam.
 Puis on compile avec la commande : rpmbuild -ba samba.spec. La compilation peut
prendre plusieurs minutes.
 Après cette compilation, déplacez-vous dans le répertoire /usr/src/redhat/RPMS/i386
où vous trouverez les paquets à installer. Pour installer tous les paquets créer, faites
ceci : rpm -ivh samba-*.rpm
Ainsi samba est prêt pour être pris en compte par LDAP.

3.4.2- Configuration de samba : smb.conf

Description : Fichier de configuration pour réaliser un contrôleur de domaine sous
Samba.
Option general du serveur
[global]
# Nom du groupe de travail ou du domaine
workgroup = foadweb.cm
# nom de la machine (= hostname)
netbios name = KIGMOSERVER
# Nom qui apparait lors du parcours reseau (%h = hostname)
server string = PDC SAMBA-LDAP
# Activation du cryptage des mots de passe
encrypt passwords = yes
# Mode authentification
# share = ok pour tous
# user = oblige d'avoir un compte sur le serveur samba
# domain = pour joindre un domain
security = user
# Traitement des utilisateurs anonymes
;map to guest = Bad User
# Liste des utilisateurs non valides
; invalid users = guest
# Pour pouvoir synchroniser l'horloge des clients sur celle du serveur
;time server = Yes
# Option de connection
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
; hosts allow = 192.168.0. EXCEPT 192.168.0.35
; hosts deny = ALL
# Configuration des logs du serveur
log file = /var/log/samba/%m.log
# Taille maximal des logs (en kb)
max log size = 200
Option pour un contrôleur de domaine

40
# L'option ci-dessous définit Samba comme le contrôleur de domaine principal (maître).
domain master = yes
# Le niveau d'OS indique l'importance de ce serveur en tant que candidat au rôle de contrôleur
principal lorsqu'une élection est provoquée
os level = 65
# L'option ci-dessous indique samba de forcer une élection de contrôleur de domaine au
démarrage, et lui donne ainsi une petite chance de gagner lors de cette action
preferred master = yes
# Activez ce qui suit si vous voulez activer des "logon scripts" lorsque les utilisateurs se
connectent sur des postes Win95, 98, Me ou NT :
domain logons = yes
# Nom du script qui est exécuté lorsque les utilisateurs se logue
logon script = logon.bat
# Administrateur du domaine
admin users = root
# Utilisation de WINS pour la résolution des noms NETBIOS
#wins support = yes
dns proxy = no
# Ordre de résolution des noms NETBIOS
#name resolve order = lmhosts wins host bcast
ldap passwd sync = Yes
ldap suffix = dc=foadweb,dc=cm
ldap machine suffix = ou=Computers
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap admin dn = cn=Manager
ldap ssl = no
; SAMBA-LDAP declarations
passdb backend = ldapsam:ldap:// kigmoserver.foadweb.cm /
ldap filter = (&(objectclass=sambaSamAccount)(uid=%u))
ldap admin dn = cn=Manager,dc=foadweb,dc=cm
ldap suffix = dc=foadweb,dc=cm
ldap group suffix = ou=Groups
ldap user suffix = ou=Users
ldap machine suffix = ou=Computers
ldap ssl = start_tls
add machine script = /usr/local/sbin/smbldap-useradd -w "%u"
add user script = /usr/local/sbin/smbldap-useradd -m "%u"
#delete user script = /usr/local/sbin/smbldap-userdel "%u"
add group script = /usr/local/sbin/smbldap-groupadd -p "%g"
#delete group script = /usr/local/sbin/smbldap-groupdel "%g"
add user to group script = /usr/local/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/local/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/local/sbin/smbldap-usermod -g "%g" "%u"
#Option pour les partages de dossiers
# Le partage ci-dessous apparaîtra comme répertoire personnel pour l'utilisateur qui se
connecte au serveur. Samba remplacera automatiquement homes par le nom de l'utilisateur.
[homes]
comment = Home Directories

41
browseable = no
writable = yes
[netlogon]
# Dossier contenant les scripts à exécuter par les clients après leur authentification
path = /home/netlogon
read only = yes
write list = @domain admin
[public]
# Partage du dossier public, visible et accessible par tout le monde
comment = Répertoire public sur serveur
writable = yes
path = /home/samba/public
guest ok = yes

3.4.3- Premiers tests

Afin de tester Openldap, nous créerons un compte système dans l’annuaire LDAP
avec smbldap-tools : smbldap-useradd –a –m –P francis.
Le ‘-a’ signifie que l’on va créer un compte utilisateur Windows, c'est-à-dire un compte qui
pourra se connecter sur le domaine depuis une station cliente Windows.
Le ‘-m’ signifie que le répertoire personnel ‘home’ de ce compte utilisateur doit être crée.
Le ‘-P’ permet d’exécuter smbldap-passwd pour définir directement le mot de passe de
l’utilisateur après sa création.
Cet utilisateur pourra se "loguer" avec son compte sous GNU/Linux ET Windows ; si l'on
veut qu'il ne puisse pas se "loguer" sous GNU/Linux, il faut préciser un home "/dev/null" et
un shell "/bin/false", en le créant ainsi : smbldap-useradd -d /dev/null -s /bin/false -a -m -g
221 francis. On peut alors faire un premier test de connexion au serveur Openldap. Pour cela,
sur le serveur lui-même, on tente d’ouvrir une session avec l’utilisateur ‘francis ‘ et si on y
parvient, c’est que le serveur Openldap fonctionne correctement.
Maintenant que le serveur fonctionne, testons la jonction au domaine d’une station cliente
Windows et de s’authentifier sur le domaine avec l’utilisateur ‘francis’. Pour cela il faut créer
un compte machine avec smbldap-tools : smbldap-useradd –m Prophet$.
Prophet correspond au nom netbios de la machine Windows, le $ ajouté en fin de nom signifie
que cet "utilisateur" est une machine. Si cette commande pose problème, peut-être avons-nous
oublié de modifier les smbldap-tools ou de les configurer ? En suite vérifions que le compte
est bien reconnu du système avec la commande getent passwd qui devrait si tout va bien nous
présenter le compte Prophet$. Il est aussi possible de vérifier avec id Prophet$ qui en cas
d’absence de réponse signifie que le compte n’est pas vu ou reconnu du système. Enfin, nous
allons joindre le domaine en utilisant la machine cliente Windows ‘Prophet$’ et le compte
‘root’. Pour cette jonction, depuis le poste Windows l’on fait un clic droit sur poste de travail

42
> propriétés > mon de l’ordinateur. Dans la fenêtre qui s’ouvre, nous modifions le nom de
l’ordinateur et en cliquant sur le bouton radio Domaine, nous entrons foadweb.cm qui est
notre nom de domaine. Si le domaine est trouvé, nous serons invités à entrer un compte et mot
de passe. Utilisons le compte ROOT et son mot de passe.

Figure 3.7 : Ajout d'un poste Windows au domaine

Si tout se passe bien nous devons avoir une boite de dialogue avec le message «Bienvenue
dans le domaine Foadweb.cm».

Figure 3.8 : Bienvenue dans le domaine Foadweb.cm

A la demande du système à redémarrer la machine, nous acceptons afin que le nouveau

domaine soit pris en compte. Normalement si tout fonctionne, on doit pouvoir ouvrir une
session sur le domaine avec l’utilisateur ‘francis’ depuis la station cliente Windows Prophet$.

43
 Nous avons ainsi achevé avec la configuration de notre contrôleur de domaine et
pouvons y joindre l'ensemble des postes.

3.5- TLS entre client et le serveur LDAP

Nous allons implémenter TLS sur notre serveur LDAP pour que les communications
soient chiffrées. Cette manœuvre ajoute juste une commande de type STARTTLS qui permet,
si on le désire, de démarrer une transaction sécurisée sur le port standard LDAP. Il restera
toujours possible de communiquer "en clair" avec notre serveur. OpenLDAP doit être compilé
avec l'option --with-tls et OpenSSL doit être installé.

3.5.1- Génération des clefs et du certificat

Création de la structure des répertoires : mkdir certs csr datas keys private
datas/ca.db.certs touch private/ca.key datas/ca.db.serial
cp /dev/null datas/ca.db.index
Generation pseudo-random bytes: openssl rand 1024 > datas/random-bits
Création de la clé pour le CA : une « pass phrase » vous sera demandé. Ne l'oubliez pas: il
vous sera demandé chaque fois que vous voulez créer un nouveau certificat.
openssl genrsa -des3 -out private/ca.key 1024 -rand datas/random-bits
chmod 600 private/ca.key
Auto-signature du CA openssl req -new -x509 -days 3650 -key private/ca.key -out
certs/ca.pem
Création d'un fichier de configuration ca.conf pour le CA
Copier le fichier /usr/share/ssl/openssl.conf vers /etc/openssl et modifier les lignes suivantes :
dir = . # Where everything is kept
certs = ./certs # Where the issued certs are kept
new_certs_dir = ./datas/ca.db.certs # Where the issued crl are kept
database = ./datas/ca.db.index # database index file
serial = ./datas/ca.db.serial # The current serial number
RANDFILE = ./datas/random-bits # private random number file
certificate = ./certs/ca.pem # The CA certificate
private_key = ./private/ca.key
Initialisation de la serial database
echo '01' > datas/ca.db.serial
Nous avons donc les certificats et clé de base pour générer les certificats (ca.pem, ca.key). A
partir de ces fichiers, nous allons créer une clé et un certificat pour le serveur. Ces deux

44
fichiers auront comme autorité la clé et le certificat de base. Ces commandes sont à exécuter
dans le répertoire /etc/openssl.
Création de la clé et du certificat pour le serveur kigmoserver.foadweb.cm :
Création de la clé pour le serveur kigmoserver.foadweb.cm :
openssl genrsa -out keys/kigmoserver.key 1024
Création du certificat de données pour kigmoserver.foadweb.cm Quand le système vous
demande le Common Name, vous devez mettre le nom du serveur au format FQDN (full
qualified name), ex : kigmoserver.foadweb.cm.
openssl req -new -key keys/ kigmoserver.key -out csr/ kigmoserver.csr
Signé le certificat kigmoserver.foadweb.cm avec le CA
openssl ca -config ca.conf -out certs/ kigmoserver.txt -infiles csr/ kigmoserver.csr
Extraction du certificat kigmoserver.foadweb.cm:
perl -n -e 'm/BEGIN CERTIFICATE/ && do {$$seen=1}; $$seen && print;' < certs/
kigmoserver.txt > certs/ kigmoserver.pem
Vous pouvez aussi vérifier le certificat :
openssl verify -CAfile certs/ca.pem certs/ldap kigmoserver.pem
Vous avez alors les trois fichiers nécessaires pour configurer correctement le serveur:
/etc/openssl/certs/ca.pem : Le CA certificats
/etc/openssl/certs/kigmoserver.pem : Le certificat du serveur ldap.
/etc/openssl/keys/ kigmoserver.key : et la clé associée.

3.5.2- Mise en place côté serveur

Sur le serveur, modifier /etc/Openldap/slapd.conf et ajouter les chemins vers les différentes
clefs et le certificat :
# Chemin vers le certificat du serveur LDAP
TLSCertificateFile /etc/openssl/certs/kigmoserver.pem
# Chemin vers la clef privée du serveur LDAP
TLSCertificateKeyFile /etc/openssl/keys/kigmoserver.key
# Chemin vers le certificat de la CA
TLSCACertificateFile /etc/openssl/certs/ca.pem
Attention de bien ajouter ceci dans la section globale.
Si vous redémarrez votre serveur LDAP, il devrait désormais être capable de communiquer
avec TLS. Cette communication se fera sur le port 389 (standard, port LDAP) via la
commande starttls qui activera la transaction sécurisée. Attention, ceci est différent d'une

45
communication "purement" TLS, qui pourrait être mise en place sur le port LDAPS (636) via
un tunnel SSL.

3.5.3- Mise en place côté client

Nous allons mettre en place TLS au niveau de notre PDC.
La configuration des outils LDAP, de nss-ldap et de pam-ldap se fait via le fichier ldap.conf.
Pour autoriser les communications TLS, il faut modifier le fichier ldap.conf. Deux types de
directives existent : les directives OpenLDAP pures et les directives ajoutées par pam_ldap et
nss_ldap. Elles sont supplémentaires, l'oubli de l'une ou l'autre fera que l'application qui
l'utilise ne fonctionnera pas. Ceci peut conduire à des erreurs difficiles à diagnostiquer !
Ajoutez ceci au fichier ldap.conf du PDC :
#Directive SSL OpenSSL (pour ldapsearch notamment)
TLS_CACERT /etc/openssl/certs/ca.pem
#Directives SSL nss et pam
# Activation SSL brute (port 636)
# ssl no
# Acivation SSL via commande starttls (port standard 389)
ssl start_tls
#Verifie certificat serveur
tls_checkpeer yes
# Emplacement certificat CA
tls_cacertfile /etc/openssl/certs/ca.pem
Le fichier 'ca' doit être présent sur notre disque. Il s'agit du certificat de la CA. Il convient de
le copier au bon endroit (ici /etc/ldap/cert/) depuis notre serveur LDAP.

3.5.4- Test de connexion sécurisée

Testons depuis notre PDC, si les outils clients OpenLDAP fonctionnent :
ldapsearch -b 'dc=foadweb,dc=cm' -ZZ -xh kigmoserver.foadweb.cm L'ajout de -ZZ force la
communication en TLS. Vous devriez voir apparaître l'arborescence que nous avions déjà
auparavant. Si vous avez une erreur, vérifiez bien que le nom du serveur utilisé pour la
requête est bien le nom passé dans le CN lors de la demande de certificat du serveur ! Testons
ensuite la bonne configuration de ldap.conf : exécutons 'getent passwd' et voir si nos
utilisateurs LDAP sont bien listés.

3.5.5- Mise en place pour Samba

Le but de tout ceci étant de pouvoir intégrer TLS aux communications entre Samba et
notre serveur LDAP, terminons ce chapitre en modifiant le fichier smb.conf du PDC. Il suffit
de rajouter une ligne à notre configuration précédente : 'ldap ssl = start_tls'. N'oubliez pas non

46
plus de préciser le port sur lequel samba devra se connecter. Ici, le numéro du port est le 389,
puisque l'on utilisera la commande 'start_tls' sur une connexion LDAP standard. Notez qu'il
s'agit du port par défaut pour une connexion de type 'start_tls', mais autant le spécifier pour en
être sûr. Vérifiez enfin que le nom du serveur passé pour la directive 'ldap Server' correspond
bien au CN utilisé lors de la génération du certificat du serveur LDAP ! Si vous oubliez ce
petit détail, samba ne pourra pas établir la connexion TLS et votre fichier de "log" vous
indiquera : "TLS: can't connect"...
Pour vérifier que ceci fonctionne, "loguez" vous à partir de votre machine cliente Windows et,
au choix : sniffez les connexions entre le serveur LDAP et le PDC, ou bien examinez le
fichier de log concernant la machine cliente généré par Samba, vous pourrez lire, si tout se
passe bien : "Start_TLS issued: using a TLS connection".

3.6- Gestion des quota de disque

Généralement dans la plupart des distributions, les quotas sont utilisables d'office. Vous
devez vérifier deux choses afin utiliser les quotas :

 vous devez disposer des outils de gestion des quotas :

root@kigmoserver# rpm -qa | grep quota
quota-3.06-9
 la gestion des quotas doit être activée dans le noyau :
root@kigmoserver# grep -i quota /boot/config-2.4.20-8 CONFIG_QUOTA=y

En cas d’aucune réponse à la première commande, cela signifierait que les outils de
gestion de quota ne sont pas installés et qu’il faut avant tout les installer.

3.6.1- Configuration de /etc/fstab

Les quotas sont activés au démarrage grâce à la commande quotaon lancée par le script
/etc/rc.d/rc.sysinit. Les quotas sont désactivés à l'arrêt du système par la commande quotaoff.
Pour fixer les quotas sur un système de fichiers, il faut mettre à jour le fichier /etc/fstab. On va
pour cela ajouter les options de montage pour le ou les systèmes de fichiers concernés. Deux
options peuvent être utilisées, avec possibilité de combinaison:
 usrquota : active les quotas par utilisateur.
 grpquota : active les quotas par groupe d’utilisateur.

47
Exemple:
/dev/hdc1 /home ext3 defaults,usrquota 1 2
/dev/hdc2 /tmp ext3 defaults,grpquota 1 1

3.6.2- Création des structures nécessaires au fonctionnement des quotas

Un ou deux fichiers doivent être créés pour l'utilisation des quotas : aquota.user et
aquota.group. C'est dans ces fichiers que l'on configurera les quotas attribués aux utilisateurs
et/ou aux groupes. Ces fichiers doivent être créés à la racine des systèmes de fichiers qui
comportent ces quotas.
Exemple :
root@kigmoserver# touch /home/aquota.user
root@kigmoserver# touch /tmp/aquota.group
Attention : ne pas oublier de modifier les droits sur ces fichiers. Ils doivent comporter les
droits en écriture et lecture pour ROOT uniquement.
Exemple :
root@kigmoserver# chmod 600 /home/aquota.user
root@kigmoserver# chmod 600 /tmp/aquota.group
Remonter le ou les systèmes de fichiers concernés pour prendre en compte l'utilisation de
quotas pour ce système de fichiers.
root@kigmoserver# mount -o remount /home
root@kigmoserver# mount -o remount /tmp
Après création de ces fichiers, il faut initialiser la base des quotas en exécutant la commande
suivante : # quotacheck –auvg. Dans le cas contraire, la sanction est immédiate : edquota:
Quota file not found or has wrong format. No filesystems with quota detected.
Activer les quotas:
root@kigmoserver# quotaon -a

3.6.3- Attribution et vérification des quotas

3.6.3.1- Fixer des quotas

L'attribution des quotas se fait grâce à la commande edquota, utilisable quel que soit le
type de quota (utilisateur ou groupe). La commande ouvre un éditeur (vi ou emacs selon le
contenu de votre variable EDITOR), qui vous permet de modifier directement les fichiers
aquota.user ou aquota.group.

48
Syntaxe : edquota [-u user] [-g group] [-t]
 -u user définit les quotas pour un ou plusieurs utilisateurs
 -g group définit les quotas pour un ou plusieurs groupes
 -t définit les délais
Exemple :
root@ kigmoserver# edquota -u francis
Disk quotas for user francis (uid 500):
Filesystem blocks soft hard inodes soft hard
/dev/hdc1 0 9000 10000 0 90000 10000
Le fichier se compose de 6 colonnes :

 Filesystem : système de fichiers concerné par les quotas

 blocks : nombre de blocs occupés par l'utilisateur dans le système de fichiers. Ici
aucun fichier n'a encore été créé.
 soft : limite soft en nombre de blocs. Ici elle est fixée à 9 000 blocs soit environ 9 Mo
 hard : limite hard en nombre de blocs (environ 10 Mo)
 inodes : nombre d'inodes occupées par l'utilisateur dans le système de fichiers
 soft : limite soft en nombre d'inodes
 hard : limite hard en nombre d'inodes

On procédera de la même façon pour l'attribution de quotas à un groupe. (Ne tentez pas
d'éditer directement ces fichiers; ils ne sont pas au format texte.)

3.6.3.2- Fixer un délai

Nous avons vu également qu'on pouvait moduler le délai fixé entre le moment où
l'utilisateur atteint la limite soft et celui où on va lui interdire toute occupation supplémentaire
dans le système de fichiers. Nous fixerons la durée de ce délai, elle sera la même quel que soit
l'utilisateur et/ou le groupe.
Syntaxe : edquota -t
Exemple : root@ kigmoserver# edquota -t
Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
Filesystem Block grace period Inode grace period
/dev/hdc1 7minute 7minute
Il suffit donc de remplacer les valeurs par vos valeurs dans l'unité qui vous convient : second,
minute, hour, day, week.

49
3.6.3.3 - Dépassement de quotas : que se passe-t-il ?
Du côté utilisateur, nous décrirons les principaux cas de figure de dépassement de
quotas et les messages envoyés à l'utilisateur.
Prenons l'exemple suivant : l'utilisateur francis dispose de 9Mo en limite douce et 10 Mo en
limite dure. Son délai de grâce est de 7 minutes. Ci-dessous le contenu du système de fichiers
faisant l'objet de ces quotas :
francis@kigmoserver$ ls -l /home/francis
total 1842
-rw------- 1 root root 7168 fév 28 23:50 aquota.user
-rw-r--r-- 1 francis francis 1857516 mar 1 12:19 fic1
drwx------ 2 root root 12288 nov 28 12:59 lost+found
Nous sommes largement en dessous des quotas. Nous allons maintenant copier 4 fois le
fichier fic1. Les 3 premières copies se passent bien et nous avons fic2, fic3 et fic4. Ci-dessous,
la dernière copie
francis@kigmoserver$ cp fic1 fic5
ide1(22,10): warning, user block quota exceeded.
francis@kigmoserver$ ls -l
total 9134
-rw------- 1 root root 7168 fév 28 23:50 aquota.user
-rw-r--r-- 1 francis francis 1857516 mar 1 12:19 fic1
-rw-r--r-- 1 francis francis 1857516 mar 1 13:18 fic2
-rw-r--r-- 1 francis francis 1857516 mar 1 13:18 fic3
-rw-r--r-- 1 francis francis 1857516 mar 1 13:18 fic4
-rw-r--r-- 1 francis francis 1857516 mar 1 13:18 fic5
drwx------ 2 root root 12288 nov 28 12:59 lost+found

La limite douce est dépassée. L'utilisateur reçoit un message mais l'écriture est réalisée car
nous n'avons pas dépassé la limite dure. Deux cas de figure peuvent alors se présenter si
l'utilisateur ne contacte pas l'administrateur ou s'il ne libère pas de l'espace pour repasser en
dessous de la limite douce.
1er cas : l'utilisateur tente d'écrire dans le système de fichiers ce qui l'amène à dépasser la
limite dure.
francis@kigmoserver$ cp fic1 fic6 « ide1(22,10): write failed, user block limit reached. »
cp: écriture de `fic6': Débordement du quota d'espace disque L'opération échoue. Une partie
du fichier seulement a été copiée. L’utilisateur ne pourra plus écrire dans le système de
fichiers.
2ème cas : l'utilisateur laisse s'écouler le délai de grâce de 7 minutes fixé par l'administrateur.
Il tente alors de copier le contenu du fichier /etc/passwd par exemple. Le total de l'espace
occupé reste toutefois inférieur à la limite dure.
La sanction sera identique que dans le 1er cas. L'opération échoue.

50
francis@kigmoserver$ cp /etc/passwd.
ide1(22,10): write failed, user block quota exceeded too long.
cp: écriture de `./passwd': Débordement du quota d'espace disque L'opération a échoué
comme en témoigne le listage ci-dessous :
francis@kigmoserver$ ls -l passwd
-rw-r--r-- 1 francis francis 0 mar 1 14:48 passwd

De même si vous essayez d'écrire dans le fichier passwd, vous obtiendrez le message suivant
dans votre éditeur au moment de l'enregistrement :"passwd" erreur d'écriture (système de
fichiers plein ?) Appuyez sur ENTRÉE ou tapez une commande pour continuer. Il vous est
impossible d'écrire.

3.6.3.4- Vérification et affichage des quotas

Les commandes suivantes vont vous permettre d'une part de vérifier les quotas affectés
à chaque groupe et/ou utilisateur et éventuellement de synchroniser les informations
nécessaires au système pour le suivi de ces quotas.

La commande repquota permet d'afficher un résumé de l'utilisation des quotas et délais

de grâce.
Syntaxe : repquota [ -vug ] -a | filesystem

 -v : mode verbeux, affiche des infos supplémentaires

 -u : affiche des informations sur les quotas utilisateurs
 -g : affiche des informations sur les quotas groupes
 -a : affiche des informations sur tous les systèmes de fichiers disposant de quotas
 filesystem : affiche des informations sur les quotas du système de fichiers spécifié

Pour l'exemple, j'ai ajouté un utilisateur Bob.

# repquota -avug
*** Report for user quotas on device /dev/hdc10
Block grace time: 00:07; Inode grace time: 00:07
Block limits File limits
User used soft hard grace used soft hard grace
----------------------------------------------------------------------
root -- 19 0 0 2 0 0
francis -- 7293 9000 10000 5 9000 10000
bob +- 9000 8000 9000 00:07 5 8000 9000

51
+ -- 19 0 0 2 0 0
Statistics:
Total blocks: 7
Data blocks: 1
Entries: 3
Used average: 3,000000
On trouve ici les informations relatives aux quotas imposés aux utilisateurs. On trouvera
autant de lignes que d'utilisateurs, groupes et systèmes de fichiers concernés. Sont rappelés les
quotas fixés en nombre de blocs et d'inodes. On trouve également le nombre de blocs et le
nombre d'inodes utilisés. Quand un horodatage apparaît dans la colonne grace, comme par
exemple pour Bob, cela signifie que l'utilisateur (ou le groupe) a dépassé la limite douce. Le
délai de grâce est donc décompté. Vous pouvez également utiliser la commande quota suivie
du nom d'un utilisateur ou d'un groupe. Là encore vous obtiendrez toutes les informations
relatives aux quotas et à l'utilisation de l'espace attribué. Exemple : pour obtenir les
informations liées aux quotas concernant francis : root@kigmoserver# quota nom_user Disk
quotas for user francis (uid 500): Filesystem blocks quota limit grace files quota limit
grace /dev/hdc10 7293 9000 10000 5 9000 10000
Il peut arriver que les fichiers de quotas deviennent incohérents. La gestion de ceux-ci
devient alors impossible. D'autre part, lorsque vous ajoutez un nouvel utilisateur ou un
nouveau groupe à l'aide de la commande edquota, il faut là encore synchroniser les fichiers
pour la prise en compte de ces nouvelles notions.
Syntaxe: quotacheck [-vug] -a | filesystem

 -v : mode verbeux, affiche des infos supplémentaires

 -u : vérifie uniquement les fichiers de quotas utilisateurs
 -g : vérifie uniquement les fichiers de quotas groupes
 -a : vérifie les fichiers de quotas de tous les systèmes de fichiers
 filesystem : vérifie les fichiers de quotas du système de fichiers spécifié

Exemple : vérifier tous les fichiers de quotas, quel que soit le système de fichiers
concerné
root@kigmoserver# quotaoff -a
root@kigmoserver# quotacheck -auvg
quotacheck: Scanning /dev/hdc10 [/home/francis/quota] done
quotacheck: Checked 2 directories and 10 files
Voilà pour cette partie concernant les quotas. Pour plus d'informations, consulter le
manuel des commandes : repquota, quotaon, quotaoff, quotacheck, edquota.

52
 A ce niveau de paramétrage, nous notons que le système (couplage SAMBA et
OpenLDAP) est opérationnelle et les différents échanges entre les postes clients et le serveur
se feront de manière sécurisée à l'aide de TLS. De même, une utilisation rationnelle de
l'espace disque sera observée par les utilisateurs car chacun a une limite à respecter et pour
cela, ne devra garder sur le serveur que ce qui est vraiment important.

53
Chapitre 4 : Les résultats obtenus
A cette phase de notre travail, nous allons présenter les résultats obtenus après la phase
d'implémentation, ceci afin de vérifier si solution a été trouvé pour le problème initial et
ressortir les possibilités d'amélioration.

4.1 - Résultats techniques

Dans la configuration initiale du système, les postes de travail fonctionnaient de
manière indépendante. Chaque poste disposait de sa base d'identification et y avait accès
uniquement les utilisateurs y possédant un compte. A l'arrivée d'un nouvel utilisateur dans la
structure, l'administrateur devra se déplacer sur chacun des postes pour lui créer un compte.

Tableau 4.1 : Gestion des comptes sans annuaire

Poste A Poste B Poste C Total

N Création de N Création de N Création de N (Nombre de
utilisateurs comptes utilisateurs comptes comptes poste)
(Identifiant et mot de utilisateurs (Identifiant et mot * (Nombre
passe) (Identifiant et mot de passe) d'utilisateur)
de passe)

5 utilisateurs 5 comptes 5 comptes 5 comptes 15

100 100 comptes 100 comptes 100 comptes 300

utilisateurs

Ainsi avec cinq utilisateurs dans une structure, l'on devra créer quinze comptes afin de
permettre à chaque utilisateur d'avoir accès aux trois postes de la structure. A défaut, créer un
compte unique sur chaque poste (soit trois comptes) et que ce compte soit utilisé par
l'ensemble des utilisateurs, ce qui pose un sérieux problème de sécurité et de confidentialité.
Dans cette configuration, un serveur n'est pas nécessaire.
La mise en place du domaine et la centralisation de l'authentification dans l'annuaire,
nous permet une gestion plus simple de nos utilisateurs et réduit considérablement la charge
de travail de l'administrateur système et réseaux. La présence d'un serveur devient impérative.
Poste A Poste B Poste C Serveur Total
N utilisateurs Aucun Aucun Aucun Création de N comptes N comptes
utilisateurs
(Identifiant et mot de passe)
5 utilisateurs 0 0 0 5 5

54
100 0 0 0 100 100
utilisateurs
Tableau 4.2 : Gestion des comptes avec annuaire

Pour le même nombre de cinq utilisateurs, nous avons désormais trois postes et un
serveur. Uniquement cinq comptes seront utilisés, ce qui réduit presque de moitié la charge de
travail liée à la création et la gestion des comptes utilisateurs. Nous constatons que plus le
nombre d'utilisateurs est élevé, plus l'on devra en créer des comptes sur les différents postes.
La centralisation nous donne de ne plus tenir compte du nombre de poste disponible dans le
réseaux mais de gérer uniquement l'utilisateur qui avec ses droits d'accès pourra travailler sur
l'ensemble des postes du domaine.
Pour une administration plus simple de notre annuaire, nous avons mis en place une
interface web qui est phpLDAPadmin. Notre interface d'administration sera dont ainsi :

Figure 4.1 : Interface d'administration phpLDAPadmin

La solution mise en place, en plus de simplifier la gestion des comptes utilisateurs,
permettra une gestion centralisée du réseau dans l'ensemble. Le partage de ressources
(imprimantes par exemple) devient assez pratique et économique.

4.2 - Résultats économiques

Sur le plan financier, la solution mise en place permet à la structure de faire des
économies considérables. Nous notons qu'une solution propriétaire à l'instar d'Active

55
Directory aura nécessité un budget pour la licence du système d'exploitation serveur ainsi
qu'un antivirus dont la licence est périodiquement (annuellement en général) renouvelée. Une
licence Windows serveur 2012 coute environ 300.000 FCFA et Windows serveur est déjà à la
version 2019. Une licence antivirus pour serveur coute environ 100.000 FCFA pour une
validité d'un an. En optant dont pour une solution libre, des économies très significatives ont
été faite par la structure.
Nous avons mis en place sur un seul serveur physique, le contrôleur de domaine
SAMBA et l'annuaire OpenLADAP. Cette configuration permet déjà un gain considérable sur
le prix d'achat d'un serveur bien que cela soit potentiellement un risque. En cas de panne de la
machine physique, le contrôleur de domaine et l'annuaire se trouvent indisponible.

Figure 4.3 : SAMBA et OpenLDAP en UN

L'architecture à la fin de l'implémentation est dont la suivante :

56
 SAMBA + OpenLDAP

Poste B
Utilisateur 1
Utilisateur 2
Utilisateur 3
Utilisateur 4
Utilisateur 5
Utilisateur 6

Poste A
Switch

Poste C

Poste D
Figure 4.3 : Architecture finale

4.3 - Perspectives
Le système mis en place répond bien à la situation initiale où la gestion des utilisateurs
dans la structure n'était pas centralisée. L'on note tout de même à partir de l'architecture finale
des points à optimiser. Une indisponibilité quelconque du serveur mettrait en mal le
fonctionnement global de l'ensemble du système avec l'impossibilité des utilisateurs à se
connecter, l'indisponibilité des ressources partagées. Il devient dont nécessaire de mettre en
place un système de réplication à la fois de l'annuaire et du contrôleur de domaine, ce qui
permettra une haute disponibilité des serveurs.

Figure 4.4 : Architecture Samba et LDAP avec réplication

57
 Conclusion Générale

Au terme de ce travail, nous pouvons dire et sans risque de nous tromper que nous
avons été confrontés à de nombreuses difficultés, surtout au niveau de la compréhension de
nos principaux outils de travail à savoir Samba, Openldap et les modules PAM et NSS
pour LDAP; Cependant, faisant abstraction de toutes ces difficultés, nous avons pu obtenir
quelques résultats concrets, au regard de l’objectif qui a été préalablement fixé : Mise sur Pied
d’un Contrôleur de Domaine SAMBA avec Authentification via un Annuaire LDAP et
Gestion des Quotas de Disque. Pour atteindre cet objectif, nous avons utilisé SAMBA
comme contrôleur de domaine, Openldap comme l’annuaire LDAP ainsi que ses modules
PAM et NSS et smbldap-tools pour la création des comptes utilisateurs du domaine SAMBA
dans l’annuaire. phpLDAPadmin a été installé pour simplifier l'administration de notre
annuaire.
Tous les postes utilisateurs ont pu être joint au domaine mis en place et chaque
utilisateur dispose désormais d'un compte unique (login et mot de passe) permettre d'avoir un
accès à partir de tout ordinateur lié au domaine. Des paramétrages supplémentaires peuvent
limiter les accès des une et des autres en fonction des postes ou autres ressources mais ces
restrictions n'ont pas été faites.
Avec le contrôleur de domaine que nous avons mis sur pied, on se rend
compte que les utilisateurs ne peuvent y accéder qu’à partir d’un ordinateur faisant partie du
domaine, ou se trouvant dans le même réseau IP à partir du voisinage réseau. Vue cette limite,
l’on pourra dans la mesure du possible ajouter à notre serveur SAMBA, un serveur FTP (File
Transfer Protocol) qui permettrait aux utilisateurs, même hors du domaine et dans un
réseau IP différent d’accéder à leurs répertoires personnels. L'option de réplication sera
une solution pour prévenir à une indisponibilité de notre serveur principale.

58
 Bibliographie

[1] Marcel Rizcallah - Annuaires LDAP, 2e édition

[2] Dominique Colombani - LDAP : Maîtrise du protocole - Exploitation d'un service
d'annuaire (OpenLDAP, Active Directory), Eni Editions.
[3] Marc OLORY – LDAP et les services d’annuaire, Décembre 2010, http://igm.univ-
mlv.fr/~dr/XPOSE2009/ldap/xpose_ldap.pdf, consulté le 05-08-2019
[4] Michel Gardie http://www-public.imtbs-tsp.eu/~gardie/LDAP/Articles/annuaires-
LDAP.html, consulté le 01-08-2019
[5] http://www.padl.com/OSS/nss_ldap.html, consulté le 30-08-2019
[6] http://www.padl.com/OSS/pam_ldap.html, consulté le 30-08-2019
[7] Copyright © 2004 L'équipe Freeduc-Sup http://www.linux-
france.org/prj/edu/archinet/systeme/ch25s11.html, consulté le 12-09-2019
[8] http://www.tux-planet.fr/un-controleur-de-domaine-avec-samba/, consulté le 12-09-2019
[9] http://www-lor.int-evry.fr/~michel/LDAP/SASL/TLS-SSL.html, consulté le 11-09-2019
[10] http://www.authsecu.com/ssl-tls/ssl-tls.php, consulté le 19-09-2019
[11] Anne, https://lea-linux.org/documentations/Admin-admin_fs-quotas, consulté le 19-09-
2019
[12] http://www.ced-info.com/administration-reseaux/pdc-samba-ldap
[13] Jehan Procaccia MCI INT-EVRY - jehan.procaccia@int-evry.fr, http://www.telecom-
sudparis.eu/s2ia/user/procacci/ldap/Ldap_int.html#htoc1, consulté le 27-09-2019
[14] Copyright © 2004 Michaël Parienti Maire , Easter-eggs, http://ldapbook.labs.libre-
entreprise.org/book/html/ch01s04.html, consulté le 30-09-2019
[15] Steve HERVE, http://www-igm.univ-mlv.fr/~dr/XPOSE2003/HERVE/, consulté le 19-
09-2019
[16] Xavier Claude. Licence CC by-sa. https://linuxfr.org/news/samba-se-met-enfin-en-4-0-
et-prend-en-charge-les-ad#toc_0, consulté le 09-08-2019
[17] http://rpm.pbone.net/index.php3/stat/4/idpl/55096805/dir/redhat_el_7/com/openldap-
2.4.39-3.el7.x86_64.rpm.html, consulté le 29-08-2019
[18] http://rpm.pbone.net/index.php3/stat/4/idpl/56565574/dir/redhat_el_7/com/smbldap-
tools-0.9.11-6.el7.noarch.rpm.html, consulté le 29-08-2019
[19] http://rpm.pbone.net/index.php3?stat=26&dist=0&size=8477647&name=samba-3.0.1-
5sls.src.rpm, consulté le 29-08-2019
[20] http://listes.cru.fr/sympa/info/ldap-fr : ldap-fr@cru.fr

59