Ralentissement lors de l’utilisation des revendications SAML avec SharePoint 2010

Article d’origine publié le jeudi 14 juillet 2011

Bonjour, notre ami Adam C. du support technique SharePoint nous a récemment alerté au sujet d’une plainte émanant fréquemment de clients utilisant les revendications SAML. Cela devient extrêmement long de se connecter à un site utilisant l’authentification SAML. Si vous surveillez les requêtes via un outil comme Fiddler, vous observez que la majeure partie du temps est utilisée sur le serveur SharePoint, très probablement dans le sous-répertoire /_trust. Si vous êtes dans ce cas de figure et diagnostiquez que votre requête passe la majeure partie de son temps sur le serveur SharePoint, votre batterie de serveurs n’a peut-être pas l’accès à Internet. Vous devez pouvoir vérifier cela si vous activez la connexion CAPI2 sur les serveurs SharePoint. Adam vous explique comment procéder :

CAPI2 est la nouvelle API de chiffrement disponible dans Vista/2008. Les diagnostics CAPI2 améliorent énormément les diagnostics PKI disponibles dans 2000/XP/2003. Les informations des diagnostics CAPI2 sont consignées dans le journal de fonctionnement de CAPI2, qui est situé dans Applications and Services Logs\Microsoft\Windows\CAPI2\Operational, dans l’observateur d’événements. Vous pouvez utiliser la journalisation CAPI2 pour dépanner la plupart des opérations PKI dans Vista/2008.

La journalisation CAPI2 est désactivée par défaut. Pour l’activer, cliquez avec le bouton droit sur le journal CAPI2 Operational dans l’observateur d’événements et sélectionnez Activer l’enregistrement dans le journal. Vous pouvez également l’activer en utilisant Wevtutil :

wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true

Pour la désactiver avec Wevtutil, la syntaxe est :

wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false

Pour plus d’informations, voir Résolution des problèmes PKI dans Windows Vista.

Une fois la journalisation CAPI2 activée, vous allez vous authentifier à nouveau auprès de SharePoint, puis regarder dans l’observateur d’événements. Si vous constatez des codes d’événement 11 (BuildChain) et 53 (Retrieve Object from Network), observez l’événement 53 de plus près pour voir s’il essaie de faire une requête à https://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab. Si vous constatez cela et que votre batterie n’a pas accès à Internet, vous allez endurer des délais interminables lors de ces tentatives d’accès. Pour l’instant, vous pouvez contourner ce problème de deux manières :

1. Exportez le certificat d’autorité racine SharePoint à partir de SharePoint et importez-le dans le magasin Autorités de certification racine de confiance. Accédez à la console MMC Certificats et exportez le certificat d’autorité racine SharePoint, puis importez-le dans les autorités racine approuvées. Vous les trouverez tous les deux dans le magasin de certificats de l’ordinateur, et vous trouverez le certificat d’autorité racine SharePoint dans le nœud SharePoint dans la console MMC.
2. Désactivez la récupération des certificats racines tiers à partir du réseau via Stratégie de groupe. Pour cela, vous pouvez accéder à votre Objet de stratégie de groupe et descendre dans Configuration ordinateur, Paramètres Windows, Paramètres de sécurité, Stratégies de clé publique. Recherchez une stratégie appelée Paramètres de validation du chemin d’accès du certificat, ouvrez-la et cliquez sur l’onglet Récupération du réseau. Activez la case à cocher Définir ces paramètres de stratégie, et désactivez la case à cocher Mettre automatiquement à jour les certificats dans le programme de certificat racine Microsoft (recommandé).

Une fois ces changements effectués, les temps de connexion devraient considérablement s’améliorer. Merci encore à Adam de partager ces informations.

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale ici : You May Experience Slowness When Using SAML Claims with SharePoint 2010