Haute disponibilité pour Microsoft Active Directory Federation Services avec NGINX Plus

Armand Sultantono

Microsoft Active Directory Federation Services (AD FS) permet aux organisations qui hébergent des applications sur Windows Server d’étendre l’accès par authentification unique (SSO) aux employés de partenaires commerciaux de confiance via un extranet. Le partage d’informations d’identité entre les partenaires commerciaux est appelé une fédération.

En pratique, l’utilisation d’AD FS signifie que les employés des entreprises membres d’une fédération doivent uniquement se connecter à leur environnement local. Lorsqu’ils accèdent à une application web appartenant à un partenaire commercial de confiance, le serveur AD FS local transmet leurs informations d’identité au serveur AD FS du partenaire sous la forme d’un jeton de sécurité. Ce jeton se compose de plusieurs revendications, qui correspondent à des attributs individuels de l’employé (nom d’utilisateur, fonction professionnelle, identifiant d’employé, etc.) stockés dans l’instance locale d’Active Directory. Le serveur AD FS du partenaire met en correspondance les revendications du jeton avec celles reconnues par les applications du partenaire, puis détermine si l’employé est autorisé à bénéficier du type d’accès demandé.

Pour AD FS 2.0 et les versions ultérieures, vous pouvez activer la haute disponibilité (HA), afin d’améliorer la résilience et l’évolutivité des services d’authentification de vos applications. Dans un cluster AD FS à haute disponibilité, également appelé ferme, plusieurs serveurs AD FS sont déployés dans un même centre de données ou répartis entre plusieurs centres de données. Un cluster configuré en haute disponibilité entièrement active nécessite un équilibreur de charge pour répartir uniformément le trafic entre les serveurs AD FS. Dans un déploiement à haute disponibilité actif-passif, l’équilibreur de charge peut assurer le basculement vers le serveur AD FS de secours en cas de défaillance du serveur principal.

Cet article explique comment configurer NGINX Plus afin d’assurer la haute disponibilité dans les environnements exécutant respectivement AD FS 3.0 et AD FS 4.0 sous Windows Server 2012 R2 et Windows Server 2016.

Topologie HA standard pour AD FS

Cet article utilise une topologie de batterie AD FS standard à titre d’illustration. Il ne constitue pas une recommandation et ne vise pas à couvrir tous les scénarios de déploiement possibles. Pour les déploiements sur site, une batterie standard se compose d’un ou de plusieurs serveurs AD FS sur l’intranet de l’entreprise, placés derrière un ou plusieurs serveurs Proxy d’application web (WAP) situés sur un réseau DMZ. Les serveurs WAP font office de proxys inverses et permettent aux utilisateurs externes d’accéder aux applications web hébergées sur l’intranet de l’entreprise.

Cependant, WAP ne dispose d’aucune fonctionnalité intégrée permettant de configurer un cluster de serveurs ou d’assurer la haute disponibilité. Un équilibreur de charge doit donc être déployé devant les serveurs WAP. Un équilibreur de charge est également placé à la frontière entre la DMZ et l’intranet afin d’assurer la haute disponibilité d’AD FS. Dans une batterie AD FS standard, la fonctionnalité Équilibrage de la charge réseau (NLB) de Windows Server 2012 et 2016 fait office d’équilibreur de charge. Enfin, des pare-feu sont généralement mis en place devant l’adresse IP externe de l’équilibreur de charge et entre les différentes zones réseau.

Utilisation de NGINX Plus dans la topologie HA standard

Comme indiqué précédemment, NLB peut assurer la répartition de charge d’une batterie de serveurs AD FS. Toutefois, ses fonctionnalités sont assez rudimentaires (simples contrôles d’intégrité et capacités de surveillance limitées). NGINX Plus offre de nombreuses fonctionnalités essentielles à la haute disponibilité des environnements AD FS de production, tout en restant léger.

Dans le déploiement de la topologie standard décrit ici, NGINX Plus remplace NLB pour répartir la charge du trafic de toutes les batteries de serveurs WAP et AD FS. Notez toutefois que nous ne configurons pas NGINX Plus pour mettre fin aux connexions SSL destinées aux serveurs AD FS, car, pour fonctionner correctement, AD FS doit voir le certificat SSL réel du serveur WAP (pour plus de détails, consultez cet article Microsoft TechNet).

Nous vous recommandons également de mettre en œuvre la haute disponibilité pour NGINX Plus lui-même dans les environnements de production, bien que cela ne soit pas présenté ici. Pour obtenir des instructions, consultez Prise en charge de la haute disponibilité pour NGINX Plus dans les déploiements sur site dans le guide d’administration de NGINX Plus.

Configuration de NGINX Plus pour répartir la charge entre les serveurs AD FS

La configuration de NGINX Plus pour la répartition de charge entre les serveurs AD FS est simple. Comme indiqué précédemment, un serveur AD FS doit voir le certificat SSL réel d’un serveur WAP. Nous configurons donc l’instance NGINX Plus située à la frontière entre la DMZ et l’intranet afin qu’elle transmette le trafic chiffré par SSL aux serveurs AD FS sans y mettre fin ni le traiter d’une quelconque autre manière.

Outre les directives obligatoires, nous incluons les directives suivantes dans la configuration :

• zone alloue une zone de mémoire partagée dans laquelle tous les processus de travail NGINX Plus peuvent accéder aux informations de configuration et d’état d’exécution des serveurs du groupe en amont.
• hash établit la persistance de session entre les clients et les serveurs AD FS en fonction de l’adresse IP source (celle du client). Cette persistance est nécessaire même si les clients établissent une seule connexion TCP avec un serveur AD FS, car, dans certaines conditions, certaines applications peuvent subir plusieurs redirections de connexion si la persistance de session n’est pas activée.
• status_zone signifie que l’API NGINX Plus collecte des métriques pour ce serveur, qui peuvent être affichées dans le tableau de bord intégré de surveillance de l’activité en temps réel (l’API et le tableau de bord sont configurés séparément).

stream {    upstream adfs_ssl {
        zone adfs_ssl 64k;
        server 10.11.0.5:443; # AD FS server 1
        server 10.11.0.6:443; # AD FS server 2
        hash $remote_addr;
    }

    server {
        status_zone adfs_ssl;
        listen 10.0.5.15:443;
        proxy_pass adfs_ssl;
    }
}

Pour que le trafic provenant des serveurs WAP transite par NGINX Plus jusqu’aux serveurs AD FS, nous devons également associer le nom du service de fédération (fs.example.com dans notre exemple) à l’adresse IP sur laquelle NGINX Plus est à l’écoute. Pour les déploiements en production, ajoutez un enregistrement d’hôte DNS A dans la DMZ. Pour les déploiements de test, il suffit d’ajouter une entrée dans le fichier hosts de chaque serveur WAP ; c’est ce que nous faisons ici en associant fs.example.com à 10.0.5.15 dans un fichier hosts :

Pour vérifier que le trafic provenant des serveurs WAP atteint les serveurs AD FS, nous exécutons la commande ipconfig /flushdns afin de vider le cache DNS, puis nous nous connectons à AD FS dans notre navigateur depuis la page d’authentification unique (SSO), https://fs.example.com/adfs/ls/idpinitiatedsignon.htm :

Configuration de NGINX Plus pour répartir la charge entre les serveurs WAP

Nous configurons maintenant NGINX Plus afin de répartir la charge des connexions HTTPS provenant de clients externes entre les serveurs WAP. Les bonnes pratiques recommandent que le trafic soit toujours chiffré par SSL lorsqu’il atteint les serveurs AD FS. Nous utilisons donc l’une des deux approches suivantes pour configurer NGINX Plus afin qu’il transmette le trafic HTTPS aux serveurs WAP : le relais SSL ou le rechiffrement SSL.

Configuration du relais SSL

La configuration la plus simple consiste à faire en sorte que NGINX Plus transmette le trafic TCP chiffré par SSL aux serveurs WAP sans le modifier. Pour cela, nous configurons un serveur virtuel dans le contexte stream similaire à celui utilisé précédemment pour l’équilibrage de charge des serveurs AD FS.

Ici, NGINX Plus écoute le trafic externe sur une autre adresse IP unique, 10.0.5.100. Dans les environnements de production, le nom de domaine complet (FQDN) externe de l’application publiée doit pointer vers cette adresse au moyen d’un enregistrement d’hôte DNS de type « A » dans la zone publique. Pour les tests, il suffit d’ajouter une entrée dans le fichier hosts de votre machine cliente.

Remarque : Si vous prévoyez de configurer des services HTTPS supplémentaires dans le contexte stream afin qu’ils écoutent sur la même adresse IP que ce serveur, vous devez activer l’indication du nom du serveur (SNI) à l’aide de la directive ssl_preread et d’une directive map pour acheminer correctement le trafic vers les différents groupes de serveurs en amont. Ce sujet dépasse le cadre de cet article, mais la documentation de référence de NGINX fournit des exemples.

stream {    upstream wap {
        zone wap 64k;
        server 10.11.0.5:443; #WAP server 1
        server 10.11.0.6:443; #WAP server 2
        least_time connect;
    }
  
    server {
        status_zone wap_adfs;
        listen 10.0.5.100:443;
        proxy_pass wap;
    }
}

Configuration du rechiffrement HTTPS

Comme alternative au relais SSL, nous pouvons tirer parti de toutes les fonctionnalités de couche 7 de NGINX Plus en configurant un serveur virtuel dans le contexte http afin d’accepter le trafic HTTPS. NGINX Plus met fin aux connexions HTTPS des clients et établit de nouvelles connexions HTTPS avec les serveurs WAP.

Les fichiers de certificat et de clé secrète, example.com.crt et example.com.key, contiennent le nom de domaine complet (FQDN) externe de l’application publiée dans l’attribut Nom commun (CN) ou Autre nom de l’objet (SAN) ; dans cet exemple, le FQDN est fs.example.com.

Les directives « proxy_ssl_server_name » et « proxy_ssl_name » activent l’en-tête Server Name Indication (SNI) requis, qui spécifie le nom d’hôte distant à envoyer dans le message SSL Client Hello. Cet en-tête doit correspondre au nom de domaine complet (FQDN) externe de l’application publiée, dans cet exemple fs.example.com.

Nous utilisons les directives « proxy_set_header » pour transmettre les informations pertinentes aux serveurs WAP et pouvoir également les consigner dans les journaux :

• L’en-tête « X-Real-IP » contient l’adresse IP source (celle du client), telle qu’elle est enregistrée dans la variable « $remote_addr ».
• L’en-tête « X-Forwarded-For » reprend cet en-tête de la requête du client en y ajoutant l’adresse IP du client (ou contient uniquement cette adresse si la requête du client ne comporte pas cet en-tête).
• L’en-tête « x-ms-proxy » indique que l’utilisateur a été acheminé via un serveur proxy et identifie l’instance NGINX Plus comme étant ce serveur.

Outre les directives présentées ici, NGINX et NGINX Plus proposent plusieurs fonctionnalités permettant d’améliorer les performances et la sécurité de SSL/TLS. Pour plus d’informations, consultez notre blog.

http {    upstream wap {
        zone wap 64k;
        server 10.0.5.11:443;
        server 10.0.5.10:443;
        least_time header;
    }

    server {
        listen 10.0.5.100:443 ssl;
        status_zone fs.example.com;
        server_name fs.example.com;
        ssl_certificate     	/etc/ssl/example.com/example.com.crt;
        ssl_certificate_key 	/etc/ssl/example.com/example.com.key;

        location / {
            proxy_pass https://wap; # 'https' enables reencrypt 
            proxy_ssl_server_name on;
            proxy_ssl_name $host;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header x-ms-proxy $server_name;
        }
    }
}

Configuration de NGINX Plus dans une topologie sans serveurs WAP

Lorsque vous autorisez des clients externes à accéder à vos serveurs AD FS, il est recommandé d’interrompre le trafic externe à la frontière entre la DMZ et l’intranet de l’entreprise, mais aussi d’identifier les tentatives d’authentification externes en insérant l’en-tête « x-ms-proxy ». Les serveurs WAP assurent ces deux fonctions, tout comme NGINX Plus lorsqu’il est configuré comme indiqué dans la section précédente.

Les serveurs WAP ne sont pas nécessaires dans certains cas d’utilisation, par exemple lorsque vous n’utilisez pas de règles de revendication avancées telles que celles basées sur le réseau IP et les niveaux de confiance. Dans ce cas, vous pouvez supprimer les serveurs WAP et placer NGINX Plus à la frontière entre la DMZ et l’intranet afin d’authentifier les requêtes adressées aux serveurs AD FS internes. Vous réduisez ainsi vos coûts de matériel, de logiciels et d’exploitation.

Cette configuration remplace celles de la topologie HA standard. Elle est presque identique à la configuration de rechiffrement HTTPS pour l’équilibrage de charge des serveurs WAP, mais ici, NGINX Plus répartit les requêtes externes directement entre les serveurs AD FS du réseau interne.

upstream adfs {    zone adfs 64k;
    server 192.168.5.5:443; # AD FS Server 1
    server 192.168.5.6:443; # AD FS Server 2
    least_time header;
 }

server {
    listen 10.0.5.110:443 ssl;
    status_zone adfs_proxy;
    server_name fs.example.com;
    ssl_certificate         /etc/ssl/example.com/example.com.crt;
    ssl_certificate_key     /etc/ssl/example.com/example.com.key;
  
    location / {
        proxy_pass https://adfs;
        proxy_ssl_server_name on;
        proxy_ssl_name $host;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header x-ms-proxy $server_name;
    }
 }

Essayez NGINX Plus dans votre déploiement AD FS : commencez dès aujourd’hui un essai gratuit de 30 jours ou contactez-nous pour discuter de votre cas d’utilisation.

À propos de l’auteur

Armand Sultantono

Autres articles de Armand Sultantono