Vous êtes sur la page 1sur 61
Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt
Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch

version 01.01

Auteur :

Ion Marculescu Ingénieur Trainer MCSE, MCT

01.01 Auteur : Ion Marculescu Ingénieur Trainer MCSE, MCT ISEIG - Institut Suisse d'Enseignement de

ISEIG - Institut Suisse d'Enseignement de l'Informatique de Gestion Avenue des Boveresses 52, Case postale 99

CH - 1000 LAUSANNE 21

Tél. : 021/654.40.60, Fax : 021/654.40.69 E-Mail : info@iseig.ch, URL : www.iseig.ch

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

Table des matières

1

Introduction

3

1.1

Objectifs du mandat

3

1.2

Champ et limites de la mission

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.3

Composition de l'équipe

 

4

2

Etude de l'existant

5

2.1

Forêt intranet.epfl.ch

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

2.2

Domaine racine de la forêt intranet.epfl.ch

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

2.3

Domaine sg.intranet.ch

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

6

2.4

Domaine

servers.intranet.epfl.ch

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

8

2.5

Domaine représentatif des 24 autres domaines utilisateurs

 

8

2.6

Problèmes relatifs au déploiement de Windows 2000 dans l'environnement hautement

décentralisé de l'EPFL

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

2.7

Implémentation de Exchange 2000

 

9

3

Recommandations

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

3.1

Objectifs du déploiement

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

3.2

Recommandations générales

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

3.3

Recommandations pour le domaine intranet.epfl.ch

 

16

3.4

Recommandations pour le domaine servers.intranet.epfl.ch

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

3.5

Recommandations pour le domaine sg.intranet.epfl.ch

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

3.7

Introduction aux annexes

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

Annexe 1 -

Liste des événements à auditer

 

24

Annexe 2 -

Procédure de Pré-Creation d’un Child Domain

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

26

Annexe 3 -

Etablissement d'une stratégie de sécurité des

 
 

comptes et contrôle de son application

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

30

Annexe 4 -

Permissions required for Installation and management of Microsoft

 
 

Exchange 2000

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

Annexe 5 -

Mesures de protection de l’unité d’organisation Domain controllers et de

 

sa stratégie par défaut Default Domain Controllers Policy

 

53

Annexe 6 -

Mot de passe de restauration du service d’annuaire

 

56

Annexe 7 -

Utilisations des groupes Exchange 2000

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

57

Annexe 8 -

Procédure de mise à jour des destinataires dans des environnements

 

multi-domaines

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

60

Annexe 9 -

Procédure d'octroi des accès à l'organisation, au groupe administratifs

 
 

et aux objets de l’organisation Exchange EPFL

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

61

Annexe 10 -

Procédure de vérification des messages entrants à la recherche de pièces jointes .vbx, .bat, .exe

 

64

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

1

Introduction

1.1 Objectifs du mandat

Le présent mandat consiste à étudier :

• l'implémentation du service d'annuaire de Microsoft Windows 2000 dans le domaine

sg.intranet.epfl.ch appartenant aux Services Généraux de l'EPFL et de son intégration dans la forêt intranet.epfl.ch;

• l'intégration de l'organisation Exchange 2000 dans la forêt intranet.epfl.ch;

• l'infrastructure matérielle devant supporter l'Active Directory et les procédures de sauvegarde/restauration permettant d'assurer son bon fonctionnement;

) pour faire face à d'éventuelles

• l'organisation à mettre en place (personnel, procédures, situations critiques.

Il doit permettre de vérifier que le déploiement de Windows 2000 dans le domaine sg.intranet.epfl.ch a été effectué selon les règles conseillées par Microsoft et que la configuration actuelle de l’Active Directory permet une migration optimale de tous les autres ordinateurs Windows NT 4.0 vers Windows 2000.

1.2 Champ et limites de la mission

L'étude porte principalement sur les contrôleurs de domaine et les serveurs des domaines sg.intranet.epfl.ch et intranet.epfl.ch. Comme les utilisateurs du domaine sg.intranet.epfl.ch utilisent des ressources du domaine servers.intranet.epfl.ch, il a été décidé de l'intégrer à l'étude, de même que le domaine dsc-lanos jugé représentatif des environ 24 autres domaines de la forêt intranet.epfl.ch.

L'audit porte sur l'implémentation de Windows 2000 sur les contrôleurs du domaine et les serveurs du domaine. Il ne prend en compte que partiellement les aspects de sécurité physique relatifs aux :

• risques dont l'origine est naturelle : foudre, inondation,

• risques dont l'origine est un incident technique : incendie, dégât des eaux, panne/bris de

machines, panne de réseau physique (cablâge, routeurs,

),

• risques dont la cause principale est humaine : événements accidentels et socio- économiques (erreurs, grève/démission), actes délictueux (vol/sabotage matériel, détournement d'informations, détournement de logiciels, fraude, sabotage immatériel).

Ces aspects de sécurité sont analysés continuellement par des spécialistes de l'EPFL.

1.3 Composition de l'équipe

ISEIG

• Ion Marculescu ingénieur en électronique et télécommunication de l'Ecole Polytechnique de Bucarest, MCSE - Microsoft Certified System Engineer and Trainer

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

EPFL

• M. Daniel Chuard, chef de la section informatique de gestion

• M. Daniel Perret, ingénieur système, responsable du domaine sg.intranet.epfl.ch, SG

• M. Olivier Michaud, ingénieur système, SG

• M. Robert Ritter, ingénieur système, responsable des contrôleurs du domaine intranet.epfl.ch

• M. T. Charles, collaborateur technique AMD/SIC/SII

• M. C. Zufferey, ingénieur système,

• M. T. Schimming, assistant DSC/LANOS

• M. F. Georgy, ingénieur ETS, DSC

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

2 Etude de l'existant

2.1 Forêt intranet.epfl.ch

L'informatique de l'EPFL comprend environ 8000 ordinateurs dont quelques 2000 PC répartis dans environ 60 domaines.

dont quelques 2000 PC répartis dans environ 60 domaines. Le schéma ci-dessus présente l'implémentation

Le schéma ci-dessus présente l'implémentation existante de la forêt intranet.epfl.ch composée de :

C

1 domaine racine intranet.epfl.ch;

C

environ 24 domaines enfants.

2.2 Domaine racine de la forêt intranet.epfl.ch

Ce domaine est vital pour le bon fonctionnement de l'ensemble des domaines qui forme la forêt car il assure des fonctionnalités essentielles pour l'ensemble de la forêt, fonctionnalités qui ne peuvent pas être transférées à d'autres domaines.

La perte de ce domaine nécessite une réinstallation de tous les domaines de la forêt

(Windows 2000, comptes utilisateurs,

).

Les services de ce domaine clé sont assurés par :

C 2 ordinateurs "de bureau" tournant sous Windows 2000 qui assure chacun les fonctions

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

de :

C

contrôleur de domaine;

C

serveur DNS;

C

serveur de catalogue global.

C 1 serveur de sauvegarde centralisé

Constats :

C

localisation : les 2 contrôleurs de domaine ainsi que le serveur de sauvegarde sont installés dans le même local (bâtiment MA).

C

gestion : assurée par 1 seul télé-informaticien, M. Robert Ritter.

C

disponibilité

 

C

tolérance de panne : assurée par la présence de 2 ordinateurs assurant les mêmes fonctionnalités

C

les disques des serveurs n'utilisent pas le miroir disque

C

sauvegarde :

 

C

les serveurs n'ont pas d'unité de sauvegarde locale.

C

une sauvegarde complète sur bandes se fait durant le week-end à travers le réseau et une sauvegarde de l'état du système chaque nuit sur bande.

C

le système d'archivage, le nombre de bandes, la gestion/archivage des bandes n'ont pas été contrôlés

C

aucun crash test n'a été effectué jusqu'à maintenant

C

la procédure de sauvetage et de restauration n'est pas documentée

C

confidentialité

C

les noms DNS des contrôleurs de domaine et de tous les ordinateurs peuvent être résolus en adresses IP par n'importe quel utilisateur Internet de la planète. Par ailleurs, la commande ping fonctionne depuis internet vers tous les ordinateurs de l'intranet de l'EPFL. Ce problème se retrouve sur tous les domaines enfants. La sécurité est assurée par des routeurs avec accès contrôlés qui permettent ces 2 opérations et peut-

 

être plus (connexions virtuelles VPN,

).

 

C

accès aux serveurs localement et à travers le réseau : hors du champ de cet audit

C

les accès sont contrôlés et enregistrés dans le journal d'audit de Windows 2000, sauvegardés lors des sauvegardes journalières et hebdomadaires. Il n’y a pas d’archivage séparé des journaux de sécurité

C

documentation du système : aucune documentation système n'a été établie

C

performances du système

C présence d'un très grand nombre de domaines occasionnant une baisse des performances du système qui rend sa compréhension et administration longue et difficile.

2.3 Domaine sg.intranet.ch

Les ordinateurs regroupés dans ce domaine sont utilisés pour mener à bien les tâches administratives de l'EPFL.

Les services de ce domaine clé sont assurés par :

C

2 contrôleurs de domaine Windows 2000 dont 1 assure la fonction de catalogue global pour la gestion de tous les objets de la forêt.

C

1 serveur Exchange 2000 installé sur un serveur membre du domaine utilisé essentiellement pour le partage d'agenda et non pour la gestion du courrier électronique.

C

3 serveurs de fichier Windows 2000

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

C

1 serveur de sauvegarde centralisé

C

environ 50 postes de travail aujourd'hui et 350 prévus à court terme

Ce domaine permet l'authentification des utilisateurs des Services généraux (SG). La perte de ce domaine empêche les utilisateurs créés dans ce domaine d'ouvrir des sessions et donc d'utiliser leur ordinateur.

Constats :

C

localisation :

C

salle principale : 1 contrôleur de domaine et tous les serveurs se trouvent dans la salle des serveurs du MA.

C

salle de backup : le 2ème contrôleur de domaine est situé dans la salle des serveurs du SIG.

C

gestion : les contrôleurs de domaine et les serveurs sont gérés par 2 informaticiens, M. D. Perret et M. O. Michaud. Les autres ordinateurs du SG sont maintenus par 3 autres informaticiens.

C

disponibilité

C

tolérance de panne : assurée par la présence de 2 ordinateurs assurant les mêmes fonctionnalités et installés dans 2 locaux différents

C

les disques de tous les serveurs utilisent le miroir disque pour assurer la tolérance de panne

C

sauvegarde :

C

tous les serveurs sont équipés d'une unité de sauvegarde locale.

C

une sauvegarde complète sur bandes se fait toutes les nuits en local et à travers le réseau. Tous les 3 mois, un archivage des données est effectué et la cassette de sauvegarde est placée dans un coffre, dans un autre bâtiment. Une procédure a été mise en place et documentée pour introduire et sortir les cassettes du coffre.

C

la gestion/archivage des bandes sauvetage local et réseau permet les meilleures conditions de restauration.

C

des crash tests ont été effectués pour les données. Des tests de restauration forcés de l'Active Directory ont été effectués avec succès.

C

la procédure de sauvetage et de restauration n'est pas documentée, mais elle est connue et appliquée par les 3 personnes responsables.

C

confidentialité

C

accès aux serveurs localement et à travers le réseau : contrôlés par routeurs en fonction du subnet. Les 2 administrateurs aux serveurs gèrent les accès aux partages.

C

les accès sont contrôlés et enregistrés dans le journal d'audit de Windows 2000, sauvegardé lors des sauvegardes journalières et hebdomadaires.

C

documentation du système : schéma du domaine, liste des accès aux serveurs, documentation des ordinateurs et leur disquette de réparation d'urgence se trouvent dans le bureau de l'ingénieur système responsable du domaine SG, M. Perret. Les mots de passe se trouvent dans un coffre-fort dont l'accès n'est permis qu'aux 3 responsables du domaine.

2.4 Domaine servers.intranet.epfl.ch

Les ordinateurs de ce domaine gèrent les données d'intérêt général partagées pour les utilisateurs des différents domaines de la forêt intranet.epfl.ch.

Ce domaine comprend 2 domaines enfants :

C

expo.servers.intranet.epfl.ch

C

metadir.servers.intranet.epfl.ch

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

Les services de ce domaine important sont assurés par :

C

2 ordinateurs "de bureau” installés comme contrôleurs de domaine Windows 2000

C

1 serveur Exchange 2000 installé sur un serveur membre du domaine.

C

3 serveurs de fichiers Windows 2000

C

1 serveur de sauvegarde centralisé

La perte de ce domaine empêche tous les utilisateurs de la forêt d'accéder aux données qui sont mises à leur disposition.

Constats :

C

localisation :

C

les 2 contrôleurs de domaine et tous les serveurs se trouvent dans différents locaux

 

du bâtiment MA.

C

gestion : les serveurs sont gérés par 2 informaticiens, M. T. Charles et C. Zufferey.

2.5 Domaine représentatif des 24 autres domaines utilisateurs

Ces domaines ne font pas partie du champs de l'étude. Toutefois, comme ils font partie de la forêt, leur configuration peut occasionner des problèmes pour le bon fonctionnement des ordinateurs des domaines du champ de l'étude. Il a donc été décidé en accord avec le mandant de mentionner les problèmes qu'ils pourraient engendrer pour la forêt.

Il existe environ 24 domaines enfants avec 1 ou 2 contrôleurs de domaine, 10 à 15 serveurs ou stations et 20 à 30 utilisateurs. Les ordinateurs de ces domaines sont installés, configurés et administrés par différents groupes de personnes qui ont travaillé avec Windows NT 4.0 et qui semblent continuer à raisonner dans la philosophie Windows NT 4.0. Ces domaines font partie de la forêt intranet.epfl.ch et sont administrés par des ingénieurs système qui n'ont pas toujours les connaissances suffisantes ou le temps pour définir un concept optimal d'intégration dans l'Active Directory. Un trop grand nombre d’administrateurs représente un risque pour le bon fonctionnement de l'ensemble de l'intranet de l'EPFL. La configuration actuelle nécessite des moyens humains et matériels importants qui pourraient être diminués.

2.6 Problèmes relatifs au déploiement de Windows 2000 dans l'environnement hautement décentralisé de l'EPFL

C

grand nombre de domaines : environ 24 domaines dans la forêt Windows 2000, environ 60 domaines NT 4.0

C

l'EPFL comprend environ 10 départements qui sont assimilable à des entreprises indépendantes. De ce fait, chaque département définit sa propre politique d'implémentation et de sécurité avec le minimum de coordination.

2.7 Implémentation de Exchange 2000

C

L’organisation de Exchange 2000 a été crée par une nouvelle installation. Il n'y a donc pas eu de migration depuis Exchange 5.5.

C

L’organisation de Exchange 2000 fonctionne en mode mixte et ce, malgré qu’il n'y a aucun serveur Exchange 5.x dans l’organisation EPFL. Sur le même réseau physique, il existe d'autres serveurs Exchange 5.5 qui font partie d'autres sites Exchange 5.5. Les

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

utilisateurs qui font partie de ces sites seront migrés également vers Windows 2000. Avant de passer l'organisation Exchange en mode natif, il faut vérifier les 2 points suivants :

C

aucun serveur Exchange 5.5 ne doit se trouver dans l'organisation Exchange EPFL, ce qui est le cas actuellement.

C

aucun nouveau serveur 5.5 ne pourra être installé. La nécessité d'installer un serveur 5.5 dans l'organisation Exchange EPFL peut se présenter si des applications de passerelle avec d'autres systèmes de messagerie non Microsoft devaient être installés et si ces applications ne tournent que sur Exchange 5.5.

Groupe administratif

Serveurs Exchange

Nombre contrôleurs de

Rôle

2000

domaine dans le domaine du serveur Exchange

First Administrative group

lanos.dcs-

1

DC

lanos.intranet.epfl.ch

First Administrative group

Sicsrv1.serveurs.intran

   

et.epfl.ch

First Administrative group

Verseur

   

DSC-SG

Postman

2

 

LAVOC

pc18.dgc.intranet.epfl.c

2

 

h

SG

sgexchange.sg.intranet.

2

Serveur

epfl.ch

membre

C

Les serveurs Exchange ont été groupés en groupes administratifs. Les administrateurs des différents serveurs Exchange se sont attribués les droits qu’ils considéraient justes directement au niveau de l’objet Serveur Exchange et non pas au niveau des groupes administratifs.

C

Les tâches d’administration n’ont pas été systématiquement déléguées à l’aide de l’Assistant Délégation d’administration Exchange.

C

Le schéma ci-après présente les 4 groupes administratif existants :

ci-après présente les 4 groupes administratif existants : Version 01.01 27 août 2001 (10h36) EPFL_Audit_010817.wpd
Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

C

Quelques stratégies système de test ont été créées dans certaines groupes administratif et appliquées aux serveurs du même groupe administratif.

C

Le groupe administratif "First Administrative Group" n’est utilisé ni pour un contrôle centralisé, ni pour regrouper des stratégies système, ni pour définir des paramètres pour

toute l’ EPFL. Ces stratégies pourraient contrôler des paramètres tels que : la taille des

boîtes aux lettres, la durée de conservation des messages,

Ces stratégies pourraient

être appliquées aux serveurs d’autres groupes administratifs par les administrateurs de ces groupes.

C

Certains serveurs se trouvant dans des domaines différents sont groupés dans un même groupe administratif.

C

Certains serveurs plus utilisés et probablement déconnectés, ont été observés dans l’organisation Exchange.

C

Le nombre moyen des utilisateurs par domaine est inférieur à 50. La même moyenne d’utilisateurs a été constatée pour chaque serveur Exchange.

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

3

Recommandations

3.1 Objectifs du déploiement

Un bon concept de déploiement doit permettre de:

C

définir un concept de déploiement Windows 2000 évolutif

C

définir un concept gérable

C

définir un concept sécurisé

C

minimiser les charges d'administration

C

établir une politique de gestion de la sécurité relative aux rapports entre l’EPFL et les utilisateurs.

C

ne pas partir dans une fausse direction ou une impasse

3.2 Recommandations générales

Les recommandations suivantes s'appliquent à tous les domaines.

Microsoft Windows 2000

C

Microsoft Windows 2000 comprend un nombre conséquent de fonctionnalités nouvelles qui n'étaient pas disponibles sous Windows 4.0. Microsoft le présente comme une évolution majeure et non pas comme une simple mise à jour de l'existant. De ce fait, avant toute installation, il faut s'assurer que les concepts Active Directory ont bien été assimilés. Pour ce faire, il est nécessaire de mettre en place une structure permettant aux ingénieurs système d'acquérir, de perfectionner et de partager leurs connaissances.

C

organisation de formations et de procédures de contrôle d'acquisition de connaissances.

Microsoft Exchange 2000

C Microsoft Exchange 2000 est étroitement intégré dans l'Active Directory de Windows 2000. Vu les besoins d'administration décentralisée de l'EPFL, il est indispensable d'acquérir les connaissances définies dans le cours officiel Microsoft "2307 - Configuration de Microsoft Exchange 2000 pour l'entreprise" d'une durée de 3 jours avant tout déploiement. Le déploiement de Exchange 2000 ne pourra se faire qu'après contrôle que les connaissances de ce cours sont acquises. Les nombreux problèmes rencontrés par tous les administrateurs Exchange de l'EPFL interrogés illustrent cette nécessité de formation.

Important

C organisation d'une structure pour le partage de connaissances (base de connaissances,

mailing list, hot-line, rencontres,

indispensable pour assurer un niveau minimal de service aux utilisateurs.

).

Le bon fonctionnement de cette structure est

Serveur DHCP

C installation de serveurs DHCP pour permettre une attribution dynamique des adresses

IP. Les serveurs DHCP seront installés sur des serveurs membres, mais pas sur des contrôleurs de domaine.

Outils de management du réseau

C dû au nombre important d'ordinateurs et d'utilisateurs, il est indispensable d'implémenter

un outil de management du réseau pour maîtriser la gestion du parc, l'inventaire matériel et logiciel. Les outils permettant cette gestion sont par exemple : prochaine version de

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

Microsoft SMS qui est actuellement en version beta, ZenWorks (Zero Effort Network), HP Open View, Compaq Insight Manager XE,

Convention d'attribution des noms

C convention d'attribution des noms de tous les objets gérés par Active Directory

) en les préfixant par exemple par le

sigle de l'unité organisationnelle (ex : SICServe01, SICCompta,

absolument nécessaire. Il ne faut pas en retarder la mise en place, malgré les modifications organisationnelles planifiées.

Cette convention est

(domaines, OU, ordinateurs, groupes, utilisateurs,

).

Recommandations générales à long terme relatives à la politique de création d'unités organisationnelles en remplacement de domaines enfants la création des domaines enfants permet d’implémenter une stratégie de sécurité différente dans chaque domaine enfant. Il n’y a aucune autre raison pour créer un domaine enfant. Cependant, chaque domaine supplémentaire augmente le travail des administrateurs, rend plus complexe l'ensemble et de ce fait augmente les risques de problèmes. Il est nécessaire de réduire le nombre de domaines au nombre de départements ou facultés. La multiplication des domaines peut être évitée par l'implémentation d'unités d’organisation (OU). Une OU permet de déléguer les droits d'administration à un groupe d'administrateurs et de les rendre pratiquement autonomes par rapport aux administrateurs du domaine. L'implémentation

d'OU implique une formation moins lourde pour ses futurs administrateurs comparée à celle nécessaire pour la gestion d'un domaine. Elle évite par ailleurs l'installation des composants

Un domaine peut contenir

nécessaires à un nouveau domaine (contrôleurs de domaines,

plusieurs OU. Le passage d'un domaine enfant à une OU se fait par déplacement des utilisateurs du domaine dans l'OU d’un autre domaine de la forêt; le domaine devenu inutile est ensuite supprimé. Les administrateurs de chaque domaine supprimé deviendront administrateurs d’une unité d’organisation.

).

C modification de la procédure actuelle de création des domaines enfants :

C

proposer la création d'unités d'organisation (OU) plutôt que de domaines enfants;

C

s'assurer que les administrateurs des éventuels domaines enfants ont les compétences, les moyens et le temps nécessaire à l'administration de leur domaine

C

les privilèges d'administrateur du domaine intranet.epfl.ch ne doivent en aucun cas être accordés aux administrateurs des domaines enfants, et ce, même temporairement. S'il est indispensable pour des raisons de stratégie de sécurité de mots de passe différents, de créer un domaine enfant, les procédures décrites dans l'annexe 2 doivent être utilisées.

C

l'autonomie des facultés est bien comprise. Le besoin de partager des données sur le réseau et d'accéder à des ressources communes implique des règles communes pour tous les partenaires. L'autonomie ne justifie pas automatiquement la création d’un nouveau domaine

C

il faut être conscient que chaque nouveau domaine implique une augmentation des

coûts (personnel système, matériel,

).

Dans ce nouveau modèle, les membres des nouveaux groupes Entreprise Admins et dans une moindre mesure, des groupes Domain Global Groups (par exemple Domain Admins) font l’objet d’un certain niveau de confiance sur tous les domaines de la forêt. Dès lors, un intrus ou compte infiltré dans l’un de ces groupes chevauchant plusieurs limites peut affecter d’autres domaines d'une forêt. Dû au grand nombre de domaines, le groupe Utilisateurs authentifiés doit être considéré comme un groupe peu fiable lors de l’attribution des autorisations sur des ressources. C'est pourquoi nous vous recommandons de placer des entités de grande taille auxquelles on ne peut pas faire une totale confiance (par exemple un domaine créé pour effectuer des tests systèmes visant à chercher les faiblesses du système dans le cadre d'un cours de sécurité informatique) dans des forêts qui leur sont propres, ou de les mettre en œuvre sous la forme de

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

serveurs totalement autonomes.

Politique de délégation de l’autorité d’administration Exchange 2000 La délégation de l’autorité d’administration nécessite l’identification du niveau d’accès et des autorisations nécessaires à un utilisateur devant remplir un rôle administratif. Une fois que vous avez accordé le niveau d’accès approprié, vous pouvez attribuer un rôle administratif en déterminant si l’utilisateur aura besoin de modifier l’objet ou de déléguer des autorisations d’accès de cet objet. Pour plus d’informations sur les niveaux d’autorisations requis pour effectuer des tâches administratives, consultez le livre blanc Microsoft Exchange 2000 Internals : Permissions Guide situé dans le dossier contenant les lectures complémentaires, sur le CDRom du stagiaire du cours Administration de Exchange 2000 dans l’entreprise (Annexe 4).

Administration de groupes Exchange 2000 L’intégration entre une forêt Windows 2000 et une organisation Exchange 2000 est totale. Avant d’activer la messagerie pour un groupe de sécurité, étudiez l’annexe 6. Si dans chaque domaine il existe un groupe avec le nom “Professeurs” par exemple, l’administration sera difficile. Il est extrêmement important de préfixer les groupes avec le sigle du département ou de la faculté, par exemple MAT Professeurs, GC Professeurs, Chimie Professeurs. Si un groupe “Professeurs” doit être créé, il contiendra tous les professeurs de l’EPFL, mais pour éviter de faire des exceptions, même dans ce cas, il faut ajouter au nom du groupe EPFL, par exemple “Professeurs EPFL”

Etablissement de directives à l'attention des administrateurs et des utilisateurs

C

création de directives pour administrateurs : procédures d'installation, de configuration,

d'administration, problèmes connus et leur solution, base de connaissances

C

organisation de formations et de procédures de contrôle d'acquisition de connaissances

C

création de directives à l'attention des utilisateurs pour éviter une utilisation incorrecte du réseau

C

établissement d'un formulaire à signer par l'utilisateur à la demande de création de son compte attestant qu'il a pris connaissance du règlement de l'utilisation du réseau (règles d'utilisation des ordinateurs, des logiciels et des différents services (messagerie, accès

à Internet,

)

et des sanctions éventuelles pour violation de ces dernières)

C

base de connaissance des patches à installer pour assurer la sécurité des serveurs.

Définition de procédure de sauvegarde/restauration

C

pour les contrôleurs de domaine vitaux, les répartir dans 2 bâtiments protégés différents

(salle de serveurs et salle de backup);

C

tous les contrôleurs de domaine et serveurs doivent utiliser les disques miroir;

C

mise en place d'un système de sauvegarde journalier complet, en local, sur des unités

de sauvegarde directement reliées au serveur;

C

définition, organisation, documentation et test régulier de la stratégie de sauvegarde;

C

organisation, documentation, test régulier de la procédure de restauration : la documentation doit contenir également les mots de passe de restauration du service

d'annuaire pour chaque contrôleur de domaine,

;

Une stratégie de sécurité des mots de passe sera définie par domaine

C

définition d'une stratégie de sécurité des mots de passe. Au moins les paramètres suivants doivent être définis :

C

longueur minimale des mots de passe (exemple : 6 caractères);

C

fréquence des changements des mots de passe (exemple : 30 jours).

C

verrouillage des comptes après la 3ème tentative d'accès avec mot de passe incorrect.

C

contrôle de la stratégie de sécurité des mots de passe à l'aide de l'utilitaire SecurityConfigurationEditor.

C

une stratégie de sécurité différente peut être définie pour chaque domaine. Les domaines

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

critiques au niveau de la sécurité doivent utiliser des stratégies adaptées au niveau de sécurité souhaité. Si une stratégie de sécurité commune aux départements ne peut pas être décidée, il est nécessaire de créer plusieurs domaines; chaque domaine a une seule et unique stratégie de sécurité.

Stratégie d'audit

C implémentation d'une stratégie d'audit pour chaque domaine ou chaque OU, par les administrateurs. Les événements à surveiller sont choisis à l'aide de la liste des événements de l'annexe 1. Les fichiers Security.log seront archivés à l’aide de l’outils dumpel.exe du RessourceKit.

Passage de la forêt en mode natif

C passage du 1er domaine en mode natif, puis de tous les autres. Dans un domaine en mode natif, tous les contrôleurs du domaine doivent fonctionner sous Windows 2000. Il n'est plus possible d'exploiter des contrôleurs de domaine tournant sous Windows NT 4.0. Il est toutefois possible d'exploiter des serveurs membres Windows NT 4.0, des stations de travail NT 4.0 Workstation ou Windows 9x. Après le passage en mode natif et le redémarrage de tous les contrôleurs de tous les domaines, l'administration des groupes sera largement facilitée.

Amélioration de l'environnement de l'utilisateur

C implémentation des technologies qui font parties du concept Intellimirror qui permettent

:

C

profil itinérant pour permettre aux utilisateurs de conserver leur profil quelque soit l'ordinateur utilisé;

C

stratégie de redirection des dossiers pour rediriger le dossier "Mes documents" vers le dossier de base de l'utilisateur pour permettre un accès au dossier de base de l'utilisateur quelque soit l'ordinateur utilisé;

C

installation du service d'installation à distance (RIS) pour permettre le déploiement et la réinstallation de tous les ordinateurs;

C

implémentation des stratégies de groupe pour publier ou attribuer les logiciels;

C

implémentation de racines DFS de domaine et réplica pour afficher aux utilisateurs une structure logique qui leur permettra de trouver facilement les ressources réseau, bénéficier d’une balance de charge et tolérance de panne.

3.3 Recommandations pour le domaine intranet.epfl.ch

L'importance stratégique des fonctions demandées aux 2 contrôleurs de ce domaine nécessite de tout mettre en oeuvre pour éviter des interruptions courtes ou prolongées de leur fonctionnement.

Les mesures suivantes sont proposées :

C

installation d'un 3e contrôleur de domaine avec du matériel conçu pour assurer les fonctionnalités d'un serveur;

C

localisation des contrôleurs de domaine dans 2 bâtiments protégés différents (salle de serveurs et salle de backup);

C

mise en oeuvre d'un système de miroir sur tous les contrôleurs de domaine;

C

mise en place d'un système de sauvegarde journalier complet, en local, sur des unités de sauvegarde directement reliées au serveur;

C

définition, organisation, documentation et test régulier de la stratégie de sauvegarde;

C

organisation, documentation, test régulier de la procédure de restauration : la documentation doit contenir également les mots de passe de restauration du service

d'annuaire pour chaque contrôleur de domaine,

;

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

C

organisation du service d'administration des systèmes afin d'assurer la maintenance continuelle (au moins pendant les heures d'ouverture) en affectant plus qu'une personne à la gestion du domaine;

C

documentation claire et structurée de la configuration des contrôleurs de domaine et des

objets gérés (noms de domaines avec coordonnées de leurs responsables,

),

documentation claire et structurée des utilisateurs/groupes avec leurs droits et permissions;

C

surveillance de tous les accès à ce 1er domaine. Nous recommandons de choisir les

événements à auditer à l’aide de la liste de l’annexe 1. Les fichiers security.log doivent être archivés et mis à disposition en consultation pour tous les administrateurs des domaines enfants. Un groupe sera chargé de surveiller que toutes les modifications soient documentées pour faciliter les éventuelles modifications;

C

configuration TCP/IP et documentation des contrôleurs de domaine. Dans les propriétés TCP/IP, l'ordre de recherche DNS doit impérativement être configuré sur tous les contrôleurs du 1er domaine en spécifiant les adresses IP dans le même ordre sur tous les contrôleurs du 1er domaine (ex : 128.172.15.227, 128.178.15.228, 128,

128.172.15.xxx,

).

C

configuration et documentation DNS des contrôleurs du 1er domaine. Dans la boîte de dialogue "Redirecteurs", configurez l'ordre des redirecteurs qui a été défini (ex : 128.178.15.7, 128.178.15.8). Les 2 serveurs DNS UNIX 128.178.15.7 et 128.178.15.8, pour des raisons de sécurité, ne doivent pas permettre la résolution de noms internes aux clients se trouvant à l'extérieur de l'EPFL. Des exceptions à cette règle se feront pour tous les serveurs web qui doivent être accessibles depuis Internet. Selon les spécialistes en sécurité informatique, les contrôleurs du 1er domaine ne doivent pas être autorisés à effectuer des requêtes directement vers Internet. Après l'activation de l'option "ne pas utiliser la récurcivité", en cas de panne des redirecteurs 128.178.15.7 et 128.178.15.8, les contrôleurs de domaine ne feront pas de recherche par eux-même et l'accès à Internet sera impossible. Les 2 serveurs DNS Active Directory seront configurés pour autoriser les transferts de zone uniquement vers les serveurs autorisés. Les 2 serveurs DNS Active Directory accepteront uniquement les mises à jour sécurisées. Créer une zone de recherche inversée. Rendre impossible la résolution des noms des contrôleurs de domaine en adresse IP depuis l'extérieur de l'EPFL. Vérifier qu'aucune délégation n'a été effectuée sur les serveurs 128.178.15.7 et 128.178.15.8 pour la zone intranet.epfl.ch.

C

les administrateurs doivent protéger les ressources par un contrôle des accès efficace. Si nécessaire, les administrateurs doivent protéger les serveurs contre des attaques internes à l'aide de IPSec et Encrypted File System.

3.4 Recommandations pour le domaine servers.intranet.epfl.ch

C

Dans l'immédiat, renforcer la sécurité de la base de données d'annuaire du domaine par l'ajout d'un 3e contrôleur de domaine installé sur un matériel prévu pour assurer les

fonctionnalités d'un serveur (performance, tolérance de panne,

)

C

Les objets des 2 domaines enfants expo.servers.intranet.epfl.ch et metadir.servers.intranet.epfl.ch doivent être déplacés dans des unités d'organisation. Une fois le déplacement effectué, le programme dcpromo permettra de supprimer ces 2

domaines enfants.

C

A terme, servers.intranet.epfl.ch, comme tous les domaines enfants de la forêt, devrait être transformé en une OU dans le domaine intranet.epfl.ch par exemple. Cette OU pourra servir d'exemple d'administration entièrement indépendante à l'intérieur d'un domaine. Ce modèle d'administration sera proposé aux différents départements.

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

3.5 Recommandations pour le domaine sg.intranet.epfl.ch

Eviter toute création de domaines enfants. Tous les services faisant partie des services généraux doivent être implémentés comme des unités d'organisation dans sg.intranet.epfl.ch. A long terme, comme pour tous les domaines de la forêt, il faut étudier la possibilité de consolider toutes les ressources dans un minimum de domaines. La diminution du nombre de domaines doit constituer un exemple pour tous les domaines de la forêt.

3.6 Recommandations générales pour l'implémentation de Microsoft Exchange 2000

Passage du mode de fonctionnement de l’organisation Exchange au mode natif Par défaut, à l'installation de Exchange 2000 Server, le mode d’ opération de l'organisation est en mode mixte. Ce mode permet la prise en compte simultanée de serveurs Exchange 5.x dans la même organisation. Le mode mixte implique des restrictions opératoires de Exchange 2000 Server. Ces restrictions affectent directement l'usage des groupes administratifs en forçant Exchange 2000 Server à gérer les groupes administratifs comme Exchange 5.5 gère les sites. En mode mixte, les possibilités de gestion des boîtes aux lettres sont limitées.

Activation et utilisation du mode d’opération natif En mode natif, Exchange 2000 Server n'est pas soumis aux restrictions impliquées par la cohabitation avec Exchange 5.x. Ce mode permet l'activation du système des groupes de routage et la création d'autres groupes selon les besoins. Par contre, Exchange 2000 Server ne peut plus cohabiter avec les sites Exchange 5.x dans la même organisation. Le service Pack Exchange 2000 est livré avec un outil de migration qui permet de migrer des sites Exchange 5.5 vers l'organisation Exchange 2000 EPFL. Cet outil de migration nécessite que l'organisation Exchange 2000 soit en mode mixte.

Comme il n’y a pas de serveur Exchange 5.x dans l’organisation EPFL, il est conseillé de passer en mode natif. Avec ce mode natif, il est possible, dans certaines conditions, de déplacer un serveur Exchange 2000 d’un groupe administratif vers un autre groupe administratif.

Mises à jour de destinataires dans des environnements multi-domaines S’il existe des objets destinataires avec accès boîte aux lettres ou messagerie dans un domaine où le service de "mise à jour de destinataire" n'est pas configuré, les adresses de messagerie correspondantes ne seront pas générées. Les objets destinataires sans adresse de messagerie ne sont pas affichées dans le carnet d'adresses.

Procédure d'octroi des accès à l'organisation, au groupe administratifs et aux objets de l’organisation Exchange EPFL

C

Octroi de l’accès à des objets Exchange Il n’est pas recommandé d’octroyer un accès à des objets Exchange. Ces accès peuvent devenir difficiles à gérer. Des exceptions sont parfois nécessaires, par exemple : l’accès à une arborescence de dossiers publics peut être octroyé à un responsable qui ne doit pas accéder à d’autres objets de l’organisation Exchange.

C

Octroi de l’accès à des propriétés spécifiques Les administrateurs du groupe administratif ont besoin d’accéder à certaines propriétés

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

d'objets pour modifier plusieurs aspects d’un compte d’utilisateur. Toutefois, dans certains cas, ils ne doivent pas avoir un contrôle total sur ce compte. Dans la configuration de l'EPFL, les administrateurs Exchange des groupes administratifs sont également administrateurs du domaine dans lequel le serveur Exchange est installé. De ce fait, l'octroi de l'accès à des propriétés spécifiques n'est pas recommandé.

Analyse des tâches qui doivent être gérées par les groupes administratifs Lors des entretiens d’audit, les responsables consultés ont appuyé la politique de décentralisation pour répondre aux besoins d’autonomie des différents départements qui doivent être considérés comme des entreprises différentes. L’utilisation de plusieurs domaines à condition de limiter leur nombre au strict nécessaire a l’avantage d’offrir un degré d’autonomie supérieur aux départements en ce qui concerne les stratégies de sécurité mais avec une augmentation des ressources humaines et matériels nécessaires à l’administration du réseau comme décrit dans le rapport d’audit. Exchange 2000 utilise l’Active Directory pour stocker tous les objets Exchange. L’existence de plusieurs domaines n’est pas la condition suffisante garantissant l’autonomie des domaines enfant. L’utilisation des groupes administratifs est obligatoire pour assurer le degré d’autonomie des départements. Chaque département qui utilise Exchange 2000 dispose d’un groupe d'administrateurs qui offre un support technique et une assistance aux utilisateurs de ce département. Pour pouvoir offrir un support efficace à tous les utilisateurs du département, les administrateurs de ces départements ont besoin d’afficher et modifier la configuration des serveurs locaux Exchange 2000. Ils doivent également pouvoir afficher et modifier les propriétés des utilisateurs dans Active Directory. Le bon fonctionnement d’une structure décentralisée nécessite une garantie du maintien des conditions nécessaires à cette structure et un minimum de coordination.

C

Tâches du groupe Administrateurs Exchange Ce groupe Administrateurs Exchange doit impérativement être créé. Il aura la responsabilité d’implémenter les autorisations nécessaires pour permettre une totale autonomie d’administration des départements. Un minimum de coordination entre les départements sera nécessaire pour établir les besoins de ces départements et informer les éventuels futurs administrateurs de leurs responsabilités.

Les domaines enfants ou les serveurs Exchange plus utilisés et non désinstallés selon les procédures définies par Microsoft, affectent la sécurité et l'intégrité du réseau et contraignent les administrateurs du domaine racine à des procédures longues et laborieuses pour restaurer l'intégrité du réseau. Les départements ou services qui installent de manière non justifiée des domaines enfant ou des serveurs Exchange, pour administrer un faible nombre d'utilisateurs (par exemple moins de 10) et/ou pour une courte durée (par exemple une semaine) et qui ne prennent pas les mesures nécessaires pour désinstaller correctement les domaines lorsqu'ils n'en n'ont plus besoin n’auront plus le droit d’administrer leur propre domaine à l'intérieur de la forêt intranet.epfl.ch avant d’avoir prouvé qu’ils ont les compétences et le temps nécessaires pour mener à bien leur tâche.

C

Tâches de l'administrateur du département (domaine enfant) Les administrateurs d’un groupe administratif doivent avoir le droit Administrateur intégral Exchange au niveau de leur groupe administratif. Ils doivent pouvoir effectuer toutes les opérations nécessaires au bon fonctionnement des objets situés dans leur groupe administratif y inclus la délégation des tâches administratives. Ils ne seront pas autorisés à modifier les objets présents dans d’autres groupes administratives. Ils seront chargés de la responsabilité de l’administration des utilisateurs et des boîtes aux lettres d'utilisateur et de gérer les stratégies de serveur et de banque des boîtes aux lettres. Chaque administrateur d’un groupe administratif doit créer et appliquer les stratégies

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

uniquement aux serveurs présents dans son propre groupe administratif. Ils doivent également pouvoir créer et administrer des arborescences et des dossiers publiques.

C

Utilisation des groupes administratifs Chaque serveur Exchange installé par les administrateurs d’un domaine enfant sera installé dans un groupe administratif distinct avec un nom identique au nom du domaine enfant conformément à la stratégie de nommage décidée, ce qui permet de mieux identifier les responsabilités. Les administrateurs des domaines enfants peuvent décider de déléguer certaines tâches d'administration à un autre groupe. Pour faciliter l’administration, ces tâches doivent être attribuées aux groupes et non directement aux comptes individuels.

C

Formation des utilisateurs Les utilisateurs doivent être formés à l’utilisation du réseau et du système de messagerie pour éviter les abus.

C

Configuration des groupes administratifs Lorsque plusieurs groupes d’administrateurs sont autorisés à effectuer diverses fonctions, il peut arriver que certains administrateurs procèdent à des modifications de configuration sur des objets qu’ils ne doivent pas modifier. Pour éviter cela, les groupes administratifs peuvent être configurés pour que des rôles différents soient attribués aux différents administrateurs selon les directives de l’annexe 4 de l’audit.

C

Implémentation de l’archivage des messages L’archivage des messages permet de dédier une boîte aux lettres spécifique à la réception de tous les messages traités par des serveurs sur lesquels la fonction d’archivage est activée. Une stratégie sur ce serveur peut être définie pour spécifier la boîte aux lettres dans laquelle les messages doivent être archivés.

C

Configuration des autorisations des dossiers de premier niveau Etant donné que la hiérarchie de tous les dossiers de premier niveau est répliquée dans l’intégralité d’une organisation Exchange 2000, des autorisations de dossiers de niveau supérieur doivent être configurées pour :

C

empêcher les utilisateurs de créer des dossiers publics à la racine de la hiérarchie des dossiers MAPI

C

permettre le contrôle de la croissance et de la complexité de votre hiérarchie de dossiers.

C

Recommandations pour le renforcement de la sécurité face aux attaques extrêmes

C

Protection contre les virus :

 

Antivirus pour Exchange Planification et vérification de la mise à jour des antivirus.

 

C

Vérification des messages entrants à la recherche de pièces jointes .vbs, .bat, .exe,

C

Protection des boîtes aux lettres et de leur contenu

C

Application des dernièrs patchs de sécurité disponibles sur le site de Microsoft. Consultation des sites spécialisés sur les problèmes de sécurité comme www.ntsecurity.net.

C

Utilisation de serveurs ponts et de groupes de routage pour renforcer la sécurité.

C

Protection des ports

C

Organisation des sauvegardes des données Exchange 2000

C

Utilisation d’une forêt de backup pour tester les sauvegardes

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

L’utilisation d’une forêt de backup est recommandée pour tester les sauvegardes et pour diminuer l’intervalle de l’indisponibilité des services Exchange en cas de pannes.

C

Conclusion

Il est nécessaire de créer un groupe d’administrateurs et de nommer les responsables de la coordination interdépartementale. Les taches à accomplir seront :

C

assurer le minimum de coordination nécessaire entre les départements pour le bon fonctionnement du réseau.

C

établir des règles communes nécessaires au fonctionnement du réseau

C

décider une convention de nommage.

C

accorder les autorisations nécessaires permettant aux administrateurs des domaines enfants d’administrer les objets qui se trouvent dans leurs domaines y inclus les serveurs Exchange sans interférence avec les autres domaines.

C

documenter les autorisations accordées.

C

s'assurer, par un audit continuel, que les autorisations accordées permettent d’assurer la disponibilité, l’intégrité et la confidentialité des données qui se trouvent sous la responsabilité des administrateurs des départements.

C

apporter le soutien aux administrateurs des départements pour réaliser les objectifs définis.

Les décisions nécessaires à l'implémentation de l'Active Directory doivent être prise au plus haut niveau de la hiérarchie de l'EPFL et ce au plus vite. Si décisions ne pourraient être prise dans rapidement, les 2 alternatives suivantes peuvent être mise en place pour éviter le compromettre l'intégrité et la sécurité des données :

C

Administrer tous les serveurs Exchange d’une façon centralisée dans un seul et unique groupe administratif par un seul groupe d’administrateurs responsables du bon fonctionnement de la messagerie. Interdire l'installation des serveurs Exchange dans les domaines enfants. Cette solution est la plus rationnelle d'un point de vue économique. Elle ne nécessite que 2 personnes à plein temps. Une solution décentralisée nécessite 2 personnes pour le premier groupe administratif et également 2 personnes pour chaque groupe administratif supplémentaire. L'emplacement des serveurs Exchange dans les locaux du SIC présente les meilleures conditions pour garantir l'intégrité, la disponibilité et la sécurité des données.

C

Créer une forêt séparée pour la messagerie. Les inconvénients de cette solution sont les suivants :

C

augmentation importante du travail d’administration et des ressources matériels L’installation de plusieurs organisations Exchange nécessite une synchronisation. En effet, les destinataires situés dans les autres forêts ne représentent pas des entités de sécurité dans la forêt locale et doivent être maintenus en tant que contacts. L’agent de gestion Active Directory de Microsoft Metadirectory Services 2.2 peut être utilisé pour créer directement une copie miroir du contenu d’une forêt Windows 2000. MMS permet de filtrer et de mapper les attributs pour la synchronisation.

C

diminution des fonctionnalités Les fonctionnalités suivantes ne sont pas disponibles dans un environnement multi-forêts :

C

accès aux dossiers publics

C

accès aux informations de disponibilité et d'occupation du calendrier

C

accès aux autres carnets de rendez-vous des utilisateurs

C

services de conférence et la messagerie instantanée

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

C

autres restrictions au niveau de la délégation des autorisations et de l'accès aux applications

C

l'attribution des autorisations aux contacts Active Directory, car ils ne constituent pas des entités de sécurité (ils ne sont pas utilisateurs). Cela diffère d'Exchange 5.5 qui mettait en oeuvre son propre modèle de sécurité. Même si l'intégration Web renforcée peut résoudre certaines restrictions au niveau de la visibilité, elle risque de compromettre la sécurité.

3.7 Introduction aux annexes

Les annexes ci-jointes sont :

C

des réponses à des questions soulevées pendant l’étude de la configuration EPFL

C

des réponses à des problèmes qui risquent de se poser à très court terme.

Ces informations techniques doivent être mises à disposition des administrateurs après adaptation et test.

Ces annexes sont extraites des supports de cours ISEIG et leur utilisation nécessite les connaissances dispensées dans les cours Administration de l'Active Directory et Configuration de Microsoft Exchange 2000 pour l’entreprise. Ces connaissances sont indispensables pour administrer le réseau de l'EPFL.

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

Annexe 1 - Liste des événements à auditer

Audit account logon events: (track local logon events on your server ou worksfation)

672

Authentication ticket granted

673

Service ticket granted

674

Ticket granted renewed

675

Preauthentication failed

676

Authentication ticket request failed

677

Service ticket request failed

680

Account used for logon

681

NTLM authentication request failed

Audit account management

624

User object created

630

User object deleted

631

Global group added

632

Member added to Global group

633

Member removed from Global group

634

Global group deleted

635

Local group added

636

Member added to Local group

637

Member removed from Local group

638

Local group deleted

639

Local group changed

641

Global group changed

642

User object changed

644

User account locked out

645

Computer object added

646

Computer object changed

647

Computer object deleted

658

Universal group added

659

Universal group changed

660

Member added to Universal group

661

Member removed from Universal group

662

Universal group deleted

668

Group type changed

Audit directory service access

565 Information about accessed objects in AD

Audit logon events (authentication on DC or user connects to a server over the network)

528

Successful logon

529

Failed logon (unknown username or bad password)

530

Failed logon (account logon time restriction violation)

531

Failed logon (account disabled)

532

Failed logon (account expired)

533

Failed logon (user not permitted to Iog on at machine)

534

Failed logon (user hasn't been granted requested logon type at machine>

535

Failed logon (password expired)

537

Failed logon (unspecified error)

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

538 Successful Iogoff

539 Failed logon (account Iocked out)

540 Successful network logon

Account object access

560 Object opened (Ouverture d’un fichier – security.log de la machine ou le fichier se

trouve)

562 Handle closed

Audit policy change

608

User right assigned

609

User right removed

610

New trusted domain

611

Removing trusted domain

612

Audit policy change

615

IPSec policy changed (Event Viewer Iists this event under the Audit process tracking category)

616

IPSec poIicy agent encountered a potentially serious failure (Event Viewer lists this event under the Audit process tracking category)

617

Kerberos policv changed

618

Encrypted data recovery policy changed

620

Trusted domain information modified

Audit privilege use (More than 34 user rights exists)

576 Special privileges assigned to new logon

577 Privileged service called

578 Privileged object operation

Audit process tracking

592 New process has been created. ( Lancement d’une application – security.log sur la machine ou l’application a été lancé) Windows 2000 utilise 10 digit process ID

593 A process has exited ( Fermeture d’une application – security.log sur la machine ou l’application a été fermé). Windows 2000 utilise 3 ou 4 digit process ID

Audit system events

512

Windows NT is starting up. (comparez avec le dernier évent pour obtenir la période d’interruption

513

Windows NT is shutting down (WIn2K doesn’t log this event accurately)

514

Authentication package has been loaded by the Local Security Authority (LSA)

515

Trusted logon process has registered with the LSA

517

Audit log was cleared

518

The SAM has Ioaded a notification package

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

Annexe 2 - Procédure de Pré-Creation d’un Child Domain

The central administrators group of intranet.epfl.ch (the root administrator, specifically) also

is responsible for pre-creating subordinate domains across the tree/forest. By performing this

preparatory work, the group can control domain naming conventions, the purpose of the domain, and who will administer the domains. The central group has several options. It can build and configure the child domain controllers at a staging location managed by the central

office and then ship them to their destinations. It can install Terminal Services on the server and allow a group within the central office to connect over the network and execute the DCPROMO process. These alternatives do not require any changes to the Active Directory default configuration. They also provide a way to maintain a high level of control over the Administrator' s accounts in the various child domains, while delegating the day-to-day tasks

to other user accounts; this is an advantage but these methods may not meet the needs of

many decentralized IT organizations.

The group has a third alternative: it can pre-create a cross-reference for the child domain in the root forest, then set the appropriate ACLs on the Schema, Configuration, and Domain naming contexts to allow a non-administrative account to execute DCPROMO. This requires an Enterprise Administrator in the root domain to create a cross-reference object to the child domain. This object ties together LDAP referrals that span the forest. The child administrator then must use the credentials of a user in a special group in the root to execute DCPROMO. This approach, which requires changing the Active Directory ACL structure, granting a non-Domain Administrator account privileges to complete the process, allows you to delegate the DCPROMO process but requires the procedure below to prepare the root domain.

Warning: The processes below require you to edit Active Directory internals. Before you change anything, make sure you understand how to restore it if a problem occurs.

Root Domain Preparation for Delegation of Child Domain Creation To delegate the DCPROMO process for the creation of child domains, you have to:

1. Create a group for the sole purpose of running DCPROMO (to create the first domain controller in the new child domain).

2. Use this group to create appropriate privileges (on an ACL) for the appropriate Active Directory objects. These steps, which you perform only once, are discussed in the remainder of this section. (Four steps are required to create a child domain. They are discussed in the next section.)

The first step in delegating any task is to identify which user or set of users will be given permissions to perform it. You can simplify long-term administration by identifying a group then adding users to it as needed. This method allows you to apply all ACL changes to objects using the group instead of to individual users. For example, create a Domain Creators Group

in the root domain and add the account Dcreator1. The account will later be used to run

DCPROMO. To allow a child administrator to join the tree/forest without any administrative rights on the root, the root administrator must make changes to the Schema, Configuration, and Domain naming contexts

A number of the ACL changes rely on the use of a Well-Known SID group, Creator Owner,

that allows you to transfer object permissions to groups when they create new objects. For example, a user account has Create privileges on an object and the Creator Owner Group is given full rights to that object. When the object is created, Creator Owner Group's full rights are transferred to the user account that created the object. One of the side effects of using this approach is that you may not want the user account that created the object to be its owner. Once the object is created, you can remove all rights from the account that created the object

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

and allow some other account to take ownership of it.

The Schema and Configuration naming contexts are shared across the Active Directory tree/forest, so the Domain Creators Group must have the rights to read and replicate their contents. Grant the following permissions to the Domain Creators Group on both the Configuration (cn=Configuration,,dc=iseig,dc=ch) and Schema (cn=Schema dc=iseig,dc=ch) containers:

• Read

• Manage Replication Topology

• Replicating Directory Changes

• Replication Synchronization

The Default-First-Site is the first site in the tree/forest. New servers are assigned to it whenever their TCP/IP subnet is not assigned to an existing site. The Domain Creators group must have permission to create a new server in the Default-First-Site. These permissions are applied to the Default-First-Site container:

• Add the Domain Creators Group and give it rights to Read and Create child objects for THIS OBJECT AND ALL CHILD OBJECTS.

• Add the Creator Owner Group and give it Full Control for THIS OBJECT AND ALL CHILD OBJECTS.

If the root administrator also wants to control the site creation process, you have to create a new site where the child domain server will reside. To register the server in the proper location, you would also have to add the server's subnet and associate it with the new site (the site has no meaning without a subnet). Then the root administrator needs to grant the two permissions above to the new site.

This gives the Domain Creators group permission to replicate the Configuration and Schema information and to create a new server in the appropriate site.

Child Domain Creation Now that the root domain is prepared, perform these steps to create each child domain:

1. Create a cross-reference object for the new domain.

2. Set the Access Control List (ACL) on the appropriate objects.

3. Perform the DCPROMO process.

4. Grant full control of the new DC to the Domain Administrators of the new child domain.

To create a cross-reference object for the child domain, use the command line utility NTDSUTIL. You have to be logged on to the root domain with an account that has Enterprise Administrative rights, and when you specify the cross-reference to the child domain you must use the NetBIOS name of the child domain in UPPER CASE. Here are the steps required to pre-create the child domain cross-reference, HB-RES where server2.HB-RES.ISEIG.CH is the first server in that domain.

1. NTDSUTIL

2. Type Domain Management

3. Type Connections

4. Type Connect to Server SERVER1.ISEIG.CH

5. Type quit

6. Type precreate dc=HB-RES,dc=iseig,dc=ch server2.hb-res.iseig.ch

After you create the cross-reference you have to give the Domain Creators Group permission

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

to access the information. Locate the new cross-reference in the Partitions container within the Configuration-naming context, then set the permissions. Add the Domain Creators Group and give it Full Control on the object.

Active Directory uses Kerberos transitive trusts between the domains within the tree/forest. The trust objects reside in the system container within the Domain naming context of the parent domain, so you have to allow the Domain Creators Group to create a trust object for the child domain that is being promoted.

1. Add the Domain Creators Group to the System container under the Domain naming context and give the group the rights to Read and Create child objects privileges. 2. Add the Creator Owner Group and give it Full Control privileges.

The last preparatory step is to make sure the server where DCPROMO will be executed from is properly registered with DNS. Under the properties of 'My Computer' you will find a dialog box for the primary DNS suffix. Verify that it contains the Fully Qualified Domain Name (FQDN) of the new child domain. In addition you can use the DNS NSLOOKUP command to verify that the server host record (A) exists.

Now the local administrator on the member server can start DCPROMO. The DCPROMO wizard prompts for credentials under which it should execute and these should be an account that is a member of the Domain Creators Group (for example, dcreator1). After completing DCPROMO, the root administrator must grant full control permissions to the child domain administrators group on the new domain controller; this allows the child domain administrator to take ownership of the server and install additional domain controllers or other resources without having to involve the root forest administrator.

By default the Enterprise Administrator group will have permissions to the child domain. To control the level of access the members of the root administrators have over the child domain’s naming context, the child domain administrator can remove the Enterprise Administrator group from having any permissions over the dc=hb-res, dc=iseig,dc=ch object.

At this stage, the child domain administrators cannot create sites, subnets, site links, or other associated objects: the root administrator has to perform these tasks, or delegate them to a separate group or to the individual child domain administrators (discussed in the “Site Management” section, below).

Create Replica Domain Controllers It often is necessary to delegate the creation of additional domain controllers to another group or a third party. in which case you normally give them a user account without administrative rights on the domain, so they can complete the process without affecting any of the other servers.

As with delegating child domain creation, the recommended procedure is to create a group for this process, then add members to it as necessary. The server will hold a copy of the Domain naming context, so you have to allow this group the right to replicate it as well as the Configuration and Schema naming contexts (dc=hb-res, dc=iseig,dc=ch):

• Read

• Add/Remove Replica in Domain (Domain Naming context only)

• Manage Replication Topology

• Replicating Directory Changes

• Replication Synchronization

Since the process for promoting a domain controller requires an authenticated domain

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

account, the server must join the domain before it is promoted. This allows you to use an authenticated domain account and to use group policies, which make delegation easier.

The group you delegate the DCPROMO process to must be able to log on locally to the server to start it, so make this group a member of the Machine Local Administrators group. Also, use the Group Policy object in the Domain Controllers container to give the group the right to log on locally and to enable computer and user accounts to be trusted for delegation.

Because DCPROMO changes the properties of the server object in the Domain naming context, you have to give this group permission to Read and Write to the server object. One step in the promotion process is to move the server object from the Computers container to the Domain Controllers container. This requires administrative rights, so you need to move the object before it is promoted.

The final step is to allow the group to create the server object in the configuration container, so the domain controller is advertised across the tree/forest and link topology generator can create the appropriate number of replication links. Give the group the permission to create a new server in the site where it is located:

• Give the group rights to Read and Create child objects for THIS OBJECT AND ALL CHILD OBJECTS.

• Add the Creator Owner Group and give it Full Control for THIS OBJECT AND ALL CHILD OBJECTS.

Grandchild Domain Creation The process of delegating grandchild domain creation is similar to the process for child domains, but it requires coordinated efforts between the administrators of the root forest and the child domain. At the root domain, you must create the cross-reference object and give Full Control to the Domain Creators Group, just as you do when you pre-create a child domain. The Domain Creators Group already has proper permissions for the various objects in the schema and configuration naming contexts. Because the Kerberos trust is established between a child and its parent domain, you have to give the Domain Creators Group permission to create the trust object in its parent's domain naming context. When you create a child domain, you give permission in the root Domain naming context because the root is the child domain's parent. Now you have to grant permission in the system container in the child Domain naming context because it is the grandchild's parent.

DHCP et RIS Authorization To prevent rogue DHCP servers from assigning TCP/IP addresses to clients across the domain, you must register them before they are allowed to operate. By default only the Domain Administrators Group in the root domain is authorized to do this, but in a decentralized environment it is not practical for child domain administrators to contact the root administrator every time a DHCP server needs to be authorized To allow the child domain DHCP Administrators Group to authorize DHCP servers set these ACLs on the NetServices container (CN=NetServices,CN=Services,CN=Configuration,DC=mycompany,DC=ch):

• Give the child Domain DHCP Admin Group the rights to Read, Write, and Create child objects for THIS OBJECT ONLY.

• Add the Creator Owner Group and give it Full Control for THIS OBJECT ONLY

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

Annexe 3 - Etablissement d'une stratégie de sécurité des comptes et contrôle de son application

Cette annexe définit la procédure de mise en place d'une stratégie de mot de passe et de compte en utilisant des modèles de sécurité.

Création d'un modèle de stratégie de mots de passe

1. Ouvrir la console

2. Ajouter/supprimer des composants logiciels enfichables

3. Ajouter le composant enfichable Modèles de sécurité. (Security Templates)

4. Dans la console, faire un clic droit sur %Svstemroot %\Security\Templates puis effectuer un clic droit, Nouveau modèle

5. Sous Nom du modèle, taper : «stratégie de comptes epfl» et bouton OK, Stratégie de verrouillage du compte

6. Développer le modèle - Stratégie de comptes epfl

7. Stratégie de comptes et définir les paramètres décidés

Application du modèle de stratégie de compte epfl

1. Lancer la console

2. Dans la console Utilisateurs et ordinateurs Active Directory, faire un clic droit sur le nom du domaine, clic sur Propriétés puis onglet Stratégie de groupe

3. Modifier la stratégie existante : Default Domain Policy. Il y a une seule et unique Stratégie de comptes pour un domaine

4. Développer Configuration ordinateur (Computer configuration)

5. Paramètres Windows (Windows Settings) et

6. clic droit sur Paramètres de sécurité (Security Settings)

7. Clic sur Importer une stratégie

8. Sélectionner la stratégie (stratégie de compte) et clic sur le bouton Ouvrir

9. Fermer la fenêtre de stratégie de groupe ainsi que la fenêtre des propriétés du domaine

10. Fermer la console Utilisateurs et ordinateurs Active Directory.

11. Entrer la commande : secedit /refreshpolicy machine_policy /enforce et dans Sites et services Active Directory : Répliquer

Analyse de la sécurité à effectuer régulièrement

1. Ajouter le composant enfichable Configuration et analyse de la sécurité (Security Configuration and Analysis)

2. Dans la console, clic droit sur Configuration et analyse de la sécurité puis clic sur Ouvrir une base de données

3. Donner un nom au fichier de base de données qui stockera le résultat de l'analyse puis clic sur le bouton Ouvrir

4. Sélectionner le modèle de sécurité à analyser (par exemple Stratégie de comptes de epfl) puis clic sur le bouton Ouvrir

5. Pour lancer l'analyse, clic droit sur Configuration et analyse de la sécurité, puis clic sur

Analyser l'ordinateur maintenant

,

Chemin… Confirmez

6. Une fois l'analyse terminée, développer chaque point de la stratégie pour vérifier si les paramètres de la colonne Paramètres de base de données correspondent à ceux de la colonne Paramètre ordinateur

7. Si des différences sont constatées, consulter le journal d'audit pour connaître qui a modifié les paramètres par défaut et prendre les mesures qui s'imposent. Clic droit sur Configuration et analyse de la sécurité et clic sur : Configurer l'ordinateur maintenant pour revenir aux paramètres implémentés dans le modèle

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt

Audit de l'infrastructure Microsoft Active Directory (domaine SG) et de son intégration dans la forêt intranet.epfl.ch - version 01.01

Annexe 4 - Permissions required for Installation and management of Microsoft Exchange 2000

Introduction

This white paper describes the minimum permissions required for the installation and management of Microsoft® Exchange 2000 Server.

Please note that you might not need to explicitly set the roles outlined in this document to perform the desired action, as roles can be supersets.

For example, at the administrative group level:

• Exchange Administrator includes Exchange View Only Administrator

• Exchange Full Administrator includes both Exchange Administrator and Exchange View Only Administrator

Additionally, at the organization level:

• Exchange View Only Administrator includes Exchange View Only Administrator at the administrative group level

• Exchange Administrator includes Exchange View Only Administrator at the organization level as well as Exchange Administrator and Exchange View Only Administrator at the administrative group level

• Exchange Full Administrator includes all other permissions at both the organization and administrative group levels

The following table displays a graphical representation of the effective permissions versus the granted permissions.

Effective Permissions (right) versus Granted Permissions (below)

AG:

AG:

AG: Full

ORG:

ORG:

ORG:

View

Admin

Admin

View

Admin

Full

Admin

AG: Exchange View Only Administrator

Yes*

         

AG: Exchange

Yes*

Yes*

       

Administrator

AG: Exchange Full Administrator

Yes*

Yes*

Yes*

     

ORG: Exchange View Only Administrator

Yes

   

Yes