Sécurité sous Windows NT

 ^{2 sur 9}     Méthodes d'authentification IIS

Tous les utilisateurs doivent être authentifiés avant de pouvoir accéder aux ressources d'IIS. IIS prend en charge l'authentification anonyme, l'authentification de base, l'authentification Stimulation/Réponse de Windows NT et l'authentification DAA (Digest Access Authentication).

Authentification anonyme

L'authentification anonyme accorde l'accès aux utilisateurs qui n'ont pas de compte propre sur l'ordinateur hôte, par l'intermédiaire d'un compte « anonyme » spécial. Chaque service Internet, comme le World Wide Web ou FTP, utilise un compte Windows NT (un nom d'utilisateur et un mot de passe) pour traiter les requêtes anonymes. Internet Information Services crée le compte anonyme IUSR_nommachine pour les services Web pendant sa configuration. Par défaut, toutes les requêtes clientes Web utilisent ce compte, qui permet aussi aux clients d'accéder au contenu du site Web. Vous pouvez activer simultanément l'ouverture de session anonyme et l'accès par authentification.

Quand IIS reçoit une requête anonyme, il emprunte l'identité du compte d'ouverture de session anonyme. La requête aboutit si le compte anonyme est autorisé à accéder à la ressource demandée (les autorisations du compte sont déterminées par l'ACL de la ressource). Si le compte anonyme ne possède pas l'autorisation appropriée, la requête n'aboutit pas. Le service WWW demande alors à l'utilisateur de fournir un nom d'utilisateur et un mot de passe Windows NT valides.

Authentification de base

L'authentification de base est prise en charge par la plupart des serveurs Web d'Internet. Quand un serveur utilise cette méthode, le navigateur Web (ou le client FrontPage) demande à l'utilisateur un nom d'utilisateur et un mot de passe, informations qui sont transmises en clair via HTTP et permettent à IIS d'authentifier l'utilisateur Windows NT correspondant.

Avec l'authentification de base, l'utilisateur est toujours connecté avec des droits de connexion en local, ce qui est similaire à une ouverture de session interactive sur la console de l'ordinateur. (Pour utiliser l'authentification de base, accordez à chaque compte d'utilisateur le droit d'accès Se connecter en local sur le serveur IIS.) L'utilisation de la connexion en local par l'authentification de base peut être à l'origine de deux problèmes dont les administrateurs doivent être conscients :

• L'authentification de base n'aboutira pas si le compte d'utilisateur ne dispose pas de droits de connexion en local. Même si la configuration de FrontPage, d'IIS et de Windows NT semble correcte, l'utilisateur ne pourra pas être authentifié si les droits de connexion en local ne lui ont pas été accordés dans le gestionnaire d'utilisateurs de Windows NT.
• Avec la connexion en local, si un utilisateur est autorisé à accéder physiquement à l'ordinateur hôte qui exécute IIS, il pourra lancer une session interactive sur la console.

L'authentification de base présente également un risque de sécurité car les noms d'utilisateur et les mots de passe sont transmis sur le réseau dans un format facile à décoder.

Si votre site Web doit prendre en charge les opérations d'auteur par le client FrontPage version 1.1 (qui ne gère pas l'authentification Stimulation/Réponse de Windows NT) ou si vous voulez être sûr que votre site Web est accessible à partir de tous les types de navigateurs, vous devez laisser l'authentification de base activée. De plus, cette authentification fonctionne à travers un pare-feu via un serveur proxy. Si les utilisateurs se connectent à votre serveur Web sur Internet via un serveur proxy, vous devez utiliser l'authentification de base au lieu de l'authentification Stimulation/Réponse de Windows NT.

L'authentification de base est plus rapide que la Stimulation/Réponse de Windows NT. Combinée au protocole Secure Sockets Layer (SSL), elle garantit une authentification sûre et rapide.

Authentification Stimulation/Réponse de Windows NT

L'authentification Stimulation/Réponse de Windows NT (également appelée NTLM) est plus sûre que l'authentification de base. Quand un utilisateur est authentifié avec la Stimulation/Réponse de Windows NT, il est connecté au serveur Web en tant qu'ouverture de session réseau. Le navigateur Web ou le client FrontPage essaie d'abord d'utiliser les informations d'identification fournies par l'utilisateur pour se connecter à l'ordinateur client. Si ces informations sont rejetées, la Stimulation/Réponse de Windows NT affichera une boîte de dialogue invitant l'utilisateur à indiquer un nom et un mot de passe. Si un utilisateur s'est connecté sur un ordinateur local en tant qu'utilisateur de domaine, il sera inutile de l'authentifier à nouveau lorsqu'il accédera à un ordinateur distant de ce domaine.

Le nom d'utilisateur et le mot de passe sont codés efficacement par un processus d'interaction impliquant plusieurs transactions entre le client et le serveur Web. Cette interaction vous met à l'abri des espions réseau qui essaient de s'introduire sur des systèmes en surveillant le trafic réseau entre un client et un serveur.

L'authentification Stimulation/Réponse de Windows NT a néanmoins ses limites :

• Elle ne peut pas franchir un pare-feu via un serveur proxy. Dans ce type de situation, vous devez utiliser l'authentification de base.
• Certains navigateurs Web (comme, Netscape Navigator) ne la prennent pas en charge Windows NT.
• Elle ne prend pas en charge la délégation à des serveurs secondaires. Les informations d'identification de l'utilisateur ne peuvent pas être transmises à un autre ordinateur. Par exemple, quand une requête parvient à IIS, les informations d'identification du compte d'utilisateur ne peuvent pas être transmises à Microsoft SQL Server sur un ordinateur secondaire.

L'authentification Stimulation/Réponse de Windows NT ne pouvant pas franchir un pare-feu, elle est surtout utile sur les intranets, où la communication intervient derrière le pare-feu d'une organisation.

Vous pouvez activer l'authentification de base et l'authentification Stimulation/Réponse de Windows NT en même temps. Si le navigateur Web prend en charge la Stimulation/Réponse, il utilise cette méthode. Sinon, il utilise l'authentification de base. À l'heure actuelle, la Stimulation/Réponse n'est prise en charge que par Microsoft Internet Explorer version 2.0 ou ultérieure. .

Authentification DAA (Digest Access Authentication)

Comme l'authentification de base, l'authentification DAA (Digest Access Authentication) est basée sur une méthode de stimulation-réponse simple. Son modèle utilise une valeur unique (une chaîne de données unique générée chaque fois qu'une erreur 401 survient). Une réponse valide contient un total de contrôle composé du nom d'utilisateur, du mot de passe, de la valeur unique, de la méthode HTTP et de l'URL demandée. De cette façon, le mot de passe n'est jamais transmis sous forme de texte facile à décoder, ce qui constitue la plus grande faiblesse de l'authentification de base.

L'authentification DAA suppose qu'Internet Explorer  5.0 soit installé sur l'ordinateur client.