Onglet Proxy authentifié : 5 méthodes d'authentification

EOLE propose un mécanisme d'authentification web via un proxy.

Tous les accès web (HTTP et HTTPS) nécessiteront alors une phase d'authentification.

Cette fonctionnalité offre deux avantages :

  • il sera possible de savoir quel utilisateur a accédé à une ressource particulière ;
  • il sera possible d'appliquer des politiques de filtrage pour chaque utilisateur.

Pour profiter de cette fonctionnalité, il faut activer l'authentification du proxy dans l'onglet Authentification : Activer l'authentification web (proxy).

Cinq méthodes d'authentification sont alors disponibles dans l'onglet Proxy authentifié.

Authentification NTLM/SMB

Il s'agit d'une authentification transparente pour les postes utilisateurs Windows intégrés dans un domaine Samba.

Cette configuration est à choisir si vous disposez d'un serveur pédagogique Scribe ou d'un serveur administratif Horus.

Cette méthode d'authentification nécessite l'intégration du serveur au domaine Samba.

L'intégration peut être réalisée lors de l'instanciation du module en répondant oui à la question suivante :

Voulez-vous (ré)intégrer le serveur au domaine maintenant ?

Truc & astuce

Si la configuration de l'authentification est réalisée après l'instanciation, il est possible de relancer l'intégration du serveur à tout moment à l'aide du script enregistrement_domaine.sh.

Remarque

L'enregistrement au domaine étant proposé lors de l'instanciation du module, de ce fait l'authentification NTLM/SMB n'est plus proposée pour une deuxième authentification.

Remarque

La syntaxe pour utiliser le proxy authentifié avec une machine hors domaine est domaine\login mais elle ne fonctionne pas avec toutes les versions de navigateurs.

Attention

L'authentification NTLM/SMB nécessite l'application de la clé de registre suivante sur les clients Windows Vista et Windows Seven :

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]

"LMCompatibilityLevel"=dword:00000001

Pour plus d'informations, consulter : http://technet.microsoft.com/en-us/library/cc960646

Authentification NTLM/SMB poste hors domaine

En mode normal, l'authentification NTLM[1] peut être facilitée par l'utilisation d'un proxy. Le proxy NTLM proposé par EOLE utilise le logiciel libre Cntlm[2].

Le service proxy NTLM Cntlm est pré-installé sur les modules Amon et AmonEcole.

Cette méthode permet d'utiliser l'authentification NTLM sur des machines qui ne savent pas le gérer. Ce qui est le cas des machines hors domaine.

À partir de la version 2.6.1, la configuration a été adaptée afin que Cntlm redirige les requêtes provenant d'une interface vers le proxy qui écoute sur cette même interface. Le service cntlm ne supportant pas nativement cette fonctionnalité, il est donc remplacé par le service eole-cntlm (service eole-cntlm start/stop/status) qui gère le proxy Cntlm uniquement pour les interfaces pour lesquelles le service est nécessaire.

Remarque

Une fois activé, le choix peut être fait de désactiver le proxy NTLM sur une interface donnée, pour cela il faut se rendre en mode expert dans l'onglet de l'interface à paramétrer.

Pour activer le proxy NTLM Cntlm il faut passer la variable Activer le proxy NTLM à oui.

Remarque

Le port utilisé par défaut par Cntlm est 3127, il est modifiable en mode expert.

Pour continuer à profiter de l'authentification transparente, les postes intégrés au domaine ne doivent pas passer par Cntlm.

Les postes intégrés au domaine doivent donc utiliser le port 3128 pour passer par le proxy et les postes nomades (hors domaine) doivent utiliser le port 3127 pour passer par Cntlm.

Dans le cas où la découverte automatique du proxy avec WPAD est activée, le port proposé par défaut est automatiquement celui du proxy NTLM Cntlm (3127 par défaut).

Authentification NTLM/KERBEROS

Il s'agit d'une authentification transparente pour les postes utilisateurs Windows intégrés dans un domaine Active Directory.

Cette méthode d'authentification nécessite l'intégration du serveur au royaume Kerberos.

L'intégration peut être réalisée lors de l'instanciation du module en répondant oui à la question suivante :

Voulez-vous (ré)intégrer le serveur au domaine maintenant ?

Truc & astuce

Si la configuration de l'authentification est réalisée après l'instanciation, il est possible de relancer l'intégration du serveur à tout moment à l'aide du script enregistrement_domaine.sh.

Authentification NTLM/KERBEROS poste hors domaine

En mode normal, l'authentification NTLM[1] peut être facilitée par l'utilisation d'un proxy. Le proxy NTLM proposé par EOLE utilise le logiciel libre Cntlm[2].

Le service proxy NTLM Cntlm est pré-installé sur les modules Amon et AmonEcole.

Cette méthode permet d'utiliser l'authentification NTLM sur des machines qui ne savent pas le gérer. Ce qui est le cas des machines hors domaine.

À partir de la version 2.6.1, la configuration a été adaptée afin que Cntlm redirige les requêtes provenant d'une interface vers le proxy qui écoute sur cette même interface. Le service cntlm ne supportant pas nativement cette fonctionnalité, il est donc remplacé par le service eole-cntlm (service eole-cntlm start/stop/status) qui gère le proxy Cntlm uniquement pour les interfaces pour lesquelles le service est nécessaire.

Remarque

Une fois activé, le choix peut être fait de désactiver le proxy NTLM sur une interface donnée, pour cela il faut se rendre en mode expert dans l'onglet de l'interface à paramétrer.

Pour activer le proxy NTLM Cntlm il faut passer la variable Activer le proxy NTLM à oui.

Remarque

Le port utilisé par défaut par Cntlm est 3127, il est modifiable en mode expert.

Pour continuer à profiter de l'authentification transparente, les postes intégrés au domaine ne doivent pas passer par Cntlm.

Les postes intégrés au domaine doivent donc utiliser le port 3128 pour passer par le proxy et les postes nomades (hors domaine) doivent utiliser le port 3127 pour passer par Cntlm.

Dans le cas où la découverte automatique du proxy avec WPAD est activée, le port proposé par défaut est automatiquement celui du proxy NTLM Cntlm (3127 par défaut).

Authentification LDAP

Il s'agit d'une authentification non transparente s'appuyant sur un annuaire de type OpenLDAP.

Ce type d'authentification est recommandé pour les postes hors domaine.

En mode normal, il est possible de déclarer un annuaire de secours.

Cet annuaire est interrogé uniquement si le premier ne répond pas.

Cette fonctionnalité est recommandée dans le cas d'annuaires répliqués.

Authentification LDAP (Active Directory)

Il s'agit d'une authentification non transparente s'appuyant sur un annuaire de type Active Directory.

Ce type d'authentification est recommandé pour les postes hors domaine.

Authentification sur Fichier local

Il s'agit d'une authentification non transparente s'appuyant sur un fichier de comptes locaux.

Ce type d'authentification peut être utilisé dans une petite structure, comme une école, qui ne disposerait pas vraiment d'un réseau local.

Pour cette authentification, le fichier utilisé par défaut est : /etc/squid/users

Il doit être au format htpasswd et il peut être peuplé en utilisant la commande suivante :

# htpasswd -c /etc/squid/users <compte>

Attention

En mode conteneur (module AmonEcole par exemple), le fichier /etc/squid/users se trouve dans le conteneur proxy :

# ssh proxy

# htpasswd -c /etc/squid/users <compte>

ou

# CreoleRun "htpasswd -c /etc/squid/users <compte>" proxy

Désactivation de l'authentification sur une interface

Pour chacune des interfaces (hors interface 0 si plusieurs interfaces sont configurées), il est possible d'activer/désactiver l'authentification proxy.

Par exemple, pour désactiver l'authentification proxy uniquement sur le réseau de l'interface 2, il faut aller dans l'onglet Interface-2 et répondre non à la question Activer l'authentification sur cette interface (s'applique aussi aux VLAN).

Notes techniques

Les fichiers de logs spécifiques au premier type d'authentification sont les suivants :

  • /var/log/rsyslog/local/squid/squid1.info.log → 1ère instance de squid
  • /var/log/rsyslog/local/e2guardian/e2guardian0.info.log → 1ère instance de e2guardian (filtre web 1)
  • /var/log/rsyslog/local/e2guardian/e2guardian1.info.log → 2ème instance de e2guardian (filtre web 2)