Memoire Final (Corrigé)

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 68

MINISTERE DE L’ENSEIGNEMENT TECHNIQUE ET REPUBLIQUE TOGOLAISE

DE LA FORMATION PROFESSIONNELLE Travail-Liberté-Patrie


(M.ET.F.P)

OFFICE DU BREVET DE TECHNICIEN SUPERIEUR


(OBTS)

INSTITUT AFRICAIN D’ADMINISTRATION ET


D’ETUDES COMMERCIALES
(IAEC)

MEMOIRE DE FIN DE FORMATION EN VUE DE L’OBTENTION DU


BREVET DE TECHNICIEN
SUPERIEUR – BTS

OPTION : ADMINISTRATEUR DE RESEAUX LOCAUX D’ENTREPRISES

THEME :

PROJET DE MISE EN PLACE ET CONFIGURATION DE


SAMBA EN TANT QUE SERVEUR DE FICHIERS ET
CONTROLEUR DE DOMAINE SUR LE RESEAU DE LA
CHAMBRE DE COMMERCE ET D’INDUSTRIE DU
TOGO (CCIT)

PROMOTION 2004 - 2006

Présenté et soutenu par :

DOLA Kossi Séyram

Sous la direction de :

Directeur de Mémoire Maître de stage

M. Norbert GLAKPE M. KAVEGE Yawo


Instructeur Cisco au CIC/CAFMICRO (UL)
Responsable IT TOTAL-TOGO Administrateur réseau de la CCIT
SOMMAIRE

Sommaire .......................................................................................................................... i
Dédicaces .......................................................................................................................... ii
Remerciements ................................................................................................................ iii
Avant propos.................................................................................................................... iv
Introduction...................................................................................................................... 1
PREMIERE PARTIE : PRESENTATION DE LA CCIT .............................. 3
A. PRESENTATION GENERALE ........................................................................ 4
B. PRESENTATION ET ANALYSE DU DOMAINE D’ETUDE ................... 9
DEUXIEME : PARTIE ETUDE PREALABLE................................................... 10
A. ETUDE DE L’EXISTANT .................................................................................. 11
B. ARCHITECTURE LAN DE LA CCIT ............................................................. 15
C. CRITIQUE DE L’EXISTANT ............................................................................ 16
D. PROBLEMATIQUES ET APPROCHES DE SOLUTIONS ........................ 16
TROISIEME PARTIE : ETUDE DETAILLEE DU PROJET..................... 18
A. OPTIMISATION DE LA GESTION DES UTILISATEURS ET DES PARTAGES 19
B. LA MISE EN PLACE ........................................................................................... 27
SCHEMA FINAL DE L’ARCHITECTURE PROPOSEE POUR LE RESEAU LAN DE LA CCIT ..................... 54
CONCLUSION .......................................................................................................................... 56
BIBLIOGRAPHIE ..................................................................................................................... 58
TABLE DES MATIERES ....................................................................................................... 60

i
DEDICACE

Je dédie ce document à mon père DOLA Kodjo Gayanglo Joseph et à ma mère


ESSEH Akossiwa Grace-Pauline, qui n’ont sans cesse œuvré pour faire de mon
cursus scolaire une réussite.

ii
REMERCIEMENTS

Le présent travail n’aurait été possible sans les divers efforts que certaines
personnes ont déployés à notre égard. Nous tenons ainsi à présenter à toutes ces
personnes nos reconnaissances et remerciements.
Toutes nos gratitudes vont particulièrement à :

• Au Président de la CCIT
• M. BROUHM secrétaire général de la CCIT

• Tout le personnel de la CCIT pour leur encouragement, et


disponibilité tout au long du stage.
• M. Bassabi KAGBARA, Président Directeur Général du Groupe BK

• M. Anawoe ABISSI, Directeur Général de l’IAEC


• Mes parents qui, malgré toutes les difficultés de la vie, n’ont jamais
cessé de m’apporter leur soutien moral et financier.
• Nos frères et sœurs Honoré, Philippe, Jocelyne et Myriam pour leur
soutien moral et encouragement.
• M. GLAKPE Komlan : notre Directeur de mémoire pour ses précieux
conseils et sa disponibilité.
• M. KAVEGE Yawo notre maître de stage, pour ses conseils et son
encadrement technique.
• M. KOSSI Ezoba, juriste pour son soutien et encouragement.
• Tous les enseignants de l’IAEC pour le partage de connaissances.
• Tous nos camarades KOUDEKA Morlé, SEBA Eyram, NYONATO
Nunya, Cyrille ROASSOUM NGARBIM, KOUDEKA Edem,
DJINADJA Christelle, NEBONA Dimitri, et Jean YARBONDJOA
pour leur encouragement et atmosphère familiale qu’ils m’ont fait
vivre durant toutes ces années.
• Tous ceux qui de près ou de loin ont contribués à la réalisation de ce
travail.

iii
AVANT PROPOS

L’Institut Africain d’Administration et d’Etudes Commerciales est l’une des


premières écoles de BTS au Togo. Elle fut fondée en 1986. L’IAEC forme en
deux ans, des techniciens supérieurs très qualifiés ayant des compétences à
mettre au profit des sociétés et de la nation.

Cette formation étalée sur (2) ans est théorique et plus axée sur la pratique. Elle
est sanctionnée par deux diplômes : le Diplôme de Technicien Supérieur DTS et
le Brevet de Technicien Supérieur BTS (diplôme de l’Etat Togolais).

L’étudiant en fin du premier cycle, admissible au BTS doit parfaire ses


connaissances par un stage obligatoire en entreprise.

A la fin de ce stage en entreprise, la rédaction d’un mémoire tenant compte des


réalités socioprofessionnelles, des problèmes techniques et des approches de
solutions, sera présenté devant un jury afin d’obtenir le diplôme final. C’est dans
cette perspective que ce document est rédigé.

Ce document est le fruit de trois (3) mois de stage au Service Informatique de la


Chambre de Commerce et d’Industrie du Togo (CCIT).

iv
INTRODUCTION

1
Aujourd’hui, la communication entre les différents agents de l’entreprise est un
facteur primordial dans le développement d’une entreprise. L’information doit
être partagée entre les différents agents de l’entreprise, afin que celle-ci puisse
répondre efficacement aux besoins de son environnement.
Ainsi l’accès, la circulation, le tunnel de communication, le traitement et le
partage de l’information sont d’une importance capitale pour l’entreprise, qui se
veut compétitive dans un environnement où l’information est devenue un facteur
de croissance.
Dans le souci de répondre efficacement aux besoins des entreprises, la CCIT a
mis en place un réseau informatique en vue de faciliter les traitements et
d’optimiser les temps de réponses. La CCIT s’est doté d’un parc informatique
composé d’ordinateurs tournant sur des systèmes d’exploitation propriétaires
tels que Windows Xp professionnel, Windows 2003 server et des systèmes
d’exploitation libres tels que Redhat 8.0 et Ubuntu.
Cependant, bien qu’étant doté d’un système informatique afin d’automatiser et
de faciliter les tâches de gestion courantes, il subsiste encore des insuffisances
dans la gestion des ressources partagées et l’authentification des utilisateurs.
Cela engendre une vulnérabilité du réseau.
Afin de relier tous ses ordinateurs dans un même réseau, leur permettant
d’accéder de manière sécurisée aux ressources partagées. Il nous a été demandé
de constituer un projet permettant de gérer l’authentification des utilisateurs
dans le domaine, ainsi qu’une politique de partage et d’accès aux ressources au
sein de ce réseau hétérogène.
Le projet est subdivisé essentiellement en trois points à savoir : la mise en place
d’un serveur de fichier Samba pour gérer le partage des ressources, la mise en
place d’un Annuaire OpenLDAP pour gérer les authentifications et d’un
contrôleur de domaine (DC) pour unifier la gestion des droits sur les ressources
et mieux définir les accès à celles-ci.
Notre document s’articule autour de trois grands axes : à savoir la présentation
de la chambre de commerce et d’industrie du Togo (CCIT), son évolution, ses
objectifs et missions, son fonctionnement sur le plan social et organisationnel ;
l’analyse global des équipements matériel et logiciel, la politique d’accès aux
ressources, la gestion des authentifications au sein du réseau existant, leurs
insuffisances et problèmes rencontrés ; et en définitive la présentation détaillée
du projet qui nous a été confié.

2
1ER PARTIE

PRESENTATION DE LA CCIT

3
A. PRESENTATION GENERALE
I- HISTORIQUE

Située à l’angle de l’Avenue de la Présidence et de l’Avenue Georges


POMPIDOU au Sud de la ville de Lomé, la Chambre de Commerce et
d’Industrie du Togo (CCIT) est l’émanation d’une ancienne institution de
l’époque coloniale française.
En effet, la Chambre de Commerce et d’Industrie du Togo fut instituée par
l’arrêté n°58 du 21 Juin 1921 dans un contexte de nécessité. Il s’agissait à
l’époque d’étendre sur le Togo le décret instituant ce type de chambre en
Afrique Occidentale Française (AOF). Au delà de cet objectif, la France désirait
tirer profit de l’ancienne colonie allemande par le biais d’une bonne organisation
du circuit commercial.
Après l’effort de guerre de 1939 à 1945, les autochtones, aspirent à une plus
grande liberté et désirent participer à la gestion des affaires de leur pays. D’une
part, c’est pour répondre à ce désir qu’une section agricole et industrielle fut
annexée à la section principale commerciale. D’autre part, il s’agissait d’étendre
sur le Togo le décret du 15 Mars 1917 approuvant le mode d’institution des
Chambres de Commerce, d’Agriculture et d’Industrie en AOF, ratifié par le
Togo en vertu du décret du 22 Mai 1924.
Ainsi, depuis le 11 Mai 1954, la Compagnie Consulaire devient la Chambre de
Commerce, d’Agriculture et d’Industrie du Togo (CCAIT).
Donc, de 1954 jusqu’à 1977, la CCAIT a œuvré dans les secteurs du commerce,
de l’agriculture et de l’industrie. Mais à partir de la loi n°97/12 du 9 Juillet 1997
portant création, organisation et fonctionnement de la Chambre d’Agriculture, la
CCAIT est devenue CCIT et ne traite plus que les affaires relatives au
commerce et à l’industrie sur l’ensemble du territoire de la République
Togolaise et assure la représentation des intérêts commerciaux et industriels.
L’année 1998 verra la création dans chaque région économique du Togo et dans
la commune de Lomé d’une chambre régionale de commerce et d’industrie.
II- LES OBJECTIFS ET MISSIONS DE LA CCIT
1. Les Objectifs de la CCIT

Les objectifs principaux de la CCIT se situent à cinq (5) niveaux :

• Connaître l’environnement économique du Togo et suivre son évolution ;


• Servir de relais entre le secteur privé et les pouvoirs publics ;

4
• Aider à promouvoir les secteurs de commerce et de l’industrie du Togo ;
• Diffuser l’information et organiser la réflexion dans les secteurs
concernés au niveau national, régional, et international ;

• Créer et gérer des infrastructures favorisant le développement du pays.

2. Missions de la CCIT

La CCIT a pour missions :


• De représenter l’ensemble des opérateurs économiques sur le plan
national ;
• D’assurer la promotion du commerce, de l’industrie et des prestations de
services ;
• D’informer, de former et de conseiller ses ressortissants ;
• De présenter ses vues sur les moyens d’accroître le développement et la
prospérité des activités économiques ;
• De donner à l’administration les renseignements et les avis qui lui sont
demandés ;
• De désigner, à la demande de l’administration des représentants aux
commissions éventuelles formées pour l’étude des problèmes
commerciaux, industriels et des services ;
• D’assurer, sous réserve des autorisations réglementaires, l’exécution des
travaux et la gestion des services nécessaires aux intérêts dont elle a la
charge ;
• De participer à des enquêtes économiques et de prêter ses concours à
certaines manifestations telles que les foires, les expositions, etc.
• De recevoir des autorisations judiciaires compétentes, notification de
toute inscription ou modification au registre du commerce des entreprises
en vue de tenir à jour les fichiers et répertoires d’informations relatives à
ses ressortissants.

5
III- STRUCTURE ADMINISTRATIVE ET ORGANISATIONNELLE

La CCIT est un établissement public à caractère professionnel dirigé par un


bureau élu par l’ensemble des opérateurs économiques. L’assemblée consulaire
est dirigée par un président ; ce dernier détient les pouvoirs étendus pour agir au
nom du bureau.
Pour atteindre ses objectifs, la CCIT dispose de la structure suivante :
- Le Secrétariat Général
- Division des Entreprises et de la Formation Professionnelle (DEFP)
- Le Centre des Formalités Des Entreprises (CFE) ou Guichet Unique
- Les Cellules d’Assistance aux Entreprises
- La Division Assistance aux Entreprises (DIVAE)
- Le Centre Togolais des Investisseurs (CTI)
- Le Centre pour le développement des Entreprises (CDE, accord ACP-UE de
Cotonou)
- La Division Documentation et Publication
- La Division Presse
-La Division du Fonds de Garantie Routier (FGR)
- La Division des Relations extérieures
- La Division Financière et Comptable
- Division Ressources Humaines
- Délégation de Kara ou l’Antenne de Kara
1. Le Secrétariat Général

Sur proposition du Président et après accord du bureau, le Ministre de tutelle


nomme par arrêté un Secrétaire Général, qui peut être pris hors de l’Assemblée
Consulaire ; Le Secrétaire Général étant sous l’autorité et le contrôle du
Président, veille au fonctionnement administratif de la Chambre Consulaire. Il
est le Directeur des services. Il a aussi un attaché qui est chargé de la
coopération internationale.

6
2. Division des Entreprises et de la Formation Professionnelle (DEFP)

Elle assiste les entrepreneurs dans les différentes étapes de la création


d’entreprise telles :

• La mise à disposition des informations sur les procédures


administratives ;
• L’inscription des entreprises au registre du commerce ;
• Obtention de la carte de ressortissant ;
• Délivrance des visas de certificats d’origine pour les produits agrées ;
• Des renseignements commerciaux et des relations avec les entreprises ;
• La collecte des cotisations annuelles.
3. Le Centre des Formalités Des Entreprises (CFE) ou Guichet Unique

Il a été créé par le décret n°2000-09/PR du 08 Novembre 2000 pour simplifier la


procédure administrative de création d’entreprise.
4. Les Cellules d’Assistance aux Entreprises

¾ La Division Assistance aux Entreprises (DIVAE)


C’est une cellule d’appui aux microréalisations qui assiste les entreprises
dans :
9 La recherche et définition des projets ;
9 L’orientation d’activités ;
9 Négociation de crédits et prêts bancaires ;
9 Assistance à la gestion, au financement et à l’information
¾ Le Centre Togolais des Investisseurs (CTI)
C’est une cellule d’appui aux projets industriels.
¾ Le Centre pour le développement des Entreprises
(CDE, accord ACP-UE de Cotonou)
Elle accorde des subventions aux entreprises et organisations
intermédiaires pour financer leur création et / ou leur développement.

7
5. La Division Documentation et Publication

Elle met à la disposition des opérateurs économiques des informations sur la


fiscalité, l’industrie, la douane, le commerce intérieur et extérieur et un centre de
documentation, un cyberespace pour l’accès à Internet et un bulletin trimestriel
d’information dénommé « La croisière des Opérateurs Economiques » sur les
activités consulaires et la vie des sociétés.
6. La Division Presse

Elle publie une revue mensuelle « l’Entrepreneur » sur les opportunités


d’affaires au Togo et dans le monde.
7. La Division du Fonds de Garantie Routier (FGR)

Elle éclaire sur le Transit Routier Inter-états (TRIE) des marchandises au sein de
la CEDEAO, l’organisation générale et la réglementation du transit.
8. La Division des Relations extérieures

Elle permet la promotion des produits et un contact avec les consommateurs


dans un climat favorable aux affaires.
9. La Division Financière et Comptable

Ce service tient la comptabilité de la Compagnie Consulaire et participe à la


préparation du budget, et assure le contrôle de la gestion.
10. Division Ressources Humaines

La CCIT a un personnel dynamique composé des employés dont des agents


d’exécution, des agents de maîtrise et des agents cadres et des agents hors
catégorie. Cette division a en charge la gestion du personnel et s’occupe de son
cursus professionnel en termes de gestion des avancements, des formations, des
recyclages, des stages, des congés, de l’assurance, de la mise en disponibilité,
des départs à la retraite…
11. Délégation de Kara ou l’Antenne de Kara

Créée depuis 1982, la délégation de Kara est une antenne de relais qui représente
la CCIT dans toute la partie septentrionale du Togo. Elle fournit aux opérateurs
économiques de cette région, les renseignements relatifs à l’obtention du registre
de commerce.

8
B. PRESENTATION ET ANALYSE DU DOMAINE D’ETUDE

I- LE SERVICE INFORMATIQUE
Il est un service très important de la chambre de commerce et d’industrie du
Togo (CCIT). Il assure le bon fonctionnement du réseau, le développement
d’applications répondant aux besoins des utilisateurs ou des services, l’entretien
et la maintenance des équipements informatiques.

II- LE PARC INFORMATIQUE


Le parc informatique de la CCIT est assez important, il est composé de trois
serveurs :

Serveurs Système d’exploitation Description


Sert au service Comptabilité
Comptabilité Windows Server 2003 pour l’immobilisation et paye
sous Sage Saari
Utiliser pour le partage de la
Proxy Linux RedHat 8.0 connexion Internet à tous les
services
Utiliser pour la résolution de
nom, la gestion des mails de
DNS, Mail et Web Linux RedHat 8.0
tout le personnel et la
publication de site Web

Mis à part les serveurs cités ci-dessus, le réseau de la CCIT dispose de cinquante
(50) ordinateurs, de huit (8) switchs, trois (3) scanneurs, quinze (15)
imprimantes, d’un routeur Cisco 1720, d’onduleurs, de câbles réseau Ethernet
catégorie 5, de connecteurs RJ45 , de deux(2) panneaux de brassages (24) ports
et de trois (3) coffrets.

9
2EME PARTIE

ETUDE PREALABLE

10
A. ETUDE DE L’EXISTANT
I- PRESENTATION DU PROJET ET DE SES OBJECTIFS
La Compagnie consulaire qu’est la C.C.I.T, dans le souci de satisfaire sa
clientèle et ses partenaires économiques ne cesse de faire des efforts
considérables dans le domaine de la modernisation. C'est ainsi qu'elle s'est
lancée dans le processus d’informatisation de tous ses services en vue d’une
meilleure rentabilité.
A ce souci de modernisation, il faut aussi ajouter sa volonté d’aider les étudiants
en fin de formation à mettre en pratique les enseignements reçus aux cours de
leur formation technique. C’est pour toutes ces raisons qu’il nous a été confié le
projet << la mise en place et la configuration de Samba en tant que serveur de
fichier et contrôleur de domaine sur le réseau de la CCIT >>
La gestion du réseau informatique d’une entreprise est un travail très complexe
et ceci est le cas d’une grande structure organisée comme la chambre de
commerce et d’industrie du Togo. Cette gestion est confiée au service
informatique, qui se charge de :
• L’implémentation de nouveaux services sur le réseau, répondant aux
besoins des utilisateurs ;
• La maintenance et l’installation de tous les équipements informatiques ;

• L’assistance auprès des utilisateurs confrontés aux divers problèmes


informatiques ;
• La formation des utilisateurs sur les nouvelles fonctionnalités ou services
disponibles sur le réseau ;
• Le contrôle et le suivi du trafic sur le réseau ;
• L’installation des logiciels sur les postes de travail et serveurs ;
• La réalisation d’interviews permettant d’évaluer les besoins, attentes et
satisfactions des utilisateurs.
Nous comprenons donc l’importante place qu’occupe le service informatique
dans cette structure organisée qu’est la CCIT et mérite par conséquent une
attention particulaire de la part de ses dirigeants.
Nos entretiens avec certains responsables de la CCIT et du service informatique,
nous ont permis de mieux cerner les objectifs du projet :

11
• Evaluer les insuffisances du mode de partage de ressources (imprimantes,
dossiers et fichiers) et proposer des approches de solutions ;
• Centraliser les authentifications des utilisateurs sur un contrôleur de
domaine ;
• Etudier les droits et méthodes d’accès aux ressources par les utilisateurs,
référencer les problèmes rencontrés lors des accès ;
• Proposer une nouvelle méthode de gestion des droits et accès aux
ressources permettant de sécuriser les données contre les accès
frauduleux.
Pour atteindre ces objectifs, il nous importe d’avoir une vision réelle et
représentative du domaine étudié par une description de l’existant.
II- DESCRIPTION DE L’EXISTANT
1. Le service informatique

1.1. Les équipements réseaux

Le réseau local de la CCIT est subdivisé en quatre sous–réseaux :


192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24 et 192.168.4.0/24. Le local
technique est constitué de trois (3) switchs D-Link 16 ports cascadés, deux
panneaux de brassage de 24 ports, un routeur Cisco 1720 series dans le coffret
C1 au premier étage. Les serveurs (3), l’ordinateur de l’administrateur réseau,
les ordinateurs de la division financière et comptable (8), les ordinateurs de la
division presse (2) et les ordinateurs de la division assistance aux entreprises (5)
sont reliés à ces trois(3) switchs. Le Centre de Formalité des Entreprises (CFE)
dispose de dix (10) ordinateurs tous connectés à deux (2) switchs cascadés reliés
au local technique. Quant aux ordinateurs du Centre des Opportunités
d’Affaires(8), ils sont reliés à un switch 3Com 16 ports dans le coffret C2. Et
ceux de la division documentation et publication(3), de la division ressources
humaines(1), de la division entreprise et formation professionnel(5), du fonds de
garantie routier(3), de la division relation extérieure(1), de la bibliothèque(3), et
du secrétariat général (2) sont reliés à 2 switchs D-Link 16 ports cascadés dans
le coffret C3 au rez-de-chaussée. Les ordinateurs sont reliés au réseau par des
câbles à paire torsadée non blindée de catégorie 5 (UTP CAT 5). Ces câbles sont
sertis selon la norme EIA-TIA 568 B : ce sont des câbles droits. Ces câbles
supportent un débit maximum de 100Mbps.

12
1.2. Les serveurs

C’est au local technique où sont regroupés tous les serveurs de la CCIT. Ils sont
au nombre de trois :
• Un serveur de comptabilité, d’immobilisation et paye, Sage Saari qui est
sous Windows Server 2003 ; c’est un serveur dédié HP COMPAQ 3,2
GHz, 512 Mo de RAM et un disque dur de 40 Go ;
• Un serveur dédié DNS, Mail et Web pour la résolution de nom, la gestion
des mails de tout le personnel et publication de site Web qui est sous
Linux Redhat 8, c’est un serveur IBM 2,8 GHz, 1 Go de RAM et un
disque dur de 80 Go ;
• Un serveur proxy sous Linux Redhat 8 pour le partage de la connexion
internet à tous les services de la CCIT, c’est un serveur HP proliant
biprocesseurs 3GHz chacun, 2 Go de RAM et un disque dur de 80 Go.

1.3. Les postes de travail

Les postes de travail sont des ordinateurs de diverses marques (HP-Compaq,


Dell, HP et des clowns). Ce sont des pentiums 3 et 4, de mémoire RAM compris
entre (256-512) Mo et un espace disque compris entre (20-60) Go.
2. L’adressage

Le réseau local de la CCIT est subdivisé en quatre sous-réseaux :


192.168.1.0/24 ; 192.168.2.0/24 ; 192.168.3.0/24 et 192.168.4.0/24. L’adressage
est fait de manière statique. Le serveur DNS (Domain Name Server) se charge
d’établir une table de correspondance entre les adresses IP et les noms NetBIOS
des machines.
3. Gestion des authentifications

Les utilisateurs se connectent directement sur leur ordinateur. Les


authentifications ne sont pas centralisées. Les comptes des utilisateurs sont soit
des comptes administrateurs ou des comptes limités. Les comptes Invités sont
actifs sur certains postes de travail. Les utilisateurs étant sur Redhat 8 ont des
comptes utilisateurs avec des droits biens spécifiques sur chaque fichier et
répertoires. Mais n’ont pas accès aux ressources partagées du réseau. Cela est dû
à la différence entre la gestion réseau des systèmes Linux et Windows.

13
4. Politique d’accès aux ressources partagées

La politique d’accès aux ressources partagées sur le réseau de la CCIT n’est plus
adaptée au réseau. Les ordinateurs sont déclarés dans un groupe de travail en
fonction du service auquel ils appartiennent. Certaines ressources sont partagées
par les utilisateurs eux-mêmes. Ainsi on observe que les disques durs soient
partagés dans leur globalité avec un accès en modification et écriture accordé à
tout le monde. Tout ceci constitue une faille dans la sécurité du réseau et source
de potentielles intrusions.
5. La sécurité

Il est installé un serveur antivirus Symantec Antivirus 10.0 et est déployé sur
l’ensemble du réseau. Les mesures de sécurité quant à l’accès aux données sont
faibles. Les utilisateurs installent d’autres systèmes antivirus sur leurs postes.
Ces systèmes antivirus installés sont source de problèmes. Il existe un pare-feu
logiciel installé sur le serveur proxy pour parer aux éventuelles attaques
extérieures.
6. Internet

La chambre de commerce et d’industrie du Togo dispose d’une connexion


ADSL d’un débit de 128 Kbps. Cette connexion est partagée aux utilisateurs par
l’intermédiaire d’un serveur proxy sous Linux Redhat 8.

14
B. ARCHITECTURE LAN DE LA CCIT

15
C. CRITIQUE DE L’EXISTANT
I- GESTION DES AUTHENTIFICATIONS
Les utilisateurs se connectent avec des comptes administrateurs, limités ou
invités sur leurs ordinateurs. Ils peuvent faire toutes les tâches d’administrations
(formatage de disque, création de nouvelle partitions, suppression de partitions,
partages de dossiers et fichiers, …). Il n’existe aucun contrôleur de domaine ni
d’annuaire pour gérer les authentifications, les utilisateurs, les groupes
d’utilisateurs, les machines et les droits d’accès aux ressources de manière
cohérente et objective.
II- POLITIQUE D’ACCES AUX RESSOURCES PARTAGEES
Certains dossiers et fichiers sont partagés par les utilisateurs. Aucun droit
d’accès sur ces dossiers et fichiers partagés n’est défini. Tout le monde peut y
accéder et y faire des modifications. Le libre accès aux données par tout le
monde cause un problème de sécurité des données et sur la fiabilité de ses
données, puisque tout le monde peut les modifier à sa convenance.
III-LA SECURITE
Mis à part le système antivirus réseau installé, les utilisateurs installent leurs
propres systèmes antivirus qui entrent en conflit avec celui cité plus haut.
Certains dossiers et fichiers sont en libre accès à tout le monde. Ceci constitue
une voie royale pour les virus et attaques.
D. PROBLEMATIQUES ET APPROCHES DE SOLUTIONS
I. PROBLEMATIQUE

Après une analyse minutieuse du réseau local de la Chambre de Commerce et


d’Industrie du Togo, il se dégage trois principales problématiques :
• La méthode de gestion des utilisateurs n’est plus adaptée à la structure en
place ;
• L’inexistence d’une politique d’accès aux ressources partagées sur le
réseau ;
• La vulnérabilité du réseau faute au niveau de sécurité assez bas.

16
II. APPROCHES DE SOLUTIONS

1. Optimiser la gestion des utilisateurs

Afin de mettre en place une méthode d’authentification centralisée des


utilisateurs, nous suggérons l’implémentation d’un contrôleur de domaine sur le
réseau de la CCIT. Le contrôleur de domaine principal (PDC : Primary Domain
Controler) gère les authentifications et contrôle les logons des utilisateurs. Il est
relayé en cas de panne par un contrôleur de domaine secondaire (BDC : Backup
Domain Controler) qui gère aussi les authentifications, les répertoires des
utilisateurs ainsi que leurs profils.
2. Mise en place d’une politique de sécurité sur les ressources partagées

Les accès aux ressources partagées se feront par une authentification sur le PDC.
Les comptes utilisateurs, les groupes d’utilisateurs les machines, seront stockés
dans l’annuaire OpenLDAP.
3. Nouvelle gestion des partages

Les partages se feront par rapport aux différents groupes d’utilisateurs. Des
droits spécifiques seront attribués aux partages ; ainsi que les utilisateurs ou
groupes d’utilisateurs pouvant y accéder. Les partages seront déclarés sur le
contrôleur de domaine principal (PDC) et répliquée sur le contrôleur de domaine
secondaire (BDC).
4. Formation du personnel

La formation du personnel aux nouvelles technologies de l’information et aux


nouveaux services disponibles sur le réseau est indispensable. Cette formation
leur permettra de mieux appréhender et utiliser les outils et services misent à
leur disposition afin de travailler plus professionnellement.

17
3EME PARTIE

ETUDE DETAILLEE DU PROJET

18
A. OPTIMISATION DE LA GESTION DES UTILISATEURS ET DES
PARTAGES
Les utilisateurs seront regroupés dans des groupes. Les groupes seront constitués
par rapport aux divers services de la CCIT. On aura au moins un groupe par
service. Nous suggérons l’installation d’un contrôleur de domaine qui permettra
de mieux gérer les authentifications des utilisateurs ayant leurs comptes sur
l’annuaire OpenLDAP. Ce dernier offre une grande sécurité aux ressources
partagées sur le serveur Samba en y définissant des droits.
I- LE CONTROLEUR DE DOMAINE
1. Un domaine NT

Un domaine est un ensemble de machines interconnectées partageant la même


politique de gestion et disposant de ressources communes. Le domaine nous
permet donc d’unifier la gestion des droits sur les ressources et d’y autoriser ou
non l’accès à ses acteurs. Ces ressources sont principalement les fichiers et
imprimantes partagés.
2. Les acteurs du domaine

Les acteurs du domaine sont les suivants :


• Les utilisateurs

• Les machines

• Les groupes
Chacun de ces acteurs cités ci-dessus est représenté par un compte sur le
domaine.
• Un utilisateur possède un compte

• Un groupe possède un compte

• Une machine possède également un compte qui est représenté par un $(au
début du nom de compte de la machine). C’est ce compte qui permet à
une machine de faire partie d’un domaine ;

19
• Les comptes locaux et les comptes globaux : les comptes locaux sont des
comptes uniquement disponibles sur une machine donnée. Les comptes
globaux sont des comptes disponibles sur le domaine, généralement
stockés sur le contrôleur de domaine ;

• Les comptes prédéfinis.


Tous ces acteurs et ressources sont gérer par le contrôleur de domaine principal
(PDC) et est aidé par un ou plusieurs contrôleurs de domaine secondaires
(BDC). On retrouve généralement des serveurs de fichiers et d’impression sur le
domaine. Samba nous fera office à la fois de PDC et de serveur de fichiers et
d’impression.

Représentation d’un domaine NT

3. Les SIDs

Le SID (Security Identifier) identifie un acteur (utilisateur, groupe et machine)


de manière unique sur un domaine. Il est composé de deux parties :
• Le SID local qui est celui du domaine est identique pour tous les acteurs.

• Le RID qui est un nombre qui identifie l’acteur au sein du domaine.


Exemple : S-1-5-21-4109349211-2507905533-872075644-513

20
Notre domaine possède Le SID local S-1-5-21-4109349211-2507905533-
872075644 et le RID 513 qui désigne l’acteur au sein du domaine qui n’est autre
que ‘’les Utilisateurs du domaine ‘’ ici. L’ensemble des acteurs seront regroupés
dans une base de données où ils sont classés et organisés. Cette base de données
assez spéciale est un annuaire.
II- L’ANNUAIRE OPENLDAP
1. Introduction

L'informatique et la gestion de l'information prend une place de plus en plus


importante dans notre société, particulièrement en entreprises. La multiplication
des applications et des serveurs rend cette information difficile à maîtriser. Les
annuaires LDAP offrent une réponse à ce problème en proposant de centraliser
les informations et, par le biais d'un protocole standardisé, d'y connecter des
applications clientes.
2. Définition d’un annuaire

Un annuaire présente un ensemble de données protégées et organisées étant


consultables et disponibles de manière permanente.
Chaque annuaire possède les caractéristiques suivantes :
• Un annuaire présente un ensemble défini de données ;
• Un annuaire organise les données ;
• Un annuaire peut protéger les données ;
• Un annuaire offre un service de consultation ;
• Un annuaire est tout temps disponible ;
• Un annuaire est plus consulté que mis-à-jour.
Le standard LDAP tient aussi compte de toutes ces caractéristiques.
3. Différents types d’annuaires

Il existe d’autres types d’annuaires très utilisés :


• DNS : Domain Name Services (services des serveurs de nom de domaine)
• NIS : Network Information Services (services offrant toutes les
informations du réseau)
• Whois : base d’information concernant les noms de domaines

21
4. Protocole LDAP

L'Union Internationale des Télécommunications (UIT) crée en 1988 les


annuaires X.500 dans le but d'uniformiser l'accès aux services, de centraliser les
ressources et de les protéger. Le protocole utilisé pour y accéder est le protocole
DAP (Directory Access Protocol). Malheureusement, le protocole DAP s'avère
difficile à mettre en œuvre et ne fonctionne pas sur les réseaux TCP/IP. En 1993,
l'Université du Michigan réfléchit à un moyen d’accéder aux annuaires X.500 de
manière simple et fonctionnant sur le réseau TCP/IP : elle met en place le
protocole LDAP (Lightweight Directory Access Protocol). N’étant qu’un simple
"connecteur" TCP/IP avec des annuaires X.500 au départ, LDAP devient en
1995, un protocole natif et utilisable indépendamment de X.500.LDAP est donc
une évolution de la norme X.500. Le serveur LDAP agit en tant qu’intermédiaire
entre la source de données et le client. Le principal rôle du protocole LDAP est
de présenter les informations. Sa version actuelle est la version 3 (RFC 2251),
elle propose les évolutions suivantes par rapport à la version 2 :
• Le support des communications chiffrées via SSL/TLS
• L'authentification via SASL

• Le support des Referrals (une branche pointe vers un autre annuaire)


• Le support d'Unicode (internationalisation)
• La capacité d'étendre le protocole
• Le support des schémas dans l'annuaire
LDAP fonctionne sur le port 389 par défaut.
5. Caractéristiques et fonctionnement

Le serveur LDAP constitue « le cordon ombilical » entre le client et la source de


données. Il définit alors l’organisation des données qu’il présente de manière
hiérarchique à travers un format de fichier standard LDIF (LDAP Data
Interchange Format). Les caractéristiques et fonctionnement de l’annuaire
LDAP sont souvent regroupés sous forme de quatre modèles :
• Le modèle de nommage : définit la manière de stockage et d’organisation
des données
• Le modèle fonctionnel : définit les différents services fournit par
l’annuaire
• Le modèle d’information : définit le type d’informations stockées

22
• Le modèle de sécurité : définit les droits d’accès aux ressources
Notre annuaire OpenLDAP fournit alors un ensemble d’information au
contrôleur de domaine et offre une sécurité aux ressources partagées étant sur le
serveur de fichier (Samba) par les droits d’accès qui y seront définit.
III-LE SERVEUR SAMBA
1. Présentation de Samba

Samba est une suite de logiciels qui nous permettra d'interconnecter des
systèmes hétérogènes, afin d'en partager les ressources. Ces ressources sont
composées d'utilisateurs, de groupes, de machines et d'imprimantes. Ainsi toutes
les machines Unix peuvent accéder à une machine ou domaine Windows et
inversement. Samba est composé de trois logiciels serveurs (smbd, nmbd et
winbindd) qui lui permet de créer un environnement Windows NT quasiment
identique à l’original. Samba va ainsi nous permettre de contrôler le domaine
qu’on mettra en place et d’en être le serveur de fichiers.
2. Principe de fonctionnement

Samba est composé de trois principaux logiciels serveurs (nmbd, smbd et


winbindd). Chacun d'entre eux joue un rôle très précis dans l'interconnexion
réseau des machines.
• Nmbd permet de gérer la résolution de noms NetBIOS et toutes les
connexions UDP. Il est le premier serveur démarré dans le processus de
démarrage de Samba. Il fonctionne sur le port 137.
• Smbd, permet de gérer toutes les connexions SMB/CIFS notamment le
partage de fichiers et d’imprimantes. Il gère également les
authentifications locales. Il est démarré juste après Nmbd. Il fonctionne
sur le port 139.
• Winbindd permet la mise en commun des comptes Windows et Unix.
Le partage de fichiers et d'imprimantes est assuré par le protocole "SMB"
(Server Message Block), renommé en 1996 en "CIFS" (Common Internet File
System) par Microsoft. CIFS peut, ou non, utiliser NetBIOS (sur les ports 137,
138,139).
Ceci est souvent le cas mais est en train d'évoluer vers la méthode "Direct-
hosted" et l'implémentation de CIFS directement sur TCP/IP (sur le port 445).
CIFS fonctionne au niveau des couches 6 et 7 du modèle OSI. NetBIOS,
"Network Basic Input/Output System", n'est pas un protocole, il s'agit plutôt
d'une méthode de communication sur un protocole existant ; NetBIOS constitue
la couche Session au sein du modèle OSI.

23
C’est en fait une couche intermédiaire entre SMB et un protocole sous-jacent tel
que TCP (NBT) ou IPX. Il fournit une méthode de résolution de noms et de
services aux couches supérieures. Il utilise un modèle de noms de machines de
15 caractères + 1 caractère de contrôle spécifiant les services offerts par la
machine. A chaque démarrage, une machine Windows annonce son nom
NetBIOS ainsi que ses rôles (contrôleur de domaine, serveur de fichiers, ...) sur
le réseau.
Situation des protocoles utilisés par Samba par rapport au modèle OSI

3. Authentification et gestion des utilisateurs

En tant que contrôleur de domaine, Samba gère l'authentification des


utilisateurs. Il lui faut dans ce cas une base à laquelle se référer afin de
déterminer les droits de chacun. Cette base est double. Samba utilise tout d'abord
les mécanismes internes à Unix pour identifier (via nsswitch) et authentifier
(généralement via pam) les utilisateurs. Un compte Unix est donc préalablement
nécessaire à tout compte Samba.
Cependant, sous Unix les informations relatives à chaque utilisateur sont très
limitées : principalement un nom, un uid (User id), gid (Group id), et un
répertoire personnel. Elles ne sont pas appropriées, car : Windows utilise un SID
(identifiant relatif au domaine) afin, d'identifier un acteur du domaine, tandis
qu'Unix utilise un simple uid (user identifier), sans aucun rapport à un
quelconque domaine. Pour pallier à ces manques, Samba doit ajouter ses propres
informations telles que le chemin du répertoire home de l'utilisateur (local ou
distant), son répertoire de profils, son SID, ... Cet ajout d'informations constitue
en quelques sortes une base SAM et nécessite un espace de stockage
supplémentaire, souvent un fichier de base de données (tdb) stocké sur le PDC
où alors sur un annuaire OpenLDAP.

24
4. Stockage des utilisateurs

Les fichiers smbpasswd et tdb sont des fichiers de bases de données.


Historiquement, smbpasswd est apparu avant tdb et stocke moins de propriétés.
L'inconvénient de ce type de stockage est qu'il n’est adapté qu’à un nombre
limité d'enregistrements ; et ne convient que pour quelques dizaines
d'utilisateurs, au sein d'une petite structure. Il n'offre qu'une faible capacité de
monter en charge, et est d’une lenteur considérable.
LDAP et NIS sont deux "backends" supplémentaires apparus récemment sous
Samba. L'avantage principal de tels media est une compatibilité accrue avec les
applications déjà existantes, telles que les applications d'administration. Ils
permettent aussi de réutiliser des annuaires déjà existants et offrent une capacité
de montée en charge plus importante que les fichiers à plat. Enfin, un avantage
très important est qu'ils autorisent une personnalisation très fine au niveau des
paramètres de chaque compte d'utilisateur.
Nous serons alors en mesure de paramétrer pour chacun des utilisateurs le
répertoire de profils, alors que ceci se faisait de manière générique par
l'utilisation de variables dans le chemin du répertoire avec un fichier à plat
(smbpasswd et tdb). Un serveur LDAP va également permettre de mettre en
place un système de tolérance aux pannes en utilisant la réplication entre
serveurs.
5. Gestion des groupes et utilisateurs sous samba

C'est par un regroupement d'utilisateurs que l'on va pouvoir obtenir une


précision importante au niveau des droits attribués, tout en conservant une
certaine facilité d'administration. Sous Samba, trois groupes de domaine peuvent
être utilisés : les "Administrateurs du domaine", les "Utilisateurs du domaine" et
les "Invités". La déclaration d'appartenance à un groupe de domaine se fera par
le biais d'une directive dans le fichier de configuration. On fait correspondre le
groupe Unix au groupe désiré. Ainsi, un utilisateur appartenant au groupe Unix
se verra attribué les droits du groupe Windows en correspondance. Les autres
utilisateurs sont, par défaut, des utilisateurs du domaine.
6. Gestions des comptes

Le rôle principal de Samba en tant que serveur est de permettre à des comptes de
type Windows de se connecter à une machine Unix. Or, et nous avons vu
notamment avec la notion de SID, que la gestion des comptes sous Windows est
totalement différente de celle sous Unix. Tout le travail de Samba va être
d'effectuer correctement une relation entre les deux types de comptes.

25
6.1 Dualité des comptes

Samba va donc établir une correspondance entre les utilisateurs Unix et les
utilisateurs Windows. Ceci implique qu’à chaque utilisateur, Samba doit faire
correspondre un utilisateur Unix (un compte POSIX). Cette relation est
nécessaire pour qu’on puisse, définir les droits de l'utilisateur au niveau du
système de fichiers. Il nous serait très intéressant de centraliser les deux types de
comptes sur un même annuaire LDAP ; l'administration sera ainsi grandement
simplifiée.
6.1.1 Compte POSIX

Un compte POSIX est un compte Unix. Il est utilisé par samba pour la gestion
des droits sur le système et contient les informations des utilisateurs (Uid, Gid,
mot de passe, répertoire personnel …). Il est obligatoire et peut être en local
dans le fichier etc/passwd ou peut être distant en utilisant un annuaire
OpenLDAP ou un SGBD (MySQL ou XML) grâce au mécanisme de nsswitch et
de PAM.
6.1.2 Compte Samba

Le compte samba complète les informations du compte POSIX par des


informations purement Windows, telles un SID, un répertoire home, un script de
logon,... Ces informations sont souvent stockées dans un « backend ». Ce
backend peut être un fichier à plat (fichier smbpasswd ou un tdb) ou un annuaire
LDAP.
6.2 Gestion des groupes

Tout comme pour les comptes utilisateurs, samba va ajouter des informations
aux groupes Posix déjà existants tels le SID local et le type de groupe.
7. Gestion des droits

Il existe deux types de droits sous samba : les droits de connexion qui nous
permettrons de définir les utilisateurs ou groupes pouvant se connecter à un
partage ; et les droits du système de fichiers qui nous permettrons de définir les
droits qu’aura l’utilisateur sur les fichiers une fois connecté.
7.1 Les droits Posix

Il s’agit des droits de lecture (r) , d’écriture (w) et d’exécution (x) qu’ont un
utilisateur (u), un groupe (g) ou tout autre personne (o) sur les fichiers et
répertoires du système. Des droits spécifiques seront attribués à chaque groupe
et utilisateur.

26
7.2 Les droits Posix sous Samba

Les droits Posix sous samba sont les droits de lecture, d’écriture et
d’exécution associés à chaque fichier crée par l’utilisateur.
B. LA MISE EN PLACE
I. ETUDE DES BESOINS
L'étude des besoins fut la première étape à la mise en place des plateformes de
tests. L'idée de départ était de se baser sur une architecture regroupant un PDC
et un BDC : chaque contrôleur de domaine doit être potentiellement capable
d'authentifier un utilisateur et doit pouvoir accéder à la base les concernant. La
base doit pouvoir être mise à jour en temps réel, même si l'authentification ne se
fait plus par le PDC. Il faut donc séparer la fonction d'authentification de celle
de stockage. En cas de panne du service d'authentification, nous serions ainsi
dans la capacité de continuer à modifier les données concernant les utilisateurs.
Il doit également être possible de disposer des répertoires personnels et profils
des utilisateurs sur n'importe quel serveur membre du domaine, sans dépendre
du contrôleur de domaine.
Les répertoires des utilisateurs devront être personnalisé et non générique.
Chaque service aura un partage accessible uniquement à ses membres, et dont le
chef service aura le contrôle total. Les utilisateurs doivent disposer d’un partage
accessible à tout le monde. Pour plus de sécurité les mots de passe seront cryptés
et la communication chiffrée sur tout le domaine. Les utilisateurs devront avoir
des profils itinérants de manière à ce qu’ils puissent se connecter peu importe la
machine ou le système d’exploitation. Il doit être possible de se connecter même
si le PDC et l’annuaire OpenLDAP tombent en panne.
II. INSTALLATION ET CONFIGURATION DE L’ANNUAIRE OPENLDAP
1. Contexte

Le serveur OpenLDAP est déjà installé par défaut sur le système Linux RedHat
8 édition Server et Fedora Core 2. Les machines utilisées sont de puissance
moyenne Pentium 4, de 2,4GHz, disposant d’une mémoire de 256Mo et un
espace disque de stockage de 80Go.
2. Configuration du serveur

2.1 Configuration de l’adresse IP

Nous allons attribuer l’adresse IP 192.168.1.20 à notre serveur OpenLDAP et


ldap1.ccit.com comme nom DNS et 192.168.1.21 à notre serveur LDAP
secondaire et ldap2.ccit.com

27
Sur le serveur LDAP1
root#Ifconfig eth0 192.168.1.20 netmask 255.255.255.0
root#hostname ldap1.ccit.com
Sur le serveur LDAP2
root# ifconfig eth0 192.168.1.21 netmask 255.255.255.0
root#hostname ldap2.ccit.com
Les adresses IP sont assignées de même que les noms DNS des deux serveurs.
2.2 Edition du fichier de configuration

Editons le fichier le fichier /etc/ldap/slapd.conf pour configurer OpenLDAP :


include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
database ldbm
suffix "dc=ccit,dc=com"
rootdn "cn=Manager,dc=ccit,dc=com"
rootpw secret
directory /var/lib/ldap
index cn eq

Le "rootdn" représente le compte autorisé à modifier la base LDAP. Le "rootpw"


représente son mot de passe. Nous disposons maintenant d'une configuration
suffisante pour démarrer le serveur : root#/etc/init.d/ldap start
2.3 Premier test

Nous allons essayer d'insérer, depuis l'hôte local, quelques enregistrements dans
notre base LDAP, afin de tester notre serveur : Nous allons créer un fichier
test.ldif
root#kwrite test.ldif

dn: dc=ccit,dc=com
objectclass: dcObject
dc: ccit
objectclass: organization
o: ccit
dn: ou=personnes,dc=ccit,dc=com
objectclass: top
objectclass: organizationalUnit
ou: personnes
description: Branche personnes

28
Il faut ensuite insérer les données du fichier par la commande :
root#ldapadd ‐W ‐D 'cn=Manager,dc=ccit,dc=com' ‐f test.ldif

Pour rechercher l’unité d’organisation ‘personnes’ à partir de 'dc=ccit,dc=com' :


root#ldapsearch ‐W ‐D 'cn=Manager,dc=ccit,dc=com' ‐b 'dc=ccit,dc=com'
ou :
root#ldapsearch ‐b 'dc=ccit,dc=com' (car dans notre cas, pas besoin d'authentification
pour les recherches)
Nous allons effacer les données afin de laisser notre base propre :
root#ldapdelete ‐W ‐D 'cn=Manager,dc=ccit,dc=com' 'ou=personnes,dc=ccit,dc=com'

Le serveur LDAP est maintenant près pour recevoir les comptes et groupes
d’utilisateurs.
Pour cela nous allons inclure le schéma de samba dans le fichier slapd.conf de
notre serveur pour qu’il puisse le chargé au démarrage.
Nous avons récupérer les sources de Samba sur http://www.samba.org
La version téléchargée est la samba-3.0.23c. Les sources sont compressées au
format tar.
Nous allons les décompresser : root#tar xvzf samba3.0.23c‐.tar.gz
Nous allons copier le fichier /samba-3.0.23c/examples/LDAP/samba.schema
dans /etc/ldap/schema/ et ensuite l’inclure dans le fichier slapd.conf.
root#cp /samba‐3.0.23c/examples/LDAP/samba.schema /etc/ldap/schema/

Nous allons à présent éditer le fichier slapd.conf pour inclure le schéma de


samba :
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/samba.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
database ldbm
suffix "dc=ccit,dc=com"
rootdn "cn=Manager,dc=ccit,dc=com"
rootpw secret
directory /var/lib/ldap
index objectClass,rid,uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial

Le serveur est maintenant près à recevoir les comptes Samba. Il ne nous reste
qu’à configurer les clients LDAP : cela se fera par l’édition du fichier ldap.conf

29
Edition du fichier /etc/ldap/ldap.conf :
root#kwrite /etc/ldap/ldap.conf

base dc=ccit,dc=com
host 127.0.0.1

Nous pouvons désormais redémarrer notre serveur LDAP : #/etc/init.d/ldap


restart

Il sera prêt à être interrogé par Samba, une fois que nous l'aurons peuplé.
III. INSTALLATION ET CONFIGURATION DE SAMBA EN TANT QUE CONTROLEUR DE
DOMAINE PRINCIPAL (PDC)

1. Installation de Samba

Les fichiers sources de samba sont déjà décompressés.


Configurons les différents modules à installer.
root#./configure ‐‐with‐smbwrapper ‐‐with‐smbmount \
‐‐with‐msdfs ‐‐with‐syslog ‐‐with‐utmp ‐‐with‐fhs ‐‐prefix=/usr \
‐‐sysconfdir=/etc ‐‐with‐privatedir=/etc/samba ‐‐localstatedir=/var \
‐‐with‐netatalk ‐‐with‐sambabook ‐‐with‐utmp ‐‐with‐readline ‐‐with‐libsmbclient \
‐‐with‐winbind ‐‐with‐automount ‐‐with‐acl‐support \‐‐with‐profile \‐‐disable‐static \
‐‐with‐ldapsam 2>&1 | tee config.my.log
Maintenant compilons les fichiers samba
root#make 2>&1 | tee make.log

Les fichiers ont été compilés et nous pouvons les installer avec la commande :

root#make install

Le serveur samba est près. Démarrons-le à présent :


root#/etc/rc.d/init.d/smb start

Si le démarrage à réussi, les messages suivants sont affichés.


Starting SMB services: Done
Starting NMB services: Done

Nous allons à présent vérifier si les services de samba ont démarrés :


La commande ‘ps ax | grep mbd’ permet de vérifier si les services de Samba sont
démarrés. Au quel cas le retour de la ligne de commande sera :
1268 ? S 0:00 /usr/local/samba/bin/smbd ‐D

30
1270 ? S 0:00 /usr/local/samba/bin/nmbd ‐D
1465 pts/2 S 0:00 grep mbd
Nous allons à présent arrêter samba. La commande utilisée est :
root#/etc/rc.d/init.d/smb stop
Avec comme retour de ligne de commande :
Shutting down SMB services : Done

Shutting down NMB services : Done

2. Préparation du PDC pour l'authentification via LDAP

Samba nécessite deux types de comptes : un compte Système, pour pouvoir


identifier les utilisateurs, et un compte interne, pour pouvoir les authentifier et
disposer d'informations propres au domaine (répertoire home, profils, etc...) qui
ne sont pas stockées dans le compte système. Par défaut, sur Linux, les comptes
systèmes utilisés par Samba sont situés dans /etc/passwd et /etc/group. Puisque
ceci nous obligerait à avoir deux enregistrements pour un seul utilisateur : un
dans /etc/passwd et un dans LDAP, nous allons rediriger les appels systèmes
vers notre serveur LDAP. Cette redirection se fait via nsswitch. Ainsi, Samba
fera toujours deux appels : un appel système (redirigé vers LDAP) et un appel
interne (vers les comptes Samba stockés sous LDAP). Cependant, ceci se fera de
manière totalement transparente ; nous ne stockons qu'un seul compte pour
chaque utilisateur dans notre annuaire LDAP. Nous allons également utiliser
pam, puisque l'on veut que nos utilisateurs puissent s'authentifier avec leur
compte LDAP sous GNU/Linux. Pam va permettre la même redirection que
nsswitch, mais cette fois-ci pour l’authentification.
2.1 Installation des outils nécessaires à la redirection de compte

2.1.1 Installation de libnss-ldap

Cette librairie 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.
root#rpm ‐i libnss‐ldap.source.rpm

2.1.2 Installation de libpam-ldap : 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

31
d'authentification (de la carte à puce, aux fichiers passwd, 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 Linux.
root#rpm ‐i libpam‐ldap.source.rpm

2.2. Installation des smbldap-tools

Les smbldap-tools sont des outils développés par la société 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, ils facilitent l'administration et la gestion des comptes. Les
smbldap-tools sont déjà dans les sources de samba. Nous allons créer les
répertoires d’installations et y attribuer les droits.
root#mkdir ‐p /opt/IDEALX/sbin
root#chown root:root /opt/IDEALX/sbin
root#chmod 755 /opt/IDEALX/sbin
root#mkdir ‐p /etc/smbldap‐tools
root#chown root:root /etc/smbldap‐tools
root#chmod 755 /etc/smbldap‐tools
root#cd /samba‐3.0.23c/examples/LDAP/smbldap‐tools‐0.9.2
root#cp smbldap*conf /etc/smbldap‐tools/
root#cp smbldap‐* configure.pl *pm /opt/IDEALX/sbin/
root#chmod 750 /opt/IDEALX/sbin/smbldap‐*
root#chmod 750 /opt/IDEALX/sbin/configure.pl
root#chmod 640 /etc/smbldap‐tools/smbldap.conf
root#chmod 600 /etc/smbldap‐tools/smbldap_bind.con

Nous allons configurer smbldap_tools.pm situé dans /opt/IDEALX/sbin pour


qu’il puisse prendre certaines variables en compte.
root#kwrite /opt/IDEALX/sbin/ smbldap_tools.pm
...
# ugly funcs using global variables and spawning openldap clients
my $smbldap_conf="/etc/smbldap‐tools/smbldap.conf";
my $smbldap_bind_conf="/etc/smbldap‐tools/smbldap_bind.conf";
...
Pour terminer l’installation de smbldap-tools nous allons attribuer des droits et
permissions sur les divers fichiers de /opt/IDEALX/
root #chown root:root /opt/IDEALX/sbin/*
root #chmod 755 /opt/IDEALX/sbin/smbldap‐*
root #chmod 640 /opt/IDEALX/sbin/smb*pm

32
2.2.1 Configuration de smbldap-tools
Smbldap-tools à besoin d’identifier le nom de NetBIOS du serveur Samba inclut
dans smb.conf.
root#cd /opt/IDEALX/sbin

Nous allons à présent récupérer le SID du domaine

root#net get localsid


S‐1‐5‐21‐4109349211‐2507905533‐872075644

Exécutons le script de configuration

root#./configure.pl
‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=
smbldap‐tools script configuration
‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=
Before starting, check
. if your samba controller is up and running.
. if the domain SID is defined (you can get it with the
’net getlocalsid’)
. you can leave the configuration using the Crtl‐c key combination
. empty value can be set with the "." character
‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=
Looking for configuration files...
Samba Config File Location [/etc/samba/smb.conf] >
smbldap‐tools configuration file Location (global parameters)
[/etc/opt/IDEALX/smbldap‐tools/smbldap.conf] >
smbldap Config file Location (bind parameters)
[/etc/opt/IDEALX/smbldap‐tools/smbldap_bind.conf] >
‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=

Nous allons maintenant commencer par configurer les scripts smbldap‐tools ...

. workgroup name: name of the domain Samba act as a PDC


workgroup name [CCIT] >
. netbios name: netbios name of the samba controler
netbios name [PDC] >
. logon drive: local path to which the home directory
will be connected (for NT Workstations). Ex: ’H:’
logon drive [H:] >
. logon home: home directory location (for Win95/98 or NT Workstation)
(use %U as username) Ex:’\\PDC\%U’
logon home (press the "." character if you don’t want homeDirectory)
[\\PDC\%U] >
. logon path: directory where roaming profiles are stored.
Ex:’\\PDC\profiles\%U’

33
logon path (press the "." character
if you don’t want roaming profile) [\\%L\profiles\%U] >
. home directory prefix (use %U as username)
[/home/%U] > /data/users/%U
. default users’ homeDirectory mode [700] >
. default user netlogon script (use %U as username)
[scripts\logon.bat] >
default password validation time (time in days) [45] > 900
. ldap suffix [dc=ccit,dc=com] >
. ldap group suffix [ou=Groups] >
. ldap user suffix [ou=Users] >
. ldap machine suffix [ou=Computers] >
. Idmap suffix [ou=Idmap] >
. sambaUnixIdPooldn: sambaUnixIdPooldn object (relative to ${suffix})
[sambaDomainName=CCIT] >
. ldap master server: IP adress or DNS name of the master
(writable) ldap server
ldap master server [ldap1.ccit.com] >
. ldap master port [389] >
. ldap master bind dn [cn=Manager,dc=ccit,dc=com] >
. ldap master bind password [] >
. ldap slave server: IP adress or DNS name of the slave ldap server:
can also be the master one
ldap slave server [ldap2.ccit.com] >
. ldap slave port [389] >
. ldap slave bind dn [cn=Manager,dc=ccit,dc=com] >
. ldap slave bind password [] >
. ldap tls support (1/0) [1] >
. SID for domain CCIT: SID of the domain
(can be obtained with ’net getlocalsid PDC’)
SID for domain CCIT
[S‐1‐5‐21‐4109349211‐2507905533‐872075644]] >
. unix password encryption: encryption used for unix passwords
unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA) [SSHA] > MD5
. default user gidNumber [513] >
. default computer gidNumber [515] >
. default login shell [/bin/bash] >
. default skeleton directory [/etc/skel] >
. default domain name to append to mail adress [] > ccit.com
‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=
backup old configuration files:
/etc/opt/IDEALX/smbldap‐tools/smbldap.conf‐>
/etc/opt/IDEALX/smbldap‐tools/smbldap.conf.old
/etc/opt/IDEALX/smbldap‐tools/smbldap_bind.conf‐>
/etc/opt/IDEALX/smbldap‐tools/smbldap_bind.conf.old
writing new configuration file:
/etc/opt/IDEALX/smbldap‐tools/smbldap.conf done.
/etc/opt/IDEALX/smbldap‐tools/smbldap_bind.conf done.

34
2.2.2 Insertion de l'arborescence de base pour samba dans LDAP

Notre domaine va nécessiter une arborescence de base qui va permettre


d'organiser les différents comptes, créons la.
Nous allons peupler la base LDAP du Serveur ldap1.ccit.com :
-Démarrons le serveur LDAP
root#/etc/init.d/ldap start

-Changeons de répertoire
root#cd /opt/IDEALX/sbin

-Peuplons la base
root#./smbldap‐populate ‐a root ‐k 0 ‐m 0

et nous avons comme retour de commande :


Using workgroup name from smb.conf: sambaDomainName=CCIT
‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=
=> Warning: you must update smbldap.conf configuration file to :
=> sambaUnixIdPooldn parameter must be set
to "sambaDomainName=CCIT,dc=ccit,dc=com"
‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=‐=
Using builtin directory structure
adding new entry: dc=ccit,dc=com
adding new entry: ou=People,dc=ccit,dc=com
adding new entry: ou=Groups,dc=ccit,dc=com
entry ou=People,dc=ccit,dc=com already exist.
adding new entry: ou=Idmap,dc=ccit,dc=com
adding new entry: sambaDomainName=CCIT,dc=ccit,dc=com
adding new entry: uid=root,ou=People,dc=ccit,dc=com
adding new entry: uid=nobody,ou=People,dc=ccit,dc=com
adding new entry: cn=Domain Admins,ou=Groups,dc=ccit,dc=com
adding new entry: cn=Domain Users,ou=Groups,dc=ccit,dc=com
adding new entry: cn=Domain Guests,ou=Groups,dc=ccit,dc=com
adding new entry: cn=Domain Computers,ou=Groups,dc=ccit,dc=com
adding new entry: cn=Administrators,ou=Groups,dc=ccit,dc=com
adding new entry: cn=Print Operators,ou=Groups,dc=ccit,dc=com
adding new entry: cn=Backup Operators,ou=Groups,dc=ccit,dc=com
adding new entry: cn=Replicators,ou=Groups,dc=ccit,dc=com

Modifions le fichier /etc/smbldap-tools/smbldap.conf


root#kwrite /etc/smbldap‐tools/smbldap.conf

# Where to store next uidNumber and gidNumber available

35
#sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"
sambaUnixIdPooldn="sambaDomainName=CCIT,dc=ccit,dc=com"

Créons un nouveau fichier idmap.ldif dans /etc/openldap, ce fichier permettra au


serveur LDAP de mapper dynamiquement les comptes samba et Posix.
root#kwrite /etc/openldap/idmap.ldif

dn: ou=Idmap,dc=ccit,dc=com
objectClass: organizationalUnit
ou: idmap
structuralObjectClass: organizationalUnit

-Insertion du fichier /etc/openldap/idmap.ldif


root#ldapadd ‐x ‐D "cn=Manager,dc=ccit,dc=com" \
‐w secret < /etc/openldap/idmap.ldif

LDAP est maintenant prêt à recevoir nos utilisateurs, aussi bien GNU/Linux
que Samba. On remarque que l'arbre comprend 3 branches principales : Groups,
People, et Computers, destinées à stocker, respectivement : les Groupes
d'utilisateurs, les Utilisateurs (reliés aux groupes via le gid) et les Ordinateurs.
Nous avons également quelques groupes standards de domaine à disposition
(Domain Users, Domain Guests), bien que Samba ne les exploite pas tous. Nous
allons bientôt pouvoir nous identifier via LDAP : il reste maintenant à
configurer notre système pour qu'il utilise notre serveur pour l'authentification.
2.3 Configuration des méthodes d'authentification du Système

2.3.1 Configuration de Nsswitch

La configuration générale de libnss-ldap se fait via le fichier /etc/ldap/ldap.conf.


Il nous faut tout d'abord modifier le fichier /etc/nsswitch.conf pour qu'il fasse
appel à LDAP.
root#kwrite /etc/nsswitch.conf

passwd: files ldap


group: files ldap
shadow: files ldap
hosts: files dns
services: ldap [NOTFOUND=return] files
networks: ldap [NOTFOUND=return] files
protocols: ldap [NOTFOUND=return] files
rpc: ldap [NOTFOUND=return] files
ethers: ldap [NOTFOUND=return] files
netmasks: files
bootparams: files
publickey: files
automount: files

36
aliases: files
netgroup: files nis

2.3.2 Configuration de Pam

La configuration générale de libpam-ldap se fera via le fichier


/etc/ldap/ldap.conf
Nous allons modifier le fichier /etc/pam.d/system-auth
root#kwrite /etc/pam.d/system-auth

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 sufficient /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

Nous allons modifier chaque fichier dans /etc/pam.d pour ajouter LDAP à pam
(pam_ldap.so). A chaque fichier correspond un service. Modication de
/etc/pam.d/ssh :
root#kwrite /etc/pam.d/ssh

auth sufficient pam_ldap.so


auth required pam_nologin.so
auth required pam_unix.so
auth required pam_env.so # [1]
account sufficient pam_ldap.so
account required pam_unix.so
session sufficient pam_ldap.so
session required pam_unix.so
session optional pam_lastlog.so # [1]
session optional pam_motd.so # [1]
session optional pam_mail.so standard noenv # [1]
session required pam_limits.so
password sufficient pam_ldap.so
password required pam_unix.so

3. Configuration générale des librairies libpam-ldap et libnss-ldap

Nsswitch et Pam font appel à ces deux librairies, il va maintenant falloir les
configurer. Le paramétrage se fera via la configuration des outils Ldap, dans le
fichier ldap.conf.

37
- Modification de /etc/ldap/ldap.conf
root#kwrite /etc/ldap/ldap.conf

host ldap1.ccit.com
base dc=ccit,dc=com
ldap_version 3
binddn cn=Manager,dc=ccit,dc=com
bindpw secret
timelimit 50
bind_timelimit 50
bind_policy hard
idle_timelimit 3600
pam_password exop
nss_base_passwd ou=Users,dc=ccit,dc=com?one
nss_base_shadow ou=Users,dc=ccit,dc=com?one
nss_base_group ou=Groups,dc=ccit,dc=com?one
pam_password md5
ssl off

‐ Il faut également créer un fichier /etc/ldap.secret :


root#echo "secret" > /etc/ldap.secret,

Ce fichier contiendra le mot de passe du rootbinddn pour les mises à jour de la


base.

4. Configuration de Samba

La configuration de Samba se fait via le fichier smb.conf. Celui-ci comporte une


description du comportement général du serveur (section [global]), ainsi qu'une
énumération des partages qui seront créés sur la machine (les autres sections).
Le PDC offrira le partage netlogon, que l'on ne peut pas déporter sur le BDC. Le
BDC, quant à lui, offrira les autres partages de données (répertoire home,
profils, et autres partages divers).
‐ Edition du fichier /etc/samba/smb.conf :
root#kwrite /etc/samba/smb.conf
[global]
; le nom de notre domaine
workgroup = CCIT
; notre nom de machine netbios
netbios name = PDC
; le nom complet
server string = Ccit PDC Server
encrypt passwords = Yes
; Synchro pass Unix
passwd program = /usr/local/sbin/smbldap‐passwd.pl ‐o %u
passwd chat = *new*password* %n\n *new*password* %n\n *successfully*
unix password sync = Yes

38
; Ajout de machine via smbldap‐tools
add user script = /usr/local/sbin/smbldap‐useradd.pl ‐w %u
domain admin group = " @"Domain Admins" "
; Logs
log file = /var/log/samba/%m.log
log level = 2
max log size = 5000
; Quelques options réseau
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
; On contrôle les logons, on est DC
domain logons = Yes
; Master browser, browser pour le domaine (un seul par domaine)
domain master = Yes
; Force élections en tant que master browser + donne un avantage
preferred master = Yes
; Poids lors des élections de master browser
os level = 65
; Local master browser (browser pour le sous réseau)
local master = Yes
dns proxy = No
; Serveur Wins actif (un seul par reseau)
wins support = Yes
security = user
; LDAP
ldap suffix = dc=ccit,dc=com
ldap admin dn = cn=Manager,dc=ccit,dc=com
ldap port = 389
ldap server = ldap1.ccit.com
ldap ssl = No

; Répertoire scripts
[netlogon]
comment = Network Logon Service
path = /export/samba/netlogon
guest ok = Yes

5. Création du répertoire netlogon

Nous allons créer le répertoire /export/samba/netlogon pour le stockage des


scripts de connexion.
root#mkdir /export/samba/netlogon
root#chmod 550 /export/samba/netlogon

6. Test : Joindre une machine au domaine

Redémarrons samba et le service winbindd.


root#/etc/rc.d/init.d/smb start

root#/etc/rc.d/init.d/winbind start

39
Créons un compte de sécurité pour le domaine .
root#net rpc join –S CCIT –U root%secret

Et nous avons comme retour de commande :


Joined domain CCIT.

Nous disposons maintenant d'un domaine complet, sur lequel nous allons joindre
une machine. Nous allons utiliser ici notre client Windows XP.
Pour joindre le domaine, il faut disposer d'un compte machine autorisé dans
LDAP, les scripts de smbldap-tools le font automatiquement mais il est
préférable de l’ajouter manuellement depuis notre PDC.
-Ajout de la machine Xp qui a pour nom NetBIOS « XP-TEST »
root#smbldap‐useradd.pl –w XP‐TEST$

-Ajout de l’utilisateur rootadmin qui pourra ajouter une machine au domaine


root#smbldap‐useradd.pl –a –m –g 512 rootadmin

root#smbldap‐usermod.pl –u 0 –g 0 rootadmin

root#smbldap‐passwd.pl rootadmin secret

-Ajout de l’utilisateur (xpuser) qui pourra se connecter au domaine à partir de


XP-TEST
root#smbldap‐useradd.pl –a –m –g 513 xpuser

root#smbldap‐passwd.pl xpuser userpasswd

L’utilisateur xpuser arrive à se connecter au domaine à partir de la machine XP-


TEST mais xpuser ne peut accéder à son répertoire personnel ni à son profil car
les répertoires des utilisateurs et leurs profils sont stockés sur le contrôleur de
domaine secondaire.
IV. MISE EN PLACE DU CONTROLEUR DE DOMAINE SECONDAIRE (BDC)
La mise en place d'un BDC dans notre réseau va permettre de séparer la fonction
d'authentification de celle du partage de fichiers. Nous allons pouvoir ajouter sur
notre domaine la gestion des répertoires personnels "homes" et "profiles" des
utilisateurs, habituellement situés sur le PDC. Cette décentralisation permet de
supprimer les points sensibles sur notre réseau et de palier en cas panne du
contrôleur de domaine principal.

40
1. Processus de montage du répertoire Home d'un utilisateur et de prise de
relais du BDC en cas de panne du PDC

1: L'utilisateur demande l'authentification sur le domaine auprès du PDC


2 : Le PDC se connecte au serveur LDAP pour vérifier la validité du compte
utilisateur
[2 bis] : Le BDC se connecte au serveur LDAP pour vérifier la validité du
compte utilisateur en cas de panne du PDC
3 : L'annuaire LDAP répond au PDC
[3 bis] : L'annuaire LDAP répond au BDC en cas de panne du PDC
4 : Il autorise (ou non) l'utilisateur à accéder aux ressources du domaine
[4 bis] : Le BDC autorise (ou non) l’utilisateur à accéder aux ressources du
domaine
5 : Si l'utilisateur est authentifié, il peut accéder au BDC, et demander l'accès à
une ressource
6 : Le BDC lui fournit cet accès s’il est autorisé à accéder à cette ressource

2. Configuration du BDC (serveur 3 bdc.ccit.com)

La configuration du BDC se fait de la même manière que celle du PDC, à la


différence des options d'élections présentes dans le fichier smb.conf qu'il faut
modifier (baisser) et les partages qui seront différents. Le BDC doit, lui aussi,
dispose d'un nsswitch modifié, ainsi que de la librairie libnss-ldap (et

41
éventuellement libpam-ldap). La base ldap-client et les smbldap-tools sont
également installés.
Le BDC a pour nom NetBIOS BDC, voici sa configuration samba
(/etc/samba/smb.conf) :
[global]
; le nom de notre domaine
workgroup = CCIT
; notre nom de machine netbios
netbios name = BDC
; le nom complet
server string = Ccit BDC Server
encrypt passwords = Yes
; Synchro pass Unix
passwd program = /usr/local/sbin/smbldap‐passwd.pl ‐o %u
passwd chat = *new*password* %n\n *new*password* %n\n *successfully*
unix password sync = Yes
; Ajout de machine via smbldap‐tools
add user script = /usr/local/sbin/smbldap‐useradd.pl ‐w %u
domain admin group = " @"Domain Admins" "
; Logs
log file = /var/log/samba/%m.log
log level = 2
max log size = 5000
; Quelques options réseau
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
; On contrôle les logons, on est DC
domain logons = Yes
; Master browser, browser pour le domaine (un seul par domaine)
domain master = No
; Force élections en tant que master browser + donne un avantage
preferred master = No
; Poids lors des élections de master browser
os level = 48
; Local master browser (browser pour le sous réseau)
local master = No
dns proxy = No
; Serveur Wins actif (un seul par reseau)
wins support = No
security = user
; LDAP
ldap suffix = dc=ccit,dc=com
ldap admin dn = cn=Manager,dc=ccit,dc=com
ldap port = 389
ldap server = ldap1.ccit.com
ldap ssl = No
; Impression
load printers = yes
printing = cups
printcap name = cups

42
; Prise en charge du francais
character set = iso8859‐1
; Répertoires homes, à mapper via \\SERVEUR\utilisateur
[homes]
path=/export/samba/home/%u
comment = Home Directories
valid users = %S
read only = No
create mask = 0664
directory mask = 0775
browseable = No
; Répertoires profiles, à mapper via \\SERVEUR\profiles\utilisateur
[profiles]
path = /export/samba/profiles
writeable = yes
browseable = no
create mode = 0644
directory mode = 0755
guest ok = yes
[tmp]
comment = Temporary file space
path = /tmp
read only = No
guest ok = Yes

Le BDC offre désormais les partages auparavant assurés par le PDC. Il va donc
falloir y créer les répertoires partagés génériques, (ici /export/samba/home et
/export/samba/profiles), ainsi que le répertoire home de chaque utilisateur :
root#mkdir /export/samba/home/’’utilisateur’’
root#chown ‘’utilisateur’’:Users /export/samba/home/’’utilisateur’’
root#chmod 755 /export/samba/home/’’utilisateur’’

Il nous faut aussi régler les droits du répertoire profiles de la même manière que
pour le PDC :
root#chown :Users /export/samba/profiles
root#chmod 775 /export/samba/profiles

Enfin, nous allons modifier le chemin des répertoires 'home' et 'profile' de notre
utilisateur au sein de LDAP. Nous allons indiquer ceux que l'on vient de
partager :
root#smbldap‐usermod.pl ‐C \\\\BDC\\’’utilisateur’’ ‐F \\\\BDC\\profiles\\’’utilisateur’’

Ainsi, notre utilisateur y aura enfin accès.


Nous allons initialiser le password samba LDAP :

43
root#smbpasswd ‐w secret

Setting stored password for "cn=Manager,dc=ccit,dc=com" in secrets.tdb

Enfin, il nous faudra synchroniser le SID du BDC avec celui du PDC. Le SID
sera stocké dans le fichier secrets.tdb, le même qui stocke le mot de passe
LDAP.
root#net rpc getsid CCIT
Storing SID S‐1‐5‐21‐4109349211‐2507905533‐872075644\
for Domain CCIT in secrets.tdb

Sur le BDC (le PDC doit être joignable) :


root#smbpasswd ‐S ‐r PDC

Voilà, si on démarre le PDC et le BDC, la station s'authentifiera sur le PDC et


montera les partages du BDC. Si le PDC tombe en panne, la station devrait
s'authentifier sur le BDC.
root#net rpc join ‐U root% secret
Joined domain CCIT.

V. LA REPLICATION LDAP (Serveur 4, ldap2.ccit.com)

On remarque une chose importante dans notre architecture : la gestion du


failover se fait au niveau des PDC/BDC : si le PDC tombe en panne, le BDC
prend correctement le relai. Cependant, que se passe-t-il si c'est le serveur LDAP
qui tombe en panne ? Là se situe un gros problème : nous n'avons plus accès à
notre base d'utilisateurs, personne ne peut plus s'authentifier... Nous allons
mettre en place un système de réplication qui permettrait la redondance
d'information en cas de panne du serveur LDAP. La mise en place d'un tel
système est très simple : le serveur maître va se mettre à l'écoute de chaque
modification apportée à la base et les renvoyer au serveur LDAP esclave qui
mettra la sienne à jour, afin de la garder à jour.
Ceci se fait grâce au service slurpd, côté maître : c'est lui qui se connectera au
service slapd de l'escalve pour mettre la base de ce dernier à jour. L'installation
d'OpenLDAP côté esclave s’est fait de la même manière que pour le serveur
maître... Passons directement à sa configuration.

44
1. Configuration côté maître (Serveur 1, ldap1.ccit.com)

Il suffit de déclarer le réplica, le nouveau serveur que nous appellerons


ldap2.ccit.com et le fichier "replog" dans lequel les changements à la base seront
répertoriés. Ce fichier sera lu par slurpd qui se connectera au serveur LDAP
esclave pour modifier sa base. Modification du fichier slapd.conf de
ldap1.ccit.com :
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/samba.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
database ldbm
suffix "dc=ccit,dc=com"
rootdn "cn=Manager,dc=ccit,dc=com"
rootpw secret
directory /var/lib/ldap
index objectClass,rid,uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
replogfile /var/lib/ldap/replog
replica host=ldap2.ccit.com:389
binddn="cn=Manager,dc=ccit,dc=com"
bindmethod=simple
credentials="secret"

45
2. Configuration côté esclave (Serveur 4, ldap2.ccit.com)

Déclaration du DN autorisé à répliquer sa base et du serveur maître auquel se


reporter en cas de demande de modification des données. Ceci se fait via le
fichier slapd.conf du serveur esclave ldap2.ccit.com :
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/samba.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
database ldbm
suffix "dc=ccit,dc=com"
rootdn "cn=Manager,dc=ccit,dc=com"
rootpw secret
directory /var/lib/ldap
index objectClass,rid,uid,uidNumber,gidNumber,memberUid eq
index cn,mail,surname,givenname eq,subinitial
updatedn "cn=Manager,dc=ccit,dc=com"
updateref "ldap://ldap1.ccit.com"

3.Tolérance aux pannes

La méthode que nous allons mettre en place est très simple : elle consiste à
passer par une adresse IP virtuelle. Chaque serveur LDAP possède sa propre
adresse IP, mais en possède aussi une seconde qui sera commune à tous les
serveurs redondants. Les serveurs demeurent accessibles via leur "vraie" adresse
IP, mais le sont désormais aussi par leur nouvelle adresse virtuelle. Côté client
(Samba), nous interrogerons la base LDAP via l'adresse IP virtuelle commune
(et non la "vraie" adresse). Le passage d'un serveur à l'autre se fera par une
modification de la table de routage du poste client, ceci de manière totalement
transparente pour l'application : si le premier serveur tombe en panne, les
données sont immédiatement redirigées vers le second. Il faut forcer le client à
consulter sa table de routage pour sélectionner le chemin que les paquets doivent
prendre. En d'autres termes, l'adresse IP virtuelle ne doit pas être sur le même
(sous-)réseau IP que le client. En effet, si le serveur distant est sur le même
(sous-)réseau que le client, les paquets pourront être acheminés sans passer par
une "machine" tierce (routeur, mais en fait notre vraie IP), ce qui, dans notre cas,
ne nous intéresse pas. Pour sélectionner notre chemin, nous allons donc indiquer
au client que l'adresse IP virtuelle (non joignable) peut être contactée en utilisant
une passerelle qui n'est autre que la "vraie" adresse IP du serveur LDAP à
contacter. Celui-ci se chargera de la transmission des paquets à son interface
virtuelle.

46
Voilà comment nous allons sélectionner nous même le "bon" serveur LDAP.
L'utilisation de nos serveurs LDAP comme gateways implique aussi que leurs
vraies IP soient dans le même (sous-) réseau IP que le client.

3.1 Configuration des serveurs

Sur le PDC samba : nous ferons la configuration de Samba et des services


clients LDAP pour interroger le serveur LDAP via son adresse IP virtuelle. Sa
table de routage lui indiquera par où passer pour atteindre l'adresse IP virtuelle
du serveur LDAP. Un script fera la modification dynamique de sa table de
routage, en fonction de l'état des serveurs.
Sur les serveurs LDAP : les vraies Adresses IP seront dans le même (sous-
)réseau que le client (pour servir de gateway). L’ajout d'une interface virtuelle
ayant une adresse IP commune à tous les serveurs redondants, mais appartenant
à un sous-réseau différent pour forcer le routage. La réplication des données de
l'annuaire entre les serveurs, se fera via leurs vraies adresses IP.
3.1.1 Configuration des serveurs LDAP

La réplication est déjà opérationnelle. Ajoutons une adresse IP virtuelle à chacun


des répliquas : root#ifconfig eth0:1 192.168.5.10 netmask 255.255.255.0
3.1.2 Configuration du client Samba (PDC, BDC)

Configurons Samba et les clients LDAP (libnss, libpam, ...) pour qu'ils
interrogent le serveur LDAP via l'adresse IP virtuelle.
- Créons puis exécutons le script de scrutage des serveurs qui modifiera la table
de routage.

47
root#kwrite scrutage.sh

#!/bin/sh
# Script scrutant IP1 et IP2, et modifiant la table de routage
# en fonction de l'état des machines.
# IP virtuelle du groupe de serveurs
VIP="192.168.5.10"
# Interface de sortie de notre client
IFACE="eth0"
# Premier serveur
IP1="192.168.1.20"
METRIC1="0"
# Deuxième serveur
IP2=" 192.168.1.21"
METRIC2="5"
# Tests à effectuer
# Port distant
TESTPORT="389"
# Nom du service
TESTSERV="ldap"
# Protocole
TESTPROTO="tcp"
# Attente entre chaque boucle
WAIT="5"
while true; do
echo "[Test de ${IP1}]"
nmap ‐sT ${IP1} ‐p ${TESTPORT} | grep "${TESTPORT}/${TESTPROTO}[ ]*open[ ]*${TESTSERV}">
/dev/null
if [ $? ‐eq 0 ]; then
route add ‐host ${VIP} metric ${METRIC1} gw ${IP1} dev ${IFACE} > /dev/null
echo "${IP1} ‐‐ Ok : routage pour ${VIP}, metrique ${METRIC1}"
else
route del ‐host ${VIP} metric ${METRIC1} gw ${IP1} dev ${IFACE} > /dev/null
echo "${IP1} !Ok : stop routage"
fi
echo "[Test de ${IP2}]"
nmap ‐sT ${IP2} ‐p ${TESTPORT} | grep "${TESTPORT}/${TESTPROTO}[ ]*open[ ]*${TESTSERV}">
/dev/null
if [ $? ‐eq 0 ]; then
route add ‐host ${VIP} metric ${METRIC2} gw ${IP2} dev ${IFACE} > /dev/null
echo "${IP2} ‐‐ Ok : routage pour ${VIP}, metrique ${METRIC2}"
else
route del ‐host ${VIP} metric ${METRIC2} gw ${IP2} dev ${IFACE} > /dev/null
echo "${IP2} !Ok : stop routage"
fi
sleep ${WAIT}
echo "‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐"
done
exit 0

Exécutons ce script sur le PDC et le BDC par la commande : root#./scrutage.sh

48
Ce script très simple utilise nmap pour tester si le port 389 (LDAP) des serveurs
est bien à l'écoute. Si c'est le cas, il inscrit les deux routes, mais avec des
métriques différentes ; celle qui a la plus petite métrique est alors utilisée. Si l'un
ou l'autre des serveurs LDAP vient à tomber en panne, la route est supprimée, ce
qui a pour effet de rendre l'autre route active : et l'autre serveur prend le relais.
VI. COMMUNICATION SECURISEE
Nous allons implémenter TLS sur notre serveur LDAP maître pour que les
communications Samba-LDAP soient chiffrées.
1. Mise en place de TLS

La mise en place de TLS se traduit par trois étapes :


• La génération des clefs/certificats côté serveur
• La mise en place de TLS côté serveur
• La mise en place de TLS côté client
1.1 Génération des clefs et du certificat

Nous allons préparer notre serveur à l'utilisation de TLS. Il va falloir générer


notre paire de clefs et faire signer notre clef publique par une Autorité de
Certification. Dans le répertoire /etc/ldap, créons un répertoire 'cert' qui
contiendra les clefs et le certificat :
root#mkdir /etc/ldap/cert

Dans ce répertoire, générons la clef privée du serveur :


root#openssl genrsa ‐out serverkey.pem 1024
Puis la clef publique et la demande de certificat (dans cert.req) :
root#openssl req ‐new ‐key serverkey.pem ‐out servercert.req
Renseignons le CN (Common Name) par le FQDN (nom dns complet :
ccit.com) de notre serveur, celui qui sera utilisé lors de l'interrogation de la base
LDAP par les clients.
Mettons-nous à la place d'une CA (Certification Authority). Générons la clef
privée de la CA :
root#openssl genrsa ‐out cakey.pem 1024
Générons son propre certificat (qui est alors auto certifié : car on ne fait pas
appel à une autre CA) :
root#openssl req ‐new ‐x509 ‐key cakey.pem ‐out cacert.pem ‐days 365
Enfin, générons signature par la CA de la clef publique de notre serveur :

49
root#openssl x509 ‐req ‐in servercert.req ‐out servercert.pem ‐CA cacert.pem ‐CAkey cakey.pem –
days\ 365 –Cacreateserial
Suppression des fichiers temporaires :
root#rm *.req
root#rm *.srl
Suppression de la clef privée de la CA :
root#rm cakey.pem

1.2 Réglage des droits

La clef privée ne doit pouvoir être lue que par root :


root# chown root:root serverkey.pem ; chmod 400 serverkey.pem
Nous disposons désormais des fichiers nécessaires pour mettre en place TLS sur
le serveur. Voyons à présent les modifications à apporter dans le fichier
slapd.conf...

2. Mise en place côté serveur

Sur ldap1.ccit.com, modifions /etc/ldap/slapd.conf et ajoutons les chemins vers


les différentes clefs et le certificat à la section global :
root#kwrite /etc/ldap/slapd.conf

# TLS
# Chemin vers le certificat du serveur LDAP
TLSCertificateFile /etc/ldap/cert/servercert.pem
# Chemin vers la clef privée du serveur LDAP
TLSCertificateKeyFile /etc/ldap/cert/serverkey.pem
# Chemin vers le certificat de la CA
TLSCACertificateFile /etc/ldap/cert/cacert.pem
Redémarrons notre serveur LDAP,
root#etc/init.d/ldap restart
Il est désormais 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.
3. Mise en place côté client

Nous allons mettre en place TLS au niveau de notre PDC. Il s'agit de la même
démarche faite sur le BDC...
La configuration des outils LDAP, de libnss-ldap et de libpam-ldap se fait,
comme précédemment, 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 libpam_ldap et libnss_ldap.
Ajoutons ces quelques lignes au fichier ldap.conf du PDC :

50
#Directive SSL OpenSSL (pour ldapsearch notamment)
TLS_CACERT /etc/ldap/cert/cacert.pem
#Directives SSL libnss et libpam
# Activation SSL brute (port 636)
# ssl yes
# Acivation SSL via commande starttls (port standard 389)
ssl start_tls
#Verifie certificat serveur
tls_checkpeer yes
# Emplacement certificat CA
tls_cacertfile /etc/ldap/cert/cacert.pem

Le fichier 'cacert' doit être présent sur notre disque. Il s'agit du certificat de la
CA. Il convient qu’il soit copier au bon endroit (ici /etc/ldap/cert/) depuis notre
serveur LDAP.

4. Mise en place sous Samba

Le but de tout ceci étant de pouvoir intégrer TLS aux communications entre
Samba et notre serveur LDAP, modifions le fichier smb.conf du PDC :
; SAMBA-LDAP declarations
ldap suffix = dc=ccit,dc=com
ldap admin dn = cn=Manager,dc=ccit,dc=com
ldap server = ldap1.ccit.com
; ldap ssl = No
ldap ssl = start_tls
ldap port = 389

Il suffit de rajouter une ligne à notre configuration précédente : 'ldap ssl =


start_tls'. Samba devra se connecter sur le port 389, puisque l'on utilisera la
commande 'starttls' sur une connexion LDAP standard.

51
VII. AJOUT DES COMPTES
Notre base d’utilisateurs et de groupes d’utilisateurs est vide, nous allons ajoutez
les groupes listés dans le tableau ci dessous dans notre annuaire ldap1.ccit.com

Droits
Groupe pouvant
Chemin du Dossiers Fichier
Groupe Partage GID accéder aux
partage du s du
partages
partage partage
President President /data/ President 513 President 2770 750
Secretariat ,
Secretariat Secretariat /data/ Secretariat 513 2770 750
president
Cfe Cfe /data/ Cfe 513 Cfe, president 2770 750
Attache Attache /data/ Attache 513 Attache, Secretariat 2770 750
Resshum,
Resshum Resshum /data/ Resshum 513 2770 750
Secretariat
Docpub Docpub /data/ Docpub 513 Docpub, Secretariat 2770 750
Presse Presse /data/ Presse 513 Presse, Secretariat 2770 750
Defp Defp /data/ Defp 513 Defp, Secretariat 2770 750
Fincompta,
Fincompta Fincompta /data/ Fincompta 513 2770 750
Secretariat
Fdgaranti,
Fdgaranti Fdgaranti /data/ Fdgaranti 513 2770 750
Secretariat
Relext Relext /data/ Relext 513 Relext, Secretariat 2770 750
Coa, Secretariat,
Coa Coa /data/ Coa 513 2770 750
Docpub
Admin Admin /data/ Admin 512 Admin, 2770 770
Tout /data/ Tout Tout le monde 2777 777

‐Création du répertoire principal des partages

root#mkdir /data
root#chown –R root :root /data
root#chmod –R 700 /data
Pour chaque ligne du tableau nous devons effectuer les opérations suivantes en
remplaçant les élements entre cotes par leur correspondance dans le tableau.
-Création du groupe
root#./smbldap‐groupadd –a ‘’Groupe’’

-Création des partages


root#mkdir ‘’chemin du partage ‘’
root#chmod –R ‘’droits sur les dossiers de partage ‘’ ‘’chemin du partage ‘’
-Ajout du partage dans le fichier smb.conf du BDC (insérer les lignes dans le
fichier)

52
[‘’Partage ‘’]
comment= ‘’ description du partage ‘’
path= ‘’chemin du partage ‘’
valid users=@’’groupe pouvant accéder aux partages’’
read only=no
browsable=yes
writable=yes
(force) create mode=’’droits sur les fichiers du partage’’
(force) directory mode=’’droits sur les dossiers du partage’’
-Pour ajouter root :
root# cd /opt/IDEALX/sbin
root# ./smbldap‐usermod ‐u 0 ‐d /root ‐s /bin/bash root
-Pour ajouter un utilisateur :
root#./smbldap‐useradd –m –a ’’utilisateur’’
root#./smbldap‐passwd ’’utilisateur’’
Changing password for ’’utilisateur’’
New password : XXXXXXXX
Retype new password : XXXXXXXX
root# smbpasswd ’’utilisateur’’
New SMB password : XXXXXXXX
Retype new SMB password: XXXXXXXX
-Pour ajouter un utilisateur au groupe :
root#smbldap‐groupmod –m ‘’utilisateur’’ ‘’Groupe’’
-Pour ajouter une machine :
root#./smbldap‐useradd –w ‘’Nom NetBIOS de la machine’’$

VIII. CONFIGURATION DES POSTES CLIENTS


Jonction du client Xp au domaine ccit
Pour joindre les machines clientes Xp au domaine nous procédons de la manière
suivante : Clic droit sur Poste de travail choisir Propriétés cliquer sur l’onglet
Nom de l’ordinateur, cliquer sur modifier puis indiquer CCIT.COM comme
nom de domaine.
Nos clients peuvent maintenant se connecter au domaine avec leur nom de
compte et mot de passe.
Notre domaine et nos clients sont configurés. Tous les utilisateurs peuvent
s’authentifier peu un importe leurs systèmes d’exploitation. La tolérance en
panne du nouveau système est assurée par le contrôleur de domaine secondaire
(bdc.ccit.com) et l’annuaire Openldap secondaire (ldap2.ccit.com). La sécurité
au sein du domaine est assurée par le cryptage des mots de passe et des
communications. Samba est un outil très complet et nous a permis de mieux
gérer notre réseau et de répondre aux attentes des utilisateurs.

53
SCHEMA FINAL DE
L’ARCHITECTURE PROPOSEE POUR
LE RESEAU LAN DE LA CCIT

54
55
CONCLUSION

56
Après présentation de la Chambre de Commerce et d’industrie du TOGO, son
historique, son organisation et sa structure, le présent document présente les
différents moyens de gestion de l’information au sein de la CCIT. La gestion de
l’information au sein de la CCIT est confrontée à divers problèmes : les partages
ne sont pas sécurisés, les utilisateurs s’authentifient en tant qu’administrateur et
le niveau de sécurité du réseau est assez bas.
Après une étude de ces différents problèmes, nous proposons une solution qui
permettra de centraliser les authentifications et les partages, offrant une
tolérance au panne du coté des partages et des authentifications des utilisateurs.
Tout ceci à travers un environnement sécurisé grâce au cryptage de données et
un canal de communication sécurisé. Ce document constitue un ensemble de
solutions appropriées aux divers problèmes d’authentification, de partage de
données et de sécurité du réseau de la CCIT.
La mise en œuvre de ces solutions permettra à la chambre de commerce et
d’industrie du Togo de sécuriser son réseau et d’offrir de nouveaux services
réseaux répondant aux attentes du personnel.

57
BIBLIOGRAPHIE

58
Ouvrages spécifiques

Using Samba, 2nd Edition De Jay Ts, Robert Eckstein, and David Collier-Brown
2nd Edition, February 2003
O'Reilly & Associates, ISBN: 0-596-00256-4

The Official Samba-3 HOWTO and Reference Guide de Jelmer R. Vernooij ,John H. Terpstra
et Gerald (Jerry) Carter

Samba-3 by Example de John H. Terpstra

Sites internet

http://www.samba.org

http://samba.idealx.org

http://www.openldap.org

http://www.padl.com

http://samba.2037.org/documentation.php

http://www.ac-creteil.fr/reseaux/systemes/linux/Welcome.html

http://lea-linux.org/cached/index/reseau-samba.html

http://www.freenix.fr/unix/linux/HOWTO/SMB-HOWTO.html

http://xenux.danstesoreilles.com/?article=22

http://forum.2037.com/viewtopic.php?t=1525

http://forum.2037.com/viewtopic.php?t=1525

http://www.linux-france.org/article/serveur/samba-mhp/smb-conf.htm

http://contribs.martymac.com/

http://samba.2037.org/documentation.php

https://gna.org/cookbook/?group=sambadoc

http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/FastStart.html

http://xenux.danstesoreilles.com/index.php?links=3&skin=skin1

http://contrib.xarli.net/optionfusionsousdebian/

http://contrib.xarli.net/peren2002/

http://www.linuxfranch-county.org/

http://www.europe.redhat.com/documentation/rhl7.3/rhl-cg-fr-7.3/s1-samba-additional-
resources.php3

59
TABLE DES MATIERES

60
TABLE DES MATIERES

Sommaire ............................................................................................................................ i
Dédicaces ............................................................................................................................ ii
Remerciements .................................................................................................................... iii
Avant propos ....................................................................................................................... iv
Introduction ......................................................................................................................... 1
PREMIERE PARTIE : PRESENTATION DE LA CCIT......................................................... 3
A. PRESENTATION GENERALE ....................................................................... 4
I. HISTORIQUE ................................................................................................................................. 4
II. OBJECTIFS ET MISSIONS DE LA CCIT ................................................................................... 4
1. Les Objectifs de la CCIT ......................................................................................... 4
2. Missions de la CCIT ................................................................................................ 5
III. STRUCTURE ADMINISTRATIVE ET ORGANISATIONNELLE ......................................... 6
1. Le Secrétariat Général ............................................................................................... 6
2. Division des Entreprises et de la Formation Professionnelle (DEFP) ....................... 7
3. Le Centre des Formalités Des Entreprises (CFE) ou Guichet Unique ..................... 7
4. Les Cellules d’Assistance aux Entreprises ............................................................... 7
5. La Division Documentation et Publication .............................................................. 8
6. La Division Presse .................................................................................................... 8
7. La Division du Fonds de Garantie Routier (FGR) ................................................... 8
8. La Division des Relations extérieures ...................................................................... 8
9. La Division Financière et Comptable ....................................................................... 8
10. Division Ressources Humaines ............................................................................. 8
11. Délégation de Kara ou l’Antenne de Kara ............................................................. 8
B. PRESENTATION ET ANALYSE DU DOMAINE D’ETUDE .......................... 9
I. LE SERVICE INFORMATIQUE ................................................................................................... 9
II. LE PARC INFORMATIQUE ........................................................................................................ 9
DEUXIEME : PARTIE ETUDE PREALABLE ........................................................................ 10
A. ETUDE DE L’EXISTANT................................................................................ 11
I. PRESENTATION DU PROJET ET DE SES OBJECTIFS ........................................................... 11
II. DESCRIPTION DE L’EXISTANT ............................................................................................... 12
1. Le service informatique ............................................................................................ 12
1.1. Les équipements réseaux ................................................................................... 12
1.2. Les serveurs ....................................................................................................... 13
1.3. Les postes de travail .......................................................................................... 13
2. L’adressage................................................................................................................ 13
3. Gestion des authentifications..................................................................................... 13
4. Politique d’accès aux ressources partagées ............................................................... 14
5. La sécurité ................................................................................................................. 14
6. Internet ...................................................................................................................... 14
B. ARCHITECTURE LAN DE LA CCIT .............................................................. 15
C. CRITIQUE DE L’EXISTANT .......................................................................... 16
I. GESTION DES AUTHENTIFICATIONS ..................................................................................... 16
II. POLITIQUE D’ACCES AUX RESSOURCES PARTAGEES .................................................... 16

I
III. LA SECURITE ............................................................................................................................. 16
D. PROBLEMATIQUES ET APPROCHES DE SOLUTIONS .............................. 16
I. PROBLEMATIQUE ....................................................................................................................... 16
II. APPROCHES DE SOLUTIONS ................................................................................................... 17
1. Optimiser la gestion des utilisateurs .......................................................................... 17
2. Mise en place d’une politique de sécurité sur les ressources partagées .................... 17
3. Nouvelle gestion des partages ................................................................................... 17
4. Formation du personnel ............................................................................................. 17
TROISIEME PARTIE : ETUDE DETAILLEE DU PROJET ................................................. 18
A. OPTIMISATION DE LA GESTION DES UTILISATEURS ET DES PARTAGES 19
I. LE CONTROLEUR DE DOMAINE .............................................................................................. 19
1. Un domaine NT ......................................................................................................... 19
2. Les acteurs du domaine ............................................................................................. 19
3. Les SIDs .................................................................................................................... 20
II. L’ANNUAIRE OPENLDAP ......................................................................................................... 21
1. Introduction .............................................................................................................. 21
2. Définition d’un annuaire ........................................................................................... 21
3. Différents types d’annuaires ...................................................................................... 21
4. Protocole LDAP ........................................................................................................ 22
5. Caractéristiques et fonctionnement ........................................................................... 22
III. LE SERVEUR SAMBA ............................................................................................................... 23
1. Présentation de Samba .............................................................................................. 23
2. Principe de fonctionnement ....................................................................................... 23
3. Authentification et gestion des utilisateurs................................................................ 24
4. Stockage des utilisateurs ........................................................................................... 25
5. Gestion des groupes et utilisateurs sous samba ......................................................... 25
6. Gestions des comptes ................................................................................................ 25
6.1 Dualité des comptes ........................................................................................... 26
6.1.1 Compte POSIX ............................................................................................. 26
6.1.2 Compte Samba .............................................................................................. 26
6.2 Gestion des groupes ........................................................................................... 26
7. Gestion des droits ...................................................................................................... 26
7.1 Les droits Posix .................................................................................................. 26
7.2 Les droits Posix sous Samba .............................................................................. 27
B. LA MISE EN PLACE ....................................................................................... 27
I. ETUDE DES BESOINS .................................................................................................................. 27
II. INSTALLATION ET CONFIGURATION DE L’ANNUAIRE OPENLDAP ............................ 27
1. Contexte .................................................................................................................... 27
2. Configuration du serveur .......................................................................................... 27
2.1 Configuration de l’adresse IP ............................................................................. 27
2.2 Edition du fichier de configuration .................................................................... 28
2.3 Premier test......................................................................................................... 28
III. INSTALLATION ET CONFIGURATION DE SAMBA EN TANT QUE CONTROLEUR DE
DOMAINE PRINCIPAL (PDC) ........................................................................................................ 30
1. Installation de Samba ................................................................................................ 30
2. Préparation PDC pour l'authentification via LDAP ................................................. 31
2.1 Installation des outils nécessaires à la redirection de compte ............................ 31
2.1.1 Installation de libnss-ldap ............................................................................ 31

II
2.1.2 Installation de libpam-ldap : Modules LDAP pour pam............................... 31
2.2. Installation des smbldap-tools ........................................................................... 32
2.2.1 Configuration de smbldap-tools ................................................................... 33
2.2.2 Insertion de l'arborescence de base pour samba dans LDAP........................ 35
2.3 Configuration des méthodes d'authentification du Système ............................... 36
2.3.1 Configuration de Nsswitch ........................................................................... 36
2.3.2 Configuration de Pam ................................................................................... 37
3. Configuration générale des librairies libpam-ldap et libnss-ldap .............................. 37
4. Configuration de Samba ............................................................................................ 38
5. Création du répertoire netlogon ................................................................................. 39
6. Test : Joindre une machine au domaine .................................................................... 39
IV. MISE EN PLACE DU CONTROLEUR DE DOMAINE SECONDAIRE (BDC) .................... 40
1. Processus de montage du répertoire Home d'un utilisateur et de prise de relais du BDC
en cas de panne du PDC ................................................................................................ 41
2. Configuration de notre BDC (serveur 3 bdc.ccit.com) .............................................. 41
V. LA REPLICATION LDAP (Serveur 4, ldap2.ccit.com) ................................................... 44
1. Configuration côté maître (Serveur 1, ldap1.ccit.com) ............................................. 45
2. Configuration côté esclave (Serveur 4, ldap2.ccit.com) ............................................ 46
3. Tolérance aux pannes ................................................................................................ 46
3.1 Configuration des serveurs ................................................................................. 47
3.1.1 Configuration des serveurs LDAP ................................................................ 47
3.1.2 Configuration du client Samba (PDC, BDC) ............................................... 47
VI. COMMUNICATION SECURISEE ............................................................................................. 49
1. Mise en place de TLS ................................................................................................ 49
1.1 Génération des clefs et du certificat ................................................................... 49
1.2 Réglage des droits .............................................................................................. 50
2. Mise en place côté serveur ........................................................................................ 50
3. Mise en place côté client ........................................................................................... 50
4. Mise en place sous Samba ......................................................................................... 51
VII. AJOUT DES COMPTES ............................................................................................................ 52
VIII. CONFIGURATION DES POSTES CLIENTS ......................................................................... 53
Schéma final de l’Architecture proposée pour le réseau Lan de la CCIT ....................................... 54
CONCLUSION ................................................................................................................... 56
BIBLIOGRAPHIE .............................................................................................................. 58
TABLE DES MATIERES .................................................................................................. 60

III

Vous aimerez peut-être aussi