Вы находитесь на странице: 1из 61

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

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

Version 01.01 27 août 2001 (10h36) Page 2/61


EPFL_Audit_010817.wpd
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;
• l'organisation à mettre en place (personnel, procédures, ...) pour faire face à d'éventuelles
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

Version 01.01 27 août 2001 (10h36) Page 3/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 4/61


EPFL_Audit_010817.wpd
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.

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

Version 01.01 27 août 2001 (10h36) Page 5/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 6/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 7/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 8/61


EPFL_Audit_010817.wpd
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 lanos.dcs- 1 DC
group lanos.intranet.epfl.ch
First Administrative Sicsrv1.serveurs.intran
group et.epfl.ch
First Administrative Verseur
group
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 :

Version 01.01 27 août 2001 (10h36) Page 9/61


EPFL_Audit_010817.wpd
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.

Version 01.01 27 août 2001 (10h36) Page 10/61


EPFL_Audit_010817.wpd
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, ...). Le bon fonctionnement de cette structure est
indispensable pour assurer un niveau minimal de service aux utilisateurs.

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

Version 01.01 27 août 2001 (10h36) Page 11/61


EPFL_Audit_010817.wpd
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
(domaines, OU, ordinateurs, groupes, utilisateurs, ...) en les préfixant par exemple par le
sigle de l'unité organisationnelle (ex : SICServe01, SICCompta, ...). Cette convention est
absolument nécessaire. Il ne faut pas en retarder la mise en place, malgré les
modifications organisationnelles planifiées.

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
nécessaires à un nouveau domaine (contrôleurs de domaines, ...). Un domaine peut contenir
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

Version 01.01 27 août 2001 (10h36) Page 12/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 13/61


EPFL_Audit_010817.wpd
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, ...;

Version 01.01 27 août 2001 (10h36) Page 14/61


EPFL_Audit_010817.wpd
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.

Version 01.01 27 août 2001 (10h36) Page 15/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 16/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 17/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 18/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 19/61


EPFL_Audit_010817.wpd
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.

Version 01.01 27 août 2001 (10h36) Page 20/61


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

Version 01.01 27 août 2001 (10h36) Page 21/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 22/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 23/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 24/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 25/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 26/61


EPFL_Audit_010817.wpd
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

Version 01.01 27 août 2001 (10h36) Page 27/61


EPFL_Audit_010817.wpd
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 AG: AG: AG: Full ORG: ORG: ORG:


(right) versus Granted View Admin Admin View Admin Full
Permissions (below) Admin
AG: Exchange View Yes*
Only Administrator
AG: Exchange Yes* Yes*
Administrator
AG: Exchange Full Yes* Yes* Yes*
Administrator
ORG: Exchange View Yes Yes
Only Administrator
ORG: Exchange Yes Yes Yes Yes
Administrator
ORG: Exchange Full Yes Yes Yes Yes Yes Yes
Administrator
Key:
* = Local administrative group only
AG = Administrative group level
ORG = Organization level

For more information on the permissions granted to these roles, see Appendix B.

Version 01.01 27 août 2001 (10h36) Page 28/61


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

Active Directory Connector


What permissions do I need to install the first Active Directory Connector (ADC) in my
Microsoft Windows® 2000 Active Directory forest?

To install the first Active Directory Connector (ADC), you will need to update the schema of
the Active Directory service as well as copy the binaries across to the local computer.
Therefore, you will need to be logged on as a user with the following Active Directory
permissions:

• Schema Admins
• Enterprise Admins
• Member of the local administrators group on the destination computer

As an alternative, an administrator in the Schema Admins group can use the /SchemaOnly
switch with the ADC setup program to make the additions to Active Directory. In this scenario,
the person who actually installs the ADC service does not need to be a member of the
Schema Admins group. An advantage to this method is that, if a company has very strict
control over the schema, these people can make the schema adjustments required, and the
ADC/Exchange administrator can perform his or her job independently.

What permissions do I need to install subsequent Active Directory Connector servers into my
Active Directory forest?

Because the schema has already been updated, you will need the following Active Directory
permissions to install additional ADCs:

• Enterprise Admins
• Member of the local Administrators group on the target machine

When installing the Active Directory Connector, I need to enter a service account. Why is this
required when Exchange 2000 services start as LocalSystem? What permissions will the
service account require?

The ADC requires a service account because a subset of the ADC technology is shipped with
the Windows 2000 operating system. Exchange 2000 has features to prepare the Active
Directory forest and domains for installation of the server (with the use of ForestPrep and
DomainPrep). Part of this preparation involves setting permissions for LocalSystem services
to Active Directory. As the ADC can be used without Exchange 2000 installed, a separate
service account is used to achieve the same functionality.

The ADC service account requires the following permissions:

• Member of the builtin Administrators group


• Member of Enterprise Admins if the ADC is used in a Windows 2000–based environment
without Exchange 2000
• Either a member of the Enterprise Admins group or have the role of Exchange Full
Administrator if the ADC is used with Exchange 2000 and not just Windows 2000

When I create a Connection Agreement in the Active Directory Connector, I need to specify
the credentials for accessing Active Directory and Exchange 5.5 Directory Service. What
permissions does this account need?

The permissions that you need are:

Version 01.01 27 août 2001 (10h36) Page 29/61


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

• Exchange 5.5
• Admin role to the Exchange 5.5 site naming context
• Admin role to the Exchange 5.5 organization naming context
• Active Directory
• Domain Admins (of the local domain)
• Exchange View Only Administrator role to the Exchange 2000 organization

Version 01.01 27 août 2001 (10h36) Page 30/61


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

Exchange 2000
What permissions do I need to run the /ForestPrep switch for Exchange 2000 Setup?

ForestPrep will update the Active Directory schema and create the Exchange organization
object. Additionally, you will be given the opportunity to specify the first Exchange 2000
administrator (this administrator can be a user or group object). To log on to Active Directory,
you will need to be a user with the following permissions:

• Schema Admins
• Enterprise Admins

ForestPrep must be run in the domain that contains the Active Directory Schema Master. By
default, this domain will be the root domain in the forest.

If I choose to join an existing Exchange 5.5 organization during ForestPrep, what permissions
do I need on the Exchange 5.5 organization?

You will need the following permissions:

• Admin role to the Exchange 5.5 site naming context (for the site that you’re joining)
• Admin role to the Exchange 5.5 configuration naming context (for the site that you’re
joining)

Additionally, you will need to know the service account name and password for the site that
relates to the server that you specify. If the Exchange 5.5 service account is in a Microsoft
Windows NT® 4.0 domain, you will need to create a one-way trust from the forest root domain
to the domain that contains the Exchange 5.5 service account.

What permissions do I need to run the /DomainPrep switch for Exchange 2000 SETUP?

DomainPrep will create an Exchange Domain Servers global group, an Exchange Enterprise
Servers local group, and seed (or configure) the permissions so that the Exchange server can
access Active Directory. To run DomainPrep, you must be logged on as a user with the
following permission:

• Domain Admins (of the local domain)

What function do the Exchange Domain Servers and Exchange Enterprise Servers groups
perform?

Both of these groups are created through DomainPrep. They reside in the Users container in
the domain and must not be moved or renamed. Each time Exchange 2000 is installed on a
computer, the computer account is added to the local Exchange Domain Servers global
security group. In turn, this group is a member of the Exchange Enterprise Servers local
security group in each domain. The Recipient Update Service is responsible for ensuring that
all Exchange group nestings are complete within the forest. The Exchange Enterprise Servers
group is given various permissions on the domain naming context in the Active Directory.
Through these inherited permissions, the Recipient Update Service is able to modify
Exchange-specific attributes on domain accounts.

What permissions do I need to install my first Exchange 2000 server?

To install your first Exchange 2000 server, you will need to be logged on to the Active
Directory with the following permissions:

Version 01.01 27 août 2001 (10h36) Page 31/61


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

• Exchange Full Administrator role (which was defined during ForestPrep)


• Member of the local administrative group on the destination computer

Additionally, if you are joining an existing Exchange 5.5 site, the logged on account must have
the following permissions to access the Exchange 5.5 directory, and the person installing
Exchange must know the Site Services account name and password:

• Admin role in the site naming context


• Admin role in the configuration naming context

How do I delegate permissions to other users so that they can manage Exchange 2000?

To delegate permissions to other users, use the Exchange Administration Delegation Wizard.
You will need to be logged on as a user with the Exchange Full Administrator role to the
organization to use the Exchange Administration Delegation Wizard.

To use the Exchange Administration Delegation Wizard, start the Exchange System Manager,
right-click the organization or administrative group, and then click Delegate Control.

If I move the Exchange 2000 computer accounts to a different organizational unit in Active
Directory, will this affect my Exchange permissions and delegation?

No, the Exchange Administration Delegation Wizard assigns permissions in the configuration
naming context of the Active Directory, not the domain naming context (which is where the
computer accounts reside).

What is the difference between the Exchange Full Administrator and the Exchange
Administrator roles?

An Exchange Full Administrator is able to manipulate any Exchange object in the configuration
naming context. Additionally, full administrators have permissions to modify the settings on
the Security tab on the following objects:

• Exchange databases
• MAPI and application folder hierarchies
• Address lists

An Exchange Administrator can manipulate any Exchange object, but will not have the ability
to delegate permissions or change the settings on the Security tab on the Exchange objects
listed above.

If I grant a user or group permissions at the Exchange organization level, do these


automatically flow down to all administrative groups?

Yes. Unlike Exchange Server 5.5, Exchange 2000 permissions are inherited.

What permissions do I need to install subsequent Exchange 2000 servers?

To install subsequent servers, you will need to be logged on to the Active Directory with the
following permissions:

• Either as Exchange Full Administrator (as defined during ForestPrep) or as a delegated


Exchange Full Administrator at the organization level
• Member of the local administrative group on the destination computer

Version 01.01 27 août 2001 (10h36) Page 32/61


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

What permissions do I need to install Exchange 2000 in a cluster configuration?

You should install the server software and create the System Attendant resource by logging
on to the Active Directory as the Cluster service account. This account will also need the
following permissions:

• Either as Exchange Full Administrator (as defined during ForestPrep) or as a delegated


Exchange Full Administrator at the organization level
• Member of the local Administrators group on both nodes

What permissions do I need to upgrade an Exchange 5.5 server to Exchange 2000?

The Exchange 5.5 server must be installed on a computer running Windows 2000 in an Active
Directory domain. You will need to be logged on to the Active Directory as a user who has the
following permissions:

• Exchange 5.5
• Admin role to the Exchange organization naming context
• Admin role to the Exchange site naming context
• Admin role to the Exchange configuration naming context
• Active Directory
• Either as Exchange Full Administrator (as defined during ForestPrep) or as a delegated
Exchange Full Administrator at the Organization level
• Member of the local Administrators group on the destination computer

I have a third-party messaging application that requires full access to each user’s mailbox.
With Exchange 5.5, we grant a special account Service Account Admin permissions, and then
tell the application to use this account. How can I achieve similar functionality in Exchange
2000?

Exchange 2000 security works very differently from that of Exchange 5.5. In fact, Exchange
2000 does not use a site service account; instead, all services start as the local computer
account.

There are a few different ways to get the desired effect. One of the easiest ways is to make
your special application account a member of the Exchange Domain Servers groups (in any
domain). This account will now have the same permissions as Exchange 2000. However, be
warned that the account that you have added can really do anything it likes to the Exchange
data. Other methods of achieving the same result are described in Microsoft Knowledge Base
article Q262054, “XADM: How to Get Service Account Access to All Mailboxes in Exchange
2000.”

Why do we have a special service account in Exchange 5.5, when Exchange 2000 services
can start as the LocalSystem (built-in computer account)?

Exchange 5.5 required a special logon account for its services because of a limitation with
Microsoft Windows NT operating system version 4.0. Although local computer accounts in
Windows NT 4.0 had tokens, they did not have credentials; therefore, one computer account
could not authenticate to another. Kerberos authentication is used in Windows 2000, and
computer accounts have both tokens and credentials.

Using the local computer account is more secure than an administrator-specified account for
the following reasons:

• The local computer password is a random hexadecimal number, rather than a human-

Version 01.01 27 août 2001 (10h36) Page 33/61


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

readable string.
• The local computer password changes automatically every 30 days.
• The Exchange 5.5 service account has to be excluded from lockout policies as a brute
force attempt to log on could disable the account and shut down the Exchange services.

The computer account for my Exchange 2000 server was accidentally deleted from Active
Directory. Although I can re-create it, will the Exchange 2000 services work correctly?

If you simply re-add the computer account, the Exchange services will start, although you
might encounter some issues such as DSAccess errors in the Event Log. The computer
account is assigned various permissions in Active Directory during the Exchange 2000 setup
process. Therefore, run Setup again and select the Reinstall option; the correct permissions
will be granted for your new computer account.

You should also check the local Exchange Domain Servers group within the domain to ensure
that your new computer account is a member. The System Attendant will attempt to add the
computer account to this group when starting; however, if this process is unsuccessful, you
will need to add the account manually.

Version 01.01 27 août 2001 (10h36) Page 34/61


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

Exchange 2000 Management


What permissions do I need to be able to create and delete mailboxes?

First, you need to have permissions to create a user object in Active Directory. For example,
you could be a Domain Admin, or you might have delegated access to a specific organization
unit. Second, you need the following Exchange permission:

• Exchange View Only Administrator role to the Administrative Group where the destination
Exchange 2000 server exists

Additionally, if you manage public folder objects, you should ensure that your administration
account (that is, the account that you log on as when you manipulate objects in the Exchange
System Manager) is mail-enabled or mailbox-enabled. If your account is not mail-enabled or
mailbox-enabled, MAPI public folders will be inaccessible.

What permissions do I need to be able to move a mailbox from Exchange 5.5 to Exchange
2000 in the same site or administrative group?

When you use Active Directory Users and Computers, the mailbox is transferred between the
two servers, and then the current credentials are used to update the Home-MTA and Home-
MDB attributes on the user or mailbox object.

You will need the following permissions:

• Exchange 5.5
• Admin to the Site naming context
• Active Directory
• Either a member of the Domain Admins or the Account Operators group to the local
domain
• Exchange Administrator role to the administrative group

What permissions do I need to run the Active Directory Account Cleanup Wizard (ADClean)?

The administrator who uses ADClean will need the following permissions in Active Directory:

• On the source object


• Read ordelete permissions in the organizational unit or container
• On the target object
• Write or modify permissions in the organizational unit or container

ADClean modifies nearly all attributes on the target object, and so it is recommended that the
administrator who runs the tool be a member of the Domain Admins group of the target
domain.

What permissions do I need to be able to configure routing groups and connectors?

When you configure routing groups and connectors, you are not directly affecting user
account objects; therefore, you only need the following permission:

• Exchange Administrator role to the administrative group where the target routing group
exists

Note Routing Group Connectors are unidirectional. To create a bidirectional routing group
connector to a routing group that is outside of the local administrative group, you will also

Version 01.01 27 août 2001 (10h36) Page 35/61


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

need to have Admin permissions to the remote administrative group.

If you need to define the global message formats for specific outbound domains or need to
specify global message thresholds, you will need the following permission:

• Exchange Administrator role to the Exchange organization

If you will also manage the SMTP service, your account will need to be a member of the built-
in administrative group on each Exchange server (for metabase access).

What permissions do I need to be able to manipulate message queues?

To view the message queues in the Exchange System Manager, you will need the following
permissions:

• Exchange View Only Administrator role on the administrative group where the connector
exists
• Member of the local Administrators group on the destination computer

To remove messages from queues, you will need the following permissions:

• Exchange Administrator role on the administrative group where the connector exists
• Member of the local administrative group on the destination computer

What permissions do I need to manage Instant Messaging?

To create and manage an Instant Messaging virtual server, you need the following permission:

• Exchange Administrator role in the administrative group where the Instant Messaging
server will be created

If you need to change the firewall topology information for Instant Messaging within your
organization, you will need this additional permission:

• Exchange Administrator role in the Exchange organization

To enable a user for Instant Messaging, you need permissions in the domain naming context
of the Active Directory domain. Enabling a user for Instant Messaging involves changing some
attributes on the user account; therefore, you will need to have permissions on the
organizational unit where the user exists. For most companies, the administrator who creates
or deletes user accounts and mailboxes will also be responsible for enabling the user for
Instant Messaging.

What permissions do I need to install Exchange Conferencing Server?

To install Exchange Conferencing Server, you will need to be logged on to the Active Directory
as a user with the following permission:

• Exchange Full Administrator role at the Exchange 2000 organization level

How do the Exchange Administrator roles affect Exchange Conferencing Server


management?
The different administrator roles are able to do different things when it comes to managing
Exchange Conferencing Server. For example:

Version 01.01 27 août 2001 (10h36) Page 36/61


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

• The Exchange Full Administrator role at the Administrative Group level can do the
following:
• Install or remove Conferencing services
• Stop and start Conferencing services
• Create or delete the Conference Calendar mailbox and resource mailboxes
• Add, remove, or configure Conferencing Technology Providers
• View or modify Conference settings
• The Exchange Administrator role at the Administrative Group level can do the following:
• Create or delete the Conference Calendar mailbox and resource mailboxes
• Add, remove, orconfigure Conferencing Technology Providers
• View or Modify Conference settings

This role cannot do the following:

• Install or remove Conferencing services


• Stop or start Conferencing services (unless local Administrator permissions are
granted)
• The Exchange View Only Administrator role at the Administrative Group level can do
the following:
• View Conference settings
This role cannot do the following:
• Install or remove Conferencing services
• Stop or start Conferencing services (unless local Administrator permissions are
granted)`
• Create or delete the Conference Calendar mailbox and resource mailboxes
• Add, remove, or configure Conferencing Technology Providers
• Modify Conference settings

What permissions do I need to create a new administrative group?

To create a new administrative group, you will need to be logged on to the Active Directory
as a user with the following permission:

• Exchange Administrator role to the Exchange organization

With Exchange Server 5.5 and Windows NT 4.0, I had two support teams: one for the
Exchange Directory and one for the Security Accounts Manager (SAM). Although I can see
the benefits of unified administration with Exchange 2000 and Active Directory, can I still split
out the user creation and mailbox creation roles?

You can achieve this scenario by restricting permissions to the Exchange attributes using the
Windows 2000 Delegation Wizard. To restrict permissions, set the delegated user or group
to have read/write access to the private information and public information property sets. You
can access the Windows 2000 Delegation Wizard by using the Active Directory Users and
Computers management console.

Version 01.01 27 août 2001 (10h36) Page 37/61


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

Appendix A
Permissions Granted During Setup

The Active Directory Connector and Exchange 2000 Setup program make many modifications
to the permissions in the Active Directory. Although most administrators do not need to
understand the low-level Access Control Entry (ACE) modifications made, this information can
be useful for troubleshooting Exchange 2000 and Active Directory errors.

Permissions on Objects in the Exchange Configuration Tree

Microsoft Exchange container


Cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>
Account Allow Deny Inheri Right On
t Property
During ForestPrep phase
Authenticated a ACTRL_DS_LIST |
Users ACTRL_DS_READ_PROP
Designated a a DS_AM_FULL_CONTROL
admin account
During server install
Exchange a a STANDARD_RIGHTS_READ |
Domain Servers ACTRL_DS_READ_PROP |
ACTRL_DS_LIST
During ADC setup
Exchange a a DS_AM_FULL_CONTROL
Services

ADC Connection Agreement container


cn=Active Directory Connections,cn=Microsoft
Exchange,cn=Services,cn=Configuration,dc=<domain>
Account Allow Deny Inherit Right On
Property
During server install
Exchange a a DS_AM_FULL_CONTROL
Domain Servers

Version 01.01 27 août 2001 (10h36) Page 38/61


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

Organization container
cn=<organization>,cn=Microsoft
Exchange,cn=Services,cn=Configuration,dc=<domain>
Account Allow Deny Inherit Right On
Property/
Applies
To
During ForestPrep phase
Authenticated a ACTRL_DS_LIST_
Users OBJECT |
ACTRL_DS_READ
PROP
Designated a a Send-As
admin account
Designated a a Receive-As
admin account
During Server install
“Enterprise a a Send-As
Admins”
“Enterprise a a Receive-As
Admins”
“Domain a a Send-As
Admins” of
root domain
“Domain a a Receive-As
Admins” of
root domain
Everyone a a ms-Exch-Create-Top-Level-
Public-Folder
Everyone a a ms-Exch-Create-Public-
Folder
Everyone a a ms-Exch-Store-Create-
Named-Properties
Everyone a a STANDARD_RIGHTS_ Applies to
READ | object
ACTRL_DS_READ class:
PROP | msExchP
ACTRL_DS_LIST | rivateMDB
ACTRL_LIST_OBJECT
Everyone a a STANDARD_RIGHTS_ Applies to
READ | object
ACTRL_DS_READ class:
PROP | msExchP
ACTRL_DS_LIST | ublicMDB
ACTRL_LIST_OBJECT
Everyone a a STANDARD_RIGHTS_ Applies to
READ | object class:
ACTRL_DS_READ mTA
PROP |
ACTRL_DS_LIST |
ACTRL_LIST_OBJECT
Exchange a a DS_AM_CONTROL_A
Domain CCESS
Servers (i.e., all extended rights)

Version 01.01 27 août 2001 (10h36) Page 39/61


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

Exchange a a ACTRL_DS_CREATE_
Domain CHILD
Servers
Exchange a a ACTRL_DS_WRITE Public-
Domain PROP Informatio
Servers n
(property
set)
Exchange a a ACTRL_DS_WRITE_ Personal-
Domain PROP Informatio
Servers n
(property
set)
Exchange a a DS_AM_FULL_ Applies to
Domain CONTROL object
Servers class:
siteAddre
ssing
When enabling an SRS (ACE is removed when SRS is disabled)
MACHINE$ a a ACTRL_DS_LIST_
OBJECT |
ACTRL_DS_CREATE_
CHILD|
ACTRL_DS_DELETE_
CHILD

Address Lists container


cn=Address Lists Container,cn=<organization>,cn=Microsoft
Exchange,cn=Services,cn=Configuration,dc=<domain>
Account Allow Deny Inherit Right On
Property
During Server install
Authenticated a a ACTRL_DS_LIST
Users

Addressing container
cn=Addressing,cn=<organization>,cn=Microsoft
Exchange,cn=Services,cn=Configuration,dc=<domain>
Account Allow Deny Inherit Right On
Property
During Server install
Authenticated a a STANDARD_RIGHTS_
Users READ |
ACTRL_DS_READ
PROP |
ACTRL_DS_LIST

Version 01.01 27 août 2001 (10h36) Page 40/61


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

Recipient Update Services container


cn=Recipient Update Services,cn=Address Lists
Container,cn=<organization>,cn=Microsoft Exchange,cn=…
Account Allow Deny Inherit Right On
Property
During Server install
Exchange a a DS_AM_FULL_
Domain CONTROL
Servers

Administrative Group
cn=<admin group>,cn=Administrative Groups,cn=<organization>,cn=Microsoft
Exchange,cn=…
Account Allow Deny Inherit Right On
Property
During Server install (set on attribute msExchPFDefaultAdminACL)
Authenticated a a Ms-Exch-Create-Public-
Users Folder

Default TLH
cn=Public Folders,cn=All Folder Hierarchies,cn=<admin group>,cn=Administrative
Groups,cn=<organization>,cn=…
Account Allow Deny Inherit Right On
Property
During Server install (set on attribute msExchPFDefaultAdminACL)
Authenticated a a Ms-Exch-Create-Public-
Users Folder

CA container
cn=CA,cn=Advanced Security,cn=<admin group>,cn=Administrative
Groups,cn=<organization>,cn=…
Account Allow Deny Inherit Right On
Property
During KMS install
MACHINE$ a a DS_AM_FULL_
CONTROL
Authenticated a a STANDARD_RIGHTREAD
Users |
ACTRL_DS_READ_
PROP

Version 01.01 27 août 2001 (10h36) Page 41/61


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

Connections Container
cn=Connections,cn=<routing group>,cn=Routing Groups,cn=<admin
group>,cn=Administrative Groups,cn=…
Account Allow Deny Inherit Right On
Property
During Server install
Exchange a a DS_AM_FULL_
Domain CONTROL
Servers

Server object
cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=…
Account Allow Deny Inherit Right On
Property
During Server install, if the server is NOT a cluster VM
MACHINE$ a a DS_AM_FULL_
CONTROL
During Server install, if the server IS a cluster VM
Exchange a a DS_AM_FULL_
Domain CONTROL
Servers

Protocols Container
cn=Protocols,cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative
Groups,cn=…
Account Allow Deny Inherit Right On
Property
During Server install
Everyone a a ACTRL_DS_LIST

Everyone a a ms-Exch-Read-Metabase-
Properties

System Attendant object


cn=Microsoft System Attendant,cn=<server>,cn=Servers,cn=<admin
group>,cn=Administrative Groups,cn=…
Account Allow Deny Inherit Right On
Property
During Server install (set on attribute msExchMailboxSecurityDescriptor)
LocalSystem a a READ_CONTROL |
fsdspermUserSendAs |
fsdspermUserMailboxOw
ner
Exchange a a READ_CONTROL |
Domain fsdspermUserSendAs |
Servers fsdspermUserMailboxOw
ner
5.5 Service a a READ_CONTROL |
Account fsdspermUserSendAs |
(if given) fsdspermUserMailboxOw
ner

Version 01.01 27 août 2001 (10h36) Page 42/61


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

MTA object
cn=Microsoft MTA,cn=<server>,cn=Servers,cn=<admin group>,cn=Administrative
Groups,cn=…
Account Allow D e n Inherit Right On
y Property
During Server install
5.5 Service a a Send-As
Account
(if given)
5.5 Service a a Read-As
Account
(if given)

Permissions on Other Objects in the Configuration Tree

Deleted Items container


cn=Deleted Items,cn=Configuration,dc=<domain>
Account Allow Deny Inherit Right On
Property
During ForestPrep phase
Designated a a STANDARD_RIGHTS
admin account READ |
ACTRL_DS_LIST |
ACTRL_DS_READ
PROP |
ACTRL_DS_LIST_
OBJECT |
WRITE_OWNER |
WRITE_DAC
During Server install
Exchange a a ACTRL_DS_LIST
Domain Servers
Active Directory Connector object
cn=Active Directory Connector,cn=Exchange
Settings,cn=<server>,cn=Servers,cn=<site>,cn=sites,cn=Configuration,…
Account Allow D e n Inherit Right On
y Property
During ADC setup
Exchange a a DS_AM_FULL_
Services CONTROL

Authenticated a a STANDARD_RIGHTS
Users READ |
ACTRL_DS_READ
PROP |
ACTRL_DS_LIST

Version 01.01 27 août 2001 (10h36) Page 43/61


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

MachineEnrollmentAgent object
cn=MachineEnrollmentAgent,cn=Certificate Templates,cn=Public Key
Services,cn=Services,cn=Configuration,cn=…
Account Allow D e n Inherit Right On
y Property
During KMS install
MACHINE$ a a DS_AM_FULL_CONT
ROL

ExchangeUser object
cn=ExchangeUser,cn=Certificate Templates,cn=Public Key
Services,cn=Services,cn=Configuration,cn=…
Account Allow D e Inherit Right On
ny Property
During KMS install
MACHINE$ a a READ_CONTROL |
ACTRL_DS_LIST |
ACTRL_DS_READ_
PROP
MACHINE$ a a Enroll

ExchangeUserSignature object
cn=ExchangeUserSignature,cn=Certificate Templates,cn=Public Key
Services,cn=Services,cn=Configuration,cn=…
Account Allow Deny Inherit Right On
Property
During KMS install
MACHINE$ a a READ_CONTROL |
ACTRL_DS_LIST |
ACTRL_DS_READ_P
ROP
MACHINE$ a a Enroll

Version 01.01 27 août 2001 (10h36) Page 44/61


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

Permissions on Objects in the Domain Naming Context

Domain container
dc=<domain>
Account Allow Deny Inherit Right On
Property
During DomainPrep phase
Exchange a a ACTRL_DS_WRITE_ Public-
Enterprise PROP Information
Servers (property
set)
Exchange a a ACTRL_DS_WRITE_ Pers onal-
Enterprise PROP Information
Servers (property
set)
Exchange a a ACTRL_DS_WRITE_ groupType
Enterprise PROP
Servers
Exchange a a DS-Replication-
Enterprise Manage-Topology
Servers

Domain proxy container


cn=Microsoft Exchange System Objects,dc=<domain>
Account Allow Deny Inherit Right On
Property
During DomainPrep phase
Exchange a DS_AM_FULL_
Enterprise CONTROL
Servers
Exchange a a DS_AM_FULL_
Domain CONTROL
Servers

Exchange Enterprise Servers group


cn=Exchange Enterprise Servers,cn=Users,dc=<domain>
Account Allow Deny Inherit Right On
Property

During DomainPrep phase


All org-level a DS_AM_FULL_
full Exchange CONTROL
admins
Exchange a DS_AM_FULL_
Enterprise CONTROL
Servers

Version 01.01 27 août 2001 (10h36) Page 45/61


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

Exchange Domain Servers group


cn=Exchange Domain Servers,cn=Users,dc=<domain>
Account Allow Deny Inherit Right On
Property
During DomainPrep phase
All org-level a DS_AM_FULL_CONTROL
full Exchange
admins
Exchange a DS_AM_FULL_CONTROL
Enterprise
Servers

Version 01.01 27 août 2001 (10h36) Page 46/61


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

Appendix B - Exchange 2000 Role Permissions

The Exchange 2000 Delegation Wizard provides a friendly interface for setting permissions
to the Exchange objects in the Active Directory. Enterprise administrators may wish to have
more granular details on the exact changes that the Delegation Wizard makes to the Active
Directory. The various Delegation Wizard roles and permissions are described here in full
detail.

Exchange Full Administrator

Description: The selected user and group can fully administer Exchange system information
and modify permissions.

Organization Rights

{Full Control} on MsExchConfigurationContainer (This object and sub-containers)


{Deny “Receive-As”, “Send-As”} on Organization container (This object and sub-containers)
{Read, Change Permissions} on “Deleted Objects” in Config NC (This object and sub-
containers)

Admin Group Rights

{Read, List object, List contents} on MsExchConfigurationContainer (This object only)


{Read, List object, List contents} on Organization container (This object and sub-containers)
{Full Control, Deny “Send-As”, Deny “Receive-As”} on Admin Group (This object and sub-
containers)
{Full Control except “Change permissions”} on Connections Container (This object and sub-
containers)
{Read, List object, List contents, Write properties} on Offline Address Lists Container (This
object and sub-containers)

Exchange Administrator

Description: The selected user and group can fully administer Exchange system information.

Organization Rights

{All except “Change permissions”} on MsExchConfigurationContainer (This object and sub-


containers)
{ Deny “Receive-As”, “Send-As”} on Organization container (This object and sub-containers)

Admin Group Rights

{Read, List object, List contents”} on MsExchConfigurationContainer (This object only)


{Read, List object, List contents”} on Organization container (This object and sub-containers)
{All except “Change permissions”, Deny “Send-As”, Deny ”Receive-As”} on Admin Group (This
object and sub-containers)
{All except “Change permissions”} on Connections Container (This object and sub-containers)
{ Read, List object, List contents, Write properties} on Offline Address Lists Container (This
object and sub-containers)

Exchange View only Administrator

Description: The selected user and group can view Exchange configuration information.

Version 01.01 27 août 2001 (10h36) Page 47/61


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

Organization Rights

{Read, List object, List contents} on MsExchConfigurationContainer (This object and sub-
containers)
{View Information Store Status} on Organization container (This object and sub-containers)

Admin Group Rights

{Read, List object, List contents} on MsExchConfigurationContainer (This object only)


{Read, List object, List contents} on Organization container (This object only)
{Read, List object, List contents} Admin Groups container (This object only)
{Read, List object, List contents, View Information Store Status} on Admin Group container
(This object and sub-containers)
{Read, List object, List contents} on MsExchRecipientsPolicyContainer, Address Lists
Container, Addressing, Global Settings, System Policies (This object and sub-containers)

Version 01.01 27 août 2001 (10h36) Page 48/61


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

Appendix C - Additional Resources

Microsoft Exchange 2000 Server Resource Kit


http://mspress.microsoft.com/prod/books/4355.htm
Microsoft Windows 2000 Server Resource Kit
http://mspress.microsoft.com/prod/books/1394.htm

Microsoft Knowledge Base


To access the Microsoft Knowledge Base, go to http://support.microsoft.com/.
Q262054, “XADM: How to Get Service Account Access to All Mailboxes in Exchange 2000”
http://support.microsoft.com/support/kb/articles/Q262/0/54.asp

Version 01.01 27 août 2001 (10h36) Page 49/61


EPFL_Audit_010817.wpd
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 5 - Mesures de protection de l’unité d’organisation Domain


controllers et de sa stratégie par défaut Default Domain
Controllers Policy

IMPORTANT : La stratégie par défaut Default Domain Controllers Policy est critique. Si un
administrateur du domaine ou de l’entreprise bien intentionné mais pas assez informé du
fonctionnement des stratégies décide d’implémenter des paramètres trop restrictifs, le réseau
peut être rendu inutilisable dans sa totalité.

Exemple : un administrateur peut modifier la stratégie par défaut Default Domain Controllers
Policy pour attribuer le droit Deny access to this computer from the network (Refuser l’accès
à cet ordinateur depuis le réseau) au groupe Tout le monde. Cette action empêchera tous les
utilisateurs d’ouvrir des sessions ou d’accéder aux dossiers partagés dans le domaine, y
inclus au dossier partagé sysvol contenant les stratégies. On pourrait croire qu’il est possible
d’ouvrir une session localement sur un contrôleur de domaine et de modifier à nouveau la
stratégie pour revenir à la situation antérieure. Ce n’est pas si simple. L’impossibilité
d’accéder à travers le réseau aux contrôleurs de domaine rend impossible la modification des
stratégies. Les stratégies sont enregistrées dans le dossier Sysvol, dossier qui est répliqué
à l’aide du système de réplication des fichiers FRS et l’accès se fait toujours à travers le
partage réseau sysvol, même si la session est ouverte en local. Une restauration forcée sera
nécessaire pour prendre le contrôle de l’Active Directory. La modification incorrecte des deux
stratégies par défaut peut avoir des conséquences désastreuses. Pour cette raison, il est
important de déléguer correctement les droits administratifs en suivant la règle des droits
minimes. Il est nécessaire de prendre des dispositions particulières pour éviter qu’un
administrateur du domaine ou de l’entreprise modifie par erreur une des stratégies par défaut
en croyant modifier la stratégie de son Unité d’Organisation.
Pour assurer un bon fonctionnement de l’Active Directory, le bon fonctionnement des
stratégies est crucial. Il faut observer avec attention les mesures prévues dans cette annexe.
Ces mesures de protection de l’unité d’organisation Domain Controllers peuvent être
appliquées à n’importe quelle unité d’organisation qui détient des ressources critiques au
niveau de la sécurité et qui sont administrés par des administrateurs compétents. Par
exemple, il serait parfaitement possible de créer une unité d’organisation pour chaque
département ou faculté. Seuls les administrateurs chargés de l’administration des ressources
du département pourront les administrer sans crainte qu'un autre administrateur de
l’entreprise prenne des dispositions contraires. Les mesures de protection conseillées pour
les 2 stratégies qui existent par défaut dans chaque domaine peuvent constituer un modèle
pour décentraliser l’administration des ressources dans un domaine et éviter la création de
domaines supplémentaires sous prétexte de pouvoir bénéficier d’une autonomie
d’administration. Les possibilités de délégation des droits administratifs de Windows 2000
sont puissantes et doivent être connues par tous les administrateurs. L'exercice suivant doit
être étudié attentivement. Les tâches nécessaires aux administrateurs qui sont chargés de
les effectuer doivent être déléguées. Actuellement, beaucoup d’administrateurs sont
intéressés à installer un domaine juste pour apprendre à l’installer. A long terme ces
administrateurs moins intéressés par le travail routinier d’administration et de sauvegarde des
ressources peuvent négliger l’exécution de tâches routinières critiques au bon fonctionnement
du réseau. Cet exercice prouve une fois de plus que Microsoft a raison de répéter que même
dans un environnement décentralisé, il n’est pas nécessaire de créer plusieurs domaines
comme c’était le cas avec Windows NT.

Version 01.01 27 août 2001 (10h36) Page 50/61


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

Exercice

• Créez d'un groupe Domain Controllers GPO Admins.


• Intégrez dans ce groupe les comptes qui seront autorisés à modifier la stratégie par défaut
Default Domain Controlers policy.

Vous allez autoriser uniquement les membres de ce groupe à modifier la stratégie prévue
pour les contrôleurs de domaine. Vous allez enlever les groupes Administrateurs, Admins de
l’Entreprise et Administrateurs du domaine de la liste des groupes autorisés à modifier la
stratégie par défaut du domaine.

• Effectuez un clic droit sur l’unité d’organisation Domain Controllers, Propriétés.


• Sélectionnez l’option Block Policy inheritance pour empêcher les stratégies définies au
niveau du domaine de s’appliquer aux contrôleurs de domaine. Si certains paramètres qui
ont été définis dans la stratégie du domaine doivent s’appliquer aux contrôleurs de
domaine, il est nécessaire de modifier la stratégie Default Domain Controllers Policy pour
les inclure dans cette stratégie.
• Sélectionnez la GPO, Default Domain Controllers Policy , et cliquez sur Propriétés.
• Sélectionnez l’onglet Sécurité, puis Avancés. Sous Permissions, enlevez de la liste les
groupes Admins du domaine Admins de l’entreprise et Administrateurs et ajoutez le groupe
que vous avez créés Domain Controllers GPO Admins.

Vous venez de prendre les mesures nécessaires pour empêcher les administrateurs de
modifier, par erreur, la stratégie par défaut. Les administrateurs peuvent toujours prendre
possession de cette GPO et dans une deuxième phase, modifier les autorisations.

• Revenez aux propriétés de Domain Controllers.


• Désélectionnez l’option Allow inheritable permissions from parent to propagate to this
object. Sélectionnez Copy pour copier les permissions et enlevez les entrées qui accordent
des autorisations aux administrateurs, administrateurs de l’entreprise ou Administrateurs
du domaine.

Ces changements empêchent les administrateurs de modifier accidentellement la stratégie


par défaut pour les contrôleurs de domaine, de créer d’autres stratégies dans l’OU Domain
Controllers ou de désélectionner l’option Block Policy inheritance.

Il est toujours possible pour un administrateur d’implémenter une stratégie au niveau du site
ou du domaine et de forcer l’application avec le paramètre No override. No override est
prioritaire par rapport à Block inheritance. Pour cette raison nous allons modifier la sécurité
sur l’objet stratégie de groupe GPO.

• Sélectionnez la stratégie Defaut Domain Controllers Policy, Propriétés et cliquez sur


Sécurité.

Notez chaque groupe qui a Full control ou Write access. L'utilisateur qui possède 1 de ces 2
droits peut modifier la stratégie et a donc plein pouvoir d’Administration sur les ordinateurs
de cette OU. Vous pouvez lier une stratégie à plusieurs OU, mais chaque stratégie a un seul
ACL (Access Control List).

Pour garder le contrôle sur les modifications des stratégies, vous devez administrer
correctement les permissions associées au OU. La liste et les options observées sur l’onglet
Group Policy dans les Propriétés d’une OU correspond à 2 propriétés qui existent sur chaque
OU : GpLink et gpOptions. GpLink correspondent à la liste des GPOs qui apparaît dans les
propriétés de l’unité d’organisation. gpOptions correspond a l’option Block policy inheritance.
Un utilisateur qui a Write access sur gpLink peut décider de sélectionner ou non l’option Block

Version 01.01 27 août 2001 (10h36) Page 51/61


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

policy inheritance. Un utilisateur qui a le droit Write sur gpOption peut ajouter ou effacer le lien
qui lie la GPO à l’OU.

• Pour observer les permissions sur une OU dans Propriété de l'OU, sélectionnez l’onglet
Sécurité : Clic sur Advanced…
• Double-cliquez sur n’importe quel ACL (accès control entries) et sélectionnez l’onglet
Propriétés :

Si vous accordez Write ou Control total sur l’OU, vous accordez également Write sur gpLink
et gpOptions. La connaissance de gpLink et gpOptions vous permettra de contrôler les accès
aux OU et GPO et de faire face à des administrateurs pas très bien formés à Windows 2000
et pas intéressés à collaborer avec les autres Administrateurs.

Version 01.01 27 août 2001 (10h36) Page 52/61


EPFL_Audit_010817.wpd
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 6 - Mot de passe de restauration du service d’annuaire


Chaque contrôleur de domaine a un mot de passe de restauration du service d’annuaire qui
lui est propre. Ce mot est spécifié pendant la promotion à l’aide de dcpromo.exe mais il n’est
jamais changé. Il est probable que certains administrateurs ont oublié ce mot de passe
rarement utilisé. Ce mot de passe est indispensable à la restauration de l’Etat du système.
L’exercice suivant vous permet de changer le mot de passe de restauration du service
d’annuaire même si vous ne pouvez pas ouvrir une session en mode de restauration du
service d’annuaire.

Ouvrez l’invité de commande et positionnez-vous dans le dossier \Winnt\system32

Renommez le fichier logon.scr pour pouvoir le restaurer à la fin de la procédure :


Ren logon.scr logon.old

Copiez le fichier cmd.exe et donnez-lui le nom logon.scr :


Copy cmd.exe logon.scr

Démarrez le contrôleur de domaine dans le mode de restauration du service d’annuaire et


patientez pendant 20 minutes environ. Au lieu de l’économiseur d’écran vous obtiendrez une
fenêtre de l’invité de commande avec les privilèges de sécurité du compte système de
l’ordinateur (et sans avoir ouvert de session)

Entrez la commande : Compmgmt.msc et changez le mot de passe du compte Administrateur


à l’aide de la console Utilisateurs et groupes locaux..

Effacez le fichier qui vous a permis de changer le mot de passe :


Del logon.scr

Remettez l’ancien fichier logon.scr à sa place :


ren logon.old logon.scr

Version 01.01 27 août 2001 (10h36) Page 53/61


EPFL_Audit_010817.wpd
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 7 - Utilisations des groupes Exchange 2000


Utilisation des groupes globaux
Seule la définition du groupe global (et non pas les adhésions) est répliquée dans le
catalogue global. L'impact de cette fonction est positif sur le plan de la réplication, car la
définition de groupe requiert très peu d'espace (environ 180 octets) dans le catalogue global.
Toutefois, que se passe-t-il lorsque Exchange 2000 Server doit déterminer les adhésions à
un groupe à partir de la réception d'un message ? L'impact de cette fonction dépend du
serveur de développement désigné par le groupe lui-même.
Le serveur de développement sélectionné décide du moment où le serveur Exchange peut
interroger Active Directory pour connaître les adhésions au groupe. Alors que ce paramètre
était peu utilisé dans les mises en œuvre précédentes d'Exchange, il doit toujours être
configuré dans un environnement multi-domaine.
Il est donc recommandé de choisir un serveur Exchange 2000 qui existe dans le domaine
auquel le groupe appartient. Par ailleurs, pensez également à choisir un serveur Exchange
promu au rang de contrôleur de domaine Active Directory.

Utilisation des groupes de domaine Local


La principale fonction administrative des groupes locaux du domaine est de consolider les
points de référence nécessaires à l'établissement des autorisations d'accès aux ressources
réseau. Ainsi, un groupe de domaine local contient en général des groupes globaux
imbriqués.
Les groupes locaux du domaine servent de référence aux ACL d'une ressource particulière.
L'étendue de ce type de groupe est le domaine local. Seule la définition est conservée dans
le catalogue global, de sorte que le développement des groupes globaux doit se produire sur
un contrôleur de domaine local.

Utilisation des groupes universels


Les groupes universels représentent le type de groupe le plus flexible d'Active Directory.
Dans un environnement en mode natif, les groupes universels peuvent être des groupes de
distribution ou des groupes de sécurité. Dans un environnement en mode mixte, les groupes
universels peuvent être uniquement constitués de groupes de distribution.
Utilisez les groupes universels dans les environnements qui nécessitent à la fois des
adhésions globales et un mode d'utilisation global. Dans le cas contraire, utilisez les groupes
globaux ou les groupes locaux du domaine et ce, pour les deux raisons suivantes :
Les groupes universels et leurs membres sont répliqués dans le catalogue global. En théorie,
les adhésions à un groupe universel sont composées de groupes globaux, ce qui réduit
l'impact sur le catalogue global.
Dans la pratique toutefois, les adhésions à un groupe universel sont généralement plus
importantes et incluent un grand nombre de comptes utilisateur. Dans ce cas, l'impact et
l'importance de la réplication augmentent sensiblement. Le second argument concerne la
sécurité. Les groupes universels peuvent être imbriqués selon un mode global et il est assez
facile d'imbriquer accidentellement des groupes universels jusqu'au niveau où ils contiennent
des adhésions indésirables.

Résumé sur l'utilisation des groupes : Les tableaux suivants vous aident à déterminer les
attributs et l'utilisation de types de groupes et des étendues.

Version 01.01 27 août 2001 (10h36) Page 54/61


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

Groupes de sécurité

Avantages Inconvénients
Peuvent être à extension boîte aux lettres L’insertion accidentelle d’utilisateurs dans
en affectant une adresse SMTP, ainsi, le le groupe peut conférer un accès illicite
groupe peut agir comme l’équivalent d’une aux ressources réseau.
liste de distribution
Peuvent être utilisés pour l’affection des Le jeton utilisateur contient les adhésions
autorisations associées aux dossiers aux groupes. Les adhésions à un grand
publics dans Exchange 2000 Server. nombre de groupes grossissent le jeton
d'accès.
Utiles si vous souhaitez également
attribuer des autorisations réseau aux
membres de ce groupe.
Réduit le nombre de groupes dans Active
Directory et le système de messagerie,
ainsi que le temps nécessaire à leur
conservation, car ceux-ci peuvent agir
comme pseudo-groupes de distribution.

Groupes de distribution

Avantages Inconvénients
Peuvent être utilisés pour l'envoi de Aucune autorisation ne peut être affectée
messages en bloc. aux ressources réseau.
Peuvent être utilisés pour les groupes Aucune autorisation ne peut être affectée
universels même dans un domaine en aux dossiers publics.
mode mixte.

Groupes locaux du domaine

Avantages Inconvénients
Les adhésions ne sont pas publiées sur le Aucune autorisation ne peut être affectée
serveur de catalogue global. Ainsi, les aux ressources réseau et aux dossiers
modifications apportées aux adhésions ne publics situés dans d'autres domaines.
génèrent pas une réplication du catalogue
global.
Les clients Outlook peuvent visualiser les Les utilisateurs d'Outlook dans d'autres
adhésions complètes des utilisateurs s'ils domaines ne peuvent pas visualiser les
sont situés dans le domaine auquel le adhésions complètes.
groupe appartient.
Les adhésions peuvent inclure des Les adhésions à un groupe doivent être
utilisateurs de n'importe quel domaine. récupérées à la demande si le
développement a lieu dans un domaine
distant.

Version 01.01 27 août 2001 (10h36) Page 55/61


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

Groupes globaux

Avantages Inconvénients
Les adhésions ne sont pas publiées sur le Peuvent contenir des objets destinataires
serveur de catalogue global. Ainsi, les issus du même domaine uniquement.
modifications apportées aux adhésions ne
génèrent pas une réplication du catalogue
global.
Les clients Outlook peuvent visualiser les Les utilisateurs d'Outlook dans d'autres
adhésions complètes des utilisateurs s'ils domaines ne peuvent pas visualiser les
sont situés dans le domaine auquel le adhésions complètes.
groupe appartient.
Les autorisations peuvent être attribuées Les adhésions à un groupe doivent être
aux ressources réseau et aux dossiers récupérées à la demande si le
publics dans n'importe quel domaine. développement a lieu dans un domaine
distant.

Groupes universels

Avantages Inconvénients
Les adhésions peuvent inclure n'importe Les modifications relatives aux
quel objet de la forêt. adhésions entraînent la réplication sur
les serveurs de catalogue global.
Les utilisateurs d'Outlook de n'importe Les groupes universels de sécurité
quel domaine peuvent visualiser les peuvent être créés uniquement
adhésions complètes. lorsqu'un domaine est en mode natif.
Vous n'avez jamais besoin de récupérer La flexibilité des groupes universels
les adhésions des contrôleurs de domaine peut générer des problèmes de sécurité
distants. lors d'une imbrication accidentelle.
Peuvent être utilisés dans les domaines
en mode mixte lorsque le type Distribution
est défini.

La mise en œuvre de différents types de groupes et étendues présente des inconvénients


évidents. La meilleure approche consiste peut-être à utiliser un type de groupe spécifique aux
exigences de la liste de distribution. Lors de la planification des groupes, suivez une approche
logique pour éviter toute confusion de l'utilisateur et de l'administrateur. Les groupes doivent
être définis dans l'ordre suivant :
Définissez les groupes de sécurité en fonction des exigences de votre modèle administratif.
Ceux-ci doivent inclure des groupes de contrôle d'accès aux dossiers publics.
Sélectionnez les groupes dont l'extension messagerie doit être activée. L'activation de tous
les
groupes pour la gestion de messages en bloc n'est pas recommandée.
Définissez les listes de distribution supplémentaires dont vous avez besoin et affectez-les à
des groupes de type distribution.

Version 01.01 27 août 2001 (10h36) Page 56/61


EPFL_Audit_010817.wpd
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 8 - Procédure de mise à jour des destinataires dans des


environnements multi-domaines
Etant donné qu'un "service de mise à jour de destinataire" ne concerne qu'un seul domaine,
il faut configurer un objet "service de mise à jour" pour chaque domaine de l'organisation qui
contient des objets destinataires. Si au moins 1 serveur Exchange 2000 est installé dans
chaque domaines, les objets requis sont automatiquement créés. Pour les domaines de la
forêt intranet.epfl.ch qui n'ont pas de serveur Exchange 2000, cette tâche doit être effectuée
manuellement.

Pour créer manuellement une référence de service de mise à jour de destinataire, le


programme d'installation Exchange 2000 doit être exécuté dans le domaine de destination à
l'aide de l'option DomainPrep. Après cela, dans le Gestionnaire système Exchange, clic avec
le bouton droit sur "Service de mise à jour de destinataire", et clic sur "Nouveau" permet de
sélectionner la commande "Service de mise à jour de destinataire". Dans la boîte de dialogue
"Nouvel objet Service de mise à jour de destinataire", clic sur "Parcourir" pour sélectionner
le domaine voulu, clic sur OK, puis sur Suivant pour continuer. Dans la deuxième boîte de
dialogue, clic sur "Parcourir" pour choisir le serveur Exchange 2000 qui doit exécuter le
service de" mise à jour de destinataire". Le contrôleur de domaine qui doit mettre à jour les
destinataires dans le domaine est automatiquement sélectionné dans la prochaine boîte de
dialogue.

Version 01.01 27 août 2001 (10h36) Page 57/61


EPFL_Audit_010817.wpd
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 9 - Procédure d'octroi des accès à l'organisation, au groupe


administratifs et aux objets de l’organisation Exchange
EPFL

C Octroi d’autorisations au niveau de l’organisation Exchange


Un groupe universel avec un nom du style "Administrateurs Exchange" doit être créé pour
inclure tous les administrateurs qui doivent administrer l’organisation Exchange. Sur un
ordinateur, Regedt32 doit être utilisé pour configurer le Gestionnaire système Exchange
afin d’afficher l’onglet Sécurité de tous les objets :

C Regedt32, HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin
C Clic une fois sur EXAdmin, Edition, Ajoutez une valeur, DWORD, puis nommez la valeur
ShowSecurityPage
C Double-clic sur ShowSecurityPage, dans la zone Données de la valeur, tapez 1 et clic
sur OK. Fermez la fenêtre de l’Editeur du registre.

Utilisez l’Assistant Délégation d’administration Exchange pour attribuer au groupe


"Administrateurs Exchange" le droit Administrateur intégral Exchange :

C Click droit sur EPFL (Exchange). Déléguer le contrôle. Ajoutez Adminstrateurs Exchange
et accordez-lui Administrateur intégral Exchange.

Attribuez aux administrateurs des domaines enfants le droit "Administrateur Exchange


Affichage seul" au niveau de l’organisation Exchange.

Contrôlez attentivement les autorisations au niveau de l’organisation Exchange et


documentez les groupes qui ont des droits au niveau de l’organisation Exchange. Ces
autorisations seront héritées au niveau des objets enfants. Si l’héritage au niveau des
Groupes administratifs n’est pas souhaité, il est possible de l’interrompre. Dans ce cas
copiez les autorisations existantes et modifiez-les pour supprimer les groupes des
personnes qui ne doivent pas accéder à votre groupe administratif. Windows 2000 permet
d’ajouter ou d'enlever de la liste des permissions plusieurs groupes d’ordinateurs qui
apparaissent sur la liste des groupes ensemble avec les groupes d’utilisateurs. Ne
confondez pas les utilisateurs avec les ordinateurs. N’ajoutez pas et ne supprimez pas les
autorisations accordés par Windows 2000 aux ordinateurs.

C Octroi d’autorisations au niveau des groups administratifs


Les administrateurs d’un domaine enfant (ou d'un autre groupe créé spécialement) doivent
avoir tous les droits nécessaires sur leur groupe administratif. Il est souhaitable de réaliser
une correspondance directe entre un groupe administratif et un domaine enfant pour
faciliter l’administration.

Utilisez l’Assistant Délégation d’administration Exchange pour attribuer à ce groupe


d’administrateurs le rôle Administrateur Exchange sur chaque groupe administratif.

Faites un clic droit sur 1 groupe administratif et déléguez le contrôle.

Ajoutez le groupe Admins du domaine et accordez-lui Administrateur intégral Exchange


Répétez l’opération pour chaque groupe administratif.

C Recommandations pour le renforcement de la sécurité interne

C Configuration des autorisations des listes de distribution

Version 01.01 27 août 2001 (10h36) Page 58/61


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

Etant donné que les listes de distribution contiennent souvent des informations
confidentielles sous forme de données d’adhésion, il est important de planifier avec soin
l’accès à chaque liste de distribution. Les autorisations des listes de distribution peuvent
être configurées pour empêcher certains utilisateurs de voir la liste des membres et
envoyer des messages à certaines listes de distribution.

C Octroi de l’accès à l’organisation


Il est indispensable de créer un groupe d'administrateurs Exchange responsables du
bon fonctionnement de l'organisation Exchange. Ce groupe a besoin de pouvoir
accéder à la totalité de l’organisation Exchange pour mener à bien leur mission.

C Octroi de l’accès aux groupes administratifs


Les administrateurs qui ont besoin de pouvoir accéder à la totalité des objets d’un
groupe administratif sont les Administrateurs des différents départements qui
répondent aux appels des clients de ces départements. Ils doivent être en mesure
d’afficher les paramètres de configuration des serveurs, de gérer tous les aspects du
groupe administratif et des objets stratégie.

C Octroi des autorisations à l’aide de ADSI Edit


Certaines autorisations ne peuvent pas être accordées à l'aide du gestionnaire
Système Exchange. Par contre, l'utilitaire ADSI Edit permet d'accorder toutes les
autorisations. Dans l’Active Directory, chaque groupe administratif se présente sous
la forme de conteneur de configuration distinct, affichable à l’aide de l’utilitaire ADSI
(Active Directory Service Interface) Edit.

CN=Configuration,DC=intranet,DC=epfl,DC=ch,
CN=Services,
CN=Microsoft Exchange,
CN=nom de l’Organisation Exchang,par Exemple : EPFL
CN=First Administrative Group
CN=Nom d’un autre group administratif (département)

Pour accorder des autorisations à un groupe, il suffit d’ajouter ce groupe à la liste des
groupes possédant des autorisations pour l’objet groupe administratif correspondant.
Active Directory applique les paramètres de sécurité à tous les objets situés dans ce
groupe administratif. Il est préférable d’utiliser l’Assistant Délégation d’administration
Exchange au lieu de l’utilitaire ADSI Edit pour gérer les autorisations des groupes

Version 01.01 27 août 2001 (10h36) Page 59/61


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

administratifs. Il est probable que les possibilités supplémentaires de ADSI Edit ne


seront pas nécessaires. Des affectations d’autorisations incorrectes effectuées à l’aide
de ADSI Edit peuvent entraîner de sérieux problèmes de configuration et nécessiter
la restauration des systèmes à partir d’une sauvegarde. Une documentation des
autorisations accordées est nécessaire pour assurer le bon fonctionnement de
l’organisation Exchange. Une formation spécifique à l’utilisation des groupes
administratifs Exchange 2000 est nécessaire.

Version 01.01 27 août 2001 (10h36) Page 60/61


EPFL_Audit_010817.wpd
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 10 -Procédure de vérification des messages entrants à la


recherche de pièces jointes .vbx, .bat, .exe
Le service SMTP peut être étendu au moyen d’un récepteur d’événements de transport. Le
code VBScript recherche les messages SMTP dont la ligne Objet contient par exemple les
mots :"I LOVE YOU" ainsi que des pièces jointes portant l’extension .VBS, ... Dans les deux
cas la remise des messages est interrompue et ces derniers seront écrits dans le répertoire
BADMAIL du serveur virtuel SMTP. Le livre "Microsoft Exchange 2000 - Mise en œuvre et
administration" (ISBN : 2-84082-779-4) contient plus d’information sur ce thème.

Version 01.01 27 août 2001 (10h36) Page 61/61


EPFL_Audit_010817.wpd