XI.11.1 Répartition des rôles Active Directory (FSMO) (Jérôme TENEUR)
Il existe 5 rôles FSMO. Ces 5 rôles sont nécessaires au bon fonctionnement de nos domaines/forêts. Chacun de ces rôles ne peut être hébergés que par des contrôleurs de domaine et non par des serveurs membres. Ils ont également des étendues différentes et des domaines de réplication différents. On distingue parmi les 5 rôles :
FSMO Emplacement Rôle DC désigné Contrôleur de schéma Unique au sein
d'une forêt
Distribue des plages RID pour les SIDs
ORS-SRV-AD2 Maître d'infrastructure Unique au sein d'un
domaine
Gère le déplacement des objets ORS-SRV-AD2 Emulateur CPD Unique au sein d'un
domaine domaine. En cas de crash d’un contrôleur assurant un ou plusieurs rôles, ce ou ces plusieurs rôles doivent être transférés manuellement à un autre contrôleur de domaine disponible.
XI.11.2 Gestion des sites et services
Vous pouvez utiliser le composant logiciel enfichable Sites et services Active Directory pour gérer les objets spécifiques aux sites qui implémentent la topologie de réplication inter-site. Ces objets sont stockés dans le conteneur Sites dans les services de domaine Active Directory (AD DS, Active Directory Domain Services).
Nous pouvons donc distinguer les sites Active Directory et y associé les contrôleurs de domaine correspondant.
Ces associations auront un rôle primordial dans la gestion des réplications. En effet nous allons optimiser les réplications en fonction de l’état des liens entre des contrôleurs de domaine.
Enfin, l’association d’un sous-réseau IP à un site Active Directory sera très importante pour l’optimisation des flux inter-site. En effet, si un utilisateur vient interroger un contrôleur, ce dernier vérifiera l’adresse réseau source afin de rediriger l’utilisateur vers le contrôleur le plus proche de lui.
Figure 52 - Sites et services
Annexes 98
XI.11.3 Mise en place de RODC (Jérôme TENEUR)
La notion de RODC, ‘est à dire de « Read Only Domain Controller » est apparu avec Windows server 2008r2. Il s’agit donc, comme son nom l’indique d’une base de données Active Directory en lecture seule. Exceptés les mots de passe utilisateurs, un RODC a une copie de l'intégralité des objets, attributs, classes... d'un AD normal. Evidemment, un poste ne peut en revanche pas modifier celui-ci. Les demandes en lectures sont honorées, tandis que les demandes d'écriture sont transférées à un « vrai » DC, comme par exemple ceux d’Orsay.
Cette nouvelle technologie offre de nombreux avantage. Dans notre cas, cela nous permettra de :
- Filtrer les attributs : Parce que certains attributs sont critiques bien que n'étant pas des mots de passe, il est préférable de ne pas les héberger sur un RODS, au cas où celui-ci serait volé ou compromis. Pour celà vous pouvez ajouter cet attribut à la liste des attributs filtrés, afin de ne pas le répliquer sur les RODC de la forêt.
- Réplication unidirectionnelle : Puisqu'aucun changement ne peut être fait sur un RODC, les DC standards partenaires de réplication ne rapatrient pas de changements (PULL) depuis ceux-ci. Autrement dit, aucune modification d'un utilisateur malicieux ne peut être répliquée vers le reste de la forêt (Ce qui permet également de réduire la consommation de bande passante).
- Séparation des rôles d'administration : Cette séparation permet de déléguer les droits locaux d'administration d'un RODC, sans octroyer au compte concerné de droits sur le domaine en entier. On parle bien sûr d'administration basique, comme le changement d'un driver, ou l'authentification locale sur la machine, pas de création d'utilisateurs.
- DNS en lecture seule : Il est possible d'installer DNS sur un RODC, et celui-ci sera capable de répliquer toutes les partitions applicatives.
Nous Pourrons donc implémenter des RODC à deux niveaux : DMZ d'Orsay
Tout d’abord dans la DMZ où il permettra de maîtriser les flux AD en direction du LAN. Ainsi des services tel que l’Exchange Edge pourrons interroger l’AD sans avoir à emmètre de requête vers le LAN. Nous renforçons donc la notion de DMZ et minimisant sans dépendance au LAN et en renforçant son autonomie.
Sophia Antipolis
Sophia Antipolis est un site à part entière car il est dédier à la production et il ne compte que 80 employés. En partant de ce postulat, nous avons émis l’hypothèse qu’un seul administrateur informatique sera en charge de ce site. Ses besoins administratifs sont ainsi (grâce à RODC) réduits au maintien fonctionnel de l’infrastructure, facilitant ainsi son rôle.
Cette proposition n’est qu’optionnel. Le site de Sophia Antipolis pouvant tout à fait se voir implémenté un AD comme les autres sites.
Annexes 99
XI.11.4 OU et Groupes d'utilisateurs (Jérôme TENEUR)
Les utilisateurs peuvent être distingués par leur site géographique de travail et leur direction d’appartenance.
Visuellement ils seront classés par site géographique, logiquement nous pourrons les administrer en fonctions de leur site géographique mais également en fonction de leur direction.
Ainsi les différentes OU permettrons de classer les utilisateurs :
Figure 53 - OU sites
Ensuite, chaque utilisateur se verra placé dans un groupe permettant de définir sa direction d’appartenance. Ces groupes permettrons de distinguer les utilisateurs, de leurs attribuer des configurations dédiées à leurs activités, ou encore de leurs données des droits d’accès spécifiques aux ressources de l’entreprise (accès en lecture/écriture/exécution sur des partages de fichiers).
L’avantage premier de ces groupes est de simplifier considérablement la maintenance et l'administration du réseau.
Enfin on notera qu’Active Directory met en œuvre deux types de groupes : groupes de distribution et groupes de sécurité. Vous pouvez utiliser les groupes de distribution pour créer des listes de distribution de courrier électronique et les groupes de sécurité pour affecter des autorisations à des ressources partagées.
XI.11.5 Stratégie de groupe (GPO) et OU (Jérôme TENEUR)
Les stratégies de groupe peuvent être considérées en trois phases distinctes - Création de la stratégie de groupe, Liaison des stratégies de groupe et Application des stratégies de groupe.
Dans un premier temps, nous attirons votre attention sur le fait que Windows server 2008 r2 introduit une nouvelle manière de gérer les stratégies de groupe. En effet, celle-ci se fait maintenant au travers d’une console spécifiquement dédié à la gestion des GPO et qui s'appelle GPMC (Group Policy Management Console).
Voici la majeure partie des GPO que nous allons ainsi déployer (les OU des sites distants auront la même arborescence qu’Orsay) :
Figure 55 - Stratégie de groupe Figure 54 - Groupes
Annexes 100
XI.11.6 Organisation Fonctionnelle des OU (Jérôme TENEUR)
Figure 56 - OrganisationFonctionnelle des OU
Annexes 101
XI.11.7 Processus d’administration (Vincent DESSEAUX)
XI.11.7.1 Rappel des besoinsNotre client Aristote souhaite limiter l’utilisation du groupe « Administrateur du domaine », « Administrateur du schéma » et « Administrateur de l’entreprise » en mettant en place une stratégie de délégation de l’administration Active Directory et prenant en compte les éléments suivant :
- La direction informatique disposera en cas d’urgence des accès utilisateurs compris dans ces groupes
- Les équipes informatiques d’administration seront situées sur chaque site avec une compétence limitée au site et auront le moins de privilèges possible
- Il sera impossible d’installer des logiciels sur les contrôleurs de domaine du site mais pourront le faire sur les serveurs membres et ordinateurs du site
- Les équipes informatiques de chaque site ne pourront ajouter/supprimer/modifier des objets stratégies de groupes, mais ont la possibilité d’une part d’attribuer des stratégies de groupes existantes sur une unité d’organisation pouvant être administré par eux, et d’autre part d’effectuer l’analyse des jeux de stratégies résultants
- Les équipes informatiques pourront utiliser les services de bureau à distance pour se connecter sur les contrôleurs de domaines et les serveurs membres de leur site respectif
- Les équipes informatiques pourront effectuer n’importe quelle opération sur les ressources partagées
Dans cette partie d’étude, nous vous présenterons la déclaration des équipes informatiques dans Active Directory ainsi que leurs privilèges et leurs droits qui sont fonction des besoins exprimés.
XI.11.7.2 Déclaration des équipes informatiques et affectations des groupes
Afin de dissocier l’administration informatique par site, en sachant que tout les sites son membres du même domaine, il convient de mettre en place des groupes pour les équipes informatiques de chaque site, ainsi qu’un groupe destiné à la direction informatique. Ces groupes seront présent dans la OU « Groupes » contenu elle-même dans la OU
« Administrateur ». Nous pouvons donc énumérer les groupes suivants ainsi que le type d’utilisateur adéquat devant y être rattaché:
Afin de faciliter l’octroi de certains droits commun aux groupes destinés aux équipes informatiques, nous proposons de mettre en place un groupe supplémentaire qui contiendra comme membre les quatre groupes informatiques.
Nom du groupe Membre de
direction_informatique Utilisateurs de la direction informatique administrateur_Orsay Utilisateurs de l’équipe informatique d’Orsay administrateur_Bayonne Utilisateurs de l’équipe informatique de Bayonne administrateur_SophiaAntipolis Utilisateurs de l’équipe informatique de Sophia Antipolis administrateur_Bruxelles Utilisateurs de l’équipe informatique de Bruxelles
Annexes 102 XI.11.7.3 Connexion des comptes utilisateurs membre des groupes « Equipes Informatiques » et « Direction
Informatique »
Afin que les comptes utilisateurs puissent se connecter depuis le contrôleur de domaine, il convient de déclarer dans les stratégies de sécurité locale (gpedit.msc) du contrôleur de domaine, les groupes autorisés à établir une ouverture de session de manière locale. Cependant et aux vu des attentes d’Aristote, nous proposons de déclarer les groupes « Equipes Informatiques » et « Direction Informatique » membre du groupe « Opérateurs de serveur ». En effet, ce groupe qui est intégré par défaut dans Windows Server dispose de privilèges très limité tel que la non installation de logiciels/rôles sur le domaine, l’impossibilité de modifier des paramètres de configuration sur les postes du domaine, ou bien encore la lecture seule sur les consoles de management.
Nom du groupe Membre de
equipes_informatiques
direction_informatique Opérateurs de serveur
Annexes 103 XI.11.7.4 Déclaration des droits à attribuer dans Active Directory pour chaque groupe
Pour autoriser les groupes précédemment créés à effectuer toutes les opérations Active Directory dans leur site, nous devons créer des règles de sécurité sur les OU correspondant à chaque site et définir les droits qu’on leur octrois dans la OU. Ces droits s’appliquent à des utilisateurs ou groupes du domaine et sont principalement des droits :
- de lecture/écriture, de création/suppression sur les objets pouvant être contenu dans l’OU - de création/suppression de lien d’un objet stratégie de groupe
- d’effectuer des analyses des jeux de stratégies résultants au niveau de l’OU Deux méthodes permettent d’attribuer ces ACL’s dans les OU :
- L’assistant de délégation de contrôle
- Dans les paramètres de sécurité de l’OU (Nécessite d’afficher les fonctionnalités avancées d’Active Directory) Les deux méthodes permettent une configuration aussi complète l’une que l’autre, cependant nous pouvons conseiller l’utilisation de l’assistant de délégation de contrôle lors d’une création de délégation, et la méthode manuelle lors de modifications et suppressions.
Les équipes informatiques se verront octroyer un contrôle total sur l’OU de leur site ainsi qu’un droit de lecture/écriture sur l’OU « groupes » afin qu’ils puissent ajouter les utilisateurs de leur site comme membre d’un des groupes y étant contenu, et auront implicitement qu’un droit de lecture sur les autres objets et conteneur du domaine. Ils devront également pouvoir créer des utilisateurs membre de l’équipe informatique de leur site, pour cela il convient de leur donner le droit de lecture/écriture sur leur groupe respectif. La direction informatique aura quant à elle un contrôle total depuis la racine du domaine et pourra donc en conséquence, administrer à n’importe quel niveau le domaine « vsn-aristote.lan ». L’ensemble des droits précédemment cités devront pouvoir s’étendre aux conteneurs et objets sous-jacent de l’OU qui se voit les droits appliqués. Ci-dessous le tableau permettant de reprendre l’ensemble des OU à appliquer et à qui elles doivent être octroyés :
Type
d’objet Nom canonique de l’objet Membres Droit
Domaine
vsn-aristote.lan direction_informatique Contrôle
total
OU vsn-aristote.lan/Orsay administrateurs_Orsay Contrôle
total
OU vsn-aristote.lan/Bayonne administrateurs_Bayonne Contrôle
total OU vsn-aristote.lan/Sophia administrateurs_SophiaAntipolis Contrôle
total
OU vsn-aristote.lan/Bruxelles administrateurs_Bruxelles Contrôle
total
OU vsn-aristote.lan/Groupes equipes_informatiques Lecture/
écriture
Annexes 104 XI.11.7.5 La gestion de la création de stratégies de groupe
Pour qu’un utilisateur puisse créer, modifier ou supprimer des objets de stratégie de groupe, il faut que celui-ci soit membre du groupe « Propriétaires créateurs de la stratégie de groupe », qui est présent dans le conteneur « Builtin ».
Dans notre cas, seul le groupe « direction_informatique » y sera membre et sera donc à même de mettre à disposition aux équipes informatiques des stratégies de groupes.
Nom du groupe Membre de
Direction_informatique Propriétaires créateurs de la stratégie de groupe XI.11.7.6 L’octroi du droit Administrateur Local pour les équipes informatiques
Il est demandé que les équipes informatiques puissent installer des logiciels sur les serveurs membres et ordinateurs de leur site. Pour permettre ce genre d’opération, il faut que les groupes des équipes informatiques soient membre d’un groupe « Administrateur ».
Le groupe « Opérateurs de serveur » n’étant pas membre du groupe « Administrateur » et devant limiter l’utilisation des groupes « Administrateur du domaine», « Administrateur du schéma» et « Administrateur du domaine», nous proposons que les groupes correspondant aux équipes informatiques ne soit pas membre d’un groupe Administrateur présent sur les contrôleurs de domaine, mais membre du groupe « Administrateur » de chaque machine locale du site qu’ils gèrent.
Pour ce faire, il convient de mettre en place une stratégie de groupe pour chaque site, qui ajoutera sur chaque poste étant intégré dans l’OU correspondant au site, le groupe de l’équipe du site comme étant membre du groupe
« Administrateur » de la machine se voyant appliqué la règle. Le groupe « direction_informatique » devra de même disposer d’une stratégie identique, mais celle-ci s’étendra sur tous les sites.
Ci-joint en annexe un modèles de stratégies de groupe à mettre en place pour la direction informatique et l’équipe informatique d’Orsay, le résultat attendu sur un ordinateur client d’Orsay, ainsi qu’un schéma permettant de définir les stratégies de groupe à appliquer et à quel niveau du domaine.
XI.11.8 L’utilisation du bureau à distance
Il est demandé que les équipes informatiques puissent utiliser les services de bureau à distance pour se connecter sur les contrôleurs de domaines et les serveurs membres de leur site respectif. Pour cela, il convient que
- sur chaque contrôleur de domaine et serveur membre, le service de bureau à distance soit activé - les groupes d’utilisateurs autorisés à établir une ouverture de session sur le serveur soit déclaré
- que les groupes d’utilisateurs concernés soient membre du groupe « Utilisateurs du Bureau à distance » L’activation du service et la déclaration des groupes autorisés à ouvrir une session se feront par le biais de stratégies de groupe déployés sur les OU contenant l’ensemble des serveurs d’un site. La déclaration des groupes d’utilisateurs membre du groupe « Utilisateurs du Bureau à distance » se fera quant à elle de manière manuelle dans Active Directory.
Ci-joint en annexe les modèles de stratégies de groupe à mettre en place ainsi qu’un schéma permettant de définir les stratégies de groupe à appliquer et à quel niveau du domaine.
Annexes 105
XI.11.9 Sauvegarde et récupération d’urgence Active Directory (Jérôme TENEUR)
XI.11.9.1 Rappel des besoinsBien que nous prévoyons la mise en place un cluster de contrôleurs de domaine sur le siège d’Aristote, il est fortement recommandé de planifier régulièrement des sauvegardes de ces contrôleurs de domaine complets avec tous leurs services liés à Active Directory qu’il s’agisse :
De l’annuaire d’Active Directory
Des rôles clés de l’Active Directory (notamment le rôle PDC) Des GPO
Du rôle DHCP Du rôle DNS
XI.11.9.2 Sauvegarde des contrôleurs de domaine
Sachant que l’infrastructure Active Directory de notre client sera basée sous Windows Server 2008 R2, nous allons utiliser la fonctionnalité de sauvegardes présente au sein du système d’exploitation lui-même. Il s’agit de Windows Server Backup qui depuis Windows Server 2008 vient complètement remplacer NTBackup et propose donc une toute nouvelle technologie de sauvegarde.
XI.11.9.3 Présentation de l’utilitaire de sauvegarde Windows Server Backup
Windows Server Backup se base sur la sauvegarde de volumes complets ou de blocs à contrario de NTBackup qui lui, était basé sur les fichiers. Nous allons utiliser la méthode de sauvegarde de volumes (grâce au service VSS : Volume Shadow Copy Service) car celle-ci permettra une restauration plus facile et rapide en cas de problèmes techniques et de besoin de récupération d’urgence.
Un autre avantage est que, comme il s’agit d’un logiciel enfichable dans une console MMC, il dispose de fonctions de prise en main complète à distance.
Le volume sauvegardé sera bien sûr celui qui contient l’annuaire Active Directory (donc le fichier NTDS.dit) et les GPO (dans le dossier SYSVOL) ainsi que la configuration de tous les autres rôles installés sur le contrôleur de domaine.
XI.11.9.4 Quel serveur sauvegarder ?
Dans un premier temps, il est nécessaire de préciser que suite aux paramètres de réplications multi-maître définis précédemment, nous allons sauvegarder un seul serveur parmi les deux d’Orsay étant donné qu’ils sont parfaitement identiques, en dehors de leurs rôles qui, pour rappel, sont définis comme suit1 :
Figure 57 - Rappel des rôles FSMO sur Orsay
Annexes 106 Plus précisément, nous sauvegarderons celui qui dispose du rôle FSMO émulateur PDC donc l’AD2 car c’est un rôle indispensable au bon fonctionnement de l’architecture Active Directory, notamment par exemple au niveau de l’authentification des utilisateurs. De plus, sachant qu’il n’y a qu’un seul domaine dans la forêt de notre client, il n’y a donc qu’un seul émulateur PDC. Si ce rôle tombe, alors ça met notre client hors activité car aucun collaborateur ne pourra s’authentifier sur le réseau.
XI.11.9.5 Précisions sur la méthode de sauvegarde dite « incrémentielle »
La sauvegarde sera incrémentielle, c’est à dire qu’il y aura une toute première sauvegarde complète du volume et que les suivantes seront seulement les différences entre la précédente sauvegarde complète du volume et le volume tel qu’il est au moment de cette sauvegarde. Ceci permet d’économiser énormément de bande passante sur le réseau car il y aura peu de données en transit une fois la sauvegarde primaire effectuée et d’économiser de la place sur le disque dur du serveur de fichiers stockant les sauvegardes.
Enfin, si l’espace disque du serveur de fichiers est saturé, Windows Server Backup se chargera de supprimer les plus anciennes sauvegardes afin de libérer de l’espace de disque pour permettre une nouvelle sauvegarde. Il y a donc une rotation automatique des sauvegardes du contrôleur de domaine.
Nous paramètrerons la sauvegarde incrémentielle afin qu’elle s’enclenche toutes les nuits à 1 heure du matin en semaine.
Et nous planifions également une sauvegarde complète cette fois-ci le weekend. Cette planification s’effectue dans la console MMC via un logiciel enfichable.
XI.11.9.6 Emplacement des sauvegardes
Nous allons également programmer les sauvegardes sur partage réseau. Un serveur de fichiers sera donc nécessaire pour les accueillir. Celui-ci sera situé à Bayonne, le second plus gros site d’Aristote pour des raisons de précaution. En effet, l’intérêt d’avoir des sauvegardes sur le même emplacement que le serveur sauvegardé est moindre puisqu’en cas de gros incident imprévisible (incident météorologique très important comme des inondations par exemple), le serveur de sauvegarde serait alors dans le même état que le serveur sauvegardé, c'est-à-dire complètement inutilisable et donc il n’y aurait aucun moyen de récupérer une quelconque information ou configuration du serveur en question.
Voici un schéma représentant alors la mise en place du serveur de sauvegardes :
Figure 58 - Schéma de la mise en place du serveur de sauvegardes
XI.11.9.7 Conclusion
XI.11.9.7 Conclusion