Gérer l'identification et l'authentification de vos utilisateurs
Ce chapitre décrit comment faire en sorte que la solution Olfeo reconnaisse les utilisateurs en provenance desquels elle reçoit des flux.
Vous y retrouverez :
Des informations générales concernant l'identification et l'authentification ainsi que les critères de choix de méthode d'authentification.
Les procédures nécessaires pour mettre en place de l'authentification associée à un annuaire MS Active Directory.
Les procédures nécessaires pour mettre en place de l'identification et de l'authentification pour d'autres cas d'usages (autres annuaires LDAP, situations "mixtes" ou sans annuaire).
Authentifier/identifier : pour quoi faire?
Pour que les règles de filtrage spécifiques à l'utilisateur puissent être appliquées, ainsi que les règles de quotas ou d'outrepassement, Olfeo On premises doit savoir précisément à quel utilisateur il a à faire. Pour qu'Olfeo On premises connaisse un utilisateur, il faut que les utilisateurs à filtrer existent dans la liste des utilisateurs. Tout utilisateur n'apparaissant pas dans cette liste est un utilisateur inconnu.
Si aucune méthode d'authentification ni d'identification n'est mise en place, tous les utilisateurs filtrés seront des utilisateurs inconnus : Olfeo On premises leur appliquera à tous la politique par défaut. Cela peut être un choix légitime (il n'est pas obligatoire d'authentifier ou d'identifier des utilisateurs). Cependant, avoir un log nominatif suppose d'avoir une méthode d'authentification ou d'identification en place. Sans cela, seules les adresses IP seront loguées.
Identification
Identifier un utilisateur ou une machine signifie récupérer une information le concernant (adresse IP, identifiant) et trouver une correspondance entre cette information et un utilisateur figurant dans la liste des utilisateurs.
Les informations permettant d'identifier un utilisateur pouvant être récupérées varient suivant le type d'intégration. Elles pourront également être récupérées par divers éléments en fonction du type d'intégration.
Authentification
Une authentification est un mécanisme de validation de l'identité. Des informations d'identification sont demandées à l'utilisateur ou au navigateur (couple identifiant/mot de passe, échange de jetons sécurisés), et ces informations sont ensuite vérifiées auprès d'un tiers de confiance (un annuaire). En authentifiant, on vérifie que l'utilisateur est bien celui qu'il prétend être.
Il existe plusieurs mécanismes d'authentification, plus ou moins forts, c'est-à-dire avec un niveau de fiabilité plus ou moins élevé : un mécanisme fort réalise une authentification pour chaque requête, tandis qu'un mécanisme faible réalise une seule action d'authentification suivie d'actions d'identification.
Olfeo On premises propose différentes méthodes d'identification et d'authentification, certaines réalisées par le proxy HTTP, certaines par le moteur de filtrage : choisissez celle qui convient le mieux à vos besoins.
Suivant le type d'intégration, l'Olfeo ne récupère pas les mêmes informations.
Type d'intégration | Informations récupérées |
|---|---|
Intégration proxy |
|
Intégration couplage/connecteur | Dans une intégration en mode couplage, si l'équipement tiers (proxy, UTM) réalise une authentification, l'identifiant de l'utilisateur sera transmis au moteur de filtrage.
|
Dans tous les cas, si un équipement situé avant l'Olfeo dans votre architecture réalise une authentification, l'Olfeo pourra recevoir l'identifiant de l'utilisateur (si l'équipement transmet cette information).
Traitement des adresses IP récupérées
Si l'Olfeo reçoit uniquement des adresses IP (et pas d'identifiants), il ne peut pas identifier les utilisateurs, l'adresse IP ne lui permettant pas de faire le lien avec la liste des utilisateurs (sauf pour les utilisateurs créés à la main pour lesquels on a renseigné une adresse IP). Pour résoudre ce problème, vous pouvez :
Utiliser un portail captif afin d'associer les adresses IP récupérées aux identifiants des utilisateurs. Vous pourrez ainsi appliquer une politique à n'importe quel niveau (utilisateur, groupe ou UO).
Créer les utilisateurs automatiquement à partir de leur adresse IP (autocréation par IP), et donc appliquer une politique sur le groupe ou l'UO.
Créer manuellement un utilisateur de type plage d'IPs et lui appliquer une politique.
Identifiant (et adresse IP)
Si l'Olfeo reçoit l'identifiant de l'utilisateur (si une authentification a été faite par un autre équipement avant que le flux n'arrive à l'Olfeo), il retrouve celui-ci dans la liste des utilisateurs et applique la politique correspondante.
Compatibilité entre méthodes d'authentification/identification et modes d'intégration
Comme pour les modules compatibles en fonction du mode d'intégration il faut vous référer à ce tableau en ce qui concerne l'authentification ou l'identification des utilisateurs.
Proxy explicite | Proxy interception | Couplage | Capture du trafic | Filtrage DNS | Nomadisme | ||
|---|---|---|---|---|---|---|---|
Coupure | Copie | ||||||
NTLM & Kerberos AD | OUI | NON | NON | NON | NON | NON | OUI(3) |
LDAP basique | OUI | NON | NON | NON | NON | NON | OUI(2) |
Portail captif | OUI | OUI | OUI | OUI | OUI | NON | OUI(2) |
Portail captif avec NTLM | OUI | OUI | OUI | OUI | OUI | NON | OUI(2) |
Identification (relation IP / login) | OUI | OUI | OUI | OUI | OUI | OUI(1) | NON |
Note
(1) : Afin de se reposer sur une association entre l'adresse IP de l'équipement filtré et un identifiant utilisateur, l'équipement Olfeo doit etre positionné en tant que serveur DNS sur les équipements à filtrer et non en tant que relais DNS.
(2): Ce sont des mécanismes d'authentification faible. L'authentification a lieu après la première requête, puis l'Olfeo stocke la correspondance entre l'identifiant de l'utilisateur et son adresse IP. Par la suite il réalisera une identification basée sur cette adresse IP. Lorsque le nomade accède au proxy externe, c'est l'adresse IP publique de la connexion internet qui sera visible dans les logs. Ce mode de fonctionnement se limite donc à un utilisateur par adresse IP gérée.
(3): Kerberos requiert l'ouverture de certains flux réseaux entre les machines clientes et l'infrastructure d'authentification, ce qui pose des problèmes de sécurité lorsque le nomade doit s'authentifier via le proxy externe.
Choisissez votre ou vos méthodes d'authentification dans Olfeo On premises selon les critères ci-dessous, en fonction de vos populations d'utilisateurs et en fonction de vos besoins réels.
Infrastructure existante et mode d'intégration
Quels critères de choix votre infrastructure impose-t-elle?
Le choix de la méthode d'authentification doit prendre en compte les contraintes liées au mode d'intégration choisi, et les deux sont étroitement liés à votre infrastructure.
Selon le mode d'intégration, Olfeo On premises ne recevra pas les mêmes informations : IP, identifiant...
Suivant votre infrastructure, l'authentification peut être réalisée par Olfeo On premises lui-même (proxy explicite) , ou bien peut récupérer des informations d’authentification d'un équipement tiers (intégration en proxy transparent, ou en ICP par ex.).
Tenez compte :
Des mécanismes d'authentification utilisés dans votre infrastructure (par exemple, si vous utilisez déjà NTLM).
Du type d'annuaire. Selon le type d'annuaire utilisé, les méthodes supportées sont les suivantes :
Active Directory : Kerberos, NTLM, authentification LDAP basique, portail captif
Des types de machines que vous gérez. Par exemple, avec des architectures client léger (serveurs TSE ou Citrix), utilisez uniquement des authentifications fortes.
Interaction avec l'utilisateur
Souhaitez-vous que vos utilisateurs aient à entrer leur mot de passe ?
Oui : portail captif sans NTLM, LDAP basique.
Non : NTLM, Kerberos, portail captif transparent pour l'utilisateur avec NTLM.
On parle parfois d'authentification transparente : l'expression "authentification transparente" s'entend au sens de "transparente pour l'utilisateur". On ne demande jamais à l'utilisateur de saisir son identifiant/mot de passe à la main, l'authentification se fait de façon automatique. Mais par nature une authentification n'est pas transparente pour l'application cliente (le proxy demande toujours explicitement au client de s'authentifier).
Sécurité
Quel niveau de sécurité est nécessaire pour votre organisation?
Il existe plusieurs mécanismes d'authentification, plus ou moins forts, c'est-à-dire avec un niveau de fiabilité plus ou moins élevé.
Mécanisme fort : l'utilisateur est authentifié pour chaque requête. Attention, ce mécanisme a de fortes contraintes : voir ci-dessous, Contraintes liées à la force de l'authentification.
Mécanismes d'authentification forts proposés par Olfeo : Kerberos, NTLM.
Mécanisme faible : à la première requête, la solution réalise une action d'authentification. Une fois l'authentification faite, la solution stocke la correspondance entre l'identifiant de l'utilisateur et son adresse IP, et par la suite elle fait simplement une identification en se basant sur l'adresse IP. La fiabilité de cette méthode diminue au cours du temps car l'adresse IP et l'identifiant sont susceptibles de ne plus se correspondre.
Mécanismes d'authentification faibles proposés par Olfeo : portail captif, authentification LDAP basique, portail public (plus disponible en v7).
Fiabilité des différentes méthodes
Dans tous les cas, gardez à l'esprit qu'aucune méthode ne garantit de façon absolue l'identité de la personne physique ayant effectué la navigation.
Identification, basée sur l'adresse IP | Une adresse IP identifie une machine et non un utilisateur. L'adresse IP n'est pas un critère fiable pour identifier un utilisateur :
|
Authentification utilisant directement ou indirectement le couple identifiant/mot de passe | Lorsqu'une authentification est faite ou que l'Olfeo reçoit un identifiant, il voit qu'une personne a utilisé un certain compte utilisateur pour surfer sur tel ou tel site internet, mais cela ne garantit pas que la personne physique ayant utilisé le navigateur est bien la personne titulaire de cet identifiant. Par exemple :
|
Contraintes liées à la force de l'authentification
Quel niveau de contrainte êtes-vous prêts à gérer?
Une authentification forte est contraignante. Avec des méthodes fortes, chaque requête est authentifiée :
Vous devrez définir des exceptions pour toutes les applications ne sachant pas s'authentifier, et le nombre d'exceptions peut être conséquent.
En outre, il sera nécessaire d'utiliser un Active Directory comme contrôleur de domaine, et il sera obligatoire de joindre la machine Olfeo au domaine Windows.
NTLM |
|
Kerberos |
|
Recommandation
Si vous êtes dans un environnement contrôlé (typiquement : postes fixes, dont les adresses IP sont attribuées au moment de l'ouverture matinale de la session utilisateur), et que votre besoin est d'appliquer des politiques de filtrage par identifiant, utilisez un portail captif. (Avec NTLM si vous souhaitez que l'utilisateur n'ait pas à entrer son mot de passe.) Cette solution vous permet de vous affranchir des contraintes imposées par les méthodes d'authentification fortes : coût réseau et/ou cryptographique, nombreuses exceptions à gérer au quotidien...
Résumé
Méthode | Annuaire utilisé pour authentifier/identifier | Transparent pour l’utilisateur ? | Authentification/identification réalisée par ? |
|---|---|---|---|
NTLM | AD | Oui (avec fallback explicite) | Proxy |
Kerberos AD | AD | Oui | Proxy |
LDAP basique | LDAP, AD | Non (fenêtre pop-up) | Proxy |
Portail captif | LDAP, AD | Non (page HTML) | Moteur de filtrage |
Portail captif NTLM | AD | Oui | Moteur de filtrage |
Authentification auprès du proxy HTTP
La page → → vous permet de définir dans quels cas le proxy HTTP demandera une authentification ou non, et quelle méthode d'authentification utiliser. Par exemple, vous pouvez :
Désactiver l'authentification pour les mises à jour automatiques d'un serveur qui n'accède à l'extérieur que pour des tâches connues et planifiées.
Mettre en place une authentification forte pour les utilisateurs connectés à un serveur TSE (ceux-ci ne peuvent pas être identifiés via leur adresse IP car seule celle du serveur TSE est reçue par le proxy).
Désactiver l'authentification pour les utilisateurs identifiés via le moteur de filtrage (portail captif).
Désactiver l'authentification pour les applications clientes ne supportant pas la méthode authentification sélectionnée.
Appliquer l'authentification à seulement certaines populations (plages d'IP, ou certains ports du proxy, afin que seules les populations qui envoient les flux sur ce port de l'Olfeo soient authentifiées).
Une seule méthode d'authentification peut être appliquée à un même proxy. Pouvoir s'authentifier auprès du proxy HTTP exige que le mode d'intégration soit en proxy explicite (car il y a échange direct d’informations entre le client et le proxy).
Si le proxy HTTP est configuré pour demander une authentification, c'est l'authentification auprès du proxy qui sera réalisée en premier, avant que les règles du moteur de règles ne soient traitées.
Pour l'authentification NTLM, si vous avez plusieurs annuaires AD, un seul annuaire peut être joint au domaine : vous devez mettre en place les relations d'approbation appropriées pour que l'authentification puisse se faire sur tous les annuaires AD.
Méthodes disponibles
Les méthodes d'authentification au proxy HTTP disponibles sont les suivantes :
Kerberos 2008 (pour AD 2008 et supérieur)
Basique - {nom de la zone d'authentification} : authentification LDAP basique. La liste proposera toutes les zones d'authentification créées à la page → → .
À la page → → , les choix présents dans la liste Méthode d'authentification dépendent des types d'annuaires avec lesquels votre Olfeo est synchronisé (NTLM et Kerberos Windows : annuaire Active Directory, LDAP basique : tous types d'annuaires (LDAP, AD, Novell). Kerberos natif ne nécessite pas d'annuaire).
NTLM permet d'authentifier des utilisateurs issus d'un annuaire Active Directory. NTLM réalise :
Une authentification NTLM SSP, transparente pour l’utilisateur, pour les utilisateurs utilisant un poste client membre du domaine ou ayant ouvert une session Windows avec leur compte de domaine. L'utilisateur est authentifié à chaque requête.
En solution de secours, une authentification NTLM basique, explicite pour l'utilisateur, pour les utilisateurs dont le poste n'est pas joint à l'AD. Une fenêtre pop-up s'affichera et l'utilisateur devra saisir son identifiant et son mot de passe.
NTLM authentifiera tout utilisateur de l'annuaire, cependant, pour que les politiques (ainsi que les quotas, l'outrepassement, etc) puissent être appliquées, il faut que les utilisateurs soient synchronisés dans l'Olfeo. Les utilisateurs non synchronisés seront authentifiés et pourront accéder à internet, mais ils seront considérés comme des utilisateurs inconnus et le moteur leur appliquera la politique par défaut.
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 Critères de choix. 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 Utiliser le serveur NTP de votre Contrôleur de Domaine.
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 :
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.
L'utilisateur tente d'accéder à une page web : le proxy reçoit sa requête.
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).
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.
Le proxy envoie ces informations à l'annuaire AD, qui les stocke. L'annuaire sait donc que l'utilisateur cherche à s'authentifier.
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).
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
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.
À la page → → , 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.
(Si vous entrez 30, l'Olfeo lance 30 processus NTLM SSP et 30 NTLM basiques.)
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.
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).
Cliquez sur le bouton Valider pour enregistrer les changements.
Kerberos AD permet d'authentifier des utilisateurs issus d'un annuaire Active Directory. Cette méthode réalise une authentification transparente pour l’utilisateur, pour les utilisateurs utilisant un poste client membre du domaine et ayant ouvert une session Windows avec leur compte de domaine. L'utilisateur est authentifié à chaque requête.
Kerberos AD authentifiera tout utilisateur de l'annuaire, cependant, pour que les politiques (ainsi que les quotas, l'outrepassement, etc) puissent être appliquées, il faut que les utilisateurs soient synchronisés dans Olfeo On premises. Les utilisateurs non synchronisés seront authentifiés et pourront accéder à internet, mais ils seront considérés comme des utilisateurs inconnus et le moteur leur appliquera la politique par défaut.
Attention, seul Kerberos 2008 est supporté.
Sensibilité à la casse
Kerberos est une méthode d'authentification sensible à la casse. Ainsi MARTIN@domain et martin@domain sont bien deux utilisateurs disctincts. S'il est possible de rendre une authentification Kerberos insensible à la casse, cette approche est déconseillée par Microsoft et n'est pas supportée par Olfeo On premises.
Modes d'intégration compatibles
L'authentification Kerberos AD 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 Kerberos est un mécanisme fort, qui présente de fortes contraintes :
Une infrastructure Active Directory est nécessaire, et Olfeo On premises 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 Kerberos pour ces utilisateurs.
L'authentification Kerberos présente un coût cryptographique important (ressources CPU). Un épuisement des ressources CPU se traduit par un grand nombre d'échecs d'authentification, ainsi que de gros ralentissements de surf pour les utilisateurs authentifiés.
Pour assurer une bonne performance, les serveurs DNS utilisés doivent être très réactifs.
L'authentification Kerberos n'est compatible avec Internet Explorer qu'à partir de la version 7.
Au niveau des postes client, c'est le FQDN du proxy qui doit être renseigné, et non son adresse IP.
Pour que l'authentification Kerberos AD fonctionne, Olfeo On premises doit être synchronisé avec le serveur NTP interne à l'AD ou avec le même serveur NTP que l'AD.
Le hostname de la machine ne peut excéder 15 caractères.
Mettre en place une authentification Kerberos AD
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, établissez les relations d'approbation appropriées pour que l'authentification prenne en compte tous les AD.
À la page → → , dans la liste Méthode d'authentification, sélectionnez Kerberos ou Kerberos 2008 (selon la version de votre annuaire : voir ci-dessus). La page affiche les options correspondantes et le champ Statut indique le domaine Windows auquel Olfeo On premises est joint.
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.
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).
Cliquez sur le bouton Valider pour enregistrer les changements.
L'authentification LDAP basique est une méthode d'authentification explicite : le navigateur ouvre une fenêtre pop-up demandant à l'utilisateur de saisir son identifiant et son mot de passe.
Une authentification LDAP basique peut authentifier des utilisateurs issus de n'importe quel type d'annuaire supporté par Olfeo On premises. Attention, même s'ils sont authentifiés par le proxy, les utilisateurs non synchronisés dans Olfeo On premises seront considérés comme des utilisateurs inconnus.
Modes d'intégration compatibles
L'authentification LDAP basique auprès du proxy HTTP 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 LDAP basique est un mécanisme d'authentification faible : sa fiabilité diminue au cours du temps.
Sécurité
Cette méthode doit être limitée à des cas d'usages spécifiques et très maîtrisés car elle est peu sécurisée : par définition, les identifiants et mots de passe circulent en clair sur le réseau.
Fonctionnement
L'utilisateur tente d'accéder à internet.
Le proxy envoie une demande d'authentification au navigateur (code 407).
Le navigateur ouvre une fenêtre pop-up demandant à l'utilisateur de saisir son identifiant et son mot de passe.
L’utilisateur saisit son identifiant et son mot de passe et clique sur OK.
Ces informations arrivent au proxy : celui-ci tente une authentification auprès de l'annuaire correspondant (il vérifie le mot de passe dans l'annuaire).
Si l'authentification réussit, le moteur de filtrage applique les règles et politiques concernant cet utilisateur : le cas échéant, l'utilisateur peut accéder au site demandé. L'utilisateur reste identifié auprès du proxy pendant 2h. L'association IP/identifiant est également utilisée pour le filtrage applicatif ou les proxys autres qu'HTTP.
Si l'authentification échoue, le navigateur renvoie la pop-up d'authentification indéfiniment, sauf si un compte invité a été défini dans la zone d'authentification (dans ce cas, l'utilisateur est authentifié sur le compte invité).
Mettre en place une authentification LDAP basique
Synchronisez le ou les annuaires contenant vos utilisateurs.
Créez une zone d'authentification contenant le ou les annuaires désirés.
À la page → → , sélectionnez cette zone d'authentification dans la liste. La page affiche les options correspondantes.
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.
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).
Cliquez sur Valider.
Avant de mettre en place l'authentification, il vous faudra d'abord définir une zone d'authentification nécessaire pour définitr
Une zone d'authentification est une liste de modules d'authentification (liés à un annuaire LDAP ou définissant des identifiant par défaut) qui sert à mettre en place :
l'authentification par portail captif
l'authentification LDAP basique.
Fonctionnement
Pour ces deux types d'authentification, lorsqu'un utilisateur essaye de se connecter à internet, il reçoit :
dans le cas de l'authentification LDAP basique, une fenêtre d'authentification ouverte par le navigateur.
dans le cas du portail captif, une page de connexion envoyée par Olfeo On premises.
Une fois que l'utilisateur a saisi son identifiant/mot de passe, Olfeo On premises vérifie ces informations : il tente une authentification auprès de l'annuaire correspondant (il vérifie le mot de passe dans l'annuaire).
Pour le portail captif, il vérifie d'abord que l'identifiant existe dans la liste des utilisateurs : le portail captif ne peut donc authentifier que des utilisateurs synchronisés dans Olfeo On premises .
Identifiant par défaut : compte invité
Pour gérer les cas où l'authentification a échoué, vous pouvez ajouter en fin de liste un compte invité servant d'identifiant par défaut.
Tous les utilisateurs dont l'authentification a échoué (utilisateur sans compte, erreur de mot de passe, aucune information saisie) seront connectés avec ce compte.
Utiliser un compte invité permet de définir des politiques par défaut pour ce portail captif différentes de celles de l'élément Configuration par défaut de la liste des utilisateurs. Le compte invité doit exister dans la liste des utilisateurs. Sans compte invité, si l'authentification échoue, le navigateur affichera à nouveau la page ou la popup de connexion.
Créer une zone d'authentification
Rendez-vous à la page → dans l'onglet Portails d'authentification.
Cliquez sur
(Ajouter un portail). La page de création s'ouvre.Avertissement
L'ordre est important : si par exemple le même identifiant existe dans 2 annuaires différents (par exemple, Administrateur), l'Olfeo On premises authentifiera l'utilisateur avec le premier compte trouvé. Cependant, vous ne pourrez pas changer l'ordre des modules d'authentification après leur création.
Saisissez un nom et une description.
Ajoutez un moyen d'authentification à l'aide du bouton
(+ Ajouter un module LDAP).Choisissez le Type de module :
LDAP : sélectionnez l'annuaire souhaité dans la liste.
Invité : dans le champ Identifiant de l'utilisateur, saisissez l'identifiant du compte invité qui servira d'identifiant par défaut (voir la section Fonctionnement ci-dessus). Ce compte doit exister dans la liste des utilisateurs. Le compte invité doit être le dernier moyen d'authentification dans la liste.
Cliquez sur Enregistrer. La fenêtre se ferme.
Portail captif
L'authentification par portail captif consiste à envoyer à l'utilisateur une page de connexion : l'utilisateur doit entrer son identifiant et son mot de passe, et ceux-ci sont vérifiés dans l'annuaire avant que l'utilisateur puisse accéder à internet.
 |
Vous pouvez personnaliser la page de connexion au portail captif envoyée par Olfeo On premises afin de l'adapter à la charte graphique de votre organisation.
Une fois l'utilisateur connecté au portail captif, l'authentification reste valable pour toute requête émanant de la machine. Toutes les applications qui ne savent pas s'authentifier fonctionneront tant que l'utilisateur restera connecté. Il n'est donc pas nécessaire de définir d'exceptions au portail captif.
Surrogate NTLM
Si vous utilisez un annuaire Active Directory, vous pouvez activer la fonctionnalité Surrogate NTLM afin de mettre en place une authentification transparente pour l'utilisateur. Une seule action d'authentification est réalisée avant de passer à l'identification, mais cette authentification est faite directement par NTLM et l'utilisateur ne reçoit ni de pop-up ni de page de portail captif. Une page de connexion au portail captif est envoyée que dans le cas où l'authentification NTLM échouerait.
Cette fonctionnalité est une très bonne alternative au mécanisme d'authentification forte NTLM géré par le proxy. D'une part, elle permet d'avoir un mécanisme transparent pour l'utilisateur avec une intégration connecteur où les flux ne passent pas par un proxy Olfeo. Plus généralement, la solution Surrogate NTLM permet de ne pas avoir d’exceptions à gérer, et fait baisser le coût réseau de l'authentification. Il faut cependant tenir compte des limitations suivantes :
Vous devez utiliser un annuaire Active Directory et Olfeo On premises doit être joint au domaine Windows.
Olfeo On premises doit être déclaré comme membre de la zone locale du navigateur.
Configuration dans Firefox : à la page about:config, entrez l'adresse IP du proxy dans le paramètre network.automatic-ntlm-auth.trusted-uris.
Configuration dans Chrome et Internet Explorer : dans les Options Internet, dans l'onglet Sécurité, cliquez sur Intranet local. Cliquez sur Sites, puis sur Avancé. Ajoutez l'adresse IP d'Olfeo On premises à la liste.
Modes d'intégration compatibles
Le Surrogate NTLM peut être utilisé avec tous les types d'intégration.
Contraintes et limitations
Le portail captif est un mécanisme d'authentification faible (LDAP basique) dont la fiabilité diminue au cours du temps.
L'authentification par portail captif ou de type Surrogate NTLM est réalisée par le moteur de filtrage. Elle est indépendante de toute authentification faite au niveau du proxy HTTP, et n'est pas compatible avec elle. Si vous avez configuré le proxy HTTP pour demander une authentification, définissez une exception pour les utilisateurs de ces méthodes. Sans cela, les utilisateurs ne seraient jamais confrontés à la page de portail captif ou Surrogate NTLM : si l'authentification proxy échouait, le proxy utiliserait la méthode de fallback correspondante.
L'authentification par portail captif ou de type Surrogate NTLM n'est pas pertinente pour gérer des serveurs TSE ou Citrix (car l'adresse IP du serveur est la seule récupérée par Olfeo On premises) : utilisez plutôt un mécanisme d'authentification forte (NTLM, Kerberos (de préférence).
Le portail captif ou Surrogate NTLM ne peut authentifier que des utilisateurs synchronisés dans Olfeo On premises.
Fonctionnement
Le portail captif ou Surrogate NTLM fonctionne selon 2 phases : pour la première requête reçue, Olfeo On premises réalise une action d'authentification, puis pour toutes les autres ne fait plus que des actions d'identification.
Lorsque l'utilisateur tente d'accéder à internet, le moteur de filtrage lui envoie une page demandant son identifiant et son mot de passe (la page de connexion au portail captif ou le handshake NTLM).
L'utilisateur entre son identifiant et son mot de passe ou le système répond automatiquement au handshake NTLM : Olfeo On premises vérifie que l'identifiant existe dans la liste des utilisateurs, puis vérifie les informations dans l'annuaire.
Si l'authentification échoue, Olfeo On premises renvoie la page de connexion, sauf si un compte invité a été défini dans la zone d'authentification (dans ce cas, l'utilisateur est authentifié sur le compte invité).
Si l'authentification est validée, la requête est envoyée au moteur de filtrage, qui applique les règles et politiques correspondant à l'utilisateur.
Une fois l'authentification faite, Olfeo On premises stocke en interne la correspondance entre l'identifiant de l'utilisateur et son adresse IP.
Pour toutes les autres requêtes : une fois les informations d'authentification stockées, et tant que le stockage dure, lorsqu’une requête est reçue, Olfeo On premises se base sur l'adresse IP pour identifier l'utilisateur.
Déconnexion :
Lorsque l'utilisateur se connecte au portail captif ou Surrogate NTLM, une fenêtre popup contenant un lien de déconnexion peut s'ouvrir. Si le navigateur bloque les popups, on affiche pendant quelques secondes une page d'information à ce sujet avant de rediriger vers la page demandée.
Si l'utilisateur n'a pas la popup de déconnexion (si celle-ci a été bloquée ou il s'il l'a fermée), il peut se déconnecter en se rendant à la page
http://keyword.olfeo.com/logout.L'utilisateur est automatiquement déconnecté du portail captif au bout de 10 minutes d'inactivité.
Mise en place
Synchronisez le ou les annuaires contenant vos utilisateurs.
Créez une zone d'authentification contenant le ou les annuaires désirés.
Rendez-vous à la page du moteur de règles en suivant les menus → .
Dans l'onglet Accès du tableau du haut, ajoutez une règle grâce au bouton "ajouter"
en bas à gauche du tableau.Dans la colonne Source, définissez pour quels utilisateurs la méthode d’authentification s’appliquera. .
Dans la colonne Action, cliquez sur l'icône
. La fenêtre Action s'ouvre.Dans le menu Sélectionner, choisissez Portail captif / Surrogate NTLM.
Dans le menu Portail, sélectionnez la zone d'authentification désirée.
Si vous souhaitez que l'authentification soit transparente pour l'utilisateur, cochez la case Surrogate NTLM. Voir la section ci-dessus, Portail Captif.
Cliquez sur Valider pour enregistrer les changements. La fenêtre Action se ferme.
Cliquez sur Valider en bas à droite du tableau pour enregistrer les changements.
Si le déchiffrement SSL n'est pas activé, activez les pages de blocage en HTTPS : en effet, si la première requête de l'utilisateur est une requête HTTPS, son navigateur attendra une réponse en HTTPS. Si le déchiffrement SSL est activé, aucun paramétrage n'est nécessaire.
Il est possible que vous deviez gérer plusieurs populations différentes : issues de différents annuaires, situées sur des réseaux séparés ou sur des sites différents. Vous pouvez utiliser des méthodes d'authentification ou d'identification différentes suivant les populations.
Dans ce cas, faites attention à l'interaction entre les différentes méthodes mises en place, afin que l'une n'empêche pas l'autre de fonctionner.
Interaction entre les différentes méthodes
Le proxy HTTP ne peut attendre qu'une seule méthode d'authentification à la fois. Par contre, vous pouvez définir plusieurs méthodes d'identification au niveau du moteur de filtrage.
Il est possible de configurer à la fois une authentification au proxy HTTP et des règles du moteur, à condition d'ajouter des exceptions à l'authentification proxy. En effet, si le proxy HTTP est configuré pour demander une authentification, c'est l'authentification auprès du proxy qui est réalisée en premier, avant que les règles du moteur de règles ne soient traitées.
Conflits proxy HTTP / moteur de filtrage :
Si le proxy HTTP est paramétré pour demander une authentification, vous devez définir des exceptions pour toutes les populations concernées par une méthode d'identification gérée par le moteur de filtrage.
Exemple : on veut envoyer le portail captif à certains utilisateurs : il faut définir une exception à l'authentification au proxy HTTP pour ces utilisateurs. Sans cela, ils ne pourront pas recevoir la page de connexion au portail captif (l'authentification sera considérée comme échouée).
Pour exclure des populations de l’authentification au proxy HTTP, dans les règles d'authentification, définissez des plages d'IPs (colonne Source), ou des ports d'écoute du proxy (colonne Ports du proxy).
Élément authentifiant
Quel élément de l'Olfeo gère quelle méthode d'authentification?
Proxy HTTP (intégration en mode proxy explicite uniquement) |
|
Moteur de filtrage (tous modes d'intégration) |
|