Ce post fait suite au précédent concernant la publication de SharePoint avec TMG : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=117

Il se peut que certains dysfonctionnements surviennent lors d'un accès distant à SharePoint à travers le Reverse Proxy, nous allons donc traiter les incidents les plus connus.

WebForm_PostBackOptions is undefined

Ce problème se produit par exemple lorsque l'on souhaite créer un dossier dans une bibliothèque SharePoint

La règle crée par l'assistant ne permet pas de publier WebResource.axd*. Il faut donc ajouter dans la règle le chemin /WebResource.axd*

Ce qui nous donne à présent :

Vous ne pouvez pas uploader un document sur une bibliothèque qui contient un caractère spécial, sous peine de recevoir un message d'erreur

Si une bibliothèque contient un dossier qui a dans son nom un accent (é par exemple) vous ne pourrez y déposer des documents à travers ISA ou TMG. Il vous sera affiché une erreur d'accès refusé en 401 avec un code d'erreur 12209 sur ISA et TMG quant à lui fera une erreur interne 500 avec un code d'erreur 12202. Cette problématique est connue, surtout pour les pays latins utilisant les accents. En fait ISA/TMG bloque les http POST avec un accent pour un défaut d'encodage (Unicode versus HighBit). Ceci se produit lorsque vous utilisez une authentification à l'aide des formulaires.

Pour contourner ce problème, vous pouvez désactiver l'authentification par formulaire et utiliser l'authentification http. Cependant, cette modification apporte de nombreux impacts. Tout d'abord d'un point de vue esthétique, vous avez peut-être déjà personnalisé le formulaire d'authentification et puis c'est tellement plus joli même nativement qu'une simple popup d'authentification. Mais surtout, c'est moins sécurisé ; Il est en effet plus facile à une personne malveillante de tenter d'exploiter une popup par bruteforce qu'un formulaire html.

Ensuite, bien entendu on peut renommer les dossiers contenant les accents. Mais là encore un impact du moins les plus importants devient une contrainte. Si vous avez déjà échangé des liens avec des partenaires ou collaborateurs, alors cela veut dire que vos anciens liens communiqués sont obsolètes. Il va falloir communiquer vers toutes les personnes susceptibles d'avoir conservé dans leurs favoris ces liens.

La dernière solution consiste à modifier le comportement de TMG (ou ISA) afin qu'il puisse mieux interpréter et « parser » ce type d'encodage. Une procédure est fournie par Microsoft sur le site de support et prévoit même un RollBack : http://support.microsoft.com/kb/940248/en-us L'action consiste à écrire un script vbs pour activer ou désactiver l'encodage. Pour utiliser correctement cette manipulation, il faut que le serveur ISA 2006 possède ce patch : http://support.microsoft.com/kb/940250 ; ISA 2006 SP1 et TMG n'ont pas besoin de ce patch pour appliquer cette modification.

Créez donc le script vbs en vous aidant de l'article KB940248 et depuis une ligne de commande exécutez-le

Si vous souhaitez le désactiver, créez le second script fourni dans l'article et exécutez le de la même manière (à l'heure où j'écris ce billet, le script pour désactiver fourni dans la KB a une erreur de syntaxe. Il sera corrigé très rapidement. Copier-Coller donc le premier script, et changer la troisième ligne de True vers False

Authentifications répétitives avec le client Office (Word, Excel, …)

Les collaborateurs vont être vite confrontés à un problème gênant lors de l'utilisation de documents Office depuis une bibliothèque SharePoint.

Ce comportement est normal lorsque l'on utilise une authentification basique (souvent utilisée dans le cadre de Reverse Proxy). Le navigateur a établi une connexion authentifiée et la navigation tout au long du site est approuvée, c'est la raison pour laquelle il n'y a pas de nouvelles demandes d'authentification lorsque l'on clique sur des liens. Cependant, lors de la tentative d'ouverture d'un document Office, on obtient une demande d'authentification. Ceci est expliqué du fait que le programme office doit établir une authentification à son tour car ce dernier n'est pas encore approuvé. Si nous étions dans le réseau interne avec un poste membre du domaine qui a correctement ouvert une session sur Active Directory ne risque pas de rencontrer ce problème. En effet, par défaut SharePoint est configuré en NTLM pour une authentification intégrée. Cela veut dire que lorsqu'en interne un utilisateur tente d'ouvrir un document Office, le programme établira automatiquement une session sécurisée et authentifiée avec les Services Web de SharePoint. Ceci ne peut être fait depuis l'extérieur, car bien souvent l'authentification a été effectuée à travers un formulaire Web et seul le navigateur obtient donc le canal sécurisé. Donc comment contourner le problème ?

La première solution, n'est pas en elle une solution mais reste simple. Il faut ajouter l'url de l'extranet dans les sites de confiance

Il faut également s'assurer que le niveau de paramètre de site de confiance contienne l'envoi automatique des informations de connexion

L'utilisateur devra cocher la case qui permet d'enregistrer automatiquement son mot de passe.

Il se verra proposée ensuite de valider uniquement l'authentification et n'aura pas à ressaisir ses identifiants/passwords. Donc ce n'est pas vraiment encore une solution...

Alors que faire pour éviter cette authentification multiple et désagréable … Utiliser des cookies persistants ! Avec ISA/TMG on peut configurer un Web Listener afin d'utiliser des cookies persistants en fonction de la zone recherchée. Pour une raison de sécurité, il est important de n'activer cette option que pour les ordinateurs privés. Dans la console ISA/TMG modifier les paramètres du Web Listener ainsi :

L'utilisateur devra utiliser l'option d'ordinateur privée pour bénéficier de cette option

Le cookie pourra donc être utilisé par le service Web Client afin d'être automatiquement connecté à la bibliothèque SharePoint depuis une application tierce.