Authentification Windows intégrée

L'authentification Windows intégrée ( IWA ) est un terme associé aux produits Microsoft qui fait référence aux protocoles d'authentification SPNEGO , Kerberos et NTLMSSP par rapport à la fonctionnalité SSPI introduite avec Microsoft Windows 2000 et incluse dans les systèmes d'exploitation ultérieurs basés sur Windows NT . Le terme est plus couramment utilisé pour les connexions authentifiées automatiquement entre Microsoft Internet Information Services , Internet Explorer et d'autres applications compatibles Active Directory .

IWA est également connu sous plusieurs noms tels que l'authentification HTTP Negotiate , l'authentification NT , l'authentification NTLM , l'authentification de domaine , l'authentification intégrée Windows , l'authentification Windows NT Challenge/Response , ou simplement l'authentification Windows .

L'authentification Windows intégrée utilise les fonctions de sécurité des clients et serveurs Windows. Contrairement à l'authentification de base ou à l'authentification Digest , elle ne demande pas initialement aux utilisateurs de saisir un nom d'utilisateur et un mot de passe. Les informations utilisateur Windows actuelles sur l'ordinateur client sont fournies par le navigateur Web via un échange cryptographique impliquant un hachage avec le serveur Web. Si l'échange d'authentification ne parvient pas initialement à identifier l'utilisateur, le navigateur Web demandera à l'utilisateur un nom d'utilisateur et un mot de passe de compte d'utilisateur Windows.

L'authentification Windows intégrée n'est pas en elle-même une norme ou un protocole d'authentification. Lorsque IWA est sélectionné comme option d'un programme (par exemple dans l' onglet Sécurité du répertoire de la boîte de dialogue des propriétés du site IIS ) cela implique que les mécanismes de sécurité sous-jacents doivent être utilisés dans un ordre préférentiel. Si le fournisseur Kerberos est fonctionnel et qu'un ticket Kerberos peut être obtenu pour la cible, et que tous les paramètres associés permettent l'authentification Kerberos (par exemple les paramètres des sites intranet dans Internet Explorer ), le protocole Kerberos 5 sera tenté. Sinon , l'authentification NTLMSSP est tentée. De même, si l'authentification Kerberos est tentée, mais qu'elle échoue, alors NTLMSSP est tenté. IWA utilise SPNEGO pour permettre aux initiateurs et aux accepteurs de négocier Kerberos ou NTLMSSP. Des utilitaires tiers ont étendu le paradigme de l'authentification Windows intégrée aux systèmes UNIX, Linux et Mac.

L'authentification Windows intégrée fonctionne avec la plupart des navigateurs Web modernes, mais ne fonctionne pas sur certains serveurs proxy HTTP . Par conséquent, elle est idéale pour une utilisation dans les intranets où tous les clients se trouvent dans un seul domaine . Elle peut fonctionner avec d'autres navigateurs Web s'ils ont été configurés pour transmettre les informations d'identification de connexion de l'utilisateur au serveur qui demande l'authentification. Lorsqu'un proxy lui-même nécessite une authentification NTLM, certaines applications comme Java peuvent ne pas fonctionner car le protocole n'est pas décrit dans la RFC-2069 pour l'authentification proxy.

• Internet Explorer 2 et versions ultérieures.
• Dans Mozilla Firefox sur les systèmes d'exploitation Windows, les noms des domaines/sites Web auxquels l'authentification doit être transmise peuvent être saisis (délimités par des virgules pour plusieurs domaines) pour le nom de préférence « network.negotiate-auth.trusted-uris » (pour Kerberos) ou dans le nom de préférence « network.automatic-ntlm-auth.trusted-uris » (NTLM) sur la page about:config . Sur les systèmes d'exploitation Macintosh, cela fonctionne si vous avez un ticket Kerberos (utilisez negotiate). Certains sites Web peuvent également nécessiter la configuration de « network.negotiate-auth.delegation-uris ».
• Opera 9.01 et les versions ultérieures peuvent utiliser NTLM/Negotiate, mais utiliseront l'authentification Basic ou Digest si celle-ci est proposée par le serveur.
• Google Chrome fonctionne à partir de la version 8.0.
• Safari fonctionne, une fois que vous avez un ticket Kerberos.
• Microsoft Edge 77 et versions ultérieures.

iOS prend en charge Kerberos de manière native via l'extension Kerberos Single Sign-on. La configuration de l'extension permet à Safari et Edge d'utiliser Kerberos.

Android prend en charge SPNEGO dans Chrome, ce qui ajoute la prise en charge de Kerberos avec une solution comme Hypergate Authenticator.