Windows Server 2008 R2 Server Core : Sécurisation de la connexion de succursale
Paul Yu
En matière de prise en charge, peu d'environnements posent davantage de défis que les bureaux distants. L'établissement et la maintenance de connexions sécurisées présentent une foule de défis techniques et procéduraux. On peut en dire autant de tout centre de données auquel un bureau distant est connecté.
Les bureaux distants sont généralement répartis sur une zone géographique étendue, sont souvent assez nombreux, chacun a une population d'utilisateurs relativement faible, ils sont connectés à des sites de centre de données par le biais de liaisons réseau lentes et il y a rarement un responsable informatique expérimenté sur place. Chaque facteur en lui-même est source de défi. Combinés, tous ces facteurs provoquent immanquablement des maux de tête.
Bien que la plupart des environnements de succursales présentent le plus souvent un ensemble de caractéristiques similaires (comme celles mentionnées plus haut), il existe également des exigences spécifiques aux organisations qui déterminent le mode de fonctionnement de l'environnement. L'importance de la sécurité ou le degré de centralisation des ressources technologiques peut varier d'une infrastructure de bureaux distants à une autre. Quel que soit le mode de fonctionnement des succursales, Windows Server 2008 R2 présente de nouvelles opportunités de déployer une technologie mise à jour qui modifie radicalement la façon dont vous pouvez déployer et tirer profit des contrôleurs de domaines dans les environnements distants.
Une solution sécurisée
La sécurisation de déploiements de succursales est un scénario courant pour les services de domaine Active Directory (AD DS, Active Directory Domain Services). Les contraintes et caractéristiques uniques aux environnements distants conviennent parfaitement aux services AD DS. Windows Server 2008 R2 propose un grand nombre de nouvelles fonctionnalités et d'approches mises à jour pour le déploiement des services AD DS. Explorons comment déployer Windows Server 2008 R2 dans ce type d'environnement de manière sécurisée. Nous examinerons les caractéristiques courantes des succursales, les principaux éléments de conception architecturale et les options de déploiement recommandées spécifiques au déploiement de Windows Server 2008 R2.
L'aspect le plus remarquable de Windows Server 2008 R2 concerne les contrôleurs de domaine en lecture seule (RODC, Read-Only Domain Controller). En règle générale, les contrôleurs de domaine en lecture seule sont déployés à des emplacements qui requièrent des services de contrôleur de domaine mais ne disposent pas des mesures de sécurité physique appropriées. Étant donné les fonctionnalités de gestion et de sécurité améliorées, le remplacement de contrôleurs de domaine existants par des contrôleurs de domaine en lecture seule peut dépasser les exigences existantes liées aux services AD DS dans de nombreux environnements de succursales. Pour les emplacements où il n'existe actuellement aucun contrôleur de domaine, les contrôleurs de domaine en lecture seule représentent une réelle opportunité d'introduire les services AD DS dans l'environnement.
L'un des autres facteurs importants est la version mise à jour de Server Core, une option d'installation de Windows Server 2008 R2 qui procure un environnement minimal pour l'exécution de rôles de serveurs spécifiques pris en charge tels que le rôle Contrôleur de domaine. La sélection de Server Core installe uniquement le sous-ensemble de fichiers binaires requis par le rôle de serveur installé (dans notre cas précis, le rôle de contrôleur de domaine en lecture seule). Cette installation minimale réduit la surface d'attaque et la maintenance, et facilite la gestion. Elle contribue également à ce que le serveur RODC s'exécute sur moins de ressources.
Une grande partie de ces facteurs pouvant aider à atténuer les contraintes couramment associées aux environnements de succursales, Windows Server 2008 R2 Server Core et les contrôleurs de domaine en lecture seule constituent une option incontournable pour tous les environnements distants. Les considérations suivantes relatives au déploiement présentent en détail les options de configuration et de déploiement spécifiques aux composants Server Core et RODC.
Cette configuration exacte est assez commune, mais elle peut ne pas répondre aux exigences de succursales de toutes les organisations. Par exemple, la plupart des aspects principaux de cette configuration sont déjà soulignés dans le guide actuel de méthodes conseillées pour la Boîte à outils Windows Server 2008 Security Compliance Management Toolkit.
Voici une description des principales considérations relatives au déploiement associées à l'établissement d'une solution de contrôleurs de domaine en lecture seule Windows Server 2008 R2 Server Core sécurisée pour des environnements de succursales. Sont traités entre autres les hypothèses de solution, les éléments de conception importants, les conditions préalables pour l'infrastructure et d'autres options de déploiement détaillées.
Planification de conception préliminaire
Comme avec tout déploiement de contrôleurs de domaine, vous devez prendre certaines décisions de conception critiques avant le déploiement. Vous devez par exemple évaluer les exigences matérielles, décider de la stratégie de mise à niveau logicielle, déterminer la conception des serveurs RODC et identifier l'ordre de mise à niveau des contrôleurs de domaine. Ces décisions détermineront le processus de déploiement global et les configurations disponibles.
D'un point de vue de l'évaluation du matériel, vous devez déterminer si votre matériel de contrôleur de domaine existant est conforme aux exigences recommandées. Ceci ne devrait pas poser de problème pour la plupart des organisations, car il existe des spécifications bien documentées. En ce qui concerne les itinéraires de mise à niveau logicielle pris en charge, il existe plusieurs options qui varient selon les versions, les éditions et les différentes options d'installation de Windows.
Server Core nécessite une nouvelle installation des contrôleurs de domaine de succursales. Il n'existe aucun moyen d'effectuer une mise à niveau vers cette option d'installation. En ce qui concerne les rôles de serveurs installés, pour des raisons de sécurité il est généralement recommandé que tous les rôles de serveurs et services non nécessaires au fonctionnement du contrôleur de domaine en lecture seule soient éliminés de la conception de serveur. Cette solution RODC stipule que les contrôleurs de domaine en lecture seule Windows Server 2008 R2 Server Core n'hébergent aucun rôle de serveur ou service supplémentaire autre que ceux de catalogue global et serveur DNS, cette approche étant de plus en plus répandue dans les entreprises.
L'ordre dans lequel vous déployez vos contrôleurs de domaine est un autre aspect critique du processus. L'ordre recommandé nécessite d'installer d'abord les services AD DS dans les centres de données sur des serveurs membres Windows Server 2008 R2 tout nouveaux pour chaque domaine, en commençant par la première forêt, puis de transférer tous les rôles de maître des opérations applicables pour chaque domaine sur ces contrôleurs de domaine. Continuez à déployer les emplacements de centres de données et à mettre complètement hors service tous les contrôleurs de domaine dans ces sites. Ceci aide à stabiliser les services AD DS dans un emplacement à grande échelle et bien administré. Cela contribue également à simplifier le processus de déploiement des contrôleurs de domaine en lecture seule proprement dit. Une fois que vous avez remplacé les contrôleurs de données des centres de données, vous pouvez commencer à travailler sur les contrôleurs de données des succursales.
Préparation des domaines et de la forêt Windows Server 2008 R2
Avant de déployer un contrôleur de domaine Windows Server 2008 R2 dans l'environnement existant, vous devez préparer les domaines et la forêt Active Directory en exécutant Adprep.exe. Tout d'abord, mettez à jour le schéma de forêt sur le contrôleur de domaine qui héberge le rôle de maître d'opérations de schéma avec la commande adprep /forestprep. À ce stade, vous pouvez mettre à jour la forêt afin d'autoriser l'installation RODC avec la commande adprep /rodcprep. Pour préparer chaque domaine enfant, vous devez exécuter la commande adprep /domainprep /gpprep sur le contrôleur de domaine qui héberge le rôle de maître d'infrastructure.
Pour finir, vous devez déployer au moins un contrôleur de domaine accessible en écriture et exécutant Windows Server 2008 R2 dans le domaine où résideront les contrôleurs de domaine en lecture seule. Notez que pour les environnements où vous avez exécuté la version Windows Server 2008 des commandes Adprep.exe, la mise à niveau vers Windows Server 2008 R2 nécessite que vous réexécutiez toutes les commandes avec la version R2, à l'exception de adprep /rodcprep, qui ne présente aucun changement par rapport à la version Windows Server 2008.
Positionnement des contrôleurs de domaine en lecture seule
D'un point de vue de la conception architecturale, les considérations relatives au positionnement des contrôleurs de domaine en lecture seule ont changé avec l'introduction de la stratégie de réplication de mot de passe. Par exemple, les contrôleurs de domaine en lecture seule doivent être en mesure d'établir une réplication des partitions de domaines avec un contrôleur de domaine Windows Server 2008 R2 accessible en écriture. La plupart des environnements de succursales étant abonnés à des topologies réseau Hub and Spoke, les sites AD DS RODC seront probablement séparés par une liaison de site unique et à faible coût vers le site du centre de données, où se trouve les contrôleurs de domaine Windows Server 2008 R2 accessibles en écriture.
Dans les cas où cela n'est pas applicable, vous pourrez déployer des contrôleurs de domaine accessibles en écriture supplémentaires dans des sites intermédiaires, déployer de nouveaux ponts entre liens de sites ou créer des liens de sites afin de contrôler le mode de création de connexions de réplication. Vous devez également vous assurer qu'aucun autre contrôleur de domaine n'est placé dans le même site AD DS que le contrôleur de domaine en lecture seule. Cette condition ne s'appliquera sans doute pas à la plupart des environnements de succursales, qui hébergent généralement un nombre de serveurs minimal. Pour les emplacements qui hébergent plusieurs contrôleurs de domaine, il se peut que le déploiement de contrôleurs de domaine en lecture seule ne soit pas une solution acceptable.
Mise en cache des informations d'identification
L'élément de sécurité le plus crucial ici est peut-être le modèle de mise en cache des informations d'identification. Il s'agit d'un composant de conception critique qu'il vous faudra soigneusement étudier avant de commencer le déploiement de succursales. Pour bon nombre d'environnements, le modèle du type « peu de comptes pouvant être mis en cache » sera probablement le modèle le plus courant et le plus approprié.
Cette approche, selon laquelle seuls les comptes locaux dans un site RODC sont configurés comme pouvant être mis en cache, fournit des conditions convenables quant au principe du moindre privilège et à la disponibilité de service. L'un de ses inconvénients est qu'elle entraîne une augmentation des responsabilités administratives, car la stratégie de réplication de mot de passe de chaque contrôleur de domaine en lecture seule sera unique et nécessitera une mise en service et hors service opérationnelle des comptes selon les besoins.
Le mode de gestion des utilisateurs itinérants est l'un des autres problèmes de conception attendus dans de nombreux environnements de succursales. Il arrive souvent que les environnements de succursales comportent des utilisateurs et des ressources dont le compte doit être mis en cache sur certains contrôleurs de domaine en lecture seule à des fins de disponibilité de service. Dans l'idéal, ces comptes seront mis en service au préalable, de manière semblable aux nouveaux employés. Cependant, étant donné la nature aléatoire et imprévisible du comportement itinérant, cette option est souvent impossible, en particulier pour un nombre élevé de ressources qui se déplacent parmi de nombreux emplacements RODC.
Pour résoudre ce problème, vous pourriez ajouter des comptes supplémentaires aux stratégies de réplication de mot de passe RODC appropriées. Pour les cas extrêmes dans lesquels un groupe de comptes requiert un accès autorisé sur toutes les stratégies de réplication de mot de passe RODC, vous pouvez également tirer profit du groupe par défaut « Groupe de réplication dont le mot de passe RODC est autorisé ». Ce groupe de sécurité doit néanmoins être utilisé avec caution, car tous ses membres peuvent être mis en cache sur tous les contrôleurs de domaine en lecture seule.
L'une des autres considérations concerne le moment où des comptes sont réellement mis en cache. Par défaut, cela ne se produit qu'après l'ouverture de session initiale sur un contrôleur de domaine en lecture seule, lorsque la demande d'authentification est transférée à un contrôleur de domaine Windows Server 2008 R2 accessible en écriture et que les informations d'identification sont répliquées sur le contrôleur de domaine en lecture seule. Les environnements de succursales qui hébergent des contrôleurs de domaine existants présentant la plupart du temps des conditions préalables en matière de disponibilité de service, l'option de préremplissage des informations d'identification sur les contrôleurs de domaine en lecture seule peut être critique.
Ceci peut être particulièrement important lors du déploiement initial d'un contrôleur de domaine en lecture seule lorsque tous les comptes du site RODC n'ont pas encore mis en cache leurs informations d'identification. Dès que la stratégie de réplication de mot de passe est configurée et que les comptes sont marqués comme pouvant être mis en cache, vous pouvez utiliser des mots de passe préremplis sur un contrôleur de domaine en lecture seule. Notez toutefois que l'utilisation des deux modes traditionnels de préremplissage de mots de passe présente certaines limitations. À l'heure actuelle, l'utilisation de la console Utilisateurs et ordinateurs Active Directory ou de la commande repadmin n'autorise pas l'utilisation de groupes de sécurité.
Le préremplissage de mots de passe un compte à la fois ou par petits lots sur la base de l'unité d'organisation n'étant pas nécessairement réalisable du point de vue pratique, vous pouvez utiliser des groupes de sécurité à l'aide de scripts. Par exemple, pour utiliser le même groupe de sécurité qui autorise la mise en cache des informations d'identification sur un contrôleur de domaine en lecture seule particulier, vous pouvez recourir au script suivant :
For /F %%a in ('"dsquery group dc=corp,dc=contoso,dc=com -name <Groupname>| dsget group -members"') do (Repadmin /rodcpwdrepl <RODCname> <RWDCname> %%a)
Installation des contrôleurs de domaine en lecture seule avec phase intermédiaire
Parmi les deux méthodes d'installation de contrôleur de domaine proposées par Windows Server 2008 R2, l'option d'installation avec phase intermédiaire est préférable à l'installation directe. La méthode alternative directe équivaut au processus traditionnel disponible dans les versions précédentes de Windows. L'installation avec phase intermédiaire utilise la séparation des rôles d'administrateur, une fonctionnalité de Windows Server 2008 R2 qui délègue aux administrateurs autres que les administrateurs de service la capacité à installer et administrer des serveurs RODC sans accorder de droits Active Directory.
Du point de vue de la sécurité, l'installation avec phase intermédiaire élimine la nécessité d'utiliser des informations d'identification élevées dans les emplacements de succursales qui peuvent ne pas être sécurisés. Pour cette raison, les arguments recommandant que les contrôleurs de domaine soient installés dans le centre de données pour prendre en charge des bureaux distants peuvent ne plus être applicables. L'installation avec phase intermédiaire divise le processus d'installation RODC en deux phases.
La première phase requiert qu'un administrateur des services AD DS crée au préalable un compte d'ordinateur pour le contrôleur de domaine en lecture seule et fournisse des paramètres de configuration tels que le nom d'ordinateur, le site AD DS approprié, les rôles de serveurs à installer, la configuration de la stratégie de réplication de mot de passe et la délégation de séparation des rôles d'administrateur. En guise de méthode conseillée, l'administrateur délégué doit être représenté par un groupe de sécurité et les informations d'identification de chaque membre doivent être mises en cache sur le contrôleur de domaine en lecture seule. Lors de la seconde phase, l'administrateur de serveur RODC délégué utilise ses informations d'identificateur d'administrateur non-services AD DS pour joindre le serveur de groupe de travail au compte RODC créé préalablement et pour achever le processus de promotion RODC.
Source de promotion RODC
Pour la source de promotion RODC, cette configuration utilise l'option d'installation Installation à partir d'un support conjointement avec l'installation avec phase intermédiaire. Cette option réduit de manière significative la quantité de données répliquée sur le contrôleur de domaine en lecture seule durant l'installation des services AD DS. Avec Ntdsutil.exe sur un contrôleur de données Windows Server 2008 R2 accessible en écriture, il existe quatre types de supports d'installation disponibles. Parmi ces quatre types, seuls deux sont ici pertinents : RODC et RODC avec SYSVOL.
Le support RODC est semblable au support Installation complète, mais ne contient pas de secrets mis en cache, tels que des mots de passe. Il s'agit d'une fonctionnalité importante d'un point de vue de la sécurité des succursales. L'unique exigence quant à la production d'un support RODC est qu'un contrôleur de domaine Windows Server 2008 R2 accessible en écriture doit être installé. Le second support d'installation, RODC avec SYSVOL, est en revanche beaucoup plus exigent du point de vue de l'infrastructure. Bien que Ntdsutil.exe crée le support RODC avec SYSVOL, l'utilisation de ce support durant l'installation requiert la réplication DFS (Distributed File System Replication) pour SYSVOL, qui nécessite le niveau fonctionnel de domaine Windows Server 2008 R2.
La plupart des organisations avec des environnements de succursales ne remplissant pas cette condition, il est probable que cette option d'utilisation du support ne sera disponible qu'une fois le déploiement initial terminé. Néanmoins, une fois ce jalon atteint, la migration vers la réplication DFS et l'utilisation des supports d'installation RODC et RODC avec SYSVOL permettront de limiter de manière significative la réplication d'annuaire. Elles permettront également de rendre l'installation ultérieure des contrôleurs de domaine de succursales beaucoup plus performante.
Exécution de DCPROMO
L'Assistant Installation de contrôleur de domaine Active Directory n'est pas disponible lors du déploiement de cette configuration car elle fait appel à des contrôleurs de domaine en lecture seule exécutant Windows Server 2008 R2 Server Core. Vous ne pouvez pas l'utiliser durant la promotion RODC proprement dite. Par conséquent, en plus de l'installation avec phase intermédiaire avec Installation à partir d'un support, un fichier d'installation sans assistance avec Dcpromo.exe installera le rôle de contrôleur de domaine. Du point de vue de la sécurité et de la facilité de gestion, cet aspect de la solution promeut des méthodes de conception de contrôleur de domaine sécurisées et cohérentes, ce qui aide à garantir la configuration et la sécurité des services AD DS dans tout l'environnement de succursales.
En outre, des méthodes de conception automatisées, prévisibles et répétables peuvent minimiser le risque d'introduction de configurations, services et logiciels non autorisés dans le processus de conception par le biais d'une intervention manuelle. Voici un exemple de commande dcpromo et un exemple de fichier de réponses simple :
DCPROMO /unattend:c:\unattend.txt
[DCINSTALL]
ReplicaDomainDNSName=corp.contoso.com
UserDomain=corp
UserName=corp\<delegated RODC security group>
Password=*
ReplicationSourcePath=C: \IFM
Safemodeadminpassword=<password>
Il est important de noter que si des configurations de stratégie de réplication de mot de passe sont incluses dans le fichier et réponses et non durant la phase de création préalable de compte RODC de l'installation avec phase, vous devez ajouter de manière explicite toutes les valeurs de stratégie de réplication de mot de passe par défaut. L'ajout manuel de configurations de stratégie de réplication de mot de passe explicites dans le fichier de réponses remplace la configuration de stratégie de réplication de mot de passe par défaut par les configurations spécifiées dans le fichier de réponses (quelles qu'elles soient).
Réplication
Les contrôleurs de domaine en lecture seule Windows Server 2008 R2 fournissant une réplication unidirectionnelle, le remplacement de contrôleurs de domaine de succursales existants par des contrôleurs de domaine en lecture seule réduit la charge de performance sur les serveurs tête de pont de centre de données qui traitent normalement la réplication entrante pour les contrôleurs de domaine de succursales. Pour les environnements de succursales, cet aspect est significatif. Cela accroît l'évolutivité et peut réduire le nombre total de serveurs nécessaires dans le centre de données.
Les contrôleurs de domaine en lecture seule procurent également une distribution automatique et homogène des objets de connexion entrants parmi les serveurs tête de pont du site concentrateur, ce qui exigeait dans Windows Server 2003 le recours à un outil supplémentaire nommé Adlb.exe. Pour cette raison, il est recommandé de mettre à niveau tous les contrôleurs de domaine de centre de données vers Windows Server 2008 R2 avant de déployer des contrôleurs de domaine en lecture seule. Cela garantit un équilibrage égal de la charge sur les connexions de réplication entrantes et évite d'avoir à recourir à des mesures alternatives pour résoudre les problèmes associés aux surcharges des serveurs tête de pont de centre de données lors du déploiement de contrôleurs de domaine en lecture seule.
Ces conseils détaillés quant à la conception et au déploiement peuvent aider à sécuriser le déploiement en succursales de contrôleurs de domaine en lecture seule Windows Server 2008 R2. Grâce à un examen des aspects clés des caractéristiques des succursales, des éléments de conception architecturale importants et des options de déploiement recommandées, vous serez en mesure de dresser une liste de méthodes conseillées applicables lors des déploiements de succursales RODC.
Paul Yu* (Paul.Yu@microsoft.com) est Conseiller en chef au sein de Microsoft Consulting Services. Il travaille pour Microsoft depuis 10 ans et propose des solutions d'infrastructure d'entreprise destinées aux grandes sociétés commerciales et aux organisations du secteur public.*