Comment IIS authentifie les clients navigateur

Cet article décrit les différentes méthodes d'authentification qui sont disponibles dans IIS pour Microsoft Windows NT 4.0 et Microsoft Windows 2000. Pour une description plus complète des informations présentées dans cet article, consultez le Windows NT 4.0 et les Guides de ressources Windows 2000.

Méthodes d'authentification qui sont disponibles pour Windows NT 4.0

Anonyme -Aucune ouverture de session n'est requise et tout le monde est autorisé à accéder aux données protégées avec cette méthode. Le serveur utilise un compte (IUSR_ [nom_ordinateur] par défaut) pour contrôler les autorisations sur les fichiers. Le navigateur n'envoie pas d'identification ou les informations utilisateur avec ce type de demande.

• Navigateurs pris en charge : toutes
• Limitations : aucun
• Droits d'utilisateur requis : Le compte utilisateur anonyme défini sur le serveur doit avoir des autorisations « Ouvrir une session localement ».
• Type de cryptage : aucun

Base (texte en clair) -Le serveur demande à l'utilisateur pour ouvrir une session et une boîte de dialogue s'affiche dans le navigateur qui permet à l'utilisateur d'entrer les informations d'identification sont nécessaires. Ces informations d'identification doivent correspondre les informations d'identification utilisateur définies sur les fichiers de l'utilisateur tente d'accéder.

• Navigateurs pris en charge : toutes
• Limitations : Pas très sûr. Mots de passe sont facilement déchiffrables.
• Droits d'utilisateur requis : Le compte d'utilisateur doit avoir des autorisations « Ouvrir une session localement ».
• Type de cryptage : Codage en Base 64 (aucun chiffrement réel)

Stimulation/réponse Windows NT -Le serveur demande à l'utilisateur pour ouvrir une session. Si le navigateur prend en charge Windows NT Challenge/Response, il envoie automatiquement les informations d'identification si l'utilisateur est connecté. Si le domaine auquel l'utilisateur est connecté est différent de celui du serveur, ou si l'utilisateur n'est pas connecté, une boîte de dialogue apparaît demandant les informations d'identification à envoyer. Windows NT Challenge/Response utilise un algorithme pour générer un hachage basé sur les informations d'identification de l'utilisateur et l'ordinateur à l'aide de l'utilisateur. Il envoie ensuite ce hachage au serveur. Le navigateur n'envoie pas de mot de passe de l'utilisateur entre sur le serveur.

• Navigateurs pris en charge : Internet Explorer 3.01 et versions ultérieures
• Limitations : Nécessite une connexion point à point. En règle générale, un circuit est fermé après une erreur « 401 unauthorized » du message ; Toutefois, lors de la négociation d'une séquence d'authentification stimulation/réponse Windows NT (qui nécessite plusieurs allers-retours), le serveur laisse le circuit ouvert pour la durée de la séquence une fois que le client a indiqué qu'il utilisera Windows NT Challenge/Response. Les proxys CERN et certains autres périphériques Internet empêchent ce travail. En outre, Windows NT Challenge/Response ne supporte pas les emprunts (dans la mesure où une fois transmis au serveur IIS, les mêmes informations d'identification ne peut pas être transmises à un serveur de back-end pour l'authentification).
• Droits d'utilisateur requis : Le compte d'utilisateur qui accède au serveur doit avoir des autorisations « Accéder à cet ordinateur à partir du réseau ».
• Type de cryptage : Algorithme de hachage NTLM est également décodé.

Ordres de priorité :Lorsque le navigateur soumet une requête, il considère toujours la première demande comme anonyme. Par conséquent, il n'envoie pas d'informations d'identification. Si le serveur n'accepte pas anonyme ou si le compte utilisateur anonyme défini sur le serveur n'a pas d'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 en utilisant l'un des scénarios suivants :

• Si Windows NT Challenge/Response est la seule prise en charge de la méthode (ou si anonyme échoue), puis le navigateur doit prendre en charge cette méthode pour communiquer avec le serveur. Dans le cas contraire, 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 prise en charge de la méthode (ou si anonyme échoue), puis une boîte de dialogue s'affiche dans le navigateur pour obtenir les informations d'identification et transmet ensuite ces informations d'identification pour le serveur. Il tente d'envoyer ces informations d'identification trois fois. En cas d'échec, le navigateur n'est pas connecté au serveur.
• Si Basic et Windows NT Challenge/Response sont pris en charge, le navigateur détermine quelle méthode est utilisée. Si le navigateur prend en charge Windows NT Challenge/Response, il utilise cette méthode et ne tombe pas dans Basic. Si Windows NT Challenge/Response n'est pas pris en charge, le navigateur utilise Basic.

Notes:

• Lorsque votre navigateur établit une connexion avec un site Web en utilisant l'authentification de base ou NTLM, il ne passe pas au mode Anonyme durant le reste de cette session avec le serveur. Si vous essayez de vous connecter à une page Web marquée anonyme uniquement après l'authentification, vous sera refusé. (Cela peut ou ne peut pas contenir true pour Netscape).
• Lorsque Internet Explorer a établi une connexion avec le serveur en utilisant l'authentification de base ou NTLM, il transmet les informations d'identification pour chaque nouvelle demande pour la durée de la session.

Méthodes d'authentification qui sont disponibles pour Windows 2000 et supérieur

Anonyme -Aucune ouverture de session n'est requise et tout le monde est autorisé à accéder aux données protégées avec cette méthode. Le serveur utilise un compte (IUSR_ [nom_ordinateur] par défaut) pour contrôler les autorisations sur les fichiers. Le navigateur n'envoie pas d'identification ou les informations utilisateur avec ce type de demande.

• Navigateurs pris en charge : toutes
• Limitations : aucun
• Droits d'utilisateur requis : Le compte utilisateur anonyme défini sur le serveur doit avoir des autorisations « Ouvrir une session localement ».
• Type de cryptage : aucun

Base (texte en clair) -Le serveur demande à l'utilisateur pour ouvrir une session et une boîte de dialogue s'affiche dans le navigateur qui permet à l'utilisateur d'entrer les informations d'identification sont nécessaires. Ces informations d'identification doivent correspondre les informations d'identification utilisateur définies sur les fichiers de l'utilisateur tente d'accéder.

• Navigateurs pris en charge : toutes
• Limitations : Pas très sécurisée. Mots de passe sont facilement déchiffrables.
• Droits d'utilisateur requis : Le compte d'utilisateur doit avoir des droits « Ouvrir une session localement »
• Type de cryptage : Codage en Base 64 (aucun chiffrement réel)

Digest -Le serveur demande à l'utilisateur pour ouvrir une session et envoie également un NONCE utilisé pour chiffrer le mot de passe. Le navigateur utilise le NONCE pour crypter le mot de passe et l'envoie au serveur. Le serveur puis crypte sa propre copie du mot de passe de l'utilisateur et compare les deux. Si elles correspondent et que l'utilisateur dispose des autorisations, l'accès est accordé.

• Navigateurs pris en charge : Internet Explorer 5 et versions ultérieures
• Limitations : Non comme sécurisé que Integrated. Exige que le serveur d'accéder à un serveur Active Directory qui est configuré pour l'authentification Digest.
• Droits d'utilisateur requis : Requiert des mots de passe pour que « Enregistrer le mot de passe en texte clair"
• Type de cryptage : Basé sur NONCE envoyé par le serveur.

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :Fortezza -Pour utiliser la sécurité Fortezza avec IIS 5.0, vous devez disposer d'un fichier Cryptographic API Service Provider (CSP) appropriée à partir d'un fournisseur Fortezza tel que http://www.spyrus.com.

Windows Integrated (divisé en deux sous-catégories)
Kerberos -Le serveur demande un utilisateur de se connecter. Si le navigateur prend en charge Kerberos, les éléments suivants a lieu :

• IIS demande l'authentification.
• Si le client n'est pas connecté à un domaine, une boîte de dialogue s'affiche dans Internet Explorer demandant les informations d'identification et puis contacte le KDC pour demander et recevoir un Ticket d'accord de Ticket. Il envoie ensuite ce Ticket avec les informations sur le serveur IIS au KDC.
• Si le Client IE a déjà connecté au domaine et a reçu un Ticket d'accord de Ticket, il envoie ce ticket avec les informations sur le serveur IIS au KDC
• Le KDC délivre au client un Ticket de ressources.
• Le Client communique ce ticket au serveur IIS.

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

• Navigateurs pris en charge : Internet Explorer versions 5.0 et ultérieures
• Restrictions : le serveur doit avoir accès à un serveur Active Directory. Le serveur et le client doivent avoir une connexion approuvée à un KDC.
• Droits d'utilisateur requis : Le compte utilisateur anonyme défini sur le serveur doit avoir des autorisations « Ouvrir une session localement ».
• Type de cryptage : cryptée du ticket.

Stimulation/réponse Windows NT -Le serveur demande à l'utilisateur pour ouvrir une session. Si le navigateur prend en charge Windows NT Challenge/Response, il envoie automatiquement les informations d'identification si l'utilisateur est connecté. Si le domaine auquel l'utilisateur est connecté est différent de celui 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 basé sur les informations d'identification de l'utilisateur et l'ordinateur à l'aide de l'utilisateur. Il envoie ensuite ce hachage au serveur. Le navigateur n'envoie pas de mot de passe de l'utilisateur entre sur le serveur.

• Navigateurs pris en charge : Internet Explorer 3.01 et versions ultérieures.
• Limitations : Nécessite une connexion point à point. En règle générale, un circuit est fermé après une erreur « 401 unauthorized » du message ; Toutefois, lors de la négociation d'une séquence d'authentification stimulation/réponse Windows NT (qui nécessite plusieurs allers-retours), le serveur laisse le circuit ouvert pour la durée de la séquence une fois que le client a indiqué qu'il utilisera Windows NT Challenge/Response. Les proxys CERN et certains autres périphériques Internet empêchent ce travail. En outre, Windows NT Challenge/Response ne gère pas les emprunts (ce qui signifie qu'une fois transmis au serveur IIS, les mêmes informations d'identification ne peut pas être passées à un serveur dorsal pour l'authentification, par exemple, lorsque IIS utilise Windows NT Challenge/Response, il ne peut pas puis authentifier l'utilisateur par rapport à une base de données SQL Server sur un autre ordinateur en utilisant la sécurité intégrée de SQL).
• Droits d'utilisateur requis : Le compte d'utilisateur accédant au serveur doit avoir des autorisations « Accéder à cet ordinateur à partir du réseau ».
• Type de cryptage : Algorithme de hachage NTLM est également décodé.

Ordres de priorité :Lorsque le navigateur soumet une requête, il considère toujours la première demande 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 n'a pas d'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 en utilisant l'un des scénarios suivants :

• Si l'authentification intégrée Windows est la seule prise en charge de la méthode (ou si anonyme échoue), puis le navigateur doit prendre en charge cette méthode pour communiquer avec le serveur. Si cela échoue, le serveur n'essaie aucune des autres méthodes.
• Si Basic est la seule méthode (ou si anonyme échoue), puis une boîte de dialogue s'affiche dans la pour obtenir les informations d'identification, puis les transmet au serveur. Il tente d'envoyer les informations d'identification trois fois. En cas d'échec, le navigateur ne se connecte pas au serveur.
• Si Basic et intégrée de Windows sont pris en charge, le navigateur détermine quelle méthode est utilisée. Si le navigateur prend en charge Kerberos ou stimulation/réponse de Windows NT, il utilise cette méthode. Il ne passe pas à Basic. Si Windows NT Challenge/Response et Kerberos ne sont pas pris en charge, le navigateur utilise Basic, Digest ou Fortezza si elle prend en charge ces. L'ordre de précédence ici est Basic, Digest puis Fortezza.

Notes:

• Lorsque votre navigateur établit une connexion avec un site Web en utilisant l'authentification de base ou intégrée Windows, il ne passe pas au mode Anonyme durant le reste de cette session avec le serveur. Si vous essayez de vous connecter à une page Web marquée anonyme uniquement après l'authentification, vous est refusé. (Cela peut ou ne peut pas contenir true pour Netscape).
• Internet Explorer a établi une connexion avec le serveur à l'aide d'une méthode d'authentification autre qu'anonyme, transmet automatiquement les informations d'identification pour chaque nouvelle demande pendant la durée de la session.

Pour plus d'informations sur la façon de configurer l'authentification de site Web IIS dans Windows Server 2003, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :Pour plus d'informations sur les problèmes qui peuvent se produire si un pool d'applications de site Web est hébergé sur IIS 6.0 est recyclé pendant le processus d'authentification, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :