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

SUPERIEUR – BTS OPTION : ADMINISTRATEUR DE RESEAUX LOCAUX D’ENTREPRISES

THEME : 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

MINISTERE DE L’ENSEIGNEMENT TECHNIQUE ET DE LA FORMATION PROFESSIONNELLE

(M.ET.F.P)

REPUBLIQUE TOGOLAISE Travail-Liberté-Patrie

OFFICE DU BREVET DE TECHNICIEN SUPERIEUR (OBTS)

INSTITUT AFRICAIN D’ADMINISTRATION ET D’ETUDES COMMERCIALES

(IAEC)

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)

i

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

ii

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.

iii

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.

iv

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).

1

INTRODUCTION

2

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é.

3

1 E R PARTIE

PRESENTATION DE LA CCIT

4

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 ;

5

• 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.

6

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.

7

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 :

La recherche et définition des projets ;

L’orientation d’activités ;

Négociation de crédits et prêts bancaires ;

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.

8

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.

9

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

Comptabilité Windows Server 2003 Sert au service Comptabilité pour l’immobilisation et paye sous Sage Saari

Proxy Linux RedHat 8.0 Utiliser pour le partage de la connexion Internet à tous les services

DNS, Mail et Web Linux RedHat 8.0

Utiliser pour la résolution de nom, la gestion des mails de 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.

10

2 E M E P A R T I E E T U D E P R E A L A B L E

11

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 :

12

• 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.

13

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.

14

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.

15

B. ARCHITECTURE LAN DE LA CCIT

16

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.

17

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.

18

3 E M E PARTIE

ETUDE DETAILLEE DU PROJET

19

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 ;

20

• 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

21

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

22

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

23

• 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.

24

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.

25

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.

26

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.

27

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

28

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

29

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

30

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

31

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

32

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

33

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’

34

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.

35

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

36

#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

37

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.

38

- 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

39

; 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

40

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.

41

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

42

é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

43

; 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 :

44

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.

45

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"

46

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.

47

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.

48

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

49

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 :

50

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 :

51

#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.

52

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

‐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)

Groupe Partage Chemin du partage GID

Groupe pouvant accéder aux

partages

Droits Dossiers

du partage

Fichiers du

partage President President /data/ President 513 President 2770 750

Secretariat Secretariat /data/ Secretariat 513 Secretariat , president 2770 750

Cfe Cfe /data/ Cfe 513 Cfe, president 2770 750 Attache Attache /data/ Attache 513 Attache, Secretariat 2770 750

Resshum Resshum /data/ Resshum 513 Resshum, Secretariat 2770 750

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 /data/ Fincompta 513 Fincompta, Secretariat 2770 750

Fdgaranti Fdgaranti /data/ Fdgaranti 513 Fdgaranti, Secretariat 2770 750

Relext Relext /data/ Relext 513 Relext, Secretariat 2770 750

Coa Coa /data/ Coa 513 Coa, Secretariat, Docpub 2770 750

Admin Admin /data/ Admin 512 Admin, 2770 770 Tout /data/ Tout Tout le monde 2777 777

53

[‘’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.

54

SCHEMA FINAL DE L’ARCHITECTURE PROPOSEE POUR

LE RESEAU LAN DE LA CCIT

55

56

CONCLUSION

57

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.

58

B IBLIOGRAPHIE

59

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

60

T A B L E D E S M A T I ER E S

I

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

II

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

III

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