Audit de l'Infrastructure Microsoft Active Directory (Domaine SG) Et

Audit de l'infrastructureMicrosoft Active Directory(domaine SG) et de son intégrationdans la forêt intranet.epfl.chversion 01.01

Auteur : Ion MarculescuIngénieur Trainer MCSE, MCT

ISEIG - Institut Suisse d'Enseignement de l'Informatique de GestionAvenue des Boveresses 52, Case postale 99CH - 1000 LAUSANNE 21Tél. : 021/654.40.60, Fax : 021/654.40.69E-Mail : [email protected], 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

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

Table des matières1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Objectifs du mandat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Champ et limites de la mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Composition de l'équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Etude de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1 Forêt intranet.epfl.ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Domaine racine de la forêt intranet.epfl.ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Domaine sg.intranet.ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Domaine servers.intranet.epfl.ch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Domaine représentatif des 24 autres domaines utilisateurs . . . . . . . . . . . . . . . . . . . . . 82.6 Problèmes relatifs au déploiement de Windows 2000 dans l'environnement hautement

décentralisé de l'EPFL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 Implémentation de Exchange 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1 Objectifs du déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Recommandations générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Recommandations pour le domaine intranet.epfl.ch . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Recommandations pour le domaine servers.intranet.epfl.ch . . . . . . . . . . . . . . . . . . . 183.5 Recommandations pour le domaine sg.intranet.epfl.ch . . . . . . . . . . . . . . . . . . . . . . . 183.7 Introduction aux annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Annexe 1 - Liste des événements à auditer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Annexe 2 - Procédure de Pré-Creation d’un Child Domain . . . . . . . . . . . . . . . . . . . . 26Annexe 3 - Etablissement d'une stratégie de sécurité des

comptes et contrôle de son application . . . . . . . . . . . . . . . . . . . . . . . . . . 30Annexe 4 - Permissions required for Installation and management of Microsoft

Exchange 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Annexe 5 - Mesures de protection de l’unité d’organisation Domain controllers et de

sa stratégie par défaut Default Domain Controllers Policy . . . . . . . . . . . 53Annexe 6 - Mot de passe de restauration du service d’annuaire . . . . . . . . . . . . . . . . 56Annexe 7 - Utilisations des groupes Exchange 2000 . . . . . . . . . . . . . . . . . . . . . . . . . 57Annexe 8 - Procédure de mise à jour des destinataires dans des environnements

multi-domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Annexe 9 - Procédure d'octroi des accès à l'organisation, au groupe administratifs

et aux objets de l’organisation Exchange EPFL . . . . . . . . . . . . . . . . . . . 61Annexe 10 - Procédure de vérification des messages entrants à la recherche de

pièces jointes .vbx, .bat, .exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64



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 domainesg.intranet.epfl.ch appartenant aux Services Généraux de l'EPFL et de son intégrationdans 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 domainesg.intranet.epfl.ch a été effectué selon les règles conseillées par Microsoft et que laconfiguration actuelle de l’Active Directory permet une migration optimale de tous les autresordinateurs 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 domainessg.intranet.epfl.ch et intranet.epfl.ch. Comme les utilisateurs du domaine sg.intranet.epfl.chutilisent 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 autresdomaines de la forêt intranet.epfl.ch.

L'audit porte sur l'implémentation de Windows 2000 sur les contrôleurs du domaine et lesserveurs 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



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



2 Etude de l'existant

2.1 Forêt intranet.epfl.ch

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

Le schéma ci-dessus présente l'implémentation existante de la forêt intranet.epfl.chcomposé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 laforêt car il assure des fonctionnalités essentielles pour l'ensemble de la forêt, fonctionnalitésqui 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



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 sontinstallé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ésC les disques des serveurs n'utilisent pas le miroir disqueC 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ésC aucun crash test n'a été effectué jusqu'à maintenantC 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 del'EPFL. Ce problème se retrouve sur tous les domaines enfants. La sécurité estassuré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 pasd’archivage séparé des journaux de sécurité

C documentation du système : aucune documentation système n'a été établieC performances du systèmeC 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 etdifficile.

2.3 Domaine sg.intranet.ch

Les ordinateurs regroupés dans ce domaine sont utilisés pour mener à bien les tâchesadministratives 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 globalpour 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



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 pertede ce domaine empêche les utilisateurs créés dans ce domaine d'ouvrir des sessions etdonc 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 autresinformaticiens.

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érentsC les disques de tous les serveurs utilisent le miroir disque pour assurer la tolérance de

panneC 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 desauvegarde 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 meilleuresconditions de restauration.

C des crash tests ont été effectués pour les données. Des tests de restauration forcés del'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 estconnue 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 trouventdans le bureau de l'ingénieur système responsable du domaine SG, M. Perret. Lesmots de passe se trouvent dans un coffre-fort dont l'accès n'est permis qu'aux 3responsables 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 lesutilisateurs des différents domaines de la forêt intranet.epfl.ch.

Ce domaine comprend 2 domaines enfants :

C expo.servers.intranet.epfl.chC metadir.servers.intranet.epfl.ch



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

C 2 ordinateurs "de bureau” installés comme contrôleurs de domaine Windows 2000C 1 serveur Exchange 2000 installé sur un serveur membre du domaine.C 3 serveurs de fichiers Windows 2000C 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 quisont 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 dela forêt, leur configuration peut occasionner des problèmes pour le bon fonctionnement desordinateurs des domaines du champ de l'étude. Il a donc été décidé en accord avec lemandant 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 serveursou 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é avecWindows 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énieurssystème qui n'ont pas toujours les connaissances suffisantes ou le temps pour définir unconcept optimal d'intégration dans l'Active Directory. Un trop grand nombred’administrateurs représente un risque pour le bon fonctionnement de l'ensemble del'intranet de l'EPFL. La configuration actuelle nécessite des moyens humains et matérielsimportants qui pourraient être diminués.

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

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

C l'EPFL comprend environ 10 départements qui sont assimilable à des entreprisesindépendantes. De ce fait, chaque département définit sa propre politiqued'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 doncpas eu de migration depuis Exchange 5.5.

C L’organisation de Exchange 2000 fonctionne en mode mixte et ce, malgré qu’il n'y aaucun 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



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

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 serveur5.5 dans l'organisation Exchange EPFL peut se présenter si des applications depasserelle avec d'autres systèmes de messagerie non Microsoft devaient être installéset si ces applications ne tournent que sur Exchange 5.5.

Groupe administratif Serveurs Exchange2000

Nombre contrôleurs dedomaine dans le

domaine du serveurExchange

Rôle

First Administrativegroup

lanos.dcs-lanos.intranet.epfl.ch

1 DC


Sicsrv1.serveurs.intranet.epfl.ch


Verseur

DSC-SG Postman 2

LAVOC pc18.dgc.intranet.epfl.ch

2

SG sgexchange.sg.intranet.epfl.ch

2 Serveurmembre

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

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

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



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

C Le groupe administratif "First Administrative Group" n’est utilisé ni pour un contrôlecentralisé, ni pour regrouper des stratégies système, ni pour définir des paramètres pourtoute l’ EPFL. Ces stratégies pourraient contrôler des paramètres tels que : la taille desboî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 deces groupes.

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

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

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



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 évolutifC définir un concept gérableC définir un concept sécuriséC minimiser les charges d'administrationC é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 2000C 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 auxingé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 indispensabled'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 avanttout déploiement. Le déploiement de Exchange 2000 ne pourra se faire qu'après contrôleque les connaissances de ce cours sont acquises. Les nombreux problèmes rencontréspar tous les administrateurs Exchange de l'EPFL interrogés illustrent cette nécessité deformation.

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

mailing list, hot-line, rencontres, ...). Le bon fonctionnement de cette structure estindispensable pour assurer un niveau minimal de service aux utilisateurs.

Serveur DHCPC 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 descontrôleurs de domaine.

Outils de management du réseauC 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érielet logiciel. Les outils permettant cette gestion sont par exemple : prochaine version de



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

Convention d'attribution des nomsC 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 lesigle de l'unité organisationnelle (ex : SICServe01, SICCompta, ...). Cette convention estabsolument nécessaire. Il ne faut pas en retarder la mise en place, malgré lesmodifications organisationnelles planifiées.

Recommandations générales à long terme relatives à la politique de création d'unitésorganisationnelles en remplacement de domaines enfantsla création des domaines enfants permet d’implémenter une stratégie de sécurité différentedans 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, rendplus complexe l'ensemble et de ce fait augmente les risques de problèmes. Il est nécessairede réduire le nombre de domaines au nombre de départements ou facultés. La multiplicationdes domaines peut être évitée par l'implémentation d'unités d’organisation (OU). Une OUpermet de déléguer les droits d'administration à un groupe d'administrateurs et de les rendrepratiquement autonomes par rapport aux administrateurs du domaine. L'implémentationd'OU implique une formation moins lourde pour ses futurs administrateurs comparée à cellenécessaire pour la gestion d'un domaine. Elle évite par ailleurs l'installation des composantsnécessaires à un nouveau domaine (contrôleurs de domaines, ...). Un domaine peut contenirplusieurs OU. Le passage d'un domaine enfant à une OU se fait par déplacement desutilisateurs du domaine dans l'OU d’un autre domaine de la forêt; le domaine devenu inutileest ensuite supprimé. Les administrateurs de chaque domaine supprimé deviendrontadministrateurs 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 domaineC 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êmetemporairement. S'il est indispensable pour des raisons de stratégie de sécurité demots de passe différents, de créer un domaine enfant, les procédures décrites dansl'annexe 2 doivent être utilisées.

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

C il faut être conscient que chaque nouveau domaine implique une augmentation descoûts (personnel système, matériel, ...).

Dans ce nouveau modèle, les membres des nouveaux groupes Entreprise Admins etdans une moindre mesure, des groupes Domain Global Groups (par exemple DomainAdmins) 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 plusieurslimites peut affecter d’autres domaines d'une forêt. Dû au grand nombre de domaines, legroupe Utilisateurs authentifiés doit être considéré comme un groupe peu fiable lors del’attribution des autorisations sur des ressources. C'est pourquoi nous vousrecommandons de placer des entités de grande taille auxquelles on ne peut pas faire unetotale 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



serveurs totalement autonomes.

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

Administration de groupes Exchange 2000L’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 danschaque domaine il existe un groupe avec le nom “Professeurs” par exemple, l’administrationsera difficile. Il est extrêmement important de préfixer les groupes avec le sigle dudépartement ou de la faculté, par exemple MAT Professeurs, GC Professeurs, ChimieProfesseurs. Si un groupe “Professeurs” doit être créé, il contiendra tous les professeurs del’EPFL, mais pour éviter de faire des exceptions, même dans ce cas, il faut ajouter au nomdu groupe EPFL, par exemple “Professeurs EPFL”

Etablissement de directives à l'attention des administrateurs et des utilisateursC création de directives pour administrateurs : procédures d'installation, de configuration,

d'administration, problèmes connus et leur solution, base de connaissancesC organisation de formations et de procédures de contrôle d'acquisition de connaissancesC création de directives à l'attention des utilisateurs pour éviter une utilisation incorrecte du

réseauC é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èglesd'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/restaurationC 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 serviced'annuaire pour chaque contrôleur de domaine, ...;

Une stratégie de sécurité des mots de passe sera définie par domaineC 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



critiques au niveau de la sécurité doivent utiliser des stratégies adaptées au niveau desé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 seuleet unique stratégie de sécurité.

Stratégie d'auditC 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’outilsdumpel.exe du RessourceKit.

Passage de la forêt en mode natifC 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. Iln'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 stationsde travail NT 4.0 Workstation ou Windows 9x. Après le passage en mode natif et leredémarrage de tous les contrôleurs de tous les domaines, l'administration des groupessera largement facilitée.

Amélioration de l'environnement de l'utilisateurC 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 del'utilisateur quelque soit l'ordinateur utilisé;

C installation du service d'installation à distance (RIS) pour permettre le déploiement etla 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 domainenécessite de tout mettre en oeuvre pour éviter des interruptions courtes ou prolongées deleur fonctionnement.

Les mesures suivantes sont proposées :

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

C localisation des contrôleurs de domaine dans 2 bâtiments protégés différents (salle deserveurs 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 serviced'annuaire pour chaque contrôleur de domaine, ...;



C organisation du service d'administration des systèmes afin d'assurer la maintenancecontinuelle (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 desobjets gérés (noms de domaines avec coordonnées de leurs responsables, ...),documentation claire et structurée des utilisateurs/groupes avec leurs droits etpermissions;

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 desdomaines enfants. Un groupe sera chargé de surveiller que toutes les modificationssoient 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 ordresur 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 webqui doivent être accessibles depuis Internet.Selon les spécialistes en sécurité informatique, les contrôleurs du 1er domaine ne doiventpas être autorisés à effectuer des requêtes directement vers Internet. Après l'activationde l'option "ne pas utiliser la récurcivité", en cas de panne des redirecteurs 128.178.15.7et 128.178.15.8, les contrôleurs de domaine ne feront pas de recherche par eux-mêmeet l'accès à Internet sera impossible.Les 2 serveurs DNS Active Directory seront configurés pour autoriser les transferts dezone uniquement vers les serveurs autorisés. Les 2 serveurs DNS Active Directoryaccepteront uniquement les mises à jour sécurisées. Créer une zone de rechercheinversée.Rendre impossible la résolution des noms des contrôleurs de domaine en adresse IPdepuis l'extérieur de l'EPFL. Vérifier qu'aucune délégation n'a été effectuée sur lesserveurs 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 attaquesinternes à 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 parl'ajout d'un 3e contrôleur de domaine installé sur un matériel prévu pour assurer lesfonctionnalités d'un serveur (performance, tolérance de panne, ...)

C Les objets des 2 domaines enfants expo.servers.intranet.epfl.ch etmetadir.servers.intranet.epfl.ch doivent être déplacés dans des unités d'organisation. Unefois le déplacement effectué, le programme dcpromo permettra de supprimer ces 2domaines 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 OUpourra servir d'exemple d'administration entièrement indépendante à l'intérieur d'undomaine. Ce modèle d'administration sera proposé aux différents départements.



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

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

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

Passage du mode de fonctionnement de l’organisation Exchange au mode natifPar défaut, à l'installation de Exchange 2000 Server, le mode d’ opération de l'organisationest en mode mixte. Ce mode permet la prise en compte simultanée de serveurs Exchange5.x dans la même organisation. Le mode mixte implique des restrictions opératoires deExchange 2000 Server. Ces restrictions affectent directement l'usage des groupesadministratifs en forçant Exchange 2000 Server à gérer les groupes administratifs commeExchange 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 natifEn mode natif, Exchange 2000 Server n'est pas soumis aux restrictions impliquées par lacohabitation avec Exchange 5.x. Ce mode permet l'activation du système des groupes deroutage et la création d'autres groupes selon les besoins. Par contre, Exchange 2000 Serverne peut plus cohabiter avec les sites Exchange 5.x dans la même organisation. Le servicePack Exchange 2000 est livré avec un outil de migration qui permet de migrer des sitesExchange 5.5 vers l'organisation Exchange 2000 EPFL. Cet outil de migration nécessite quel'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é depasser en mode natif. Avec ce mode natif, il est possible, dans certaines conditions, dedéplacer un serveur Exchange 2000 d’un groupe administratif vers un autre groupeadministratif.

Mises à jour de destinataires dans des environnements multi-domainesS’il existe des objets destinataires avec accès boîte aux lettres ou messagerie dans undomaine où le service de "mise à jour de destinataire" n'est pas configuré, les adresses demessagerie correspondantes ne seront pas générées. Les objets destinataires sans adressede 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 objetsde l’organisation Exchange EPFLC Octroi de l’accès à des objets Exchange

Il n’est pas recommandé d’octroyer un accès à des objets Exchange. Ces accès peuventdevenir 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 doitpas accéder à d’autres objets de l’organisation Exchange.

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



d'objets pour modifier plusieurs aspects d’un compte d’utilisateur. Toutefois, dans certainscas, ils ne doivent pas avoir un contrôle total sur ce compte. Dans la configuration del'EPFL, les administrateurs Exchange des groupes administratifs sont égalementadministrateurs 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 administratifsLors des entretiens d’audit, les responsables consultés ont appuyé la politique dedécentralisation pour répondre aux besoins d’autonomie des différents départements quidoivent être considérés comme des entreprises différentes. L’utilisation de plusieursdomaines à condition de limiter leur nombre au strict nécessaire a l’avantage d’offrir undegré 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 utilisel’Active Directory pour stocker tous les objets Exchange. L’existence de plusieurs domainesn’est pas la condition suffisante garantissant l’autonomie des domaines enfant. L’utilisationdes groupes administratifs est obligatoire pour assurer le degré d’autonomie desdépartements. Chaque département qui utilise Exchange 2000 dispose d’un grouped'administrateurs qui offre un support technique et une assistance aux utilisateurs de cedé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 desserveurs locaux Exchange 2000. Ils doivent également pouvoir afficher et modifier lespropriétés des utilisateurs dans Active Directory. Le bon fonctionnement d’une structuredécentralisée nécessite une garantie du maintien des conditions nécessaires à cettestructure et un minimum de coordination.

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

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

C Tâches de l'administrateur du département (domaine enfant) Les administrateurs d’un groupe administratif doivent avoir le droit Administrateur intégralExchange au niveau de leur groupe administratif. Ils doivent pouvoir effectuer toutes lesopérations nécessaires au bon fonctionnement des objets situés dans leur groupeadministratif 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ésde la responsabilité de l’administration des utilisateurs et des boîtes aux lettresd'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



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 administratifsChaque serveur Exchange installé par les administrateurs d’un domaine enfant serainstallé dans un groupe administratif distinct avec un nom identique au nom du domaineenfant conformément à la stratégie de nommage décidée, ce qui permet de mieuxidentifier les responsabilités. Les administrateurs des domaines enfants peuvent déciderde déléguer certaines tâches d'administration à un autre groupe. Pour faciliterl’administration, ces tâches doivent être attribuées aux groupes et non directement auxcomptes individuels.

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

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

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

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

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

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

C Recommandations pour le renforcement de la sécurité face aux attaques extrêmes C Protection contre les virus :

Antivirus pour ExchangePlanification 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é commewww.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



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

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

C assurer le minimum de coordination nécessaire entre les départements pour le bonfonctionnement 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 lesserveurs 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 laresponsabilité des administrateurs des départements.

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

Les décisions nécessaires à l'implémentation de l'Active Directory doivent être prise auplus 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 uniquegroupe administratif par un seul groupe d’administrateurs responsables du bonfonctionnement de la messagerie. Interdire l'installation des serveurs Exchange dansles domaines enfants. Cette solution est la plus rationnelle d'un point de vueéconomique. Elle ne nécessite que 2 personnes à plein temps. Une solutiondécentralisée nécessite 2 personnes pour le premier groupe administratif et également2 personnes pour chaque groupe administratif supplémentaire. L'emplacement desserveurs Exchange dans les locaux du SIC présente les meilleures conditions pourgarantir 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 sontles 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 desentités de sécurité dans la forêt locale et doivent être maintenus en tant quecontacts. L’agent de gestion Active Directory de Microsoft Metadirectory Services2.2 peut être utilisé pour créer directement une copie miroir du contenu d’une forêtWindows 2000. MMS permet de filtrer et de mapper les attributs pour lasynchronisation.

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



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

C l'attribution des autorisations aux contacts Active Directory, car ils ne constituentpas des entités de sécurité (ils ne sont pas utilisateurs). Cela diffère d'Exchange5.5 qui mettait en oeuvre son propre modèle de sécurité. Même si l'intégrationWeb renforcée peut résoudre certaines restrictions au niveau de la visibilité, ellerisque 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 EPFLC 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èsadaptation et test.

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



Annexe 1 - Liste des événements à auditer

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

672 Authentication ticket granted673 Service ticket granted674 Ticket granted renewed675 Preauthentication failed676 Authentication ticket request failed677 Service ticket request failed680 Account used for logon681 NTLM authentication request failed

Audit account management

624 User object created630 User object deleted631 Global group added632 Member added to Global group633 Member removed from Global group634 Global group deleted635 Local group added636 Member added to Local group637 Member removed from Local group638 Local group deleted639 Local group changed641 Global group changed642 User object changed644 User account locked out645 Computer object added646 Computer object changed647 Computer object deleted658 Universal group added659 Universal group changed660 Member added to Universal group661 Member removed from Universal group662 Universal group deleted668 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 logon529 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)



538 Successful Iogoff539 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 setrouve)562 Handle closed

Audit policy change

608 User right assigned609 User right removed610 New trusted domain611 Removing trusted domain612 Audit policy change615 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 changed618 Encrypted data recovery policy changed620 Trusted domain information modified

Audit privilege use (More than 34 user rights exists)

576 Special privileges assigned to new logon577 Privileged service called578 Privileged object operation

Audit process tracking

592 New process has been created. ( Lancement d’une application – security.log sur lamachine 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 oul’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érioded’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 LSA517 Audit log was cleared518 The SAM has Ioaded a notification package



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

The central administrators group of intranet.epfl.ch (the root administrator, specifically) alsois responsible for pre-creating subordinate domains across the tree/forest. By performing thispreparatory work, the group can control domain naming conventions, the purpose of thedomain, and who will administer the domains. The central group has several options. It canbuild and configure the child domain controllers at a staging location managed by the centraloffice and then ship them to their destinations. It can install Terminal Services on the serverand allow a group within the central office to connect over the network and execute theDCPROMO process. These alternatives do not require any changes to the Active Directorydefault configuration. They also provide a way to maintain a high level of control over theAdministrator' s accounts in the various child domains, while delegating the day-to-day tasksto other user accounts; this is an advantage but these methods may not meet the needs ofmany decentralized IT organizations.

The group has a third alternative: it can pre-create a cross-reference for the child domain inthe root forest, then set the appropriate ACLs on the Schema, Configuration, and Domainnaming contexts to allow a non-administrative account to execute DCPROMO. This requiresan Enterprise Administrator in the root domain to create a cross-reference object to the childdomain. This object ties together LDAP referrals that span the forest. The child administratorthen 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 anon-Domain Administrator account privileges to complete the process, allows you to delegatethe DCPROMO process but requires the procedure below to prepare the root domain.

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

Root Domain Preparation for Delegation of Child Domain CreationTo 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 domaincontroller in the new child domain).

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

The first step in delegating any task is to identify which user or set of users will be givenpermissions to perform it. You can simplify long-term administration by identifying a groupthen adding users to it as needed. This method allows you to apply all ACL changes to objectsusing the group instead of to individual users. For example, create a Domain Creators Groupin the root domain and add the account Dcreator1. The account will later be used to runDCPROMO. To allow a child administrator to join the tree/forest without any administrativerights 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. Forexample, a user account has Create privileges on an object and the Creator Owner Group isgiven full rights to that object. When the object is created, Creator Owner Group's full rightsare transferred to the user account that created the object. One of the side effects of using thisapproach 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



and allow some other account to take ownership of it.

The Schema and Configuration naming contexts are shared across the Active Directorytree/forest, so the Domain Creators Group must have the rights to read and replicate theircontents. Grant the following permissions to the Domain Creators Group on both theConfiguration (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 itwhenever their TCP/IP subnet is not assigned to an existing site. The Domain Creators groupmust have permission to create a new server in the Default-First-Site. These permissions areapplied to the Default-First-Site container:

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

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

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

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

Child Domain CreationNow 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 utilityNTDSUTIL. You have to be logged on to the root domain with an account that has EnterpriseAdministrative rights, and when you specify the cross-reference to the child domain you mustuse the NetBIOS name of the child domain in UPPER CASE. Here are the steps required topre-create the child domain cross-reference, HB-RES where server2.HB-RES.ISEIG.CH isthe first server in that domain.

1. NTDSUTIL2. Type Domain Management3. Type Connections4. Type Connect to Server SERVER1.ISEIG.CH5. Type quit6. 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



to access the information. Locate the new cross-reference in the Partitions container withinthe Configuration-naming context, then set the permissions. Add the Domain Creators Groupand 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 theparent domain, so you have to allow the Domain Creators Group to create a trust object forthe child domain that is being promoted.

1. Add the Domain Creators Group to the System container under the Domain naming contextand 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 fromis properly registered with DNS. Under the properties of 'My Computer' you will find a dialogbox 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 toverify that the server host record (A) exists.

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

By default the Enterprise Administrator group will have permissions to the child domain. Tocontrol the level of access the members of the root administrators have over the childdomain’s naming context, the child domain administrator can remove the EnterpriseAdministrator 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 otherassociated objects: the root administrator has to perform these tasks, or delegate them to aseparate group or to the individual child domain administrators (discussed in the “SiteManagement” section, below). Create Replica Domain ControllersIt often is necessary to delegate the creation of additional domain controllers to another groupor a third party. in which case you normally give them a user account without administrativerights on the domain, so they can complete the process without affecting any of the otherservers.

As with delegating child domain creation, the recommended procedure is to create a groupfor this process, then add members to it as necessary. The server will hold a copy of theDomain naming context, so you have to allow this group the right to replicate it as well as theConfiguration 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



account, the server must join the domain before it is promoted. This allows you to use anauthenticated 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 serverto start it, so make this group a member of the Machine Local Administrators group. Also, usethe Group Policy object in the Domain Controllers container to give the group the right to logon 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 namingcontext, you have to give this group permission to Read and Write to the server object. Onestep in the promotion process is to move the server object from the Computers container tothe Domain Controllers container. This requires administrative rights, so you need to movethe 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 cancreate the appropriate number of replication links. Give the group the permission to create anew server in the site where it is located:

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

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

Grandchild Domain CreationThe process of delegating grandchild domain creation is similar to the process for childdomains, but it requires coordinated efforts between the administrators of the root forest andthe child domain. At the root domain, you must create the cross-reference object and give FullControl 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 theschema and configuration naming contexts.Because the Kerberos trust is established between a child and its parent domain, you haveto give the Domain Creators Group permission to create the trust object in its parent's domainnaming context. When you create a child domain, you give permission in the root Domainnaming context because the root is the child domain's parent. Now you have to grantpermission in the system container in the child Domain naming context because it is thegrandchild's parent.

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

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

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



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 decompte en utilisant des modèles de sécurité.

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

1. Ouvrir la console2. Ajouter/supprimer des composants logiciels enfichables3. 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 compte6. Développer le modèle - Stratégie de comptes epfl7. 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 console2. 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 groupe3. Modifier la stratégie existante : Default Domain Policy. Il y a une seule et unique Stratégie

de comptes pour un domaine4. 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 Ouvrir9. Fermer la fenêtre de stratégie de groupe ainsi que la fenêtre des propriétés du domaine10. 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é (SecurityConfiguration and Analysis)

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

3. Donner un nom au fichier de base de données qui stockera le résultat de l'analyse puisclic 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 surAnalyser l'ordinateur maintenant..., Chemin… Confirmez

6. Une fois l'analyse terminée, développer chaque point de la stratégie pour vérifier si lesparamètres de la colonne Paramètres de base de données correspondent à ceux de lacolonne 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 surConfiguration et analyse de la sécurité et clic sur : Configurer l'ordinateur maintenant pourrevenir aux paramètres implémentés dans le modèle



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

Introduction

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

Please note that you might not need to explicitly set the roles outlined in this document toperform 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 theadministrative group level

• Exchange Administrator includes Exchange View Only Administrator at the organizationlevel as well as Exchange Administrator and Exchange View Only Administrator at theadministrative group level

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

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

Effective Permissions(right) versus GrantedPermissions (below)

AG:View

AG:Admin

AG: FullAdmin

ORG:View

ORG:Admin

ORG:Full

AdminAG: Exchange ViewOnly Administrator

Yes*

AG: ExchangeAdministrator

Yes* Yes*

AG: Exchange FullAdministrator

Yes* Yes* Yes*

ORG: Exchange ViewOnly Administrator

Yes Yes

ORG: ExchangeAdministrator

Yes Yes Yes Yes

ORG: Exchange FullAdministrator

Yes Yes Yes Yes Yes Yes

Key:* = Local administrative group onlyAG = Administrative group levelORG = Organization level

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



Active Directory Connector

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

To install the first Active Directory Connector (ADC), you will need to update the schema ofthe 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 Directorypermissions:

• 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 /SchemaOnlyswitch 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 theSchema Admins group. An advantage to this method is that, if a company has very strictcontrol over the schema, these people can make the schema adjustments required, and theADC/Exchange administrator can perform his or her job independently.

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

Because the schema has already been updated, you will need the following Active Directorypermissions 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 thisrequired when Exchange 2000 services start as LocalSystem? What permissions will theservice account require?

The ADC requires a service account because a subset of the ADC technology is shipped withthe Windows 2000 operating system. Exchange 2000 has features to prepare the ActiveDirectory forest and domains for installation of the server (with the use of ForestPrep andDomainPrep). Part of this preparation involves setting permissions for LocalSystem servicesto Active Directory. As the ADC can be used without Exchange 2000 installed, a separateservice 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 specifythe credentials for accessing Active Directory and Exchange 5.5 Directory Service. Whatpermissions does this account need?

The permissions that you need are:



• 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



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 organizationobject. Additionally, you will be given the opportunity to specify the first Exchange 2000administrator (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. Bydefault, this domain will be the root domain in the forest.

If I choose to join an existing Exchange 5.5 organization during ForestPrep, what permissionsdo 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’rejoining)

Additionally, you will need to know the service account name and password for the site thatrelates to the server that you specify. If the Exchange 5.5 service account is in a MicrosoftWindows NT® 4.0 domain, you will need to create a one-way trust from the forest root domainto 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 EnterpriseServers local group, and seed (or configure) the permissions so that the Exchange server canaccess Active Directory. To run DomainPrep, you must be logged on as a user with thefollowing permission:

• Domain Admins (of the local domain)

What function do the Exchange Domain Servers and Exchange Enterprise Servers groupsperform?

Both of these groups are created through DomainPrep. They reside in the Users container inthe domain and must not be moved or renamed. Each time Exchange 2000 is installed on acomputer, the computer account is added to the local Exchange Domain Servers globalsecurity group. In turn, this group is a member of the Exchange Enterprise Servers localsecurity group in each domain. The Recipient Update Service is responsible for ensuring thatall Exchange group nestings are complete within the forest. The Exchange Enterprise Serversgroup is given various permissions on the domain naming context in the Active Directory.Through these inherited permissions, the Recipient Update Service is able to modifyExchange-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 ActiveDirectory with the following permissions:



• 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 havethe following permissions to access the Exchange 5.5 directory, and the person installingExchange 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 theorganization 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 ActiveDirectory, will this affect my Exchange permissions and delegation?

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

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

An Exchange Full Administrator is able to manipulate any Exchange object in the configurationnaming context. Additionally, full administrators have permissions to modify the settings onthe 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 abilityto delegate permissions or change the settings on the Security tab on the Exchange objectslisted above.

If I grant a user or group permissions at the Exchange organization level, do theseautomatically 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 thefollowing permissions:

• Either as Exchange Full Administrator (as defined during ForestPrep) or as a delegatedExchange Full Administrator at the organization level

• Member of the local administrative group on the destination computer



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 loggingon to the Active Directory as the Cluster service account. This account will also need thefollowing permissions:

• Either as Exchange Full Administrator (as defined during ForestPrep) or as a delegatedExchange 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 ActiveDirectory domain. You will need to be logged on to the Active Directory as a user who has thefollowing 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 thentell the application to use this account. How can I achieve similar functionality in Exchange2000?

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

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

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

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

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

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



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 ActiveDirectory. 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 youmight encounter some issues such as DSAccess errors in the Event Log. The computeraccount is assigned various permissions in Active Directory during the Exchange 2000 setupprocess. Therefore, run Setup again and select the Reinstall option; the correct permissionswill be granted for your new computer account.

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



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 organizationunit. Second, you need the following Exchange permission:

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

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

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

When you use Active Directory Users and Computers, the mailbox is transferred between thetwo 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 localdomain• 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 theadministrator who runs the tool be a member of the Domain Admins group of the targetdomain.

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 useraccount objects; therefore, you only need the following permission:

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

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



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 tospecify 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 followingpermissions:

• Exchange View Only Administrator role on the administrative group where the connectorexists

• 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 Messagingserver will be created

If you need to change the firewall topology information for Instant Messaging within yourorganization, 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 contextof the Active Directory domain. Enabling a user for Instant Messaging involves changing someattributes on the user account; therefore, you will need to have permissions on theorganizational unit where the user exists. For most companies, the administrator who createsor deletes user accounts and mailboxes will also be responsible for enabling the user forInstant 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 Directoryas 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 Servermanagement?The different administrator roles are able to do different things when it comes to managingExchange Conferencing Server. For example:



• The Exchange Full Administrator role at the Administrative Group level can do thefollowing:• 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 settingsThis 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 Directoryas 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 theExchange Directory and one for the Security Accounts Manager (SAM). Although I can seethe benefits of unified administration with Exchange 2000 and Active Directory, can I still splitout the user creation and mailbox creation roles?

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



Appendix A

Permissions Granted During Setup

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

Permissions on Objects in the Exchange Configuration Tree

Microsoft Exchange containerCn=Microsoft Exchange,cn=Services,cn=Configuration,dc=<domain>Account Allow Deny Inheri

tRight On

PropertyDuring ForestPrep phaseAuthenticatedUsers

a ACTRL_DS_LIST |ACTRL_DS_READ_PROP

Designatedadmin account

a a DS_AM_FULL_CONTROL

During server installExchangeDomain Servers

a a STANDARD_RIGHTS_READ |ACTRL_DS_READ_PROP |ACTRL_DS_LIST

During ADC setupExchangeServices


ADC Connection Agreement containercn=Active Directory Connections,cn=MicrosoftExchange,cn=Services,cn=Configuration,dc=<domain>Account Allow Deny Inherit Right On

PropertyDuring server installExchangeDomain Servers




Organization containercn=<organization>,cn=MicrosoftExchange,cn=Services,cn=Configuration,dc=<domain>Account Allow Deny Inherit Right On

Property/A p p l i e sTo

During ForestPrep phaseAuthenticatedUsers

a ACTRL_DS_LIST_OBJECT |ACTRL_DS_READPROP


a a Send-As


a a Receive-As

During Server install“EnterpriseAdmins”

a a Send-As

“EnterpriseAdmins”

a a Receive-As

“DomainAdmins” ofroot domain

a a Send-As

“DomainAdmins” ofroot domain

a a Receive-As

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_READ |ACTRL_DS_READPROP |ACTRL_DS_LIST |ACTRL_LIST_OBJECT

Applies too b j e c tc l a s s :msExchPrivateMDB


Applies too b j e c tc l a s s :msExchPublicMDB


Applies toobject class:mTA

ExchangeDomainServers

a a DS_AM_CONTROL_ACCESS(i.e., all extended rights)




a a ACTRL_DS_CREATE_CHILD


a a ACTRL_DS_WRITEPROP

P u b l i c -Information(propertyset)


a a ACTRL_DS_WRITE_PROP

Personal-Information(propertyset)



Applies too b j e c tc l a s s :siteAddressing

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 containercn=Address Lists Container,cn=<organization>,cn=MicrosoftExchange,cn=Services,cn=Configuration,dc=<domain>Account Allow Deny Inherit Right On

PropertyDuring Server installAuthenticatedUsers

a a ACTRL_DS_LIST

Addressing containercn=Addressing,cn=<organization>,cn=MicrosoftExchange,cn=Services,cn=Configuration,dc=<domain>Account Allow Deny Inherit Right On

PropertyDuring Server installAuthenticatedUsers

a a STANDARD_RIGHTS_READ |ACTRL_DS_READPROP |ACTRL_DS_LIST



Recipient Update Services containercn=Recipient Update Services,cn=Address ListsContainer,cn=<organization>,cn=Microsoft Exchange,cn=…Account Allow Deny Inherit Right On

PropertyDuring Server installExchangeDomainServers


Administrative Groupcn=<admin group>,cn=Administrative Groups,cn=<organization>,cn=MicrosoftExchange,cn=…Account Allow Deny Inherit Right On

PropertyDuring Server install (set on attribute msExchPFDefaultAdminACL)AuthenticatedUsers

a a Ms-Exch-Create-Public-Folder

Default TLHcn=Public Folders,cn=All Folder Hierarchies,cn=<admin group>,cn=AdministrativeGroups,cn=<organization>,cn=…Account Allow Deny Inherit Right On

PropertyDuring Server install (set on attribute msExchPFDefaultAdminACL)AuthenticatedUsers

a a Ms-Exch-Create-Public-Folder

CA containercn=CA,cn=Advanced Security,cn=<admin group>,cn=AdministrativeGroups,cn=<organization>,cn=…Account Allow Deny Inherit Right On

PropertyDuring KMS installMACHINE$ a a DS_AM_FULL_

CONTROLAuthenticatedUsers

a a STANDARD_RIGHTREAD|ACTRL_DS_READ_PROP



Connections Containercn=Connections,cn=<routing group>,cn=Routing Groups,cn=<admingroup>,cn=Administrative Groups,cn=…Account Allow Deny Inherit Right On

PropertyDuring Server installExchangeDomainServers


Server objectcn=<server>,cn=Servers,cn=<admin group>,cn=Administrative Groups,cn=…Account Allow Deny Inherit Right On

PropertyDuring Server install, if the server is NOT a cluster VMMACHINE$ a a DS_AM_FULL_

CONTROLDuring Server install, if the server IS a cluster VMExchangeDomainServers


Protocols Containercn=Protocols,cn=<server>,cn=Servers,cn=<admin group>,cn=AdministrativeGroups,cn=…Account Allow Deny Inherit Right On

PropertyDuring Server installEveryone a a ACTRL_DS_LIST

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

System Attendant objectcn=Microsoft System Attendant,cn=<server>,cn=Servers,cn=<admingroup>,cn=Administrative Groups,cn=…Account Allow Deny Inherit Right On

PropertyDuring Server install (set on attribute msExchMailboxSecurityDescriptor)LocalSystem a a R E A D _ C O N T R O L |

fsdspermUserSendAs |fsdspermUserMailboxOwner


a a R E A D _ C O N T R O L |fsdspermUserSendAs |fsdspermUserMailboxOwner

5.5 ServiceAccount(if given)

a a R E A D _ C O N T R O L |fsdspermUserSendAs |fsdspermUserMailboxOwner



MTA objectcn=Microsoft MTA,cn=<server>,cn=Servers,cn=<admin group>,cn=AdministrativeGroups,cn=…Account Allow D e n

yInherit Right On

PropertyDuring Server install5.5 ServiceAccount(if given)

a a Send-As

5.5 ServiceAccount(if given)

a a Read-As

Permissions on Other Objects in the Configuration Tree

Deleted Items containercn=Deleted Items,cn=Configuration,dc=<domain>Account Allow Deny Inherit Right On

PropertyDuring ForestPrep phaseDesignatedadmin account

a a STANDARD_RIGHTSREAD |ACTRL_DS_LIST |ACTRL_DS_READPROP |ACTRL_DS_LIST_OBJECT |WRITE_OWNER |WRITE_DAC

During Server installExchangeDomain Servers

a a ACTRL_DS_LIST

Active Directory Connector objectcn=Active Directory Connector,cn=ExchangeSettings,cn=<server>,cn=Servers,cn=<site>,cn=sites,cn=Configuration,…Account Allow D e n

yInherit Right On

PropertyDuring ADC setupExchangeServices


AuthenticatedUsers

a a STANDARD_RIGHTSREAD |ACTRL_DS_READPROP |ACTRL_DS_LIST



MachineEnrollmentAgent objectcn=MachineEnrollmentAgent,cn=Certificate Templates,cn=Public KeyServices,cn=Services,cn=Configuration,cn=…Account Allow D e n

yInherit Right On

PropertyDuring KMS installMACHINE$ a a DS_AM_FULL_CONT

ROL

ExchangeUser objectcn=ExchangeUser,cn=Certificate Templates,cn=Public KeyServices,cn=Services,cn=Configuration,cn=…Account Allow D e

nyInherit Right On

PropertyDuring KMS installMACHINE$ a a READ_CONTROL |

ACTRL_DS_LIST |ACTRL_DS_READ_PROP

MACHINE$ a a Enroll

ExchangeUserSignature objectcn=ExchangeUserSignature,cn=Certificate Templates,cn=Public KeyServices,cn=Services,cn=Configuration,cn=…Account Allow Deny Inherit Right On

PropertyDuring KMS installMACHINE$ a a READ_CONTROL |

ACTRL_DS_LIST |ACTRL_DS_READ_PROP

MACHINE$ a a Enroll



Permissions on Objects in the Domain Naming Context

Domain containerdc=<domain>Account Allow Deny Inherit Right On

PropertyDuring DomainPrep phaseExchangeEnterpriseServers


P u b l i c -Information(p roper t yset)

ExchangeEnterpriseServers


Personal-Information(p rope r tyset)



groupType


a a DS-Replication-Manage-Topology

Domain proxy containercn=Microsoft Exchange System Objects,dc=<domain>Account Allow Deny Inherit Right On

Property During DomainPrep phaseExchangeEnterpriseServers

a DS_AM_FULL_CONTROL



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

Property

During DomainPrep phaseAll org-levelfull Exchangeadmins






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

PropertyDuring DomainPrep phaseAll org-levelfull Exchangeadmins






Appendix B - Exchange 2000 Role Permissions

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

Exchange Full Administrator

Description: The selected user and group can fully administer Exchange system informationand 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 (Thisobject 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 (Thisobject 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 (Thisobject and sub-containers)

Exchange View only Administrator

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



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 ListsContainer, Addressing, Global Settings, System Policies (This object and sub-containers)



Appendix C - Additional Resources

Microsoft Exchange 2000 Server Resource Kithttp://mspress.microsoft.com/prod/books/4355.htmMicrosoft Windows 2000 Server Resource Kithttp://mspress.microsoft.com/prod/books/1394.htm

Microsoft Knowledge BaseTo 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



Annexe 5 - Mesures de protection de l’unité d’organisation Domaincontrollers et de sa stratégie par défaut Default DomainControllers Policy

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

Exemple : un administrateur peut modifier la stratégie par défaut Default Domain ControllersPolicy 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 lesutilisateurs d’ouvrir des sessions ou d’accéder aux dossiers partagés dans le domaine, yinclus au dossier partagé sysvol contenant les stratégies. On pourrait croire qu’il est possibled’ouvrir une session localement sur un contrôleur de domaine et de modifier à nouveau lastraté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 desstraté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 lepartage réseau sysvol, même si la session est ouverte en local. Une restauration forcée seranécessaire pour prendre le contrôle de l’Active Directory. La modification incorrecte des deuxstratégies par défaut peut avoir des conséquences désastreuses. Pour cette raison, il estimportant de déléguer correctement les droits administratifs en suivant la règle des droitsminimes. Il est nécessaire de prendre des dispositions particulières pour éviter qu’unadministrateur du domaine ou de l’entreprise modifie par erreur une des stratégies par défauten croyant modifier la stratégie de son Unité d’Organisation. Pour assurer un bon fonctionnement de l’Active Directory, le bon fonctionnement desstraté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 êtreappliquées à n’importe quelle unité d’organisation qui détient des ressources critiques auniveau de la sécurité et qui sont administrés par des administrateurs compétents. Parexemple, il serait parfaitement possible de créer une unité d’organisation pour chaquedépartement ou faculté. Seuls les administrateurs chargés de l’administration des ressourcesdu département pourront les administrer sans crainte qu'un autre administrateur del’entreprise prenne des dispositions contraires. Les mesures de protection conseillées pourles 2 stratégies qui existent par défaut dans chaque domaine peuvent constituer un modèlepour décentraliser l’administration des ressources dans un domaine et éviter la création dedomaines supplémentaires sous prétexte de pouvoir bénéficier d’une autonomied’administration. Les possibilités de délégation des droits administratifs de Windows 2000sont 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 deles effectuer doivent être déléguées. Actuellement, beaucoup d’administrateurs sontintéressés à installer un domaine juste pour apprendre à l’installer. A long terme cesadministrateurs moins intéressés par le travail routinier d’administration et de sauvegarde desressources peuvent négliger l’exécution de tâches routinières critiques au bon fonctionnementdu réseau. Cet exercice prouve une fois de plus que Microsoft a raison de répéter que mêmedans un environnement décentralisé, il n’est pas nécessaire de créer plusieurs domainescomme c’était le cas avec Windows NT.



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évuepour les contrôleurs de domaine. Vous allez enlever les groupes Administrateurs, Admins del’Entreprise et Administrateurs du domaine de la liste des groupes autorisés à modifier lastraté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 quiont été définis dans la stratégie du domaine doivent s’appliquer aux contrôleurs dedomaine, il est nécessaire de modifier la stratégie Default Domain Controllers Policy pourles 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 groupeque vous avez créés Domain Controllers GPO Admins.

Vous venez de prendre les mesures nécessaires pour empêcher les administrateurs demodifier, par erreur, la stratégie par défaut. Les administrateurs peuvent toujours prendrepossession 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 accordentdes autorisations aux administrateurs, administrateurs de l’entreprise ou Administrateursdu domaine.

Ces changements empêchent les administrateurs de modifier accidentellement la stratégiepar défaut pour les contrôleurs de domaine, de créer d’autres stratégies dans l’OU DomainControllers 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 siteou du domaine et de forcer l’application avec le paramètre No override. No override estprioritaire 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 surSécurité.

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

Pour garder le contrôle sur les modifications des stratégies, vous devez administrercorrectement les permissions associées au OU. La liste et les options observées sur l’ongletGroup Policy dans les Propriétés d’une OU correspond à 2 propriétés qui existent sur chaqueOU : GpLink et gpOptions. GpLink correspondent à la liste des GPOs qui apparaît dans lesproprié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



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

• Pour observer les permissions sur une OU dans Propriété de l'OU, sélectionnez l’ongletSécurité : Clic sur Advanced…

• Double-cliquez sur n’importe quel ACL (accès control entries) et sélectionnez l’ongletPropriétés :

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



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 quilui est propre. Ce mot est spécifié pendant la promotion à l’aide de dcpromo.exe mais il n’estjamais changé. Il est probable que certains administrateurs ont oublié ce mot de passerarement 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 serviced’annuaire même si vous ne pouvez pas ouvrir une session en mode de restauration duservice 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 etpatientez pendant 20 minutes environ. Au lieu de l’économiseur d’écran vous obtiendrez unefenêtre de l’invité de commande avec les privilèges de sécurité du compte système del’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



Annexe 7 - Utilisations des groupes Exchange 2000

Utilisation des groupes globauxSeule la définition du groupe global (et non pas les adhésions) est répliquée dans lecatalogue global. L'impact de cette fonction est positif sur le plan de la réplication, car ladé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 duserveur 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 peutinterroger 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 Exchangepromu au rang de contrôleur de domaine Active Directory.

Utilisation des groupes de domaine LocalLa 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 ressourcesréseau. Ainsi, un groupe de domaine local contient en général des groupes globauximbriqué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 dansle catalogue global, de sorte que le développement des groupes globaux doit se produire surun contrôleur de domaine local.

Utilisation des groupes universelsLes 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 dedistribution ou des groupes de sécurité. Dans un environnement en mode mixte, les groupesuniversels peuvent être uniquement constitués de groupes de distribution.Utilisez les groupes universels dans les environnements qui nécessitent à la fois desadhésions globales et un mode d'utilisation global. Dans le cas contraire, utilisez les groupesglobaux 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 assezfacile d'imbriquer accidentellement des groupes universels jusqu'au niveau où ils contiennentdes 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.



Groupes de sécurité

Avantages Inconvénients

Peuvent être à extension boîte aux lettresen affectant une adresse SMTP, ainsi, legroupe peut agir comme l’équivalent d’uneliste de distribution

L’insertion accidentelle d’utilisateurs dansle groupe peut conférer un accès illiciteaux ressources réseau.

Peuvent être utilisés pour l’affection desautorisations associées aux dossierspublics dans Exchange 2000 Server.

Le jeton utilisateur contient les adhésions aux groupes. Les adhésions à un grand nombre de groupes grossissent le jeton d'accès.

Utiles si vous souhaitez égalementattribuer des autorisations réseau auxmembres de ce groupe.

Réduit le nombre de groupes dans Active Directory et le système de messagerie,ainsi que le temps nécessaire à leurconservation, car ceux-ci peuvent agircomme pseudo-groupes de distribution.

Groupes de distribution


Peuvent être utilisés pour l'envoi demessages en bloc.

Aucune autorisation ne peut être affectée aux ressources réseau.

Peuvent être utilisés pour les groupes universels même dans un domaine enmode mixte.

Aucune autorisation ne peut être affectée aux dossiers publics.

Groupes locaux du domaine


Les adhésions ne sont pas publiées sur le serveur de catalogue global. Ainsi, les modifications apportées aux adhésions ne génèrent pas une réplication du catalogue global.

Aucune autorisation ne peut être affectée aux ressources réseau et aux dossiers publics situés dans d'autres domaines.

Les clients Outlook peuvent visualiser les adhésions complètes des utilisateurs s'ilssont situés dans le domaine auquel legroupe appartient.

Les utilisateurs d'Outlook dans d'autres domaines ne peuvent pas visualiser les adhésions complètes.

Les adhésions peuvent inclure desutilisateurs de n'importe quel domaine.

Les adhésions à un groupe doivent être récupérées à la demande si le développement a lieu dans un domaine distant.



Groupes globaux


Les adhésions ne sont pas publiées sur le serveur de catalogue global. Ainsi, les modifications apportées aux adhésions ne génèrent pas une réplication du catalogue global.

Peuvent contenir des objets destinataires issus du même domaine uniquement.

Les clients Outlook peuvent visualiser les adhésions complètes des utilisateurs s'ilssont situés dans le domaine auquel legroupe appartient.

Les utilisateurs d'Outlook dans d'autres domaines ne peuvent pas visualiser les adhésions complètes.

Les autorisations peuvent être attribuéesaux ressources réseau et aux dossierspublics dans n'importe quel domaine.

Les adhésions à un groupe doivent être récupérées à la demande si le développement a lieu dans un domaine distant.

Groupes universels


Les adhésions peuvent inclure n'importequel objet de la forêt.

Les modifications relatives aux adhésions entraînent la réplication sur les serveurs de catalogue global.

Les utilisateurs d'Outlook de n'importequel domaine peuvent visualiser lesadhésions complètes.

Les groupes universels de sécurité peuvent être créés uniquement lorsqu'un domaine est en mode natif.

Vous n'avez jamais besoin de récupérerles adhésions des contrôleurs de domainedistants.

La flexibilité des groupes universels peut générer des problèmes de sécurité lors d'une imbrication accidentelle.

Peuvent être utilisés dans les domainesen mode mixte lorsque le type Distributionest 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 auxexigences de la liste de distribution. Lors de la planification des groupes, suivez une approchelogique 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 tousles 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.



Annexe 8 - Procédure de mise à jour des destinataires dans desenvironnements 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 quicontient des objets destinataires. Si au moins 1 serveur Exchange 2000 est installé danschaque domaines, les objets requis sont automatiquement créés. Pour les domaines de laforêt intranet.epfl.ch qui n'ont pas de serveur Exchange 2000, cette tâche doit être effectuéemanuellement.

Pour créer manuellement une référence de service de mise à jour de destinataire, leprogramme 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 avecle bouton droit sur "Service de mise à jour de destinataire", et clic sur "Nouveau" permet desé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électionnerle domaine voulu, clic sur OK, puis sur Suivant pour continuer. Dans la deuxième boîte dedialogue, clic sur "Parcourir" pour choisir le serveur Exchange 2000 qui doit exécuter leservice de" mise à jour de destinataire". Le contrôleur de domaine qui doit mettre à jour lesdestinataires dans le domaine est automatiquement sélectionné dans la prochaine boîte dedialogue.



Annexe 9 - Procédure d'octroi des accès à l'organisation, au groupeadministratifs et aux objets de l’organisation ExchangeEPFL

C Octroi d’autorisations au niveau de l’organisation ExchangeUn groupe universel avec un nom du style "Administrateurs Exchange" doit être créé pourinclure tous les administrateurs qui doivent administrer l’organisation Exchange. Sur unordinateur, Regedt32 doit être utilisé pour configurer le Gestionnaire système Exchangeafin d’afficher l’onglet Sécurité de tous les objets :

C Regedt32, HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdminC Clic une fois sur EXAdmin, Edition, Ajoutez une valeur, DWORD, puis nommez la valeur

ShowSecurityPageC 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 Exchangeet accordez-lui Administrateur intégral Exchange.

Attribuez aux administrateurs des domaines enfants le droit "Administrateur ExchangeAffichage seul" au niveau de l’organisation Exchange.

Contrôlez attentivement les autorisations au niveau de l’organisation Exchange etdocumentez les groupes qui ont des droits au niveau de l’organisation Exchange. Cesautorisations seront héritées au niveau des objets enfants. Si l’héritage au niveau desGroupes administratifs n’est pas souhaité, il est possible de l’interrompre. Dans ce cascopiez les autorisations existantes et modifiez-les pour supprimer les groupes despersonnes qui ne doivent pas accéder à votre groupe administratif. Windows 2000 permetd’ajouter ou d'enlever de la liste des permissions plusieurs groupes d’ordinateurs quiapparaissent sur la liste des groupes ensemble avec les groupes d’utilisateurs. Neconfondez pas les utilisateurs avec les ordinateurs. N’ajoutez pas et ne supprimez pas lesautorisations accordés par Windows 2000 aux ordinateurs.

C Octroi d’autorisations au niveau des groups administratifsLes administrateurs d’un domaine enfant (ou d'un autre groupe créé spécialement) doiventavoir tous les droits nécessaires sur leur groupe administratif. Il est souhaitable de réaliserune correspondance directe entre un groupe administratif et un domaine enfant pourfaciliter l’administration.

Utilisez l’Assistant Délégation d’administration Exchange pour attribuer à ce grouped’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



Etant donné que les listes de distribution contiennent souvent des informationsconfidentielles sous forme de données d’adhésion, il est important de planifier avec soinl’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 etenvoyer 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 dubon fonctionnement de l'organisation Exchange. Ce groupe a besoin de pouvoiraccéder à la totalité de l’organisation Exchange pour mener à bien leur mission.

C Octroi de l’accès aux groupes administratifsLes administrateurs qui ont besoin de pouvoir accéder à la totalité des objets d’ungroupe administratif sont les Administrateurs des différents départements quirépondent aux appels des clients de ces départements. Ils doivent être en mesured’afficher les paramètres de configuration des serveurs, de gérer tous les aspects dugroupe administratif et des objets stratégie.

C Octroi des autorisations à l’aide de ADSI EditCertaines autorisations ne peuvent pas être accordées à l'aide du gestionnaireSystème Exchange. Par contre, l'utilitaire ADSI Edit permet d'accorder toutes lesautorisations. Dans l’Active Directory, chaque groupe administratif se présente sousla 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 GroupCN=Nom d’un autre group administratif (département)

Pour accorder des autorisations à un groupe, il suffit d’ajouter ce groupe à la liste desgroupes 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 cegroupe administratif. Il est préférable d’utiliser l’Assistant Délégation d’administrationExchange au lieu de l’utilitaire ADSI Edit pour gérer les autorisations des groupes



administratifs. Il est probable que les possibilités supplémentaires de ADSI Edit neseront pas nécessaires. Des affectations d’autorisations incorrectes effectuées à l’aidede ADSI Edit peuvent entraîner de sérieux problèmes de configuration et nécessiterla restauration des systèmes à partir d’une sauvegarde. Une documentation desautorisations accordées est nécessaire pour assurer le bon fonctionnement del’organisation Exchange. Une formation spécifique à l’utilisation des groupesadministratifs Exchange 2000 est nécessaire.



Annexe 10 -Procédure de vérification des messages entrants à larecherche de pièces jointes .vbx, .bat, .exe

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

Documents

Audit de l'Infrastructure Microsoft Active Directory (Domaine SG) Et