LES SERVEURS SONT REPARTIS ENTRE SITE CENTRAL ET SITES DISTANTS
L'avantage de cette solution, par rapport
au scénario 2, n'est pas évident au premier
abord.
Le premier point à considérer est la
réplication Active Directory.
Nous avons positionné un serveur de
domaine (et donc KDC) sur chaque site
distant, supposé
utiliser une liaison bas
débit pour se connecter au site central.
Dans ces conditions, nous allons
créer, au niveau Active Directory, un
objet “ Site ” pour chaque site physique
existant.
L’intérêt est tout d’abord de ne répliquer
qu’à certains intervalles de
temps l’annuaire, probablement au
moment où le réseau est le moins utilisé
comme pendant la nuit.
Chaque site est soit un domaine à
part, soit le même domaine que le site
central, mais dans un “ site ” Active
Directory différent.
Discuter du choix du type de domaine
dépasse le cadre de cet article
sur Exchange 2000, mais fait partie intégrante,
aux premières places, d’un
projet de déploiement Windows 2000 /
Exchange 2000.
Le fonctionnement pour l’utilisateur,
par rapport au scénario, est que
toutes les requêtes auront lieu en
local :
• utilisation du DNS du site pour localiser
le KDC
• utilisation du KDC du site pour la demande
de ticket de session
• accès au serveur Exchange local
D’un point de vue utilisateur, ainsi
que du point de vue du réseau, ce scénario
est de loin le plus performant.
Les inconvénients du scénario 2
s’appliquent aussi ici :
• support et administration compliqués
par la délocalisation des serveurs
• augmentation du nombre de serveurs
(coût)
Auxquels s’ajoute la latence dans la
réplication (due à Active Directory).
Tout ceci doit donc être parfaitement planifié, pour qu’une fois déployés
ces inconvénients aient été maîtrisés.
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
