Meilleures pratiques pour les machines virtuelles de contrôleur de domaine dans Azure – Bien choisir son serveur d impression

Cette publication expliquera les meilleures pratiques et les politiques de prise en charge pour le déploiement de contrôleurs de domaine (DC) en tant que machines virtuelles dans Microsoft Azure.

Qu'en est-il des services de domaine Azure AD?

Dans un passé pas trop lointain, si vous vouliez exécuter une application dans le cloud avec l'appartenance à un domaine et des noms d'utilisateur et des mots de passe cohérents, vous n'aviez pas le choix – vous deviez déployer un ou plusieurs (de préférence 2 ou plus) contrôleurs de domaine en tant que machines virtuelles dans le nuage. Azure Active Directory (AD) n'offrait pas d'appartenance à un domaine et ne pouvait pas offrir le même type d'authentification et d'autorisation de nom d'utilisateur / mot de passe que vous obtenez avec les services de domaine Active Directory.

Cependant, les choses ont changé… légèrement. Azure AD a récemment ajouté les services de domaine en tant que fonctionnalité généralement disponible et prise en charge. Mais fais attention; Les services de domaine Azure AD ne sont peut-être pas ce que vous pensez!

Les services de domaine Azure AD vous permettent de déployer une application dépendante du domaine dans le cloud sans le coût supplémentaire des machines virtuelles qui fonctionnent comme contrôleurs de domaine. Cependant, Azure AD Domain Services n'est pas un autre contrôleur de domaine dans votre domaine existant – en fait, ce n'est même pas votre domaine existant. À l'aide d'Azure AD Connect, vous pouvez cloner votre domaine dans les services de domaine Azure AD. Cela signifie que vos unités organisationnelles (OU), stratégies de groupe, groupes, etc. peuvent vivre dans le cloud, mais dans un domaine différent qui est un clone de votre domaine local.

Si vous souhaitez que votre forêt AD locale soit vraiment étendue dans le cloud, la meilleure option consiste à continuer à utiliser des machines virtuelles exécutant le rôle des services de domaine Active Directory. Je soupçonne que cela finira par changer (j'espère que AD suivra la voie de l'échange). Ma règle d'or est la suivante: si je veux un cloud hybride avec authentification et autorisation intersite, je vais exécuter des contrôleurs de domaine dans le cloud.

Sauvegarde

L'exécution de contrôleurs de domaine en tant que machines virtuelles dans Azure est sûre, tant que vous suivez certaines règles. Si vous exécutez des contrôleurs de domaine exécutant un système d'exploitation antérieur à Windows Server 2012 (WS2012), vous ne devez jamais copier les disques durs virtuels d'un contrôleur de domaine ni le restaurer à partir d'une sauvegarde. Azure prend en charge les fonctionnalités VM-GenerationID de WS2012, vous pouvez donc restaurer en toute sécurité les contrôleurs de domaine à partir de la sauvegarde.

Il y a un peu de «gotcha» avec cette fonctionnalité VM-GenerationID. La pratique normale pour arrêter des machines virtuelles dans Azure est de le faire à partir du portail ou de PowerShell. Cela désallouera la machine virtuelle et réinitialisera le VM-GenerationID, ce qui n'est pas souhaitable. Nous devons toujours arrêter les contrôleurs de domaine à l'aide de la commande shutdown dans le système d'exploitation invité, sinon:

• La base de données AD DS est réinitialisée
• Le pool RID est supprimé
• SYSVOL est marqué comme ne faisant pas autorité

Configuration IP

Vous ne devez jamais configurer la configuration IP d'une machine virtuelle Azure dans le système d'exploitation invité. Un nouveau contrôleur de domaine se plaindra d'avoir une configuration DHCP – laissez-le se plaindre car il n'y aura aucun mal si vous suivez les procédures correctes.

Modifiez les paramètres de la carte d'interface réseau de chaque contrôleur de domaine virtuel dans le portail Azure. Configurez la carte réseau pour utiliser une adresse IP statique et enregistrez cette adresse IP. Vos nouveaux DC seront les serveurs DNS de votre réseau; ouvrez les paramètres du réseau virtuel (VNet) et configurez les paramètres du serveur DNS pour utiliser les adresses IP de vos nouveaux contrôleurs de domaine.

Notez que si vous ajoutez un nouveau contrôleur de domaine à un domaine local existant, vous aurez besoin d'une connexion réseau de site à site et vous devez configurer temporairement le réseau virtuel pour utiliser l'adresse IP de l'un de vos contrôleurs de domaine locaux. comme serveur DNS; cela permettra à votre nouveau contrôleur de domaine basé sur le cloud de trouver le domaine afin qu'il puisse le rejoindre.

Fichiers de contrôleur de domaine

Je fais rarement attention à quoi que ce soit dans l'assistant lors de la promotion d'un nouveau contrôleur de domaine; tout est suivant-suivant-suivant, et je doute que je sois unique. Cependant, il y a un écran très important que vous ne devez pas négliger.

Azure implémente la mise en cache d'écriture sur le disque du système d'exploitation des machines virtuelles. Cela entraînera un problème pour les bases de données telles que AD, ce qui peut entraîner une corruption telle qu'une restauration USN. Vous devez ajouter un disque de données, avec la mise en cache désactivée, à la machine virtuelle et utiliser ce nouveau volume pour stocker:

• Base de données AD DS
• Journaux
• SYSVOL

Il n'y a aucun coût supplémentaire pour cela si vous utilisez des disques de stockage standard; le stockage standard est facturé en fonction des données stockées et non de la taille globale des disques déployés. Notez que les frais d'instance Azure Backup sont basés sur la taille des disques, mais vous ne devriez pas avoir besoin de tant de données que vous dépasserez la fourchette de prix de 50 Go à 500 Go pour engager des frais d'instance supplémentaires.

Topologie Active Directory

Si vous travaillez dans une grande entreprise, vous vous êtes probablement déjà rendu compte que ce serait une bonne idée de définir une topologie AD pour votre nouveau site (Azure). Cependant, vous êtes nombreux à travailler dans le monde des petites et moyennes entreprises, vous n'avez donc jamais eu à faire grand-chose dans les sites et services AD.

Vous devez déployer les éléments suivants pour chaque région dans laquelle vous déployez des contrôleurs de domaine Active Directory dans:

• Un site AD
• Une définition de réseau pour chaque espace d'adressage dans Azure qui aura des membres de domaine. L'association de cette définition à un site contrôlera le trafic d'authentification / autorisation et de réplication AD
• Un lien de site pour contrôler le flux et le calendrier du trafic de réplication AD – essayez de tirer parti des liens à moindre coût si vous avez le choix.

Vous pouvez effectuer une ingénierie avancée de la réplication AD pour réduire les coûts de transfert de données sortantes. Soyez prudent car une ingénierie AD avancée peut avoir des conséquences inattendues!

• Vous pouvez introduire désactiver l'option Bridge All Site Link d'un lien de site pour empêcher la réplication intersite transitive.
• Si vous avez plusieurs liens de sites vers vos sites Azure, vous pouvez ajouter des coûts aux liens pour imiter les coûts de vos réseaux. Par exemple, un VPN de site à site peut être plus rentable qu'une connexion ExpressRoute.
• Si vous avez un grand nombre de transactions de données dans vos sites Azure qui n'affectent pas vos sites locaux, vous pouvez réduire la fréquence de réplication pour éviter la réplication redondante.
• Vous pouvez désactiver la notification de modification pour réduire davantage la réplication – faites attention à cette fonctionnalité!
• La modification de l'algorithme de compression de réplication peut réduire les coûts réseau. L'algorithme de compression DWORD HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services NTDS Parameters Replicator contrôle l'algorithme utilisé. La valeur par défaut est 3 (Xpress Compress). La modification de cette valeur à 2 (MSZip) augmente la compression mais augmentera l'utilisation du processeur dans les contrôleurs de domaine.
• Les contrôleurs de domaine en lecture seule (RODC) ne se répliquent pas, mais ils dépendent d'une connexion réseau à des contrôleurs de domaine complets pour récupérer des données afin d'effectuer l'authentification et l'autorisation.

Contrôleurs de domaine en lecture seule

Les RODC sont pris en charge dans Azure. Vous pouvez choisir de déployer des contrôleurs de domaine en lecture seule dans Azure si vous devez restreindre les secrets stockés dans le cloud; vous pouvez filtrer les attributs disponibles dans le cloud si vous le souhaitez. La plupart des rôles Windows fonctionnent bien avec les contrôleurs de domaine en lecture seule, mais assurez-vous que vos applications fonctionnent correctement et ne deviennent pas trop dépendantes des liaisons réseau de site à site.

Serveurs de catalogue global

Chaque contrôleur de domaine dans une forêt à domaine unique doit être un serveur de catalogue global; cela n'entraîne aucun coût supplémentaire de trafic de réplication (transfert de données sortantes).

Cependant, les forêts multi-domaines utilisent des groupes universels et ceux-ci nécessitent un placement et une utilisation soigneux des serveurs de catalogue global (GC). Vous devez placer au moins un serveur GC dans Azure si vous avez besoin de la forêt multi-domaine pour continuer l'authentification des utilisateurs si la liaison de site à site échoue – un GC est requis pour étendre l'appartenance au groupe universel, et un DC doit vérifier que l'utilisateur n'est pas dans un groupe universel avec une autorisation DENY.

Notez que le placement ou le manque de placement des GC aura un impact sur le trafic si vous avez étiré une forêt AD multi-domaine vers le cloud:

• L'absence d'un GC basé sur le cloud entraînera un trafic cross-VPN / ExpressRoute pour chaque authentification.
• Le fait d'avoir un ou plusieurs GC dans le cloud augmentera le trafic de réplication.

ADFS et Azure AD Connect

L'un des risques liés à l'utilisation d'ADFS pour intégrer votre forêt AD à Azure AD est que tous vos services cloud ne seront pas disponibles si Azure AD ne peut pas parler à votre cluster ADFS. La solution la plus simple consiste à déplacer ADFS (et certains contrôleurs de domaine) du local vers Azure, en plaçant efficacement votre composant critique à côté du service qui nécessite une connectivité fiable.

J'ai également choisi de déployer Azure AD Connect dans une machine virtuelle Azure. L'avantage est que dans un scénario de récupération après sinistre, ma connexion à Azure AD s'exécute déjà dans le cloud. En revanche, je dois comprendre que cela peut prendre jusqu'à 15 minutes (avec l'option la plus fréquente dans un lien de site AD) à partir d'un site AD local pour se répliquer vers un site dans Azure, puis jusqu'à 30 minutes ( l'option de réplication par défaut et la plus fréquente dans Azure AD Connect) pour que les modifications apparaissent dans Azure AD – vous pouvez déclencher manuellement la réplication intersite dans AD et Azure AD Connect.