SharePoint, les Service Packs, le Loopback Check, l'accès local et l'erreur 401.1

A plusieurs reprises, il m'a été donné d'aider des administrateurs ou développeurs SharePoint aux prises avec ce comportement pour le moins déconcertant: alors que les utilisateurs peuvent se connecter et s'authentifier au serveur SharePoint sans le moindre problème, les administrateurs ayant ouvert une session localement sur le serveur se voient refusés l'accès à SharePoint tout en recevant l'erreur HTTP 401.1 (Unauthorized: Access is denied).

Ce comportement est, comme souvent avec Microsoft "By Design" depuis le service pack 1 de Windows Server 2003: il a pour but d'augmenter le niveau de sécurité sur un serveur lorsque les conditions suivantes sont d'application:

• La version de l'OS est au moins Windows Server 2003 SP1
• Un utilisateur ou administrateur est loggé localement sur la console du serveur ou via RDP
• Il (ou elle, ne soyons pas macho, le système ne l’étant pas), tente d’accéder à une ressource ou un service utilisant l’authentification NTLM en passant un nom d’hôte pointant vers l’adresse de loopback (127.0.0.1) alors que ce nom d’hôte n’est pas “localhost”

Le résultat étant un “Access Denied” ou en langage HTTP, un 401.1. il est à noter que ce problème pourrait tout aussi bien se produire en accédant à un répertoire partagé, par ex.

Bien mais pourquoi est-ce alors si flagrant dans le cas  de SharePoint? Il existe deux grands cas de figure dans lesquels il est fréquent de recourir à la modification du fichier HOSTS afin de faire pointer une ou plusieurs application web vers l’adresse 127.0.0.1:

• L'indexeur paramétré pour se viser lui-même, et non un autre serveur frontal. Cela se faisant soit manuellement par l’édition du fichier HOSTS, soit en laissant SharePoint s’en charger
• Les machines de développement, afin d’éviter de devoir enregistrer des noms dans le serveur DNS

Il n’est pas rare que des scripts de “warm-up” de SharePoint provoque également le problème.

Plusieurs solutions existent:

• Désactiver complètement cette fonctionnalité, voir l’article de KB suivant: Message d'erreur en utilisant le nom de domaine complet ou l'alias CNAME d'un serveur pour y accéder localement après l'installation de Windows Server 2003 Service Pack 1 : « Accès refusé » ou « Aucun logiciel réseau n'a accepté le chemin réseau fourni »
• Déclarer les noms par lesquels le service sera accédé, voir le même article de KB ci-dessus
• Utiliser Kerberos plutôt que NTLM. Kerberos inclut son propre système de vérification des noms par lequel le service est accédé (Service Principal Name)

Marc