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: avril 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 Windows 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 Windows Azure/réseaux virtuels Windows Azure et les déploiements locaux traditionnels d'Active Directory. Les machines virtuelles et les réseaux virtuels Windows Azure font partie d'une offre d'infrastructure IaaS (Infrastructure-as-a-service) destinée aux entreprises pour exploiter les ressources de calcul 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 ADFS 2.0, 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 Windows 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 Windows 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 du déploiement et de la configuration d'Active Directory de Windows Azure, un service REST qui fournit des fonctionnalités de gestion d'identité et de contrôle d'accès pour vos applications Cloud. Active Directory de Windows Azure 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 Active Directory de Windows Azure, 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 Windows Azure lorsque vous utilisez Windows Azure pour étendre votre centre de données local dans le cloud.

  2. Vous pouvez utiliser Active Directory de Windows Azure 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 Windows Azure ou d'autres plateformes du cloud peuvent également l'utiliser.

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

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

Les conditions requises fondamentales pour déployer Active Directory Windows Server sur des machines virtuelles Windows Azure diffèrent peu du déploiement dans des machines virtuelles (et, dans une certaine mesure, sur des ordinateurs physiques) localement. 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 Windows Azure sont des réplicas dans un domaine et/ou une forêt d'entreprise locaux existants, le déploiement Windows 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 créé, des sous-réseaux liés à ce site et connectés à d'autres sites via des liens de sites appropriés. Il existe, toutefois, plusieurs différences communes à tous les déploiements Windows Azure et certaines qui varient selon le scénario de déploiement spécifique. Trois différences fondamentales sont décrites ci-dessous et expliquées plus en détail dans les paragraphes qui suivent :

  1. Les machines virtuelles Windows Azure devront peut-être être connectées au réseau d'entreprise local.

    La reconnexion des machines virtuelles Windows Azure à un réseau d'entreprise local nécessite un réseau virtuel Windows Azure, qui inclut un composant de réseau privé virtuel (VPN) de site à site ou de site à point capable de connecter de façon transparente les machines virtuelles Windows 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 Windows 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 Créer un réseau virtuel avec connectivité entre différents locaux, consultez Mise en réseau.

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

  2. Les adresses IP statiques NE sont PAS prises en charge sur les machines virtuelles Windows Azure.

    Des adresses dynamiques doivent donc être utilisées à la place, ce qui nécessite la création d'un réseau virtuel Windows Azure. À première vue, cela semble en contradiction avec les meilleures pratiques Active Directory Windows Server, mais étant donné que les adresses IP dynamiques des machines virtuelles Windows Azure attachées à un réseau virtuel Windows Azure persistent pendant toute la durée de vie de la machine virtuelle, les conditions requises par Active Directory Windows Server pour l'adressage IP sont satisfaites (de même que celles concernant DNS en cas de colocalisation avec le contrôleur de domaine).

    En outre, les réseaux virtuels Windows Azure fournissent des degrés de contrôle plus poussés de l'adressage IP et DNS.

    Consultez Adressage IP et DNS.

  3. Windows Azure fournit deux types distincts de disque pour les machines virtuelles.

    Le choix du type de disque est essentiel lors du déploiement de contrôleurs de domaine. Windows Azure propose des disques de système d'exploitation et des disques de données. Les disques de données utilisent le cache à double écriture, ce qui garantit la durabilité des écritures. Cela est essentiel pour l'intégrité des forêts Active Directory Windows Server qui ont plusieurs contrôleurs de domaine, car la perte d'une seule écriture affecte l'ensemble du système distribué et non pas un seul ordinateur. Les facteurs supplémentaires à prendre en compte, ainsi que les scénarios dans lesquels ils influencent les choix de configuration et de déploiement, sont décrits en détail dans le reste de ce document.

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

La liste non exhaustive de termes suivante définit différentes technologies Windows Azure pertinentes et vous aidera à comprendre ce document. Pour un glossaire complet, consultez Glossaire Windows Azure.

  • Machines virtuelles Windows Azure : offre IaaS dans Windows 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 Windows Azure : service de mise en réseau dans Windows Azure qui permet aux clients de créer et de gérer des réseaux virtuels dans Windows 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 Windows 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 Windows 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 de l'adresse qui sera affectée dynamiquement à la carte réseau virtuelle d'une machine virtuelle Windows Azure par DHCP. Toutefois, l'adresse IP sera persistante avec cette machine virtuelle pendant toute la durée de vie du déploiement de la même façon que les réservations DHCP sont attachées à des adresses MAC individuelles.

  • Réparation de service : processus dans lequel Windows 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 Windows 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 la configuration IP de la machine virtuelle est définie dans le cadre du réseau virtuel ou de la machine virtuelle (pas du système d'exploitation invité).

    Aucun de ces comportements n'affecte Active Directory Windows Server. 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 d'Active Directory Windows Server sur un réseau virtuel Windows Azure comme expliqué ci-dessus, ce qui garantit que l'adresse IP persiste via la réparation de service.

Le déploiement de contrôleurs de domaine Active Directory Windows Server sur des machines virtuelles Windows 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. Bien que Windows Azure ne fournisse pas de fonctionnalité de restauration d'instantané, certaines fonctionnalités peuvent 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. Windows 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 Windows Azure disposent de dispositifs de protection supplémentaires. Pour plus d'informations, consultez Présentation de la virtualisation des services de domaine Active Directory.

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 Windows 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 Windows Azure en Asie. Le fait d'attacher ce contrôleur de domaine à un réseau virtuel Windows Azure qui est connecté directement à l'emplacement distant améliorera les performances d'authentification.

Windows 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 Windows Azure représente une solution séduisante.

Enfin, vous pouvez déployer une application réseau sur Windows 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 Windows 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 Windows 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 Windows Azure. Mais si le VPN est indisponible, la communication entre les ordinateurs locaux et les contrôleurs de domaine Windows Azure ne fonctionne pas, ce qui entraîne une authentification et diverses autres erreurs.  

  • Pour les scénarios de déploiement Active Directory Windows Server qui incluent plusieurs machines virtuelles, nous vous recommandons d'utiliser un réseau virtuel Windows Azure afin d'assurer la cohérence des adresses IP, car les adresses affectées statiquement ne sont pas prises en charge. Notez que ce guide suppose que les contrôleurs de domaine s'exécutent sur un réseau virtuel Windows Azure.

    La cohérence des adresses IP sur le réseau virtuel Windows Azure s'effectue à l'aide d'un troisième nouveau type conceptuel d'adresse IP qui est semblable aux réservations DHCP. Aujourd'hui, les adresses IP statiques sont affectées dans le système d'exploitation à une carte d'interface réseau spécifique. Les adresses dynamiques sont louées automatiquement à partir des serveurs DHCP selon les étendues définies sur le serveur DHCP.

    Un troisième type conceptuel d'adresse est introduit par les réseaux virtuels Windows Azure et diffère légèrement de l'allocation d'adresse DHCP. Avec les machines virtuelles Windows Azure, la machine virtuelle must être configurée de façon à louer adresse IP de DHCP. Contrairement aux adresses dynamiques classiques, qui peuvent changer lorsqu'un bail expire, les adresses dynamiques sur les réseaux virtuels Windows Azure sont garanties pour la durée de vie de la machine virtuelle de la même façon que les réservations DHCP.

    ImportantImportant
    La configuration d'une adresse IP statique dans une machine virtuelle entraîne une perte de connectivité.

  • 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 Windows 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 Windows Azure au réseau local. Pour plus d'informations, consultez Présentation du réseau virtuel et Tutorial 2: Creating a Virtual Network for cross-premises connectivity.

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

  • Que vous créiez un réseau virtuel ou non, Windows 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. Pour plus d'informations sur les frais liés au trafic, consultez Présentation de la facturation Windows Azure.

  • Il est important de noter qu'il n'existe aucune connexion directe entre des réseaux virtuels Windows Azure distincts. Autrement dit, si vous créez deux réseaux virtuels, peut-être distribués géographiquement, la communication entre les machines virtuelles Windows Azure qui leur sont attachées ne peut être obtenue qu'en connectant les deux réseaux virtuels au même réseau d'entreprise via la fonction VPN de site à site. La communication entre les deux réseaux virtuels est ensuite possible, mais uniquement en routant le trafic via le réseau d'entreprise. Par conséquent, la communication entre des contrôleurs de domaine répartis dans différents points géographique doit traverser les deux réseaux virtuels et votre réseau d'entreprise. Par exemple, pour qu'une machine virtuelle Windows Azure sur un réseau virtuel en Asie communique avec une autre machine virtuelle Windows Azure sur un réseau virtuel en Amérique du Sud, la communication de bout en bout doit parcourir le réseau interne.

  • 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 Windows 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. Pour plus d'informations sur les ressources de calcul, consultez 7 points pour en savoir plus sur la capacité de Windows Azure.

ADFS est pris en charge pour le déploiement sur des machines virtuelles Windows Azure. Cependant, il existe des meilleures pratiques qui exigent des technologies qui vont au-delà des fonctions proposées par ADFS, par exemple équilibrage de charge/haute disponibilité. É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. Par exemple, il est fortement recommandé que les rôles Proxy ADFS et Service d'émission de jeton de sécurité aient une charge équilibrée et soient hautement disponibles. Windows Azure ne satisfait pas ces exigences d'équilibrage de charge et de haute disponibilité sur les interfaces privées (adresses IP dynamiques) d'une machine virtuelle. C'est pourquoi, un compromis doit être trouvé pour certaines configurations de déploiement ADFS.

Une configuration de déploiement possible utilisant AD FS qui satisfait toutes les meilleures pratiques sans compromis consiste simplement à déplacer les proxys ADFS de votre zone DMZ locale vers Windows Azure. Cette configuration repose sur les fonctions d'équilibrage de charge de Windows Azure pour les adresses IP virtuelles, ce qui respecte entièrement les meilleures pratiques d'équilibrage de la charge et de haute disponibilité pour exécuter AD FS. Pour plus d'informations sur ce scénario, consultez 2. Services ADFS : étendre une application frontale locale prenant en charge les revendications à Internet.

Pour mieux comprendre les configurations de déploiement AD FS possibles où un tel compromis est requis, reportez-vous à l'actualisateur suivant montrant le mode de déploiement local d'ADFS, et comparez-le avec les possibilités actuellement offertes par les machines virtuelles Windows Azure. Le diagramme suivant tiré de Planifier votre déploiement ADFS montre un déploiement classique d'ADFS.

WID AD FS et proxys

Les rôles Service d'émission de jeton de sécurité sont déployés dans le pare-feu d'entreprise et utilisent NLB pour l'équilibrage de charge. Lorsqu'un utilisateur attaché au réseau d'entreprise et connecté au domaine corp.fabrikam.com souhaite accéder à Office 365 dans ce scénario, il est redirigé vers le point de terminaison à charge équilibrée/hautement disponible devant les rôles Service d'émission de jeton de sécurité.

Les proxys ADFS sont déployés sur les réseaux de périmètre et utilisent également NLB pour équilibrer la charge des demandes des utilisateurs externes. Les demandes externes sont transmises par les proxys ADFS au point de terminaison à charge équilibrée/hautement disponibles devant les rôles Service d'émission de jeton de sécurité.

Dans tous les cas, notez que la recommandation garantit que les interfaces utilisées sont équilibrées en charge et hautement disponibles. Le moyen par lequel ce résultat est obtenu n'est pas important et NLB est utilisé à titre d'exemple.

noteRemarque
Pour plus d'informations sur la façon dont l'utilisateur est authentifié dans ce scénario, consultez Fonctionnement d'ADFS avec Office 365

Dans la plupart des cas, l'échec d'une application activée par ADFS est inacceptable, car ces applications sont souvent critiques. En conséquence, et étant donné qu'ADFS se trouve dans le chemin critique d'accès aux applications, les meilleures pratiques suivantes (illustrées dans le diagramme précédent) doivent être respectées :

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

    En tant que meilleure pratique de sécurité, placez les instances Service d'émission de jeton de sécurité derrière un pare-feu et connectez-les à votre réseau d'entreprise pour empêcher l'exposition à 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.

  2. Le service ADFS doit être hautement disponible.

    Si l'application qui nécessite ADFS est critique, le service ADFS 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é.

Considérons maintenant comment cette configuration peut être déployée sur des machines virtuelles Windows Azure. Les coches verte indiquent que les meilleures pratiques peuvent être satisfaites sans compromission, et une croix rouge indique que les conditions ne peuvent pas être satisfaites à l'aide de machines virtuelles Windows Azure.

AD FS et proxys sur Windows Azure

Notez que l'équilibrage de charge et la haute disponibilité ne peuvent pas être fournis pour les serveurs de Service d'émission de jeton de sécurité. La seule façon d'équilibrer la charge de ces serveurs serait de les exposer à l'aide d'une adresse IP virtuelle, car ces adresses fournissent des fonctions équilibrage de charge natives, contrairement aux adresses IP dynamiques. Toutefois, cela ne respecte pas la première meilleure pratique (N'exposez jamais les rôles Service d'émission de jeton de sécurité directement à Internet).

Pour résumer, la solution exige que la haute disponibilité ou la sécurité soit compromise. Aucun de ces compromis n'est généralement acceptable si l'application est critique, étant donné qu'ADFS réside dans le chemin critique d'accès à l'application.

Que pensez-vous du déploiement des rôles Service d'émission de jeton de sécurité avec une adresse IP virtuelle et la configuration d'un pare-feu ?

Bien qu'il soit possible de placer des contraintes de pare-feu sur l'adresse IP virtuelle proprement dite, vous devez rationaliser la stabilité, la configuration et la maintenance à long terme par rapport à la valeur fournie. Déterminez les règles qui doivent être ajoutées, ou comment exprimer une règle de pare-feu VIP qui permet l'accès au point de terminaison à charge équilibrée d'adresses IP virtuelles à partir des proxys et des utilisateurs locaux. En outre, tenez compte de la logistique de maintenance de la liste de contrôle d'accès à mesure que les fournisseurs réseau de la société évoluent, et encore plus important, de la perte d'accès à l'application résultante. Il est également possible de répondre à l'exigence d'équilibrage de charge en déployant une technologie d'équilibrage de charge locale, qui fait face aux rôles Service d'émission de jeton de sécurité qui se trouvent dans Windows Azure. Cependant, cela crée une solution très compliquée et une proposition de dépannage ambitieuse si des erreurs se produisent. Là encore, cela contredit une des raisons qui justifient la migration vers Windows Azure (simplification, réduction des coûts, etc.).

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 Windows 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 Active Directory de Windows Azure.

  4. Étant donné qu'Active Directory de Windows Azure 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 Active Directory de Windows Azure.

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

  8. Active Directory de Windows Azure 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 Active Directory de Windows Azure.

  4. Active Directory de Windows Azure 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 Active Directory de Windows Azure les valide par rapport au nom d'utilisateur et au mot de passe qui ont été synchronisés par DirSync.

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

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

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.

Conclusion

Le déploiement d'ADFS sur des machines virtuelles Windows Azure est une question de risque et d'avantage. L'avantage lié au déploiement d'ADFS dans Windows Azure peut être supérieur aux risques, mais la décision doit être prise dans le contexte du scénario de déploiement. Le tableau suivant tente de capturer la matrice de décision.

 

Déploiement Avantage Risque

Déployer des serveurs de Service d'émission de jeton de sécurité en utilisant uniquement leur adresse IP dynamique

Déploiement sécurisé qui respecte les meilleures pratiques

Compromettre la haute disponibilité et l'équilibrage de charge

Déployer des serveurs de Service d'émission de jeton de sécurité en utilisant une adresse IP virtuelle

Obtenir la haute disponibilité et l'équilibrage de charge

Ignore les meilleures pratiques légitimes concernant la sécurité

Déployer des serveurs de Service d'émission de jeton de sécurité avec une adresse IP virtuelle et des règles de pare-feu

Obtenir sécurité et haute disponibilité

Compromettre la simplicité et la configuration fragile

Déployer des programmes d'équilibrage de charge localement pour faire face aux rôles Service d'émission de jeton de sécurité qui utilisent uniquement des adresses IP dynamiques sur Windows Azure

Obtenir sécurité et haute disponibilité

Compromettre la simplicité du dépannage

Autres éléments de réflexion

  • Si vous déployez un proxy ADFS Windows Server sur une machine virtuelle Windows 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 Windows 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 Windows Azure. Si le coût est un facteur déterminant, il est recommandé de déployer les proxys ADFS sur Windows 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 Windows 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 Windows 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 Windows Azure (par opposition aux rôles Web ou de travail), une custom probe doit être utilisée, car l'agent qui répond aux default probes n'est pas présent sur les machines virtuelles Windows 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 Windows 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 Windows Azure.

  • Topologie de réseau : créez un réseau virtuel Windows 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 :

    1. Utilisez des adresses DHCP-louées (obligatoire ; les adresses statiques NE sont PAS prises en charge)

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

  • 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 Windows Azure afin de stocker la base de données Active Directory, 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 Windows 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 Windows Azure.

  • Topologie de réseau : créez un réseau virtuel Windows 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 Windows 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 ADFS Windows Server, et utiliser la fonction native d'équilibrage de charge du serveur de Windows Azure pour distribuer les requêtes entrantes entre les serveurs dans la batterie. L'équilibrage de charge natif de Windows Azure n'est pris en charge que lorsque vous utilisez des adresses IP virtuelles Internet ; les adresses IP dynamiques ne peuvent pas être équilibrées en charge.

    Pour plus d'informations, consultez le Guide de déploiement ADFS 2.0.

Déploiement AD DS intersite

Figure 3

Une application LDAP qui prend en charge l'authentification intégrée Windows et utilise lers 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 Windows 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 Windows Azure.

  • Topologie de réseau : créez un réseau virtuel Windows Azure avec une connectivité entre différents locaux. Cela exige que vous déployiez un point de terminaison de VPN compatible sur le périmètre du réseau d'entreprise. Pour plus d'informations, consultez À propos des appareils VPN pour le réseau virtuel.

  • 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 Install a replica Active Directory DC in Windows Azure Virtual Network. 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 Windows Azure.

  • Topologie de site Active Directory Windows Server : créez un site Windows 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 Windows Azure et ajoutez le sous-réseau au site. Créez un lien de site qui comprend le nouveau site Windows Azure et le site dans lequel se trouve le point de terminaison de VPN du réseau virtuel Windows Azure pour contrôler et optimiser le trafic Active Directory Windows Server vers et depuis Windows Azure.

  • Adressage IP et DNS :

    1. Utilisez des adresses DHCP-louées (obligatoire ; les adresses statiques NE sont PAS prises en charge).

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

  • Contrôleurs de domaine répartis dans plusieurs points géographiques : configurez autant de réseaux virtuels supplémentaires que nécessaires. Si une communication directe est nécessaire entre les réseaux virtuels, les deux doivent être configurés de façon à utiliser leurs fonctions VPN de site à site et le trafic entre eux sera routé via le réseau d'entreprise interne.

  • Contrôleurs de domaine en lecture seule : vous pouvez déployer un contrôleur de domaine en lecture seule dans le site Windows 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 Windows 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 Windows 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 Windows 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 Windows Azure afin de stocker la base de données Active Directory, 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 Windows 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 ?

Utiliser uniquement des adresses avec bail DHCP Windows Azure

Installer un serveur DNS Windows Server

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 ?

Aucune communication directe entre des réseaux virtuels géographiquement 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 domaines, 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 Windows Azure ?

ImportantImportant
N'utilisez pas SYSPREP pour cloner des contrôleurs de domaine. Cependant, vous pouvez utiliser le clonage de contrôleur de domaine virtuel avec des machines virtuelles Windows Azure qui exécutent Windows Server 2012.

  • 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 Windows 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

Ne par copier ou cloner les fichiers VHD

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éployer 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 Windows 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 Windows 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 Windows 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 Windows 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 Présentation de la facturation Windows 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 Windows 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 Présentation de la facturation Windows 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 Windows 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 Windows 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 Windows 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 Windows Azure sont isolées du réseau d'entreprise.

  • Le trafic entrant est gratuit.

  • Le trafic sortant est facturé conformément à la Présentation de la facturation Windows 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 Windows 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 Windows 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 Windows 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és 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 Windows Azure nécessitent des adresses avec bail DHCP et, comme mentionné précédemment, cela est contraire aux meilleures pratiques existantes. Étant donné que les adresses dynamiques de réseau virtuel Windows 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. Alors que l'utilisation d'adresses statiques peut initialement sembler fonctionner correctement, au fil du temps, elle provoque une perte complète de connectivité à la machine virtuelle et entre les machines virtuelles affectées.

En conséquence, lorsque vous utilisez une adresse dynamique sur Windows 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.

Pour la résolution de noms, déployez vôtre propre infrastructure de serveur DNS (ou utilisez l'infrastructure existante) ; l'infrastructure DNS fournie par Windows 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 Windows Azure.

noteRemarque
Vous ne pouvez pas joindre des ordinateurs locaux à un domaine Active Directory des services de domaine Active Directory Windows Server hébergé sur Windows 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 mise en route avec Windows Azure PowerShell et les Applets de commande de gestion Windows 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)

Mais aucune communication directe n'existe entre les réseaux virtuels Windows Azure. Toute communication entre différents réseaux virtuels Windows Azure doit être routée via le réseau local, ce qui peut générer un grand volume de trafic sortant (et les coûts associés à ce trafic).

Aucune connectivité entre les réseaux virtuels

Figure 4

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 Windows 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 universal.

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

Utilisez uniquement des Windows Azure Virtual Machines 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 Windows 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 Windows Azure. Les disques de données et les disques de système d'exploitation sont deux types distincts de lecteur de disque virtuel pour Windows Azure. Leurs comportements (et valeurs par défaut) sont différents.

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

Contrairement aux lecteurs de disque de système d'exploitation, 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 write-through caching. Le cache à double écriture garantit que l'écriture est validée dans un stockage Windows Azure durable before 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 certaines 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 stocker 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 Windows 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 Windows 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 Windows 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 Windows 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 Windows 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 Windows Azure comme suit :

  1. Configurez la connectivité entre les réseaux locaux et Windows 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 Windows 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 Windows Azure reçoit une adresse IP dynamique (DIP). Une DIP est une adresse privée accessible uniquement dans Windows 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 Windows Azure. Si l'application prenant en charge les revendications déployée sur Windows Azure et les services ADFS 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 ADFS 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 Windows 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 Windows 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 Windows Azure.

L'équilibrage de charge réseau (NLB) Windows Server n'est pas prise en charge sur Windows 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