Exporter (0) Imprimer
Développer tout

Recommandations en matière de déploiement de Windows Server Active Directory sur des machines virtuelles Windows Azure

Mis à jour: juin 2014

Ce document explique les différences importantes entre le déploiement local des services de domaine Active Directory Windows Server et des services ADFS (Active Directory Federation Services) et leur déploiement sur des machines virtuelles Microsoft Azure.

Table des matières

Ce document est destiné aux utilisateurs familiers du déploiement local d'Active Directory. Il traite des différences entre le déploiement d'Active Directory sur des machines virtuelles Azure/réseaux virtuels Microsoft Azure et les déploiements locaux traditionnels d'Active Directory. Les machines virtuelles et les réseaux virtuels Azure font partie d'une offre d'infrastructure IaaS (Infrastructure-as-a-service) destinée aux entreprises pour exploiter les ressources informatiques dans le cloud.

Pour ceux qui ne sont pas familiarisés avec le déploiement d'Active Directory, consultez le Guide de déploiement des services de domaine Active Directory ou le Guide de déploiement AD FS, selon le cas.

Ce document suppose que le lecteur est familiarisé avec les concepts suivants :

  • Déploiement et gestion des services de domaine Active Directory Windows Server

  • Déploiement et configuration de DNS pour prendre en charge une infrastructure de services de domaine Active Directory Windows Server

  • Déploiement et gestion des services ADFS Windows Server

  • Déploiement, configuration et gestion des applications par partie de confiance (sites Web et services Web) qui consomment des jetons ADFS Windows Server

  • Concepts généraux sur les machines virtuelles, notamment comment configurer une machine virtuelle, des disques virtuels et des réseaux virtuels

Ce document présente les conditions requises pour un scénario de déploiement hybride dans lequel les services de domaine Windows Server ou les services ADFS sont en partie déployés localement et sur des machines virtuelles Azure. Il examine d'abord les différences essentielles entre l'exécution des services de domaine Active Directory Windows Server et des services ADFS sur des machines virtuelles Azure et localement, ainsi que les choix importants qui affectent la conception et le déploiement. Le reste du document explique plus en détail les instructions à suivre pour chacune des décisions à prendre et comment appliquer les instructions à différents scénarios de déploiement.

Ce document ne traite pas de la configuration d'Azure Active Directory, un service REST qui fournit des fonctionnalités de gestion d'identité et de contrôle d'accès pour vos applications cloud. Azure Active Directory et les services de domaine Active Directory Windows Server sont conçus pour fonctionner conjointement afin de fournir une solution de gestion d'identité et d'accès pour les environnements informatiques hybrides et les applications modernes. Pour vous aider à comprendre les différences et les relations entre les services de domaine Active Directory Windows Server et Azure Active Directory, prenez en considération les points suivants :

  1. Vous pouvez exécuter les services de domaine Active Directory Windows Server dans le cloud sur des machines virtuelles Azure lorsque vous utilisez Azure pour étendre votre centre de données local dans le cloud.

  2. Vous pouvez utiliser Azure Active Directory pour donner à vos utilisateurs la possibilité d'une authentification unique dans les applications SaaS (Software-as-a-Service). Microsoft Office 365 utilise cette technologie, par exemple, et les applications exécutées sur Azure ou d'autres plateformes cloud peuvent également l'utiliser.

  3. Vous pouvez utiliser Azure Active Directory (et Access Control Service) pour permettre aux utilisateurs de se connecter en utilisant des identités Facebook, Google, Microsoft et d'autres fournisseurs d'identité dans les applications hébergées sur le cloud ou localement.

Pour plus d'informations sur ces différences, consultez Identité Azure.

Vous pouvez télécharger et exécuter Azure Virtual Machine Readiness Assessment. Cette évaluation inspecte automatiquement votre environnement local et génère un rapport personnalisé en fonction des conseils figurant dans cette rubrique afin de vous aider à migrer l'environnement vers Azure.

Nous vous recommandons d'examiner également les didacticiels, les guides et les vidéos qui traitent des rubriques suivantes :

Les conditions requises fondamentales pour déployer Active Directory Windows Server sur des machines virtuelles Azure diffèrent peu du déploiement sur des machines virtuelles (et, dans une certaine mesure, sur des ordinateurs physiques) en local. Par exemple, dans le cas des services de domaine Active Directory Windows Server, si des contrôleurs de domaine déployés sur des machines virtuelles Azure sont des réplicas dans un domaine et/ou une forêt d'entreprise locaux existants, le déploiement Azure est traité presque de la même façon que les sites Active Directory Windows Server supplémentaires. Autrement dit, des sous-réseaux doivent être définis dans les services de domaine Active Directory Windows Server, un site doit être créé, les sous-réseaux doivent être liés à ce site et doivent être connectés à d'autres sites via des liaisons de sites appropriées. Toutefois, il existe certaines différences communes à tous les déploiements Azure et certaines qui varient selon le scénario de déploiement spécifique. Deux différences fondamentales sont décrites ci-dessous et expliquées plus en détail dans les paragraphes qui suivent :

  1. Les machines virtuelles Azure devront peut-être avoir accès au réseau d'entreprise local.

    La reconnexion des machines virtuelles Azure à un réseau d'entreprise local nécessite un réseau virtuel Azure, qui inclut un composant de réseau privé virtuel (VPN) site à site ou site à point capable de connecter de façon transparente les machines virtuelles Azure et les ordinateurs locaux. Ce composant VPN peut également permettre aux ordinateurs membres du domaine local d'accéder à un domaine Active Directory Windows Server dont les contrôleurs de domaine sont hébergés exclusivement sur des machines virtuelles Azure. Toutefois, il est important de noter qu'en cas d'échec du VPN, l'authentification et d'autres opérations qui dépendent d'Active Directory Windows Server échoueront également. Bien que les utilisateurs puissent se connecter à l'aide des informations d'identification existantes mises en cache, toutes les tentatives d'authentification d'égal à égal ou de client à serveur, pour lesquelles des tickets doivent être émis ou sont obsolètes, échoueront.

    Pour obtenir une vidéo de démonstration et une liste de didacticiels pas à pas, notamment Configurer un VPN de site à site dans le Portail de gestion, consultez Réseau virtuel.

    noteRemarque
    Vous pouvez également déployer Windows Server Active Directory sur un réseau virtuel Azure qui n'a pas de connectivité avec un réseau local. Cependant, les instructions de cette rubrique supposent qu'un réseau virtuel Azure est utilisé, car il fournit les fonctions d'adressage IP qui sont essentielles à Windows Server.

  2. Les adresses IP statiques doivent être configurées à l'aide d'Azure powerShell.

    Les adresses dynamiques sont allouées par défaut, mais vous pouvez utiliser l'applet de commande Set-AzureStaticVNetIP pour attribuer une adresse IP statique. Ceci définit une adresse IP statique qui persistera à travers la réparation de service et l'arrêt/le redémarrage de la machine virtuelle. Pour plus d'informations, consultez Configuration d'une adresse IP interne statique (DIP) pour une machine virtuelle.

La liste non exhaustive de termes suivante définit différentes technologies Azure pertinentes et vous aidera à comprendre ce document.

  • Machines virtuelles Azure : offre de IaaS dans Azure qui permet aux clients de déployer des machines virtuelles exécutant presque n'importe quelle charge de travail classique de serveur local.

  • Réseau virtuel Azure : service de mise en réseau dans Azure qui permet aux clients de créer et de gérer des réseaux virtuels dans Azure et de les associer à leur propre infrastructure réseau locale à l'aide d'un réseau privé virtuel (VPN).

  • Adresse IP virtuelle (VIP) : adresse IP Internet qui n'est pas liée à un ordinateur ou à une carte d'interface réseau spécifique. Une adresse IP virtuelle est associée aux services de cloud computing pour accepter le trafic réseau qui est redirigé vers une machine virtuelle Azure. Une adresse VIP est une propriété d'un service cloud qui contient une ou plusieurs machines virtuelles Windows Azure. Notez également qu'un réseau virtuel Azure contient un ou plusieurs services de cloud computing. Les adresses IP virtuelles fournissent des fonctions d'équilibrage de charge.

  • Adresse IP dynamique (DIP) : Il s'agit uniquement de l'adresse IP interne. Elle devrait être configurée comme adresse IP statique (à l'aide de l'applet de commande Set-AzureStaticVNetIP) pour les machines virtuelles hébergeant les rôles de serveur DC/DNS.

  • Réparation de service : processus dans lequel Azure restaure automatiquement l'état d'exécution d'un service après détection d'un échec du service. La réparation de service représente un des aspects de Azure qui prend en charge la disponibilité et la résilience. Bien que cela soit peu probable, le résultat obtenu après un incident de réparation de service pour un contrôleur de domaine exécuté sur une machine virtuelle est semblable à un redémarrage non planifié, mais présente certains effets secondaires :

    • La carte réseau virtuelle d'une machine virtuelle sera modifiée.

    • L'adresse MAC de la carte réseau virtuelle sera modifiée.

    • L'ID de processeur/unité centrale de la machine virtuelle sera modifié.

    • La configuration IP de la carte réseau virtuelle ne sera pas modifiée tant que la machine virtuelle est attachée à un réseau virtuel et que l'adresse IP de la machine virtuelle est statique.

    Aucun de ces comportements n'affecte Windows Server Active Directory. En effet, il n'existe aucune dépendance sur l'adresse MAC ou l'ID de processeur/unité centrale. En outre, il est recommandé d'exécuter tous les déploiements de Windows Server Active Directory sur un réseau virtuel Azure comme expliqué ci-dessus.

Le déploiement de contrôleurs de domaine Active Directory Windows Server sur des machines virtuelles Azure est soumis aux mêmes instructions que l'exécution de contrôleurs de domaine localement dans une machine virtuelle. L'exécution de contrôleurs de domaine virtualisés est une pratique sure tant que les instructions de sauvegarde et de restauration des contrôleurs de domaine sont suivies. Pour plus d'informations sur les contraintes et des instructions pour exécuter des contrôleurs de domaine virtualisés, consultez Exécution de contrôleurs de domaine dans Hyper-V.

Les hyperviseurs fournissent ou banalisent les technologies qui peuvent poser des problèmes pour plusieurs systèmes distribués, notamment Active Directory Windows Server. Par exemple, sur un serveur physique, vous pouvez cloner un disque, ou utiliser des méthodes non prises en charge pour restaurer l'état d'un serveur, notamment en utilisant un SAN, mais il est beaucoup plus difficile d'effectuer cette opération sur un serveur physique que de restaurer un instantané de machine virtuelle dans un hyperviseur. Azure propose des fonctionnalités pouvant avoir les mêmes effets indésirables ; par exemple, vous ne devez pas copier les fichiers VHD des contrôleurs de domaine au lieu d'effectuer des sauvegardes régulières, car leur restauration risque d'entraîner une situation semblable à l'utilisation des fonctionnalités de restauration d'instantané.

De telles restaurations introduisent des bulles USN qui peuvent provoquer un état définitivement divergent entre les contrôleurs de domaine. Cela peut, notamment, entraîner :

  • des objets en attente ;

  • des mots de passe incohérents ;

  • des valeurs d'attribut incohérentes ;

  • des incompatibilités de schéma si le contrôleur de schéma est restauré.

Pour plus d'informations sur l'impact sur les contrôleurs de domaine, consultez USN et restauration d'USN.

Depuis Windows Server 2012, des dispositifs de protection supplémentaires sont intégrés aux services de domaine Active Directory. Ils protègent les contrôleurs de domaine virtualisés contre les problèmes susmentionnés, tant que la plateforme de l'hyperviseur sous-jacent prend en charge VM-GenerationID. Azure prend en charge VM-GenerationID, ce qui signifie que les contrôleurs de domaine qui exécutent Windows Server 2012 ou version ultérieure sur des machines virtuelles Azure disposent de dispositifs de protection supplémentaires.

noteRemarque
Vous devriez éteindre et redémarrer une machine virtuelle exécutant le rôle de contrôleur de domaine dans Azure à l'intérieur du système d'exploitation invité plutôt que d'utiliser l'option Arrêter dans le Portail de gestion Azure. L'utilisation du Portail de gestion pour arrêter une machine virtuelle réinitialisera VM-GenerationID, ce qui n'est pas souhaitable pour un contrôleur de domaine.

De nombreux scénarios de déploiement des services de domaine Active Directory Windows Server sont adaptés pour le déploiement en tant que machines virtuelles sur Azure. Par exemple, imaginons que vous avez une société en Europe qui doit authentifier les utilisateurs dans un emplacement distant en Asie. La société n'a pas encore déployé de contrôleurs de domaine Active Directory Windows Server en Asie en raison du coût de déploiement et des compétences limitées en matière de gestion des serveurs après le déploiement. En conséquence, les demandes d'authentification provenant d'Asie sont traitées par des contrôleurs de domaine en Europe et le résultat obtenu n'est pas optimal. Dans ce cas, déployez un contrôleur de domaine sur une machine virtuelle qui doit s'exécuter dans le centre de données Azure en Asie. Le fait d'attacher ce contrôleur de domaine à un réseau virtuel Azure qui est connecté directement à l'emplacement distant améliorera les performances d'authentification.

Azure convient également en tant que substitut des sites de récupération d'urgence coûteux. Le coût relativement faible lié à l'hébergement d'un petit nombre de contrôleurs de domaine et d'un seul réseau virtuel sur Azure représente une solution séduisante.

Enfin, vous pouvez déployer une application réseau sur Azure, telle que SharePoint, qui nécessite Active Directory Windows Server mais n'a aucune dépendance sur le réseau local ou Active Directory Windows Server d'entreprise. Dans ce cas, le déploiement d'une forêt isolée sur Azure pour répondre aux exigences du serveur SharePoint est optimal. Le déploiement d'applications réseau qui nécessitent une connectivité au réseau local et Active Directory d'entreprise est également pris en charge.

noteRemarque
Étant donné qu'il fournit une connexion de couche 3, le composant VPN qui assure la connectivité entre un réseau virtuel Azure et un réseau local permet également aux serveurs membres exécutés localement d'exploiter les contrôleurs de domaine exécutés en tant que machines virtuelles sur un réseau virtuel Azure. Mais si le VPN est indisponible, la communication entre les ordinateurs locaux et les contrôleurs de domaine Azure ne fonctionne pas, ce qui entraîne une authentification et diverses autres erreurs.  

  • Pour les scénarios de déploiement Windows Server Active Directory qui incluent plusieurs machines virtuelles, il est nécessaire d'utiliser un réseau virtuel Azure afin d'assurer la cohérence des adresses IP. Notez que ce guide suppose que les contrôleurs de domaine s'exécutent sur un réseau virtuel Azure.

  • Comme pour les contrôleurs de domaine locaux, les adresses IP statiques sont recommandées. Une adresse IP statique peut seulement être configurée à l'aide d'Azure PowerShell (voir Configuration d'une adresse IP interne statique (DIP) pour une machine virtuelle). Si vous avez des systèmes de surveillance ou d'autres solutions vérifiant la configuration des adresses IP statiques dans le système d'exploitation invité, vous pouvez attribuer la même adresse IP statique aux propriétés de carte réseau de la machine virtuelle. Vous devez toutefois savoir que la carte réseau sera ignorée si la machine virtuelle subit une réparation de service ou est arrêtée dans le Portail de gestion et que son adresse est désallouée. Dans ce cas, l'adresse IP statique dans l'invité devra être réinitialisée.

  • Le déploiement de machines virtuelles sur un réseau virtuel n'implique pas (ou ne nécessite pas) de connectivité à un réseau local ; le réseau virtuel le permet simplement. Vous devez créer un réseau virtuel pour la communication privée entre Azure et votre réseau local. Vous devez déployer un point de terminaison VPN sur le réseau local. Le VPN est ouvert de Azure au réseau local. Pour plus d'informations, consultez Présentation du réseau virtuel et Configurer un VPN de site à site dans le portail de gestion.

    noteRemarque
    Une option de création d'un VPN de point à site permet de connecter des ordinateurs Windows directement à un réseau virtuel Azure.

  • Que vous créiez un réseau virtuel ou non, Azure facture le trafic sortant, mais pas le trafic entrant. Les différents choix de conception Active Directory Windows Server affectent le volume de trafic sortant généré par un déploiement. Par exemple, le déploiement d'un contrôleur de domaine en lecture seule limite le trafic sortant, car il ne le réplique pas. Cependant, la décision de déployer un contrôleur de domaine en lecture seule doit être comparée au besoin de réaliser des opérations d'écriture sur le contrôleur de domaine et à la compatibilité que les applications et services dans le site ont avec les contrôleurs de domaine en lecture seule. Pour plus d'informations sur les frais liés au trafic réseau, consultez Aperçu rapide de la tarification Azure.

  • Bien que vous ayez un contrôle total sur les ressources serveur à utiliser pour les machines virtuelles locales, notamment la quantité de RAM et la taille du disque, sur Azure, vous devez effectuer une sélection dans une liste de tailles préconfigurées de serveur. Pour un contrôleur de domaine, un disque de données est nécessaire en plus du disque de système d'exploitation afin de stocker la base de données Active Directory Windows Server.

noteRemarque
Azure fournit plusieurs nouvelles fonctionnalités qui améliorent les capacités de mise en réseau. L'équipe AD FS recherche actuellement comment ces nouvelles fonctionnalités affectent les meilleures pratiques AD FS lorsque AD FS est implémenté sur Azure. La documentation sera mise à jour en conséquence. Pour le moment, vous pouvez obtenir plus d'informations en consultant les rubriques suivantes :

AD FS est pris en charge pour le déploiement sur les machines virtuelles Azure. Les meilleures pratiques pour le déploiement AD FS sur site s'appliquent également au déploiement AD FS sur Azure. Comme indiqué dans la rubrique Planifier le déploiement AD FS, les meilleures pratiques pour le déploiement de rôles Service d'émission de jeton de sécurité (STS) consistent à « prévoir de placer tous les serveurs de fédération de votre réseau d’entreprise derrière un hôte NLB (équilibrage de la charge réseau) qui puisse être configuré pour un cluster d’équilibrage de la charge réseau avec un nom DNS de cluster et une adresse IP de cluster dédiés ». Certaines meilleures pratiques liées à AD FS, comme l'équilibrage de la charge et la haute disponibilité, exigent des technologies qui vont au-delà des fonctions proposées par AD FS. Étant donné que ces technologies ne font pas partie de l'ensemble de fonctionnalités natives d'ADFS, elles doivent être fournies par l'infrastructure sous-jacente.

  1. N'exposez jamais les rôles STS directement à Internet.

    La configuration de ce déploiement limite l'exposition de STS à Internet. Cela est important, car les rôles Service d'émission de jeton de sécurité publient des jetons de sécurité. Par conséquent, ils doivent être traités avec le même niveau de protection qu'un contrôleur de domaine. Si un Service d'émission de jeton de sécurité est compromis, des utilisateurs malveillants ont la possibilité d'émettre des jetons d'accès qui contiennent potentiellement les revendications de leur choix dans les applications par partie de confiance et d'autres services d'émission de jeton de sécurité des organisations autorisées à approuver.

    Pour autoriser les utilisateurs externes à accéder à AD FS depuis Internet, déployez les proxys AD FS (c'est à dire le rôle Proxy d'application web dans Windows Server 2012 R2 ou le proxy AD FS dans les versions antérieures de Windows Server).

  2. Le service AD FS doit être hautement disponible et faire l'objet d'un équilibrage de la charge.

    Dans la plupart des cas, l'échec d'une application activée par ADFS est inacceptable, car ces applications sont souvent critiques. Par conséquent, et étant donné que AD FS se situe désormais sur le chemin d'accès aux applications critiques, le service AD FS doit être hautement disponible afin de simplifier l'accès à l'application. Pour obtenir une haute disponibilité, des programmes d'équilibrage de charge sont généralement déployés devant les proxys ADFS et les rôles Service d'émission de jeton de sécurité.

    Pour que les proxys AD FS bénéficient d'une haute disponibilité, il est nécessaire d'activer l'équilibrage de la charge Azure pour les adresses IP virtuelles publiques. Pour que les rôles STS bénéficient d'une haute disponibilité, il est nécessaire d'utiliser Azure PowerShell pour activer l'équilibrage de charge interne sur les interfaces réseau privées de la machine virtuelle. Le diagramme suivant montre cette configuration de base.

Pour plus d'informations, consultez 2. AD FS : étendre une application frontale locale prenant en charge les revendications à Internet.

Autre solution si l'objectif est Office 365 seul

Si l'objectif est Office 365, déployez simplement DirSync avec synchronisation des mots de passe locale et obtenez le même résultat final avec une complexité de déploiement quasi nulle. Remarque : cette méthode ne nécessite pas ADFS ni Azure.

Le tableau suivant compare le fonctionnement des processus de connexion avec et sans déploiement d'ADFS.

 

Authentification unique Office 365 à l'aide d'ADFS et DirSync Même authentification unique Office 365 à l'aide de DirSync + synchronisation des mots de passe
  1. L'utilisateur se connecte à un réseau d'entreprise, et est authentifié auprès de Windows Server Active Directory.

  2. L'utilisateur tente d'accéder à Office 365 (nom@contoso.com).

  3. Office 365 redirige l'utilisateur vers Azure Active Directory.

  4. Étant donné qu'Azure Active Directory n'authentifie pas l'utilisateur et comprend qu'il existe une approbation avec ADFS local, il redirige l'utilisateur vers ADFS.

  5. L'utilisateur envoie un ticket Kerberos au serveur Service d'émission de jeton de sécurité ADFS.

  6. ADFS transforme le ticket Kerberos en format de jeton/revendications nécessaire et redirige l'utilisateur vers Azure Active Directory.

  7. L'utilisateur s'authentifie auprès d'Azure Active Directory (une autre transformation se produit).

  8. Azure Active Directory redirige l'utilisateur vers Office 365.

  9. L'utilisateur est connecté en mode silencieux à Office 365.

  1. L'utilisateur se connecte à un réseau d'entreprise, et est authentifié auprès de Windows Server Active Directory.

  2. L'utilisateur tente d'accéder à Office 365 (nom@contoso.com).

  3. Office 365 redirige l'utilisateur vers Azure Active Directory.

  4. Azure Active Directory ne reçoit pas les tickets Kerberos directement et aucune relation d'approbation n'existe. Par conséquent, l'utilisateur doit entrer les informations d'identification.

  5. L'utilisateur entre les mêmes nom d'utilisateur et mot de passe locaux, et Azure Active Directory les valide par rapport au nom d'utilisateur et au mot de passe qui ont été synchronisés par DirSync.

  6. Azure Active Directory redirige l'utilisateur vers Office 365.

  7. L'utilisateur peut se connecter à Office 365 et OWA en utilisant le jeton Azure Active Directory.

Dans le scénario de synchronisation de mot de passe avec DirSync (sans ADFS), l'authentification unique est remplacée par la « même authentification » où « même » indique que les utilisateurs doivent confirmer leurs informations d'identification locales lorsqu'ils accèdent à Office 365. Notez que ces données peuvent être mémorisées afin de réduire les invites suivantes.

Autres éléments de réflexion

  • Si vous déployez un proxy ADFS Windows Server sur une machine virtuelle Azure, une connexion aux serveurs de Service d'émission de jeton de sécurité ADFS est nécessaire. S'ils sont locaux, il est recommandé d'exploiter la connectivité VPN de site à site fournie par le réseau virtuel pour permettre aux proxys de communiquer avec leurs serveurs de Service d'émission de jeton de sécurité.

  • Si vous déployez un Service d'émission de jeton de sécurité ADFS Windows Server sur une machine virtuelle Azure, une connexion aux contrôleurs de domaine Active Directory Windows Server, aux magasins d'attributs et aux bases de données de configuration est nécessaire. En outre, un VPN de site à site peut également être nécessaire.

  • Des frais s'appliquent à tout trafic sortant des machines virtuelles Azure. Si le coût est un facteur déterminant, il est recommandé de déployer les proxys ADFS sur Azure, et de conserver les rôles Service d'émission de jeton de sécurité localement. Si les rôles Service d'émission de jeton de sécurité sont également déployés sur des machines virtuelles Azure, il y aura des frais supplémentaires pour authentifier les utilisateurs locaux. Le trafic sortant génère un coût, qu'il parcourt ou non le VPN.

  • Si vous décidez d'utiliser des fonctionnalités natives d'équilibrage de charge des serveurs de Azure pour la haute disponibilité des rôles Service d'émission de jeton de sécurité ADFS, notez que l'équilibrage de charge fournit les sondes utilisées pour déterminer l'intégrité des machines virtuelles au sein du service cloud. Dans le cas de machines virtuelles Azure (par opposition aux rôles Web ou de travail), une sonde personnalisée doit être utilisée, car l'agent qui répond aux sondes par défaut n'est pas présent sur les machines virtuelles Azure. Pour simplifier, vous pouvez utiliser une sonde TCP personnalisée. Cela nécessite uniquement qu'une connexion TCP (un accusé de réception de synchronisation) soit établie pour déterminer l'intégrité d'une machine virtuelle. Vous pouvez configurer la sonde personnalisée de façon à utiliser n'importe quel port TCP qui écoute activement sur vos machines virtuelles. Pour cela, consultez Sonde d'équilibrage de charge Windows Azure.

    noteRemarque
    Les ordinateurs qui doivent exposer le même ensemble de ports directement à Internet (notamment les ports 80 et 443) ne peuvent pas partager le même service cloud. Par conséquent, il est recommandé de créer un service cloud dédié pour vos serveurs ADFS Windows Server afin d'éviter les chevauchements potentiels entre les spécifications de port d'une application et des services ADFS Windows Server.

La section suivante décrit des scénarios courants de déploiement qui attirent l'attention sur des considérations importantes qui doivent être prises en compte. Chaque scénario contient des liens vers des informations supplémentaires sur les décisions et les facteurs à prendre en compte.

Déploiement AD DS sur le cloud uniquement

Figure 1

SharePoint est déployé sur une machine virtuelle Azure et l'application n'a pas de dépendances sur des ressources réseau d'entreprise. L'application nécessite les services de domaine Active Directory Windows Server mais NE nécessite PAS les services de domaine Active Directory Windows Server d'entreprise. Aucune relation d'approbation Kerberos ou fédérée n'est nécessaire, car les utilisateurs sont configurés automatiquement via l'application dans le domaine des services de domaine Active Directory Windows Server qui est également hébergé dans le cloud sur des machines virtuelles Azure.

  • Topologie de réseau : créez un réseau virtuel Azure sans connectivité entre différents locaux (également appelée connectivité de site à site).

  • Configuration du déploiement du contrôleur de domaine : déployez un nouveau contrôleur de domaine dans une nouvelle forêt Active Directory Windows Server d'un seul domaine. Il doit être déployé avec le serveur DNS Windows.

  • Topologie de site Active Directory Windows Server : utilisez le site Active Directory Windows Server par défaut (tous les ordinateurs seront dans Premier-Site-Par-Défaut)

  • Adressage IP et DNS:

    • définissez une adresse IP statique pour le contrôleur de domaine à l'aide de l'applet de commande Azure PowerShell Set-AzureStaticVNetIP.

    • Installez et configurez le serveur DNS Windows Server sur le ou les contrôleurs de domaine sur Azure.

    • Configurez les propriétés de réseau virtuel à l'aide du nom et de l'adresse IP de la machine virtuelle qui héberge les rôles de serveur du contrôleur de domaine et de serveur DNS.

  • Catalogue global : le premier contrôleur de domaine de la forêt doit être un serveur de catalogue global. Des contrôleurs de domaine supplémentaires doivent également être configurés en tant que catalogue global, car dans une forêt d'un seul domaine, le catalogue global ne nécessite aucun travail supplémentaire du contrôleur de domaine.

  • Sélection élective de la base de données des services de domaine Active Directory Windows Server et de SYSVOL : ajoutez un disque de données aux contrôleurs de domaine exécutés en tant que machines virtuelles Azure afin de stocker la base de données Active Directory Windows Server, les journaux et SYSVOL.

  • Sauvegarder et restaurer : déterminez où vous souhaitez stocker les sauvegardes d'état du système. Si nécessaire, ajoutez un autre disque de données à la machine virtuelle contrôleur de domaine pour stocker les sauvegardes.

Fédération avec connectivité intersite

Figure 2

Une application prenant en charge les revendications qui a été déployée localement et utilisée par des utilisateurs d'entreprise doit devenir directement accessible à partir d'Internet. L'application fait office de serveur Web frontal dans une base de données SQL dans laquelle elle stocke et récupère des données. Les serveurs SQL utilisés par l'application sont également situés sur le réseau d'entreprise. Deux rôles Service d'émission de jeton de sécurité ADFS Windows Server et un programme d'équilibrage de charge ont été déployés localement pour fournir l'accès aux utilisateurs d'entreprise. L'application doit maintenant être accessible directement sur Internet par les partenaires commerciaux à l'aide de leurs propres identités d'entreprise et par les utilisateurs de l'entreprise existants.

Afin de simplifier et répondre aux besoins de déploiement et de configuration de cette nouvelle condition, deux serveurs Web frontaux supplémentaires et deux serveurs proxy ADFS Windows Server doivent être installés sur des machines virtuelles Azure. Chacune des quatre machines virtuelles sera exposée directement sur Internet et sera connectée au réseau local à l'aide de la fonctionnalité VPN de site à site du réseau virtuel Azure.

  • Topologie de réseau : créez un réseau virtuel Azure et configurez la connectivité entre différents locaux.

    noteRemarque
    Pour chacun des certificats ADFS Windows Server, vérifiez que l'URL définie dans le modèle de certificat et les certificats obtenus sont accessibles par les instances ADFS Windows Server exécutées sur Azure. Cela peut nécessiter une connexion entre les différents locaux à des parties de votre infrastructure PKI. Par exemple, si le point de terminaison de la liste de révocation de certificats repose sur LDAP et est exclusivement hébergé localement, une connexion entre les différents locaux est requise. Si cela n'est pas souhaitable, il peut être nécessaire d'utiliser des certificats émis par une autorité de certification dont la liste de révocation de certificats est accessible sur Internet.

  • Configuration des services de cloud computing : assurez-vous que vous disposez de deux services de cloud computing pour fournir deux adresses IP virtuelles à charge équilibrée. La première adresse IP virtuelle du service cloud sera dirigée vers les deux machines virtuelles proxy ADFS Windows Server sur les ports 80 et 443. Les machines virtuelles proxy ADFS Windows Server seront configurées de façon à pointer vers l'adresse IP du programme d'équilibrage de charge local qui donne sur les rôles Service d'émission de jeton de sécurité ADFS Windows Server. La deuxième adresse IP virtuelle du service cloud sera dirigée vers les deux machines virtuelles exécutant le serveur Web frontal sur les ports 80 et 443. Configurez une sonde personnalisée pour garantir que le programme d'équilibrage de charge dirige uniquement le trafic vers des machines virtuelles proxy ADFS Windows Server et serveur Web frontal.

  • Configuration du serveur de fédération : configurez ADFS Windows Server en tant que serveur de fédération (Service d'émission de jeton de sécurité) pour générer des jetons de sécurité de la forêt Active Directory Windows Server créée dans le cloud. Définissez les relations d'approbation de fournisseur de revendications de fédération avec les différents partenaires dont vous souhaitez recevoir les identités, et configurez les relations d'approbation de la partie de confiance avec les différentes applications dans lesquelles vous voulez créer des jetons.

    Dans la plupart des cas, les serveurs proxy ADFS Windows Server sont déployés dans une fonctionnalité connectée à Internet pour des raisons de sécurité alors que leurs homologues de fédération ADFS Windows Server restent isolés d'une connexion Internet directe. Quel que soit votre scénario de déploiement, vous devez configurer votre service cloud avec une adresse IP virtuelle qui fournira une adresse IP exposée publiquement et un port capable de répartir la charge entre vos instances Service d'émission de jeton de sécurité ADFS Windows Server ou vos instances de proxy.

  • Configuration de la haute disponibilité des services ADFS Windows Server : il est recommandé de déployer une batterie ADFS Windows Server avec au moins deux serveurs pour le basculement et l'équilibrage de charge. Vous pouvez envisager d'utiliser la base de données interne Windows pour les données de configuration AD FS Windows Server, et utiliser la fonction d'équilibrage de charge interne d'Azure pour distribuer les requêtes entrantes entre les serveurs dans la batterie.

    Pour plus d'informations, consultez le Guide de déploiement AD FS.

Déploiement AD DS intersite

Figure 3

Une application LDAP qui prend en charge l'authentification intégrée Windows et utilise les services de domaine Active Directory Windows Server en tant que référentiel pour la configuration et les données de profil utilisateur est déployée sur une machine virtuelle Azure. Il est recommandé que l'application exploite les services de domaine Active Directory Windows Server d'entreprise existants et fournisse une authentification unique. L'application ne prend pas en charge les revendications. Les utilisateurs doivent également accéder à l'application directement depuis Internet. Pour optimiser les performances et le coût, deux contrôleurs de domaine supplémentaires qui font partie du domaine d'entreprise doivent être déployés avec l'application sur Azure.

  • Topologie de réseau : créez un réseau virtuel Azure avec la connectivité entre différents locaux.

  • Méthode d'installation : déployez des contrôleurs de domaine de réplication à partir du domaine Active Directory Windows Server d'entreprise. Pour un contrôleur de domaine de réplication, installez les services de domaine Active Directory Windows Server sur la machine virtuelle, et éventuellement, utilisez la fonctionnalité Installation à partir du support pour réduire la quantité de données qui doivent être répliquées sur le nouveau contrôleur de domaine pendant l'installation. Pour bénéficier d'un didacticiel, consultez Installer un contrôleur de domaine Active Directory de réplication sur Azure. Même si vous utilisez la fonctionnalité Installation à partir du support, il peut être plus efficace de créer le contrôleur de domaine virtuel localement, puis de déplacer le VHD entier dans le cloud au lieu de répliquer les services de domaine Active Directory Windows Server pendant l'installation. Pour des raisons de sécurité, il est recommandé de supprimer le VHD du réseau local une fois qu'il a été copié dans Azure.

  • Topologie de site Active Directory Windows Server : créez un site Azure dans le composant logiciel enfichable Sites et services Active Directory. Créez un objet sous-réseau Active Directory Windows Server pour représenter le réseau virtuel Azure et ajoutez le sous-réseau au site. Créez un lien de site qui comprend le nouveau site Azure et le site dans lequel se trouve le point de terminaison de VPN du réseau virtuel Azure pour contrôler et optimiser le trafic Active Directory Windows Server vers et depuis Azure.

  • Adressage IP et DNS:

    • définissez une adresse IP statique pour le contrôleur de domaine à l'aide de l'applet de commande Azure PowerShell Set-AzureStaticVNetIP.

    • Installez et configurez le serveur DNS Windows Server sur le ou les contrôleurs de domaine sur Azure.

    • Configurez les propriétés de réseau virtuel à l'aide du nom et de l'adresse IP de la machine virtuelle qui héberge les rôles de serveur du contrôleur de domaine et de serveur DNS.

  • Contrôleurs de domaine répartis dans plusieurs points géographiques : configurez autant de réseaux virtuels supplémentaires que nécessaires. Si votre typologie de site Active Directory nécessite des contrôleurs de domaine dans des géographies correspondant à différentes régions Azure, veillez à créer vos sites Active Directory en conséquence.

  • Contrôleurs de domaine en lecture seule : vous pouvez déployer un contrôleur de domaine en lecture seule dans le site Azure, selon vos conditions requises pour effectuer des opérations d'écriture sur le contrôleur de domaine et la compatibilité des applications et des services dans le site avec les contrôleurs de domaine en lecture seule. Pour plus d'informations sur la compatibilité des applications, consultez Guide de compatibilité des applications pour contrôleurs de domaine en lecture seule.

  • Catalogue global : des catalogues globaux sont nécessaires pour traiter les demandes d'ouverture de session dans les forêts de plusieurs domaines. Si vous ne déployez pas de catalogue global dans le site Azure, vous engagerez des coûts de trafic sortant, car les demandes d'authentification entraînent des requêtes de catalogue global dans d'autres sites. Pour réduire ce trafic, activez le cache d'appartenance au groupe universel pour le site Azure dans le composant logiciel enfichable Sites et services Active Directory.

    Si vous déployez un catalogue global, configurez des liens de sites et des coûts de liens de sites, de façon à ce que le catalogue global dans le site Azure ne soit pas considéré par défaut comme le catalogue global source par d'autres catalogues globaux qui doivent répliquer les mêmes partitions partielles de domaine.

  • Sélection élective de la base de données des services de domaine Active Directory Windows Server et de SYSVOL : ajoutez un disque de données aux contrôleurs de domaine exécutés sur des machines virtuelles Azure afin de stocker la base de données Active Directory Windows Server, les journaux et SYSVOL.

  • Sauvegarder et restaurer : déterminez où vous souhaitez stocker les sauvegardes d'état du système. Si nécessaire, ajoutez un autre disque de données à la machine virtuelle contrôleur de domaine pour stocker les sauvegardes.

Ce tableau récapitule les domaines technologiques Active Directory Windows Server qui sont affectés dans les scénarios précédents et les décisions correspondantes à prendre en compte, ainsi que des liens vers plus de détail ci-dessous. Certains domaines technologiques ne s'appliquent pas à tous les scénarios de déploiement, et certains peuvent être plus critiques que d'autres dans un scénario de déploiement.

Par exemple, si vous déployez un contrôleur de domaine de réplication sur un réseau virtuel et votre forêt dispose d'un seul domaine, il n'est pas essentiel de choisir de déployer un serveur de catalogue global dans ce cas pour le scénario de déploiement. De fait, cela ne crée aucune configuration requise supplémentaire de réplication. En revanche, si la forêt possède plusieurs domaines, la décision de déployer un catalogue global sur un réseau virtuel peut affecter la bande passante disponible, les performances, l'authentification, les recherches Active Directory, etc.

 

Nombre d'élément

Domaine technologique Active Directory Windows Server

Décisions

Facteurs

1

Topologie de réseau

Créez-vous un réseau virtuel ?

Conditions requises pour accéder aux ressources d'entreprise

Authentification

Gestion du compte

2

Configuration du déploiement du contrôleur de domaine

  • Déployer une forêt distincte sans aucune approbation ?

  • Déployer une nouvelle forêt avec fédération ?

  • Déployer une nouvelle forêt avec l'approbation de forêt Active Directory Windows Server pour Kerberos ?

  • Étendre la forêt d'entreprise en déployant un contrôleur de domaine de réplication ?

  • Étendre une forêt d'entreprise en déployant un nouveau domaine enfant ou une arborescence de domaine ?

Sécurité

Conformité

Coût

Résilience et tolérance de panne

Compatibilité des applications

3

Topologie de site Active Directory Windows Server

Comment configurez-vous des sous-réseaux, des sites et des liaisons de site avec un réseau virtuel Azure pour optimiser le trafic et réduire les coûts ?

Définition de sous-réseau et de site

Propriétés de lien de site et notification de modification

Compression de la réplication

4

Adressage IP et DNS

Comment configurer les adresses IP et la résolution de noms ?

Utilisez l'applet de commande Set-AzureStaticVNetIP pour attribuer une adresse IP statique

Installez le serveur DNS Windows Server et configurez les propriétés de réseau virtuel avec le nom et de l'adresse IP de la machine virtuelle qui héberge les rôles de serveur du contrôleur de domaine et de serveur DNS.

5

Contrôleurs de domaine répartis dans plusieurs points géographiques

Comment répliquer dans des contrôleurs de domaine sur des réseaux virtuels distincts ?

Si votre typologie de site Active Directory nécessite des contrôleurs de domaine dans des géographies correspondant à différentes régions Azure, veillez à créer vos sites Active Directory en conséquence. Configurez la connectivité de réseau virtuel à réseau virtuel pour répliquer entre des contrôleurs de domaine sur des réseaux virtuels distincts.

6

Contrôleurs de domaine en lecture seule

Utiliser des contrôleurs de domaine en lecture seule ou accessibles en écriture ?

Filtrer les attributs HBI/PII

Filtrer les secrets

Limiter le trafic sortant

7

Catalogue global

Installer un catalogue global ?

Pour une forêt d'un seul domaine, faites en sorte que tous les contrôleurs de domaine soient des catalogues globaux

Pour une forêt de plusieurs domaines, des catalogues globaux sont nécessaires pour l'authentification

8

Méthode d'installation

Comment installer un contrôleur de domaine dans Azure ?

  • Installer les services de domaine Active Directory en utilisant Windows PowerShell ou Dcpromo

-ou-

  • Déplacer le VHD d'un contrôleur de domaine virtuel local

9

Sélection élective de la base de données des services de domaine Active Directory Windows Server et de SYSVOL

Où stocker la base de données des services de domaine Active Directory Windows Server, les journaux et SYSVOL ?

Modifier les valeurs par défaut de Dcpromo.exe

ImportantImportant
Ces fichiers Active Directory critiques DOIVENT être placés sur des disques de données Azure plutôt que sur des disques de système d'exploitation qui implémentent le cache d'écriture.

10

Sauvegarder et restaurer

Comment protéger et récupérer les données ?

Créer des sauvegardes d'état du système

11

Configuration du serveur de fédération

Déployer une nouvelle forêt avec fédération dans le cloud ?

Déployer les services ADFS localement et exposer un proxy dans le cloud ?

Sécurité

Conformité

Coût

Accès aux applications par les partenaires commerciaux

12

Configuration des services de cloud computing

Un service cloud est déployé implicitement lorsque vous créez la première machine virtuelle. Devez-vous déployer des services de cloud computing supplémentaires ?

Une ou plusieurs machines virtuelles nécessitent-elles une exposition directe à Internet ?

Le service a-t-il besoin de l'équilibrage de charge ?

13

Configuration requise du serveur de fédération pour l'adressage IP public et privé (DIP et VIP)

Les instances ADFS Windows Server doivent-elles être accessibles directement depuis Internet ?

L'application déployée dans le cloud a-t-elle besoin de ses propres adresse IP Internet et port ?

Créer un service cloud pour chaque VIP nécessaire pour votre déploiement

14

Configuration de la haute disponibilité des services ADFS Windows Server

Combien de nœuds sont nécessaires dans votre batterie de serveurs ADFS Windows Server ?

Combien de nœuds doivent être déployés dans votre batterie de serveurs proxy ADFS Windows Server ?

Résilience et tolérance de panne

Afin de satisfaire les conditions requises pour la cohérence des adresses IP et DNS des services de domaine Active Directory Windows Server, vous devez dans un premier temps créer un réseau virtuel Azure et attacher vos machines virtuelles à ce dernier. Pendant sa création, vous devez déterminer s'il faut éventuellement étendre la connectivité à votre réseau d'entreprise local, qui connecte de façon transparente les machines virtuelles Azure aux ordinateurs locaux. Cette opération s'effectue à l'aide de technologies VPN classiques et nécessite qu'un point de terminaison VPN soit exposé sur le périmètre du réseau d'entreprise. Autrement dit, le VPN est initialisé de Azure vers le réseau d'entreprise, et non pas le contraire.

Notez que des frais supplémentaires s'appliquent lors de l'extension d'un réseau virtuel à votre réseau local, en plus des frais standard applicables à chaque machine virtuelle. En particulier, il existe des frais pour le temps processeur de la passerelle de réseau virtuel Azure et pour le trafic sortant généré par chaque machine virtuelle qui communique avec des ordinateurs locaux sur le VPN. Pour plus d'informations sur les frais liés au trafic réseau, consultez Aperçu rapide de la tarification Azure.

La manière dont vous configurez le contrôleur de domaine dépend des conditions requises pour le service vous voulez exécuter sur Azure. Par exemple, vous pouvez déployer une nouvelle forêt, isolée dans votre propre forêt d'entreprise, afin de tester un preuve de concept, une nouvelle application, ou un autre projet à court terme qui nécessite des services d'annuaire, mais aucun accès spécifique aux ressources d'entreprise internes.

Un contrôleur de domaine d'une forêt isolée ne réplique pas avec des contrôleurs de domaine locaux, ce qui réduit le trafic réseau sortant généré par le système, ainsi que les coûts. Pour plus d'informations sur les frais liés au trafic réseau, consultez Aperçu rapide de la tarification Azure.

À titre d'autre d'exemple, imaginons que vous avez des conditions de confidentialité pour un service, mais le service dépend de l'accès à votre service Active Directory Windows Server interne. Si vous êtes autorisé à héberger des données pour le service cloud, déployez un nouveau domaine enfant pour votre forêt interne sur Azure. Dans ce cas, vous déployez un contrôleur de domaine pour le nouveau domaine enfant (sans catalogue global afin de résoudre les problèmes de confidentialité). Ce scénario, avec un déploiement de contrôleur de domaine de réplication, nécessite un réseau virtuel pour la connectivité avec vos contrôleurs de domaine locaux.

Si vous créez une nouvelle forêt, déterminez s'il faut utiliser des approbations Active Directory ou des approbations de fédération. Équilibrez les exigences en matière de compatibilité, de sécurité, de conformité, de coûts et de résilience. Par exemple, pour tirer parti de l'authentification sélective, vous pouvez choisir de déployer une nouvelle forêt sur Azure et de créer une approbation Active Directory Windows Server entre la forêt locale et la forêt du cloud. Si l'application prend en charge les revendications, vous pouvez déployer des approbations de fédération plutôt que des approbations de forêt Active Directory. Un autre facteur à prendre en compte est le coût lié à la réplication de davantage de données en élargissant votre service Active Directory Windows Server local au cloud ou à la génération de plus de trafic en raison de la charge liée à l'authentification et aux requêtes.

La configuration requise pour la disponibilité et la tolérance de panne affecte également votre choix. Par exemple, si le lien est suspendu, les applications qui exploitent une approbation Kerberos ou une approbation de fédération sont probablement entièrement arrêtées, sauf si vous avez déployé une infrastructure suffisante sur Azure. Les autres configurations de déploiement, telles que des contrôleurs de domaine de réplication (accessibles en écriture ou en lecture seule), augmentent la probabilité de tolérance de pannes de lien.

Vous devez définir correctement les sites et les liens de sites afin d'optimiser le trafic et de réduire les coûts. Les sites, les liens de sites et les sous-réseaux affectent la topologie de réplication entre les contrôleurs de domaine et le flux du trafic d'authentification. Tenez compte des frais suivants liés au trafic, puis déployez et configurez des contrôleurs de domaine conformément à la configuration requise de votre scénario de déploiement :

  • Des frais nominaux par heure s'appliquent pour la passerelle proprement dite :

    • Vous pouvez la démarrer et l'arrêter selon vos besoins.

    • Si elle est arrêtée, les machines virtuelles Azure sont isolées du réseau d'entreprise.

  • Le trafic entrant est gratuit.

  • Le trafic sortant est facturé conformément à l'Aperçu rapide de la tarification Azure. Optimisez les propriétés de lien de site entre des sites locaux et des sites du cloud comme suit :

    • Si vous utilisez plusieurs réseaux virtuels, configurez les liens de sites et leurs coûts convenablement pour empêcher les services de domaine Active Directory Windows Server de classer par ordre de priorité le site Azure par rapport à un site qui propose les mêmes niveaux de service gratuitement. Vous pouvez également envisager de désactiver l'option Relier tous les liens de sites (qui est activée par défaut). Cela garantit que seuls les sites connectés directement répliquent les uns avec les autres. Les contrôleurs de domaine des sites connectés de manière transitive ne peuvent plus répliquer directement les uns avec les autres. Ils doivent répliquer via un ou plusieurs sites courants. Si les sites intermédiaires deviennent non disponibles pour quelque raison que ce soit, la réplication entre les contrôleurs de domaine des sites connectés de manière transitive ne se produira pas, même si la connexion entre les sites est disponible. Enfin, lorsque des parties du comportement de réplication transitive restent souhaitables, créez des ponts lien de sites qui contiennent les liens de sites et les sites appropriés, notamment des sites locaux et des sites réseau d'entreprise.

    • Configurer les coûts des liens de sites de façon appropriée afin d'éviter le trafic imprévu. Par exemple, si le paramètre Essayer le site le plus proche suivant est activé, vérifiez que les sites de réseau virtuel ne sont pas les plus proches suivants en augmentant le coût associé de l'objet lien de site qui reconnecte le site Azure au réseau d'entreprise.

    • Configurer les intervalles de lien de site et les planifications conformément aux exigences de cohérence et à la fréquence des modifications d'objet. Alignez la planification de réplication avec la tolérance de latence. Les contrôleurs de domaine répliquent uniquement le dernier état d'une valeur, par conséquent en réduisant l'intervalle de réplication vous pouvez faire des économies, s'il existe une fréquence de modifications d'objet suffisante.

  • Si réduire les coûts est une priorité, vérifiez que la réplication est planifiée et la notification de modification n'est pas activée ; il s'agit de la configuration par défaut lors de la réplication entre les sites. Ceci n'est pas important si vous déployez un contrôleur de domaine en lecture seule sur un réseau virtuel, car le contrôleur de domaine en lecture seule ne réplique aucune modification sortante. Mais si vous déployez un contrôleur de domaine accessible en écriture, vous devez vous assurer que le lien de site n'est pas configuré pour répliquer des mises à jour à une fréquence inutile. Si vous déployez un serveur de catalogue global, vérifiez que chaque site qui contient un catalogue global réplique les partitions de domaine d'un contrôleur de domaine source dans un site qui est connecté avec un ou plusieurs liens de sites qui ont un coût inférieur à celui du catalogue global dans le site Azure.

  • Il est possible de réduire davantage le trafic réseau généré par la réplication entre les sites en modifiant l'algorithme de compression de réplication. L'algorithme de compression est contrôlé par l'entrée de Registre REG_DWORD de l'algorithme de compression HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Replicator. La valeur par défaut est 3, qui est en corrélation avec l'algorithme de compression Xpress. Remplacez la valeur par 2, ce qui change l'algorithme en MSZip. Dans la plupart des cas, cela augmentera la compression, mais au détriment de l'utilisation de l'UC. Pour plus d'informations, consultez Fonctionnement de la topologie de réplication Active Directory.

Les machines virtuelles Azure reçoivent des « adresses louées par DHCP » par défaut. Étant donné que les adresses dynamiques de réseau virtuel Azure persistent avec une machine virtuelle pendant toute sa durée de vie, la configuration requise pour les services de domaine Active Directory Windows Server est satisfaite.

En conséquence, lorsque vous utilisez une adresse dynamique sur Azure, vous utilisez en fait une adresse IP statique, car elle est routable pendant toute la durée du bail, et la durée du bail correspond à la durée de vie du service cloud.

Toutefois, si la machine virtuelle est arrêtée, son adresse dynamique est désallouée. Pour éviter cela, vous pouvez utiliser l'applet de commande Set-AzureStaticVNetIP pour attribuer une adresse IP statique.

Pour la résolution de noms, déployez votre propre infrastructure de serveur DNS (ou utilisez l'infrastructure existante) ; l'infrastructure DNS fournie par Azure ne répond pas aux besoins avancés de résolution de noms des services de domaine Active Directory Windows Server. Par exemple, elle ne prend pas en charge les enregistrements SRV dynamiques, etc. La résolution de noms est un élément de configuration essentiel pour les contrôleurs de domaine et les clients joints au domaine. Les contrôleurs de domaine doivent être capables de stocker des enregistrements de ressources et de résoudre les enregistrements de ressources d'autres contrôleurs de domaine.

Pour des raisons de tolérance de panne et de performances, la solution optimale consiste à installer le service DNS Windows Server sur des contrôleurs de domaine exécutés sur Azure. Configurez ensuite les propriétés de réseau virtuel Azure à l'aide du nom et de l'adresse IP du serveur DNS. Au démarrage d'autres machines virtuelles sur le réseau virtuel, les paramètres de résolution client DNS sont configurés à l'aide du serveur DNS dans le cadre de l'allocation d'adresse IP dynamique.

noteRemarque
Vous ne pouvez pas joindre des ordinateurs locaux à un domaine Active Directory des services de domaine Active Directory Windows Server hébergé sur Azure directement via Internet. Les exigences de ports pour Active Directory et l'opération de jointure de domaine empêchent l'exposition directe des ports nécessaires, et en réalité, d'un contrôleur de domaine entier, à Internet.

Les machines virtuelles inscrivent leur nom DNS automatiquement au démarrage ou lors d'un changement de nom.

Pour plus d'informations sur cet exemple et un autre différent qui explique comment configurer la première machine virtuelle et installer les services de domaine Active Directory sur celle-ci, consultez Installer une nouvelle forêt Active Directory sur Windows Azure. Pour plus d'informations sur l'utilisation de Windows PowerShell, consultez le Guide de prise en main Azure PowerShell et les applets de commande de gestion Azure.

Windows Azure présente des avantages lorsque vous hébergez plusieurs contrôleurs de domaine sur différents réseaux virtuels :

  • Tolérance de panne de plusieurs sites

  • Proximité physique des filiales (latence inférieure)

Pour plus d'informations sur la configuration des communications directes entre des réseaux virtuels, consultez Configuration de la connectivité de réseau virtuel à réseau virtuel.

Vous devez choisir s'il faut déployer des contrôleurs de domaine en lecture seule ou accessibles en écriture. Vous pouvez être enclin à déployer des contrôleurs de domaine en lecture seule, car vous n'aurez pas de contrôle physique sur eux, mais les contrôleurs de domaine en lecture seule sont conçus pour être déployés dans des emplacements où leur sécurité physique court un risque, notamment des filiales.

Windows Azure ne présente pas le risque de sécurité physique d'une filiale. Cependant, des contrôleurs de domaine en lecture seule peuvent s'avérer plus rentables, car les fonctionnalités qu'ils fournissent sont bien adaptées à ces environnements, et ce pour des raisons très différentes. Par exemple, les contrôleurs de domaine en lecture seule n'ont aucune réplication sortante et peuvent renseigner sélectivement des secrets (mots de passe). L'équilibrage de la charge réseau (NLB) de Windows Server n'est pas pris en charge sur Azure. Cependant, les secrets peuvent être renseignés et mis en cache sélectivement.

Les contrôleurs de domaine en lecture seule offrent un avantage supplémentaire en ce qui concerne les attributs HBI et PII, car vous pouvez ajouter des attributs qui contiennent des données sensibles au jeu d'attributs filtré pour contrôleur de domaine en lecture seule. Le jeu d'attributs filtré pour contrôleur de domaine en lecture seule est un jeu d'attributs personnalisable qui n'est pas répliqué dans le contrôleur de domaine en lecture seule. Utilisez-le en tant que dispositif de protection si vous n'êtes pas autorisé à stocker les attributs PII ou HBI ou si vous ne souhaitez pas les stocker sur Windows Azure. Pour plus d'informations, consultez Jeu d'attributs filtré pour contrôleur de domaine en lecture seule.

Vérifiez que les applications seront compatibles avec les contrôleurs de domaine en lecture seule que vous projetez d'utiliser. De nombreuses applications Active Directory Windows Server fonctionnent avec des contrôleurs de domaine en lecture seule. Cependant, certaines peuvent être inefficaces ou échouer si vous n'avez pas accès à un contrôleur de domaine accessible en écriture. Pour plus d'informations, consultez le Guide de compatibilité des applications pour contrôleurs de domaine en lecture seule.

Vous devez choisir s'il faut installer un catalogue global. Dans une forêt d'un seul domaine, vous devez configurer tous les contrôleurs de domaine en tant que serveurs de catalogue global. Cela n'augmentera pas les coûts, car il n'y aura pas de trafic de réplication supplémentaire.

Dans une forêt de plusieurs domaines, les catalogues globaux sont nécessaires pour développer les appartenances au groupe universel pendant le processus d'authentification. Si vous ne déployez pas de catalogue global, les charges de travail sur le réseau virtuel qui authentifient auprès d'un contrôleur de domaine sur Windows Azure génèreront indirectement le trafic d'authentification sortant pour interroger les catalogues globaux locaux lors de chaque tentative d'authentification.

Les coûts associés aux catalogues globaux sont moins prédictibles, car ils hébergent chaque domaine (en partie). Si la charge de travail héberge un service Internet et authentifie les utilisateurs auprès des services de domaine Active Directory Windows Server, les coûts peuvent être totalement imprévisibles. Pour réduire les requêtes de catalogue global en dehors du site de cloud lors de l'authentification, activez le cache d'appartenance au groupe universel.

Vous devez choisir comment installer les contrôleurs de domaine sur le réseau virtuel :

Utilisez uniquement des machines virtuelles Azure pour les contrôleurs de domaine (par opposition à des machines virtuelles de rôle Web ou de travail Windows Azure). Elles sont durables et la durabilité de l'état pour un contrôleur de domaine est nécessaire. Les machines virtuelles Azure sont conçues pour les charges de travail telles que les contrôleurs de domaine.

N'utilisez pas SYSPREP pour déployer ou cloner des contrôleurs de domaine. La possibilité de cloner des contrôleurs de domaine est uniquement disponible à compter de Windows Server 2012. La fonctionnalité de clonage nécessite la prise en charge de VMGenerationID dans l'hyperviseur sous-jacent. Hyper-V dans Windows Server 2012 et les réseaux virtuels Windows Azure prennent en charge VMGenerationID, tout comme les fournisseurs de logiciels de virtualisation tiers.

Sélectionnez où stocker la base de données des services de domaine Active Directory Windows Server, les journaux et SYSVOL. Ils doivent être déployés sur des disques de données Azure. “

noteRemarque
Les disques de données Azure sont limités à 1 To.

Les lecteurs de disque de données ne mettent pas en cache les écritures par défaut. Les lecteurs de disque de données attachés à une machine virtuelle utilisent le cache à double écriture. Le cache à double écriture garantit que l'écriture est validée dans un stockage Azure durable avant que la transaction ne soit terminée du point de vue du système d'exploitation de la machine virtuelle. Il fournit une durabilité, au détriment d'écritures légèrement plus lentes.

Ceci est important pour les services de domaine Active Directory Windows Server, car le cache en écriture invalide les hypothèses effectuées par le contrôleur de domaine. Les services de domaine Active Directory Windows Server tentent de désactiver le cache d'écriture, mais il incombe au système d'E/S disque de la traiter. L'échec de la désactivation du cache d'écriture peut, dans certains cas, introduire une restauration USN, ce qui entraîne des objets en attente et d'autres problèmes.

Pour les contrôleurs de domaine virtuels, il est recommandé de procéder comme suit :

  • Affectez la valeur AUCUN au paramètre Préférences de cache d'hôte sur le disque de données Azure. Cela permet d'éviter des problèmes de mise en cache d'écriture pour les opérations AD DS.

  • Stockez la base de données, les journaux et SYSVOL sur le même disque de données ou sur des disques de données distincts. En général, il s'agit d'un disque distinct du disque utilisé pour le système d'exploitation. Le point important à retenir est que la base de données des services de domaine Active Directory Windows Server et SYSVOL ne doivent pas être stockés sur un disque de système d'exploitation Azure. Par défaut, le processus d'installation des services de domaine Active Directory installe ces composants dans le dossier %systemroot%, ce qui N'est PAS recommandé pour Azure.

Tenez compte de ce qui est et n'est pas pris en charge pour la sauvegarde et la restauration d'un contrôleur de domaine en général, et plus particulièrement de ceux exécutés dans une machine virtuelle. Consultez Considérations sur la sauvegarde et la restauration au sujet des contrôleurs de domaine virtualisés.

Créez des sauvegardes d'état du système uniquement en utilisant un logiciel de sauvegarde qui prend en charge les critères de sauvegarde des services de domaine Active Directory, tel que Sauvegarde Windows Server.

Ne copiez pas ou ne clonez pas les fichiers VHD des contrôleurs de domaine au lieu d'effectuer des sauvegardes normales. Si une restauration est nécessaire, l'effectuer en utilisant des VHD clonés ou copiés sans Windows Server 2012 et un hyperviseur pris en charge introduira des bulles USN.

La configuration des serveurs de fédération (Service d'émission de jeton de sécurité) ADFS Windows Server dépend en partie du fait que les applications que vous souhaitez déployer sur Azure doivent accéder à des ressources sur votre réseau local.

Si les applications répondent aux critères suivants, vous pouvez les déployer isolément de votre réseau local.

  • Elles reçoivent des jetons de sécurité SAML.

  • Elles peuvent être exposées à Internet.

  • Elles n'accèdent pas aux ressources locales.

Dans ce cas, configurez les rôles Service d'émission de jeton de sécurité ADFS Windows Server comme suit :

  1. Configurez une forêt d'un seul domaine isolée sur Azure.

  2. Donnez un accès fédéré à la forêt en configurant une batterie de serveurs de fédération ADFS Windows Server.

  3. Configurez les services ADFS Windows Server (batterie de serveurs de fédération et batterie de serveurs proxy de fédération) dans la forêt locale.

  4. Établissez une relation d'approbation de fédération entre les instances locales et les instances Azure des services ADFS Windows Server.

En revanche, si les applications nécessitent l'accès aux ressources locales, vous pouvez configurer les services ADFS Windows Server avec l'application sur Azure comme suit :

  1. Configurez la connectivité entre les réseaux locaux et Azure.

  2. Configurez une batterie de serveurs de fédération ADFS Windows Server dans la forêt locale.

  3. Configurez une batterie de serveurs proxy de fédération ADFS Windows Server sur Azure.

Cette configuration présente l'avantage de réduire l'exposition des ressources locales, comme si vous configuriez les services ADFS Windows Server avec les applications dans un réseau de périmètre.

Notez que dans les deux scénarios, vous pouvez établir des relations d'approbation avec d'autres fournisseurs d'identité, si une collaboration entre entreprises est nécessaire.

Des services de cloud computing sont nécessaires si vous souhaitez exposer une machine virtuelle directement à Internet ou exposer une application Internet à charge équilibrée. Cela est possible, car chaque service cloud fournit une seule adresse IP virtuelle configurable.

Chaque machine virtuelle Azure reçoit une adresse IP dynamique (DIP). Une DIP est une adresse privée accessible uniquement dans Azure. Dans la plupart des cas, toutefois, il est nécessaire de configurer une adresse IP virtuelle (VIP) pour vos déploiements des services ADFS Windows Server. La VIP est nécessaire pour exposer les points de terminaison ADFS Windows Server à Internet qui seront utilisés par les partenaires et les clients fédérés pour l'authentification et la gestion en continu. Une adresse VIP est une propriété d'un service cloud qui contient une ou plusieurs machines virtuelles Azure. Si l'application prenant en charge les revendications déployées sur Azure et les services AD FS Windows Server sont exposés à Internet et partagent des ports, chacun nécessite sa propre VIP. Il est donc nécessaire de créer un service cloud pour l'application et un autre pour les services AD FS Windows Server.

Pour les définitions des termes VIP et DIP, consultez Termes et définitions.

Bien qu'il soit possible de déployer des services de fédération ADFS Windows Server autonomes, il est recommandé de déployer une batterie de serveurs avec au moins deux nœuds pour les rôles Service d'émission de jeton de sécurité et les proxys ADFS Windows Server des environnements de production.

Consultez Considérations sur la topologie de déploiement d'ADFS 2.0 dans le Guide de conception ADFS 2.0 pour décider des options de configuration de déploiement les plus adaptées à vos besoins.

noteRemarque
Pour obtenir l'équilibrage de charge des points de terminaison ADFS Windows Server sur Azure, configurez tous les membres de la batterie de serveurs ADFS Windows Server dans le même service cloud, et utilisez la fonction d'équilibrage de charge de Azure pour les ports HTTP (80 par défaut) et HTTPS (443 par défaut). Pour plus d'informations, consultez Sonde d'équilibrage de charge Azure.

L'équilibrage de charge réseau (NLB) Windows Server n'est pas pris en charge sur Azure.

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft