Partager via


Team Foundation Server, authentification de base et authentification Digest

Mise à jour : novembre 2007

Visual Studio 2008 peut prendre en charge les modes d'authentification de base et Digest En configurant votre déploiement de Team Foundation Server pour qu'il utilise HTTPS avec SSL (Secure Sockets Layer) et l'authentification de base ou Digest, vous pouvez prendre en charge des connexions externes à votre serveur Team Foundation Server sans avoir à utiliser une connexion de réseau privé virtuel (VPN).

Configurations

Pour prendre en charge des connexions externes à vos déploiements de Team Foundation Server, vous devez configurer IIS (Internet Information Services) pour qu'il active l'authentification de base et/ou Digest. En outre, vous devez configurer un filtre ISAPI (Internet Server Application Programming Interface). Les filtres ISAPI sont des fichiers DLL qui peuvent être utilisés pour modifier et améliorer les fonctionnalités fournies par IIS. Les filtres ISAPI s'exécutent toujours sur un serveur qui exécute IIS. Vous devez configurer le filtre ISAPI qui fait partie de SP1 avec les adresses IP de proxies Web et/ou de n'importe quel client requis pour utiliser l'authentification de base ou Digest.

Authentification de base et Authentification Digest

L'authentification de base fait partie de la spécification HTTP 1.0. Elle utilise les comptes d'utilisateurs Windows. Au cours de l'authentification de base, le navigateur invite l'utilisateur à entrer un nom d'utilisateur et un mot de passe. Les informations relatives au nom d'utilisateur et au mot de passe sont transmises sur HTTP à l'aide du codage Base64. Par défaut, l'authentification de base requiert que le compte d'utilisateur Windows possède les droits d'ouverture de session locale au niveau du serveur Web. Vous pouvez utiliser l'authentification de base dans les déploiements de groupes de travail et de domaines. Bien que la plupart des serveurs Web, serveurs proxy et navigateurs Web prennent en charge l'authentification de base, cette dernière n'est pas sécurisée. Parce qu'il est facile de décoder des données codées Base64e, l'authentification de base envoie essentiellement le mot de passe sous forme de texte brut. En contrôlant les communications sur le réseau, une personne pourrait facilement intercepter et déchiffrer ces mots de passe à l'aide d'outils disponibles publiquement.

L'authentification Digest est un mécanisme de stimulation/réponse qui envoie un condensé (également appelé hachage) plutôt qu'un mot de passe sur le réseau. Au cours de l'authentification Digest, IIS envoie une stimulation au client pour créer un condensé, puis l'envoie au serveur. Le client envoie un condensé selon le mot de passe et les données de l'utilisateur que le client et le serveur identifient comme étant la réponse à la stimulation. Le serveur utilise le même processus que le client pour créer son propre condensé, les informations concernant l'utilisateur étant obtenues à partir d'Active Directory. Si le condensé créé par le serveur correspond à celui créé par le client, IIS authentifie le client. Vous pouvez utiliser uniquement l'authentification Digest dans les déploiements de domaines Active Directory. L'authentification Digest constitue en elle-même une petite amélioration par rapport à l'authentification de base. Un intrus pourrait enregistrer la communication entre le client et le serveur et utiliser ces informations pour relire la transaction. L'authentification Digest dépend également du protocole HTTP 1.1. Les navigateurs Web ne prennent pas tous en charge ce protocole. De plus, vous devez configurer l'authentification Digest de manière appropriée, sans quoi les tentatives d'accès à Team Foundation Server échoueront. Ne choisissez pas l'authentification Digest, sauf si vos déploiements satisfont à toutes les spécifications pour l'authentification Digest. Pour plus d'informations sur l'authentification Digest, consultez le site Web de Microsoft sur https://go.microsoft.com/fwlink/?LinkID=89709h (en anglais).

Limitations

Outre les conditions requises pour les domaines et groupes de travail mentionnées plus haut, les authentifications de base et Digest sont insuffisantes en elles-mêmes pour sécuriser le réseau par rapport aux clients externes. Par conséquent, vous ne devez pas configurer Team Foundation Server pour prendre en charge des clients externes à moins que vous ne configuriez également ces connexions pour exiger HTTPS avec SSL.

Configuration du filtre ISAPI

Vous pouvez configurer le filtre ISAPI pour qu'il applique les règles à tous les jeux d'adresses IP fournis. Même si la plupart des administrateurs accordent la priorité à la configuration des règles du filtre ISAPI pour les adresses IP externes, vous pouvez configurer des règles pour les adresses internes. Toutes les adresses IP configurées dans les règles du filtre ISAPI doivent respecter les règles spécifiées dans le filtre. En fonction du paramètre RequireSecurePort, les adresses non spécifiées dans le fichier peuvent ne pas être autorisées à se connecter à Team Foundation Server.

Le filtre ISAPI utilise un fichier AuthenticationFilter.ini pour ses paramètres de configuration. Vous devez configurer ce fichier avec les paramètres appropriés à votre déploiement. Le fichier peut utiliser les clés et valeurs de configuration suivantes :

Clé

Valeurs acceptées

RequireSecurePort

True

False

ProxyIPList

IPaddress (peut être constitué de plusieurs adresses, séparées par des points-virgules)

SubnetList

IPaddress/subnetmask (peut être constitué de plusieurs adresses, séparées par des points-virgules)

[config]

En-tête de section pour le fichier de filtre ISAPI

Les clés sont définies plus loin comme suit :

  • RequireSecurePort   Si vous affectez la valeur True à RequireSecurePort, toutes les connexions doivent utiliser HTTPS/SSL et l'authentification Digest ou de base, sauf si l'une des adresses est spécifiée dans SubnetList. Si vous affectez la valeur False à RequireSecurePort, seules les connexions utilisant les adresses spécifiées dans ProxyIPList devront utiliser HTTPS/SSL et l'authentification Digest ou de base.

  • ProxyIPList   Adresses IP pour lesquelles vous souhaitez appliquer l'authentification Digest ou de base. La méthode la plus facile pour conceptualiser cette clé est de la considérer comme « Exiger seulement l'authentification de base ou Digest pour ces adresses ». Les adresses spécifiées pour cette clé seront requises pour utiliser l'authentification Digest ou de base et HTTPS/SSL. Cette clé a la priorité sur SubnetList ; si la clé ProxyIPList est présente, la clé SubnetList et ses valeurs seront ignorées.

  • SubnetList   SubnetList répertorie les paires adresses IP/masques de sous-réseau pour lesquelles vous ne souhaitez pas appliquer l'authentification Digest ou de base. La méthode la plus facile pour conceptualiser cette clé est de la considérer comme « Exiger que toutes les adresses utilisent l'authentification de base ou Digest, sauf ces adresses ». Les adresses spécifiées pour cette clé ne seront pas requises pour utiliser l'authentification Digest ou de base et HTTPS/SSL. Les adresses non spécifiées pour cette clé seront requises pour utiliser l'authentification Digest ou de base. Si la clé ProxyIPList est présente dans le filtre ISAPI, la clé SubnetList et ses valeurs seront ignorées.

Voir aussi

Tâches

Procédure pas à pas : configuration de Team Foundation Server avec SSL (Secure Sockets Layer) et un filtre ISAPI

Procédure pas à pas : configuration de Team Foundation Server pour l'utilisation de HTTPS et SSL (Secure Sockets Layer)

Concepts

Team Foundation Server, HTTPS et Secure Sockets Layer (SSL)