Sur un serveur SharePoint, l’absence d’accès à internet peut avoir un lourd impact sur les performances.  En effet pour diverses raisons, ASP.NET et SharePoint vérifient la validité de certaines informations et certificats sur les serveurs de Microsoft. Cela se traduit par des tentatives de connexion à crl.microsoft.com (modes classic et claims) et www.download.windowsupdate.com (claims uniquement) pendant l’exécution de l’application.

Après avoir mis en évidence la problématique, nous allons voir comment désactiver les mécanismes qui provoquent des connexions vers internet. Nous retrouveront alors des performances optimales.

Mise en évidence du problème

Les tests qui vont suivre ont été réalisés sur une machine virtuelle de développement Windows 2008 R2 embarquant à la fois un Active Directory, un serveur SQL, et un SharePoint Server 2010. Un IISRESET est effectué avant chaque mesure, une mesure correspondant au temps d’affichage de la page d’accueil d’un site d’équipe.  Pour bien mettre en évidence les problématiques liées au mode claims, chaque test est effectué dans les 2 modes. Les mesures des temps de réponses ont été prises avec HttpWatch Professional.

Afin d’établir un référentiel, je commence par prendre des mesures en conservant un accès internet sur le serveur :

Web App en mode classic avec accès internet : 10.6 secondes

Web App en mode claims avec accès internet : 15.2 secondes

Après avoir coupé l’accès internet, je ré effectue le même test :

Web App en mode classic sans accès internet : 42.3 secondes

Web App en mode claims sans accès internet : 57.8 secondes

Le temps de chargement est donc multiplié environ par  4. Edifiant n’est-ce pas ?

Ces latences sont dues au fait que le serveur tente de se connecter à divers services sur internet. En l’absence d’accès à internet, ces tentatives de connexions génèrent des timeout qui ralentissent l’exécution des applications.

Dans un scénario de développement, la baisse de productivité est significative puisque le développeur attend inutilement 30 à 45 secondes à chaque fois qu’il appuie sur F5 pour déployer de son projet.

Dans un scénario de production, on ne recycle pas les application pool aussi fréquemment, le problème parait donc moins gênant. Toutefois en cas d’authentification par formulaire (mode claims), une demande d’authentification peut prendre plusieurs secondes. Sur un portail extranet que j’ai étudié récemment, un utilisateur attendait systématiquement 15 secondes après avoir validé la saisie de son login et de son mot de passe, sans raison apparente, avant d’être authentifié par le serveur.

Nous allons voir que les connexions initiées par un serveur SharePoint ont 2 origines : la vérification des signatures des assemblii (en modes classic et claims), et la récupération d’une mise à jour des certificats racines (en mode claims uniquement).

Vérification des signatures des assemblii (modes classic et claims)

La vérification des signatures d’assemblii concerne Code Access Security (CAS) et est propre aux applications ASP.NET. Il s’agit d’un comportement bien connu qui existe aussi sur les environnements SharePoint 2007. Lors du chargement d’assemblii signées (celles du Framework.NET par exemple), des requêtes vers crl.microsoft.com sont faites par IIS pour en vérifier les signatures.

En cas d’absence d’accès internet, il est légitime de désactiver cette vérification en effectuant une modification dans le fichier machine.config situé dans le répertoire C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG. Une fois le fichier ouvert, localiser le noeud <runtime /> et le modifier comme ceci :

<runtime>

   <generatePublisherEvidence enabled="false" />

</runtime>

Après enregistrement, reprenons les mesures :

Web app en mode classic : 9.4 sec

Web app en mode claims : 25.4 sec

On remarque qu’en mode classic, on a d’encore meilleures performances qu’avec un accès internet. C’est logique puisque le mécanisme de vérification des signatures d’assemblii est entièrement désactivé. On économise un peu de temps CPU et surtout des connexions réseau.

Mais en mode claims, il y a toujours une latence qui semble injustifiée.

Mise à jour des certificats racines (mode claims)

Le Developer Dashboard permet d’identifier l’origine du problème. Pour la mesure prise précédemment (25.4s), il affiche ceci :

On constate que les 11.5 secondes "injustifiées" sont consommées au niveau de la méthode SPCertificateValidator.Validate(). Le rôle de cette méthode est de vérifier la validité du certificat utilisé pour chiffrer les communications avec le Security Token Service (STS). 

On trouve le certificat du STS dans le magasin "Local Computer\SharePoint".

On remarque que ce certificat est généré par une autorité de certification "SharePoint Root Authority". Malheureusement, cette autorité de certification ne fait pas partie des certificats racines trustés nativement par Windows (les Trusted Root Certificates). SharePoint étant une application, il serait injustifié qu’il en fasse partie.

Puisqu’il ne fait pas partie des Trusted Root Certificates, Windows cherche à récupérer une liste à jour des certificats racines afin de vérifier la validité du certificat avec des informations à jour. 
Analysé avec Network Monitor, une tentative de connexion vers http://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab est effectuée pour essayer de récupérer cette mise à jour.

En l’absence d’accès à internet sur le serveur, c’est ici qu’apparait le timeout.

Il est toutefois possible de désactiver cette mise à jour automatique, en suivant cette procédure :

• Sur le serveur, executer gpedit.msc
• Aller à Computer Configuration –> Windows Settings –> Security Settings –> Public Key Policies
• Afficher les propriétés de "Certificate Path Validation Settings"
• Dans l’onglet "Network Retrieval", cocher "Define this policy" et décocher "Automatically update certificates in the Microsoft Root Certificate Program"
• Valider, puis exécuter "gpupdate /force" en ligne de commande pour appliquer les modifications

Après avoir effectué cette modification, on retrouve des mesures optimales, meilleures que celle prises initialement avec un accès internet.

Web app en mode claims : 13.9 sec

On notera aussi que le Developer Dashboard ne signale plus de latence au niveau de la méthode de vérification du certificat :

A ce stade, le serveur n’effectue plus de connexion vers internet en rapport avec l’exécution de SharePoint.

Arnault Nouvel
www.winwise.com