Le blog d'Alexandre GIRAUD MVP Forefront

3^ème et dernière partie pour optimiser les connexions avec UAG et ADFS dans des environnements isolés

Nous avons vu déjà lors de deux précédents articles, qu'un environnement UAG avec ou sans ADFS pouvait ralentir les premières connexions. Ces effets étaient surtout visibles lorsque l'environnement d'UAG n'a pas d'accès à Internet : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=190

Ensuite, nous avions remarqué que le pool d'Application ADFS devait être optimisé pour éviter des ralentissements lors de la première connexion de l'utilisateur : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=191

Dans cette dernière partie, nous allons comprendre et analyser les derniers points pour définitivement enlever les problèmes de lenteur si votre infrastructure UAG/ADFS n'a pas d'accès à Internet et surtout que vos serveurs DNS internes ne peuvent résoudre les noms de domaines publics.

Pour cela, nous allons effectuer une analyse réseau directement au niveau des serveurs UAG et ADFS afin de vérifier ce qu'il se passe pendant une authentification. J'ai volontairement vidé tous les caches, des iisreset, tout redémarrer, etc… pour avoir des temps d'authentifications le plus catastrophique possible et m'en servir de référence. Verdit, … wouhaaa j'ai battu un record 80s !

Et que nous donne les analyses réseaux côté ADFS …

Alors en fait sur le serveur ADFS, Il y a bien entendu les traces réseaux attendus pour la partie ADFS

Mais il y a énormément de flux DNS, et nombreux en échec :

Bien que nous ayons installés les CRL, il tente de s'y connecter (crl.microsoft.com) et par la même occasion faire une mise à jour depuis Microsoft Update (download.microsoft.com). Ces nombreuses tentatives sont tentées à de nombreuses reprises tout le long de la négociation. Cela devient un point intéressant. Nous allons rajouter ces entrées dans un fichier host, pour éviter déjà le timeout DNS.

Et du côté du serveur UAG ?

Même combat apparemment ;) Je vais donc filtrer sur le DNS pour voir ce qu'il tente de résoudre.

Alors tout comme le serveur ADFS, le serveur UAG tente de résoudre la liste de CRL Microsoft (crl.microsoft.com) mais également de nombreux autres noms de domaines. Mais à quoi cela correspond alors ? … mon petit doigt me dit qu'il faudrait que je regarde du côté du token SAML échangé entre le client qu'il a reçu du serveur ADFS.

Bingo ;) Alors on va le détailler complètement :

Dans le cadre de cet article, je vais utiliser uniquement la résolution locale de toutes ces adresses à l'aide d'un fichier host local ; Cela reste une bonne solution, mais il y a certainement d'autres solutions encore ;)

Le fichier host aurait donc ces entrées supplémentaires :
127.0.0.1    crl.microsoft.com

127.0.0.1    schemas.microsoft.com

127.0.0.1    schemas.xmlsoap.org

127.0.0.1    docs.oasis-open.org

127.0.0.1    download.microsoft.com

Alors et maintenant, cela donne quoi au niveau du client dans les mêmes conditions qu'expliquées plus haut (flushdns, iisreset, ..) ?

• Un gain de 62s soit 1mn ! Bon, il faut prendre en considération que je suis dans un environnement en VM avec des machines optimisées au max étant donné que j'ai pas beaucoup de RAM sur mon laptop.
• D'ailleurs tous les tests expliqués ici viennent d'être rédigés dans un TGV et je n'ai pas de clé 3g (j'aimerai tellement), donc là je suis vraiment dans les conditions de réseau tel expliqué. PAS d'INTERNET !!! D'ailleurs comment est-ce encore possible aujourd'hui ? C'est la raison pour laquelle, on se retrouve parfois confronté à ce genre de problème.

Et maintenant si mon environnement je le mets dans des conditions d'utilisations normales (sans les iisreset etc…), j'obtiens le score record d'une ½ seconde J

Donc pour synthétiser ce dossier divisé en 3 articles, voilà les actions à mener :

• Installer les CRL Microsoft localement sur les serveurs UAG et ADFS. Bien sûr, penser à les mettre à jour régulièrement voir mettre en place un script automatique.
• Configurer les pools d'application IIS afin d'être exécutés automatiquement et d'être toujours éveillés
• Permettre la résolution des noms de domaines de schémas des token ADFS, soit à l'aide de votre DNS ou encore un fichier host local

Dans ce genre donc d'infrastructure, nous avons démontré de nombreux contournements pour optimiser et améliorer UAG et ADFS ensemble dans un environnement isolé. Cela demande cependant des méthodes un peu orthodoxes (copie des CRL et intégration manuelle, fichiers hosts, …). Mon avis sur ce point serait plutôt une autre approche.

Je pense que l'idéal serait d'avoir une station ou un serveur dédié pour « simuler » Internet. Ce serveur pourrai régulièrement télécharger les CRL depuis Internet avec un script (via WinHTTP si Proxy) et les fichiers de schémas ADFS. Ce serveur devra donc avoir IIS et être représentatif d'une architecture similaire à ce qu'il y a sur Internet. Quant aux serveurs DNS locaux, ils devront résoudre les noms de domaines publics vers ce nouveau serveur.

Ce que j'essaye d'expliquer, c'est que si par exemple le serveur UAG tente de télécharger une CRL il résoudra l'url crl.microsoft.com avec l'adresse IP de ce serveur. Il va ensuite se connecter à http://crl.microsoft.com/fichier.crl et le télécharger pour l'installer localement. Peut-être un autre article à venir, mais il me faudra de la mémoire supplémentaire sur mon PC car je ne peux pas créer une VM de plus sur mon PC je suis à ras bord ;) Donc pour un peu plus tard.