Authentification NTLM

Modes d'intégration compatibles

L'authentification NTLM peut uniquement être utilisée en mode proxy explicite. En effet, dans les autres modes d'intégration, le navigateur ne communique pas directement avec le proxy.

Contraintes et limitations

• L'authentification NTLM est un mécanisme fort, qui présente de fortes contraintes : voir Contraintes liées à la force de l'authentification. De plus, son coût réseau est élevé : d'une part, chaque requête doit être authentifiée, d'autre part l'authentification demande plusieurs allers-retours entre le client, le proxy et l'annuaire (il est normal que vous constatiez un grand nombre de codes 407 dans vos logs).
• Une infrastructure Active Directory est nécessaire, et l'Olfeo doit être joint au domaine Windows.
• Si vous avez des utilisateurs gérés via un annuaire autre qu'Active Directory, vous devrez utiliser une autre méthode d'authentification pour ceux-ci, et ajouter une exception à l'authentification NTLM pour ces utilisateurs.
• Pour que l'authentification NTLM fonctionne, l'Olfeo doit être synchronisé avec le serveur NTP interne à l'AD ou avec le même serveur NTP que l'AD. Voir Connecter votre Olfeo à un serveur NTP.
• Le hostname de la machine ne peut excéder 15 caractères.

Fonctionnement

Principe : La machine cliente et l'AD stockent tous les deux une représentation du mot de passe de l'utilisateur. Chacun va utiliser le mot de passe comme clé de chiffrement pour chiffrer une même chaîne. Si les résultats correspondent, l'authentification est validée.

Étapes du mécanisme :

1. L'utilisateur ouvre une session Windows sur sa machine, sur un domaine Active Directory. La machine stocke une représentation du mot de passe de l'utilisateur.
2. L'utilisateur tente d'accéder à une page web : le proxy reçoit sa requête.
3. Le proxy envoie une demande d'authentification au navigateur (code 407). Celle-ci inclut l'en-tête Proxy-Authenticate: NTLM pour indiquer au navigateur qu'il attend une authentification NTLM (et Proxy-Authenticate: Basic realm="Squid Olfeo" pour indiquer la méthode de fallback).
4. Le navigateur envoie à nouveau la requête au proxy, en incluant un en-tête Proxy-Authorization contenant l'identifiant de l'utilisateur, le hostname de la machine et son domaine.
5. Le proxy envoie ces informations à l'annuaire AD, qui les stocke. L'annuaire sait donc que l'utilisateur cherche à s'authentifier.
6. Afin de traiter la demande d'authentification, l'annuaire génère un "challenge", c'est-à-dire une chaîne aléatoire sur 16 octets, et l'envoie au proxy. Le proxy transmet le challenge au client dans une nouvelle demande d'authentification (407).
7. Le client fait un hash du challenge avec son mot de passe et l'envoie au proxy, dans une nouvelle requête. Le proxy transmet ce hash à l'AD.
   • Authentification validée : L'AD identifie l'utilisateur grâce au informations précédemment stockées. Il fait lui-même un hash du challenge avec le mot de passe de l'utilisateur et compare celui-ci avec le hash réalisé par le client : si les deux correspondent, cela veut dire que c'est le même mot de passe qui a chiffré le challenge, l'authentification est donc validée. L'AD informe le proxy que l'authentification est validée, et le proxy envoie le flux au moteur de filtrage. Le moteur de filtrage applique les règles et politiques concernant cet utilisateur : le cas échéant, l'utilisateur peut accéder à la page demandée.

     L'utilisateur est ré-authentifié à chaque requête.

   • Authentification échouée : L'AD tente d'identifier l'utilisateur grâce aux informations précédemment stockées. Si toutes les informations ne correspondent pas (par exemple, si la machine n'est pas membre du domaine), l'AD informe le proxy que l'authentification a échoué. Le proxy envoie au client une demande d'authentification explicite (code 407) : le navigateur ouvre une fenêtre pop-up pour que l'utilisateur saisisse son identifiant et son mot de passe.

Mettre en place une authentification NTLM

1. Synchronisez le ou les annuaires Active Directory contenant vos utilisateurs. Dans la page de configuration de l'annuaire, remplissez la section Domaine. Si vous synchronisez plusieurs AD, relations d'approbation.
2. Joignez l'Olfeo au domaine Windows.
3. À la page Proxy Cache QoS > HTTP > Authentification, sélectionnez NTLM (Active Directory) dans la liste Méthode d'authentification. La page affiche les options correspondantes. Le champ Statut indique le domaine Windows auquel l'Olfeo est joint.

4. Si besoin, modifiez le nombre de processus d'authentification instanciés dans le champ Nombre d'instances. Le nombre d'instances correspond au nombre de demandes d'authentification qui peuvent être traitées en parallèle à un instant donné.

   (Si vous entrez 30, l'Olfeo lance 30 processus NTLM SSP et 30 NTLM basiques.)

5. Dans la section Règles, définissez les cas dans lesquels une authentification sera demandée ou non.
   • Ajoutez une règle grâce au bouton .
   • Définissez des critères :
     • Sources : définissez les plages d'adresses IP concernées par la règle.
     • User-Agent : utilisez ce paramètre pour désactiver l'authentification auprès du proxy HTTP pour certains types d'applications clientes incapables de s'authentifier (lecteur audio/vidéo...). Définissez une expression rationnelle sur l'en-tête User-agent de la requête. Attention, toutes les requêtes n'incluent pas cet en-tête (le navigateur peut avoir été paramétré pour l'omettre). Pour ajouter un user-agent, utilisez la dernière ligne du tableau.
     • Ports du proxy : la règle ne s'appliquera qu'aux flux reçus sur le port spécifié. La liste propose tous les ports qui ne sont pas en interception (en effet, l'interception ne tolère pas l'authentification).
     • Destination : la règle s'appliquera uniquement aux requêtes à destination de ces domaines. Vous pouvez indiquer des URLs spécifiques grâce à une expression rationnelle, ou bien utiliser des listes d'URL ou des listes de domaines existantes.
     • Authentification : définissez si dans le cas décrit par la règle, le proxy doit demander une authentification ou non.
   • Si besoin, modifiez l'ordre des règles grâce aux flèches et . Le proxy évaluera les règles une par une de haut en bas : assurez-vous qu'aucune règle n'en bloque une autre. Par exemple, positionnez une règle désactivant l'authentification pour la mise à jour d'un serveur applicatif avant une règle demandant l'authentification des utilisateurs du serveur, sinon les mises à jour seront bloquées.
6. Sous la liste de règles, dans la liste Par défaut, définissez le comportement à adopter pour les requêtes ne correspondant à aucune des règles. (Pas d'authentification, ou Authentification).
7. Cliquez sur le bouton Valider pour enregistrer les changements.