Haute disponibilité pour les services de fédération Microsoft Active Directory avec NGINX Plus

Microsoft Active Directory Federation Services (AD FS) permet aux organisations qui hébergent des applications sur Windows Server d’étendre l’accès à l’authentification unique (SSO) aux employés de partenaires commerciaux de confiance sur 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 d’une fédération n’ont qu’à 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'identification au serveur AD FS du partenaire sous la forme d'un jeton de sécurité. Le jeton est composé de plusieurs revendications , qui sont des attributs individuels de l'employé (nom d'utilisateur, rôle professionnel, ID d'employé, etc.) stockés dans l'annuaire Active Directory local. Le serveur AD FS du partenaire mappe les revendications du jeton sur les revendications comprises par les applications du partenaire, puis détermine si l'employé est autorisé pour le type d'accès demandé.

Pour AD FS 2.0 et versions ultérieures, vous pouvez activer la haute disponibilité (HA), ajoutant de la résilience et de l’évolutivité aux services d’authentification de vos applications. Dans un cluster AD FS HA, également appelé batterie de serveurs AD FS, plusieurs serveurs AD FS sont déployés dans un seul centre de données ou répartis entre plusieurs centres de données. Un cluster configuré pour une haute disponibilité entièrement active a besoin d’un équilibreur de charge pour répartir le trafic de manière uniforme sur les serveurs AD FS. Dans un déploiement HA actif-passif, l’équilibreur de charge peut fournir un basculement vers le serveur AD FS de sauvegarde en cas de défaillance du serveur principal.

Cet article explique comment configurer NGINX Plus pour fournir HA dans les environnements exécutant respectivement AD FS 3.0 et AD FS 4.0 Server 2012 R2 et Windows Server 2016 .

Topologie HA standard pour AD FS

Cet article utilise une topologie de batterie de serveurs AD FS standard à des fins d’illustration. Il ne s’agit pas d’une recommandation ni d’une couverture de tous les scénarios de déploiement possibles. Pour les déploiements sur site, une batterie de serveurs standard se compose d’un ou plusieurs serveurs AD FS sur l’intranet de l’entreprise, précédés d’un ou plusieurs serveurs proxy d’application Web (WAP) sur un réseau DMZ. Les serveurs WAP agissent comme des proxys inverses qui permettent aux utilisateurs externes d'accéder aux applications Web hébergées sur l'intranet de l'entreprise.

Cependant, WAP ne dispose pas d’un moyen intégré pour configurer un cluster de serveurs ou prendre en charge HA. 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, pour activer la haute disponibilité pour AD FS. Dans une batterie de serveurs AD FS standard, la fonctionnalité d’équilibrage de charge réseau (NLB) de Windows Server 2012 et 2016 agit comme équilibreur de charge. Enfin, les pare-feu sont généralement implémentés devant l’adresse IP externe de l’équilibreur de charge et entre les zones réseau.

Utilisation de NGINX Plus dans la topologie HA standard

Comme indiqué, NLB peut effectuer l’équilibrage de charge pour une batterie de serveurs AD FS. Cependant, ses fonctionnalités sont assez basiques (juste des contrôles de santé de base et des capacités de surveillance limitées). NGINX Plus possède de nombreuses fonctionnalités essentielles pour la haute disponibilité dans les environnements AD FS de production tout en restant léger.

Dans le déploiement de la topologie standard décrite ici, NGINX Plus remplace NLB pour équilibrer la charge du trafic pour toutes les batteries WAP et AD FS. Notez cependant que nous ne demandons pas à NGINX Plus de mettre fin aux connexions SSL pour les serveurs AD FS, car le bon fonctionnement d'AD FS nécessite qu'il voie le certificat SSL réel du serveur WAP (pour plus de détails, consultez cet article Microsoft TechNet ).

Nous vous recommandons d'implémenter également HA pour NGINX Plus lui-même dans les environnements de production, mais ne l'affichez pas 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 équilibrer la charge des serveurs AD FS

La configuration NGINX Plus pour l’équilibrage de charge des serveurs AD FS est simple. Comme mentionné ci-dessus, un serveur AD FS doit voir le certificat SSL réel d'un serveur WAP. Nous configurons donc l'instance NGINX Plus sur la frontière DMZ-intranet pour transmettre le trafic chiffré SSL aux serveurs AD FS sans le terminer ni le traiter d'une autre manière.

En plus des directives obligatoires, nous incluons ces directives dans la configuration :

• zone alloue une zone dans la mémoire partagée où tous les processus de travail NGINX Plus peuvent accéder aux informations de configuration et d'état d'exécution sur les serveurs du groupe en amont.
• Le hachage établit la persistance de session entre les clients et les serveurs AD FS, en fonction de l'adresse IP source (celle du client). Cela est nécessaire même si les clients établissent une connexion TCP unique 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 sur le tableau de bord de surveillance d'activité en direct intégré (l' API et le tableau de bord sont configurés séparément ).

flux { en amont adfs_ssl { zone adfs_ssl 64k ; serveur 10.11.0.5:443; # Serveur AD FS 1 serveur 10.11.0.6:443; # Serveur AD FS 2 hachage $remote_addr ; } serveur { zone_état adfs_ssl ; écoute 10.0.5.15:443; proxy_pass adfs_ssl; } }

　
Pour que le trafic des serveurs WAP circule via NGINX Plus vers les serveurs AD FS, nous devons également mapper le nom du service de fédération ( fs.example.com dans notre exemple) à l'adresse IP sur laquelle NGINX Plus écoute. Pour les déploiements de production, ajoutez un enregistrement DNS Host A dans la DMZ. Pour les déploiements de test, il suffit de créer une entrée dans le fichier hosts sur chaque serveur WAP ; c'est ce que nous faisons ici, en liant fs.example.com à 10.0.5.15 dans un fichier hosts :

Pour tester que le trafic provenant des serveurs WAP atteint les serveurs AD FS, nous exécutons la commande ipconfig /flushdns pour vider le DNS, puis dans notre navigateur, nous nous connectons à AD FS sur la page SSO, https://fs.example.com/adfs/ls/idpinitiatedsignon.htm :

Configuration de NGINX Plus pour équilibrer la charge des serveurs WAP

Nous configurons maintenant NGINX Plus pour équilibrer la charge des connexions HTTPS des clients externes vers les serveurs WAP. Les bonnes pratiques stipulent que le trafic est toujours chiffré SSL lorsqu'il atteint les serveurs AD FS. Nous utilisons donc l'une des deux approches pour configurer NGINX Plus afin de transmettre le trafic HTTPS aux serveurs WAP : Passage SSL ou rechiffrement SSL.

Configuration du relais SSL

La configuration la plus simple consiste à laisser NGINX Plus transférer le trafic TCP chiffré SSL inchangé vers les serveurs WAP. Pour cela, nous configurons un serveur virtuel dans le contexte de flux similaire au précédent pour équilibrer la charge des serveurs AD FS .

Ici, NGINX Plus écoute le trafic externe sur une adresse IP unique différente, 10.0.5.100. Pour les environnements de production, le FQDN externe de l'application publiée doit pointer vers cette adresse sous la forme d'un enregistrement DNS Host A dans la zone publique. Pour les tests, une entrée dans le fichier hosts de votre machine cliente suffit.

Note: Si vous souhaitez configurer des services HTTPS supplémentaires dans le contexte de flux pour écouter 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 avec une carte pour acheminer correctement le trafic vers différents flux en amont. Ceci sort du cadre de ce blog, mais la documentation de référence NGINX inclut des exemples .

flux { wap en amont {
zone wap 64k ;
serveur 10.11.0.5 : 443 ; # serveur WAP 1
serveur 10.11.0.6 : 443 ; # serveur WAP 2
connexion au moins_temps ;
}

serveur {
zone_état wap_adfs ;
écoute 10.0.5.100 : 443 ;
proxy_pass wap ;
}
}

Configuration du rechiffrement HTTPS

En guise d’alternative au transfert 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 pour accepter le trafic HTTPS. NGINX Plus met fin aux connexions HTTPS des clients et crée de nouvelles connexions HTTPS aux serveurs WAP.

Les fichiers de certificat et de clé secrète, example.com.crt et example.com.key , contiennent le nom de domaine complet externe de l'application publiée dans la propriété Nom commun ( CN ) ou Nom alternatif du sujet ( SAN ) ; dans cet exemple, le nom de domaine complet est fs.example.com .

Les directives proxy_ssl_server_name et proxy_ssl_name activent l'en-tête SNI (Server Name Indication) requis, spécifiant un nom d'hôte distant à envoyer dans le client SSL Hello. L'en-tête doit correspondre au 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 également pour pouvoir les capturer dans les journaux :

• L'en-tête X-Real-IP contient l'adresse IP source (du client) telle que capturée dans la variable $remote_addr .
• Le X-Forwarded-For transmet cet en-tête à partir de la demande du client, avec l'adresse IP du client qui lui est ajoutée (ou simplement cette adresse si la demande du client n'a pas l'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 ce serveur.

En plus des directives présentées ici, NGINX et NGINX Plus fournissent un certain nombre de fonctionnalités qui peuvent 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' active le rechiffrement proxy_ssl_server_name sur ; proxy_ssl_name $host ; proxy_set_header Hôte $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Transféré-Pour $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é de terminer le trafic externe à la frontière entre la DMZ et l'intranet de l'entreprise et également d'identifier les tentatives d'authentification externes en insérant l'en-tête x-ms-proxy . Les serveurs WAP remplissent ces deux fonctions, mais comme configuré dans la section précédente, NGINX Plus le fait également.

Les serveurs WAP ne sont pas requis dans certains cas d’utilisation, par exemple lorsque vous n’utilisez pas de règles de revendication avancées telles que le réseau IP et les niveaux de confiance. Dans de tels cas, vous pouvez éliminer les serveurs WAP et placer NGINX Plus à la frontière entre la DMZ et l'intranet pour authentifier les demandes adressées aux serveurs AD FS internes. Cela réduit vos coûts matériels, logiciels et opérationnels.

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

amont adfs { zone adfs 64k;
serveur 192.168.5.5:443; # Serveur AD FS 1
serveur 192.168.5.6:443; # Serveur AD FS 2
en-tête least_time;
}

serveur {
écoute 10.0.5.110:443 ssl;
zone_état adfs_proxy;
nom_serveur fs.exemple.com;
certificat_ssl /etc/ssl/exemple.com/exemple.com.crt;
clé_certificat_ssl /etc/ssl/exemple.com/exemple.com.key;

emplacement / {
proxy_pass https://adfs;
nom_serveur_ssl_proxy on;
nom_ssl_proxy $host;
en-tête_set_proxy Hôte $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 – démarrez un essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de votre cas d’utilisation.