Vous pouvez demander aux utilisateurs de fournir un nom d'utilisateur et un mot de passe de compte Windows valides pour accéder aux informations qui se trouvent sur votre serveur. Ce processus d'identification est appelé authentification. Comme la plupart des fonctionnalités de IIS, l'authentification peut être définie au niveau du site Web, du répertoire ou du fichier. IIS fournit les méthodes d'authentification suivantes pour contrôler l'accès au contenu de votre serveur :
Pour plus d'informations sur la configuration de l'authentification, consultez Activation et configuration de l'authentification.
| Méthode | Niveau de sécurité | Configuration serveur | Configuration client | Commentaires |
| Anonyme | Aucun | compte IUSR_nom_ordinateur | N'importe quel navigateur | Utilisée pour les zones publiques des sites Internet. |
| De base | Basse | Comptes valides | Entrer un nom d'utilisateur et un mot de passe | Transmet le mot de passe sans le crypter. |
| Digest | Élevé | Copie en texte brut de chaque mot de passe. Comptes valides. | Compatibilité | Utilisable via les serveurs proxy et autres pare-feu (firewalls). |
| Intégrée de Windows | Élevé | Comptes valides | Prise en charge du navigateur | Utilisée pour les zones privées des intranets. |
| Certificats | Élevé | Obtenir des certificats serveurs. Configurer des listes de certificats de confiance (CTL) (pour la première utilisation uniquement). | Prise en charge du navigateur | Couramment utilisée pour des transactions sécurisées sur Internet. |
| FTP anonyme | Aucun | compte IUSR_nom_ordinateur | Aucun | Utilisée pour les zones publiques des sites FTP. |
| FTP de base | Basse | Comptes valides | Entrer un nom d'utilisateur et un mot de passe | Transmet le mot de passe sans le crypter. |
L'authentification anonyme permet aux utilisateurs d'accéder aux zones publiques de votre site Web ou FTP sans fournir de nom d'utilisateur ni de mot de passe. Lorsqu'un utilisateur tente de se connecter à votre site Web ou FTP public, votre serveur Web lui attribue le compte d'utilisateur Windows IUSR_nom_ordinateur, nom_ordinateur étant le nom du serveur sur lequel IIS s'exécute.
Par défaut, le compte IUSR_nom_ordinateur est inclus dans le groupe d'utilisateurs Windows Invités. Ce groupe est soumis à des restrictions de sécurité imposées par les autorisations NTFS, qui définissent le niveau d'accès et le type de contenu disponibles pour les utilisateurs publics.
Si votre serveur héberge plusieurs sites, ou si certaines zones de votre site nécessitent des privilèges d'accès différents, vous pouvez créer un compte anonyme pour chaque site Web ou FTP, chaque répertoire ou chaque fichier. En définissant des autorisations d'accès différentes pour ces comptes, ou en les attribuant à différents groupes d'utilisateurs Windows, vous pouvez accorder aux utilisateurs anonymes l'accès à différentes zones de votre contenu Web ou FTP public.
IIS utilise le compte IUSR_nom_ordinateur de la manière suivante :
Remarque
Vous pouvez modifier le compte utilisé pour l'authentification anonyme à l'aide du composant logiciel enfichable Services Internet (IIS), soit au niveau service du serveur Web, soit pour des répertoires virtuels et fichiers particuliers. Le compte anonyme doit disposer du droit d'utilisateur d'ouvrir une session localement. Si le compte ne dispose pas de l'autorisation Ouvrir une session localement, IIS ne pourra pas traiter de demandes anonymes. IIS accorde explicitement l'autorisation Ouvrir une session localement au compte IUSR_nom_ordinateur. Les comptes IUSR_nom_ordinateur sur les contrôleurs de domaine ne sont pas accordés par défaut aux comptes invités et vous devez leur octroyer l'autorisation Ouvrir une session localement pour permettre les connexions anonymes.
Remarque Vous pouvez modifier les conditions des droits Ouvrir une session localement à l'aide de ADSI (Active Directory Service Interfaces). Pour plus d'informations, consultez la référence LogonMethod dans le Guide Active Server Page.
Vous pouvez également modifier les privilèges de sécurité du compte IUSR_nom_ordinateur dans Windows, à l'aide du composant logiciel enfichable Gestionnaire de stratégie de groupe de la MMC. Toutefois, si le compte d'utilisateur anonyme n'est pas autorisé à accéder à un fichier ou à une ressource spécifique, votre serveur Web refusera d'établir une connexion anonyme vers cette ressource. Pour plus d'informations, consultez Définition des autorisations du serveur Web.
Important Si vous modifiez le compte IUSR_nom_ordinateur, les modifications apportées affectent toutes les demandes HTTP anonymes traitées par un serveur Web. Soyez prudent si vous modifiez ce compte.
L'authentification de base est une méthode standard très utilisée pour la collecte des informations relatives au nom d'utilisateur et au mot de passe. L'authentification de base se déroule de la manière suivante :
Pour plus d'informations sur la configuration de l'authentification de base, consultez Activation et configuration de l'authentification.
L'authentification de base présente l'avantage de faire partie de la spécification HTTP et d'être prise en charge par la plupart des navigateurs. Mais elle présente également un inconvénient : les navigateurs Web qui utilisent l'authentification de base transmettent les mots de passe sans les crypter. En surveillant les communications sur votre réseau, quelqu'un pourrait facilement intercepter et déchiffrer ces mots de passe à l'aide d'outils accessibles au grand public. Par conséquent, l'authentification de base n'est pas conseillée, sauf si vous êtes certain que la connexion entre l'utilisateur et votre serveur Web est sécurisée, par exemple s'il s'agit d'une connexion directe par câble ou d'une ligne dédiée. Pour plus d'informations, consultez Cryptage.
Remarque L'authentification intégrée de Windows est prioritaire par rapport à l'authentification de base. Le navigateur choisit l'authentification intégrée de Windows et essaie d'utiliser les informations d'ouverture de session Windows en cours avant de demander à l'utilisateur un nom d'utilisateur et un mot de passe. À ce jour, Internet Explorer version 2.0 ou ultérieure est le seul navigateur à prendre en charge l'authentification intégrée de Windows.
L'authentification Digest est une nouvelle fonctionnalité de IIS 5.0 qui offre les mêmes fonctionnalités que l'authentification de base mais utilise un autre mode de transmission des informations d'authentification. Les informations d'authentification sont traitées par un processus unidirectionnel souvent appelé hachage. Le résultat de ce processus, appelé hash ou message condensé, est impossible à décrypter. Cela signifie qu'il n'est pas possible de retrouver le texte d'origine à partir de la valeur de hachage.
L'authentification Digest se déroule de la manière suivante :
Des informations supplémentaires sont ajoutées au mot de passe avant le hachage afin que personne ne puisse intercepter le hachage du mot de passe et l'utiliser pour emprunter l'identité du véritable client. Des valeurs sont ajoutées pour faciliter l'identification du client, de l'ordinateur du client et du domaine auquel le client appartient. En outre, un système de datage empêche le client d'utiliser un mot de passe qui a été révoqué.
Cela constitue un avantage certain par rapport à l'authentification de base, avec laquelle une personne non autorisée peut intercepter et utiliser le mot de passe. L'authentification Digest fonctionne via les serveurs proxy et autres applications pare-feu (firewall) et est disponible en mode WebDAV (Web Distributed Authoring and Versioning). Étant donné que l'authentification Digest est une nouvelle fonctionnalité HTTP 1.1, elle n'est pas prise en charge par tous les navigateurs. Si un navigateur ne prenant pas en charge cette fonctionnalité adresse une demande à un serveur nécessitant l'authentification Digest, ce serveur rejette la demande et envoie un message d'erreur au client. L'authentification Digest est prise en charge uniquement pour les domaines comportant un contrôleur de domaine Windows 2000.
Important Le processus d'authentification Digest ne peut réussir que si le serveur de domaine qui a reçu la demande dispose d'une copie en texte brut du mot de passe de l'utilisateur à l'origine de la demande. Étant donné que le contrôleur de domaine dispose d'une copie en texte brut des mots de passe, il doit être protégé des attaques physiques et réseau. Pour plus d'informations sur la sécurisation d'un contrôleur de domaine, consultez le Kit de Ressources Techniques Microsoft Windows 2000 Server.
Remarque Une valeur de hachage comprend très peu de données binaires, en général pas plus de 160 bits. Cette valeur est obtenue à l'aide d'un algorithme de hachage. Toutes les valeurs de hachage partagent les propriétés suivantes, quel que soit l'algorithme utilisé :
L'authentification intégrée de Windows (anciennement appelée authentification stimulation/réponse de Windows NT ou NTLM) est une méthode d'authentification sécurisée car le nom d'utilisateur et le mot de passe ne sont pas transmis via le réseau. Lorsque vous activez l'authentification intégrée de Windows, le navigateur de l'utilisateur prouve sa connaissance du mot de passe par un échange cryptographique avec votre serveur Web. Cette méthode utilise le hachage.
La méthode d'authentification intégrée de Windows peut utiliser le protocole d'authentification Kerberos v5 ou bien son propre protocole d'authentification stimulation/réponse. Si le composant Services d'annuaire sont installés sur le serveur et que le navigateur est compatible avec le protocole d'authentification Kerberos v5, ce protocole et le protocole stimulation/réponse sont utilisés conjointement. Sinon, seul le protocole stimulation/réponse est utilisé.
Le protocole d'authentification Kerberos v5 est une fonctionnalité de l'architecture des services distribués Windows 2000. Pour que l'authentification Kerberos v5 fonctionne, le client et le serveur doivent disposer d'une connexion fiable à un Centre de distribution de clés (KDC, Key Distribution Center) et leurs services d'annuaire doivent être compatibles. Pour plus d'informations sur ce protocole, consultez la documentation de Windows.
L'authentification intégrée de Windows se déroule de la manière suivante :
Remarque Internet Explorer version 4.0 ou ultérieure peut être configuré pour demander d'emblée ces informations à l'utilisateur si nécessaire. Pour plus d'informations, consultez la documentation de Internet Explorer.
Bien que l'authentification intégrée de Windows soit sécurisée, elle présente deux inconvénients.
Par conséquent, l'authentification intégrée de Windows est très utile dans un environnement intranet où les ordinateurs de l'utilisateur et du serveur Web se trouvent dans le même domaine et où les administrateurs peuvent veiller à ce que chaque utilisateur dispose de Microsoft Internet Explorer version 2.0.
Vous pouvez également utiliser les fonctionnalités de sécurité SSL (Secure Sockets Layer) de votre serveur Web pour deux types d'authentifications. Vous pouvez utiliser un certificat serveur pour permettre aux utilisateurs d'authentifier votre site Web avant de transmettre des informations personnelles, par exemple un numéro de carte de crédit. Vous pouvez également utiliser des certificats clients pour authentifier les utilisateurs qui demandent des informations sur votre site Web. L'authentification SSL consiste à vérifier le contenu d'une identification numérique cryptée fournie par le navigateur Web de l'utilisateur lors de l'ouverture de session. (Les utilisateurs peuvent se procurer des certificats clients auprès d'organisations tierces choisies d'un commun accord.) Les certificats serveurs contiennent généralement des informations sur votre société et sur l'organisation ayant émis le certificat. Les certificats clients contiennent généralement des informations d'identification relatives à l'utilisateur et à l'organisation ayant émis le certificat. Pour plus d'informations, consultez À propos des certificats.
Vous pouvez associer ou mapper des certificats clients à des comptes d'utilisateur Windows sur votre serveur Web. Après avoir créé et activé un mappage de certificat, chaque fois qu'un utilisateur ouvre une session avec un certificat client, votre serveur Web associe automatiquement cet utilisateur au compte d'utilisateur Windows approprié. Ainsi, vous pouvez automatiquement authentifier les utilisateurs qui ouvrent une session avec un certificat client, sans avoir recours à l'authentification de base, à l'authentification Digest, ni à l'authentification intégrée de Windows. Vous pouvez mapper un certificat client avec un compte d'utilisateur Windows, ou bien plusieurs certificats clients avec un même compte. Par exemple, si votre serveur comporte plusieurs services ou sociétés, chacun disposant de son propre site Web, vous pouvez utiliser un mappage plusieurs-à-un pour mapper tous les certificats clients de chaque service ou société avec le site Web approprié. Ainsi, chaque site autorise l'accès uniquement à ses clients. Pour plus d'informations, consultez Mappage des certificats clients avec les comptes d'utilisateur.
Vous pouvez configurer votre serveur FTP pour autoriser l'accès anonyme aux ressources FTP. Si l'authentification anonyme est activée, IIS essaiera toujours d'utiliser cette méthode en premier, même si l'authentification de base est également activée. Si vous sélectionnez l'authentification anonyme pour une ressource, toutes les demandes concernant cette ressource sont traitées sans demander de nom d'utilisateur ni de mot de passe. Cela est possible parce que IIS crée automatiquement un compte d'utilisateur Windows appelé IUSR_nom_ordinateur, nom_ordinateur étant le nom du serveur sur lequel IIS s'exécute. Cette méthode est très similaire à l'authentification Web anonyme. Pour plus d'informations, consultez Authentification anonyme.
Pour établir une connexion FTP avec votre serveur Web à l'aide de l'authentification de base, les utilisateurs doivent ouvrir une session en utilisant un nom d'utilisateur et un mot de passe correspondant à un compte Windows valide. Si le serveur FTP ne parvient pas à vérifier l'identité d'un utilisateur, il renvoie un message d'erreur. L'authentification FTP est assez peu sécurisée, car l'utilisateur transmet son mot de passe et son nom d'utilisateur sur le réseau sans les crypter. Pour plus d'informations, consultez À propos du contrôle d'accès.
© 1997-1999 Microsoft Corporation. Tous droits réservés.