IIS authentifie les clients de navigateur

Article
03/24/2024

Cet article présente comment IIS authentifie les clients de navigateur.

Version d’origine du produit : Internet Explorer
Numéro de la base de connaissances d’origine : 264921

Résumé

Cet article décrit les différentes méthodes d’authentification disponibles dans IIS pour Windows NT 4.0, Windows 2000 et versions ultérieures de Windows. Pour obtenir une description plus complète des informations décrites dans cet article, consultez les Guides de ressources Windows NT 4.0 et Windows 2000.

Méthodes d’authentification disponibles pour Windows NT 4.0

Anonyme : aucune ouverture de session n’est requise et toute personne est autorisée à accéder aux données protégées par cette méthode. Le serveur utilise un compte intégré (IUSR_[nom de l’ordinateur] par défaut) pour contrôler les autorisations sur les fichiers. Le navigateur n’envoie pas d’informations d’identification ou d’informations utilisateur avec ce type de requête.

Navigateurs pris en charge : Tout
Limitations : Aucune
Droits de l’utilisateur requis : le compte d’utilisateur anonyme défini sur le serveur doit disposer d’autorisations d’ouverture de session localement .
Type de chiffrement : Aucun

De base (texte en clair) : le serveur demande à l’utilisateur de se connecter et une boîte de dialogue s’affiche dans le navigateur qui permet à l’utilisateur d’entrer les informations d’identification nécessaires. Ces informations d’identification doivent correspondre aux informations d’identification de l’utilisateur définies sur les fichiers auxquels l’utilisateur tente d’accéder.

Navigateurs pris en charge : Tout
Limitations : non sécurisé. Les mots de passe sont facilement déchiffrés.
Droits de l’utilisateur requis : le compte d’utilisateur doit disposer des autorisations d’ouverture de session locale.
Type de chiffrement : Encodage de base 64 (chiffrement non vrai)

Défi/réponse Windows NT : le serveur demande à l’utilisateur de se connecter. Si le navigateur prend en charge windows NT Challenge/Response, il envoie automatiquement les informations d’identification de l’utilisateur si l’utilisateur est connecté. Si le domaine sur lequel se trouve l’utilisateur est différent du domaine du serveur, ou si l’utilisateur n’est pas connecté, une boîte de dialogue s’affiche pour demander les informations d’identification à envoyer. Windows NT Challenge/Response utilise un algorithme pour générer un hachage en fonction des informations d’identification de l’utilisateur et de l’ordinateur utilisé par l’utilisateur. Il envoie ensuite ce hachage au serveur. Le navigateur n’envoie pas le mot de passe de l’utilisateur au serveur.

Navigateurs pris en charge : Internet Explorer versions 3.01 et ultérieures
Limitations : nécessite une connexion point à point. En règle générale, un circuit est fermé après un message d’erreur « 401 non autorisé ». Toutefois, lors de la négociation d’une séquence d’authentification de défi/réponse Windows NT (qui nécessite plusieurs allers-retours), le serveur maintient le circuit ouvert pendant la durée de la séquence une fois que le client a indiqué qu’il utilisera le défi/réponse Windows NT. Les proxys du CERN et certains autres appareils Internet empêchent cela de fonctionner. En outre, windows NT Challenge/Response ne prend pas en charge les emprunts d’identité à double tronçon (dans la pratique où une fois passées au serveur IIS, les mêmes informations d’identification ne peuvent pas être transmises à un serveur principal pour l’authentification).
Droits de l’utilisateur Requis : le compte d’utilisateur qui accède au serveur doit disposer des autorisations « Accéder à cet ordinateur à partir du réseau ».
Type de chiffrement : algorithme de hachage NTLM qui est également non codé.

Ordre de priorité : Lorsque le navigateur effectue une requête, il considère toujours la première requête comme anonyme. Par conséquent, il n’envoie pas d’informations d’identification. Si le serveur n’accepte pas Anonyme OU si le compte d’utilisateur anonyme défini sur le serveur ne dispose pas des autorisations pour le fichier demandé, le serveur IIS répond avec un message d’erreur Accès refusé et envoie une liste des types d’authentification pris en charge à l’aide de l’un des scénarios suivants :

Si la requête/réponse Windows NT est la seule méthode prise en charge (ou si Anonymous échoue), le navigateur doit prendre en charge cette méthode pour communiquer avec le serveur. Sinon, il ne peut pas négocier avec le serveur et l’utilisateur reçoit un message d’erreur Accès refusé .
Si Basic est la seule méthode prise en charge (ou si Anonymous échoue), une boîte de dialogue s’affiche dans le navigateur pour obtenir les informations d’identification, puis les transmet au serveur. Il tente d’envoyer ces informations d’identification jusqu’à trois fois. Si toutes ces opérations échouent, le navigateur n’est pas connecté au serveur.
Si les défis/réponses de base et Windows NT sont pris en charge, le navigateur détermine la méthode utilisée. Si le navigateur prend en charge windows NT Challenge/Response, il utilise cette méthode et ne revient pas à De base. Si windows NT Challenge/Response n’est pas pris en charge, le navigateur utilise De base.

Remarque

Lorsque votre navigateur établit une connexion avec un site Web à l’aide Basic de l’authentification ou NTLM , il ne revient pas à Anonyme pendant le reste de cette session avec le serveur. Si vous essayez de vous connecter à une page web marquée pour Anonyme uniquement après l’authentification, vous serez refusé. (Cela peut ou non être vrai pour Netscape).
Lorsque le Explorer Internet a établi une connexion avec le serveur à l’aide Basic de ou NTLM de l’authentification, il transmet les informations d’identification pour chaque nouvelle demande pendant la durée de la session.

Méthodes d’authentification disponibles pour Windows 2000 et versions ultérieures

Navigateurs pris en charge : Tout
Limitations : Aucune
Droits de l’utilisateur requis : le compte d’utilisateur anonyme défini sur le serveur doit disposer d’autorisations d’ouverture de session locale.
Type de chiffrement : Aucun

Navigateurs pris en charge : Tout
Limitations : non sécurisé. Les mots de passe sont facilement déchiffrés.
Droits de l’utilisateur requis : le compte d’utilisateur doit disposer de droits d’ouverture de session localement
Type de chiffrement : Encodage de base 64 (chiffrement non vrai)

Digest : le serveur demande à l’utilisateur de se connecter et envoie également un NONCE utilisé pour chiffrer le mot de passe. Le navigateur utilise la valeur NONCE pour chiffrer le mot de passe et l’envoie au serveur. Le serveur chiffre ensuite sa propre copie du mot de passe de l’utilisateur et compare les deux. S’ils correspondent et que l’utilisateur dispose d’autorisations, l’accès est accordé.

Navigateurs pris en charge : Internet Explorer 5 et versions ultérieures
Limitations : Pas aussi sécurisé qu’Intégré. Nécessite que le serveur ait accès à un serveur Active Directory configuré pour l’authentification Digest.
Droits de l’utilisateur requis : nécessite que les mots de passe aient « Enregistrer le mot de passe en tant que texte en clair chiffré »
Type de chiffrement : basé sur NONCE envoyé par le serveur.

Windows Intégré (divisé en deux sous-catégories)

Kerberos : le serveur demande à un utilisateur de se connecter. Si le navigateur prend en charge Kerberos, les opérations suivantes sont effectuées :

Iis demande l’authentification.
Si le client ne s’est pas connecté à un domaine, une boîte de dialogue s’affiche dans Internet Explorer demandant des informations d’identification, puis contacte le KDC pour demander et recevoir un ticket d’octroi de ticket. Il envoie ensuite le ticket d’octroi de ticket ainsi que des informations sur le serveur IIS au KDC.
Si le client IE s’est déjà connecté au domaine et a reçu un ticket d’octroi de ticket, il envoie ce ticket ainsi que des informations sur le serveur IIS au KDC
Le KDC émet un ticket de ressource au client.
Le client transmet ce ticket au serveur IIS.

Kerberos utilise des tickets générés sur un serveur d’octroi de tickets (KDC) pour s’authentifier. Il envoie ce ticket au serveur IIS. Le navigateur n’envoie PAS le mot de passe de l’utilisateur au serveur.

Navigateurs pris en charge : Internet Explorer versions 5.0 et ultérieures
Limitations : le serveur doit avoir accès à un serveur Active Directory. Le serveur et le client doivent disposer d’une connexion approuvée à un KDC.
Droits de l’utilisateur requis : le compte d’utilisateur anonyme défini sur le serveur doit disposer des autorisations d’ouverture de session locale .
Type de chiffrement : ticket chiffré.

Défi/réponse Windows NT : le serveur demande à l’utilisateur de se connecter. Si le navigateur prend en charge windows NT Challenge/Response, il envoie automatiquement les informations d’identification de l’utilisateur si l’utilisateur est connecté. Si le domaine sur lequel se trouve l’utilisateur est différent du domaine du serveur, ou si l’utilisateur n’est pas connecté, une boîte de dialogue s’affiche dans Internet Explorer demandant les informations d’identification à envoyer. Windows NT Challenge/Response utilise un algorithme pour générer un hachage en fonction des informations d’identification de l’utilisateur et de l’ordinateur utilisé par l’utilisateur. Il envoie ensuite ce hachage au serveur. Le navigateur n’envoie pas le mot de passe de l’utilisateur au serveur.

Navigateurs pris en charge : Internet Explorer versions 3.01 et ultérieures.
Limitations : nécessite une connexion point à point. En règle générale, un circuit est fermé après un message d’erreur « 401 non autorisé ». Toutefois, lors de la négociation d’une séquence d’authentification de défi/réponse Windows NT (qui nécessite plusieurs allers-retours), le serveur maintient le circuit ouvert pendant la durée de la séquence une fois que le client a indiqué qu’il utilisera le défi/réponse Windows NT. Les proxys du CERN et certains autres appareils Internet empêchent cela de fonctionner. En outre, windows NT Challenge/Response ne prend pas en charge les emprunts d’identité à double tronçon (ce qui signifie qu’une fois passées au serveur IIS, les mêmes informations d’identification ne peuvent pas être transmises à un serveur principal pour l’authentification, par exemple, quand IIS utilise le défi/réponse Windows NT, il ne peut pas authentifier l’utilisateur auprès d’une base de données SQL Server sur un autre ordinateur à l’aide de la sécurité intégrée SQL).
Droits de l’utilisateur requis : le compte d’utilisateur accédant au serveur doit disposer des autorisations « Accéder à cet ordinateur à partir du réseau ».
Type de chiffrement : algorithme de hachage NTLM qui est également non codé.

Ordre de priorité : Lorsque le navigateur effectue une requête, il considère toujours la première requête comme anonyme. Par conséquent, il n’envoie pas d’informations d’identification. Si le serveur n’accepte pas l’option Anonyme ou si le compte d’utilisateur anonyme défini sur le serveur ne dispose pas des autorisations sur le fichier demandé, le serveur IIS répond avec un message d’erreur Accès refusé et envoie une liste des types d’authentification pris en charge dans l’un des scénarios suivants :

Si Windows Integrated est la seule méthode prise en charge (ou si Anonymous échoue), le navigateur doit prendre en charge cette méthode pour communiquer avec le serveur. En cas d’échec, le serveur n’essaie aucune des autres méthodes.
Si Basic est la seule méthode prise en charge (ou si Anonymous échoue), une boîte de dialogue s’affiche dans le pour obtenir les informations d’identification, puis les transmet au serveur. Il tente d’envoyer les informations d’identification jusqu’à trois fois. Si toutes ces opérations échouent, le navigateur ne se connecte pas au serveur.
Si Les options De base et Windows Intégrée sont prises en charge, le navigateur détermine la méthode utilisée. Si le navigateur prend en charge kerberos ou Windows NT Challenge/Response, il utilise cette méthode. Il ne revient pas à Basic. Si windows NT Challenge/Response et Kerberos ne sont pas pris en charge, le navigateur utilise Basic, Digest ou Fortezza s’il les prend en charge. L’ordre de priorité ici est De base, Digest, puis Fortezza.

Remarque

Lorsque votre navigateur établit une connexion avec un site Web à l’aide de l’authentification de base ou windows intégrée, il ne revient pas à Anonyme pendant le reste de cette session avec le serveur. Si vous essayez de vous connecter à une page web marquée pour Anonyme uniquement après l’authentification, vous êtes refusé. (Cela peut ou non être vrai pour Netscape).
Lorsque l’Explorer Internet a établi une connexion avec le serveur à l’aide d’une méthode d’authentification autre qu’Anonyme, elle transmet automatiquement les informations d’identification pour chaque nouvelle requête pendant la durée de la session.

References

Pour plus d’informations sur la configuration de l’authentification de site Web IIS dans Windows Server 2003, consultez Guide pratique pour configurer l’authentification de site Web IIS dans Windows Server 2003.