Use case
Mise en place d’une répartition de charge géographique pour les demandes d’authentification SAMLv2 depuis des applications cloud (public) auprès de la fédération Active Directory (ADFS).
Nous verrons que la mise en oeuvre d’une répartition basée sur la proximité (via un probe ping par exemple) n’a pas de sens dans ce cas de figure. en effet un collaborateur utilisera sans aucun doute un autre DNS récursif lors d’une seconde demande d’authentification (collaborateur en déplacement et timeout d’authentification de plusieurs heures).
C’est sur la prochaine étape, c’est à dire la requête émise par le DNS Recursif vers le DNS authoritatif de l’entreprise (via les DNS racine si nécessaire) que cela devient intéressant…
Le DNS authoritatif de l’entreprise (company.com) doit être configuré avec 2 enregistrements pour la zone “ext” dont fait parti le FQDN. Etant donné que le comportement des DNS récursifs et des client DNS n’est pas maîtrisé, il est opportun de configurer le DNS authoritatif pour qu’il réponde à la requête avec les 2 enregistrements (@IP de NS A et NS B) dans des ordres différents afin de répartir la charge et surtout offrir une certaine résilience. Cela se passe sur BIND par le paramètre rrsort_order.
Prenons le cas où le DNS authoritatif répond avec l’IP du “NS B” en premier, IP qui sera utilisée par le DNS récursif pour la prochaine itération en vue de résoudre le FQDN (adfs.ext.company.com).
A ce stade le “NS B” n’a pas d’information quant à la proximité du client. Il répond donc avec une des IP d’un “virtual server” configuré de manière aléatoire. Dans notre cas avec l’IP du “NS A”.
Le client est ensuite à même d’envoyer sa requête SAMLv2 au “NS A” qui pourra faire office de loadbalancer local (cas avec 2 ADFS par site), voir de proxy.
Proximité
Ce n’est qu’après avoir reçu une requête DNS qu’un NS est en mesure de faire des calculs de proximité. Prenons le cas avec des mesures de RTT. Les pings émis par les NS ne peuvent se faire que sur les IP des DNS recursifs et non des IP réelles des clients, c’est donc un premier problème.
Les 2 NS procédent donc à des mesures (ping) chacun de leur coté et s’échange les informations (RTT) via un protocole (MEP pour les Netscaler). Ainsi lors d’une requête en provenance d’un DNS récursif connu, le NS en charge de la réponse pourra répondre avec l’IP du NS le plus proche.
Les chances qu’un collaborateur, après son timeout de session se connecte via le même DNS recursif est faible. C’est le second problème.
Architecture – Aspects résilience
Le fait de mettre en oeuvre des appliances NS (Netscaler) virtualisées sur des infra ESX permet de faire porter la résilience à la panne, maintenance hardware et réseau par les cluster ESX (avec la mise en oeuvre des technologie type vmWare HA, vMotion).
Reste à couvrir la maintenance software (upgrade des NS par exemple) et le sinistre (perte d’un site).
Afin de palier à ces problèmes, il faut chercher du côté du DNS authoritatif.
- Pour la maintenance software: Prévoir dans la procédure de retirer au préalable (en commentaire) l’enregistrement du NS impacté.
- Pour le sinistre il faudrait mettre en oeuvre des scripts de vérification (ping) sur le(s) serveur DNS)
Architecture – Netscaler
La configuration d’un netscaler n’est pas forcement intuitive que ce soit en CLI ou en WEB. Le schéma ci-dessous montre l’architecture logicielle:
