Onglet Proxy authentifié : 4 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/KERBEROS
Il s'agit d'une authentification transparente pour les postes utilisateurs Windows intégrés dans un domaine Active Directory[1].
Cette configuration est à choisir si vous disposez d'un serveur Scribe ou Horus en mode AD ou d'un serveur Microsoft AD.
Si l'authentification NTLM/KERBEROS est activée sur le proxy, le Nom de machine, qui se paramètre dans l'onglet Général, ne peut être supérieur à 15 caractères.
En effet un nom de machine supérieur à 15 caractères rend impossible l'intégration du module au domaine AD.
Truc & astuce
À partir d'EOLE 2.8.1,
- il n'est plus obligatoire de fournir explicitement l'
Adresse IP du contrôleur de domaine KERBEROS; - il est possible de désactiver la limitation de l'authentification au DC renseigné dans
Nom du contrôleur de domaine KERBEROS.
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
À partir d'EOLE 2.8.1, lorsque l'authentification est configurée en mode NTLM/KERBEROS, les postes hors domaine peuvent utiliser directement le proxy authentifié.
Contrairement aux versions précédentes pour lesquelles il était recommandé d'activer le proxy NTLM, les navigateurs proposent nativement une fenêtre d'authentification dans laquelle l'utilisateur saisit uniquement ses login et mot de passe Active Directory.
Authentification NTLM/SMB
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 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 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)