Configuration du module AmonEcole
La phase de configuration s'effectue au moyen de l'interface de configuration du module, celle-ci se lance avec la commande
gen_config.Cet outil permet de renseigner et de stocker en un seul fichier (
config.eol) tous les paramètres nécessaires à l'utilisation du serveur dans son environnement (l'adresse IP de la première interface réseau est un exemple de paramètre à renseigner). Ce fichier sera utilisé lors de la phase d'instanciation.Suivant les modules, le nombre de paramètres à renseigner est plus ou moins important.
Cette phase de configuration peut permettre de prendre en compte des paramétrages de fichiers de configuration de produits tels que Squid[1], e2guardian[2], etc.
Configuration généralités
La configuration suit la phase d'installation du serveur.
Il s'agit de collecter et de renseigner les paramètres nécessaires au fonctionnement du serveur.
Les paramètres saisis peuvent être internes au serveur (par exemple le nombre d'interfaces réseau) ou externes (par exemple l'adresse du DNS[3], l'adresse du serveur de temps NTP[4], ...). Cette étape nécessite une bonne connaissance de l'architecture réseau dans laquelle sera installé le serveur.
À condition d'avoir renseigné les valeurs obligatoires vous pouvez enregistrer la configuration pour l'effectuer en plusieurs temps.
On obtient alors un fichier config.eol, dans lequel sont stockées toutes les valeurs saisies.
Remarque
La configuration du module porte aussi bien sur les paramètres propres à EOLE que sur le paramétrage d'applications tierces embarquées dans le module. On retrouve par exemple les paramètres du fichier squid.conf dans l'interface de configuration du module.
Il existe deux modes de configuration :
mode autonome
Le mode autonome est l'utilisation de l'interface de configuration du module pour paramétrer le serveur.
À son lancement, l'interface de configuration du module récupère dans les différents dictionnaires, les variables, leur valeur par défaut et les libellés qui seront affichés dans l'interface.
Après instance ou reconfigure, si votre adresse IP est autorisée pour l'administration du serveur, vous bénéficier d'un accès distant à l'interface de configuration du module au travers d'un navigateur web.
mode Zéphir
Le mode Zéphir consiste à configurer le module au travers de l'application Zéphir depuis le module du même nom. Ce module permet la mise en place d'un serveur de gestion de parc de serveurs EOLE. Par le mécanisme de variante, vous pouvez avoir des configurations pré-définies pour un ensemble de serveurs.
Configuration en mode autonome
La configuration en mode autonome signifie que la configuration est réalisée directement sur le serveur à l'aide de l'interface de configuration du module.
Ce mode est recommandé pour la configuration d'un petit nombre de serveurs.
La méthode autonome permet d'exporter et/ou d'importer le fichier config.eol.
Il est donc possible d'utiliser le fichier config.eol d'un serveur en production pour en instancier un nouveau.
Truc & astuce
En mode autonome le fichier config.eol peut être préparé avant l'installation du serveur et peut être confié à une personne tierce, comme par exemple la personne en charge d'installer le serveur dans l'établissement. Celui-ci n'aura plus qu'à instancier le serveur.
L'interface de configuration du module se lance avec la commande : gen_config.
Une fois la commande gen_config lancée, comme indiqué dans la mire, vous devez ouvrir une session avec l'utilisateur root et le mot de passe aléatoire généré à l'installation.
Ce mot de passe sera bien évidement changé lors de l'étape d'instanciation.
Lors de son premier lancement l'interface de configuration du module propose un assistant de configuration rapide.
Seules les variables indispensables pour un fonctionnement minimum sont proposées dans l'assistant.
L'interface se découpe en quatre zones :
la zone Menu ;
la zone Onglet ;
la zone Formulaire ;
la zone Validation.
Certains onglets sont générés dynamiquement en fonction des éléments activés ou non dans le formulaire.
Les onglets correspondant au mode expert apparaissent si ce dernier est activé.
Accès distant
Accès distant via le port 443
Après instance ou reconfigure, l'interface de configuration du module est accessible pour les adresses IP autorisées à administrer le serveur via SSH, depuis un navigateur web en HTTPS à l'adresse suivante :
https://<adresse_serveur>/genconfig/
En fonction des certificats mis en place sur le module, il peut s'avérer nécessaire de les accepter pour accéder à l'interface.
La variable experte Activer l’interface de configuration du module (GenConfig) de l'onglet Services permet de désactiver la publication de l'interface sur le port 443.
Truc & astuce
Pour autoriser l'accès distant depuis une ou plusieurs adresses IP, il faut le déclarer explicitement dans l'onglet Interface-n de l'interface de configuration du module en passant la variable Autoriser les connexions SSH à oui.
Accès distant via le port historique
Après instance ou reconfigure, l'interface de configuration du module est accessible pour les adresses IP autorisées à administrer le serveur via SSH, depuis un navigateur web en HTTPS à l'adresse suivante :
https://<adresse_serveur>:7000/genconfig/
Ne pas oublier d'utiliser le protocole HTTPS et de préciser le numéro de port 7000.
En fonction des certificats mis en place sur le module, il peut s'avérer nécessaire de les accepter pour accéder à l'interface.
Truc & astuce
Pour autoriser l'accès distant depuis une ou plusieurs adresses IP, il faut le déclarer explicitement dans l'onglet Interface-n de l'interface de configuration du module en passant la variable Autoriser les connexions SSH à oui.
Remarque
Cette fonctionnalité est désactivable dans l'onglet Eoleflask en mode expert.
Passer la variable En écoute depuis l'extérieur à non.
La zone Menu
La zone de Menu, en haut de l'interface, propose les items suivants :
Fichier : gestion de la configuration
Aide : permet de lancer l'assistant et d'afficher l'aide de l'application
Mode : choix des modes de configuration à activer
Langue : choix de la langue pour l'interface
Session : permet de se déconnecter.
Sous-menu Fichier
Enregistrer la configuration
Recharger/Annuler les modifications
Re-syncroniser la configuration
Exporter la configuration
Importer une configuration
Quitter GenConfig
Enregistrer la configuration permet l'enregistrement du paramétrage dans le fichier config.eol du serveur.
Recharger/Annuler les modifications permet de revenir à l'état initial à l'ouverture.
Re-synchroniser la configuration permet de récupérer les informations stockées en session sur le serveur si une coupure arrivait pendant la configuration.
Exporter la configuration propose le téléchargement du fichier config.eol du serveur.
Importer une configuration permet de téléverser un fichier config.eol sur le serveur.
Sous-menu Aide
Assistant
Légende
L'assistant bascule l'interface de configuration du module en mode Basique et propose une page synthétique qui récapitule l'essentiel des variables à configurer.
Il est démarré par défaut si aucun fichier de configuration n'a été trouvé.
La légende présente un récapitulatif des différentes icônes que l'on peut rencontrer dans l'interface.
Sous-menu Mode
Debug
Basique
Normal
Expert
Le mode Debug permet d'afficher le nom des variables utilisées dans les dictionnaires (en rouge à droite du libellé). Le mode Debug est cumulable avec chacun des autres modes.
Le mode Basique n'affiche que les onglets et variables indispensables permettant une configuration rapide du module, il est le mode par défaut.
Le mode Normal active les onglets et les variables pour une configuration personnalisée du module.
Le mode Expert active les onglets et les variables pour une configuration avancée.
Ce mode demande une très bonne maîtrise du système GNU/Linux et de ses composants.
Par exemple, pour le module Amon, l'activation du mode expert fait apparaître les onglets Filtrage web, Proxy parent, Squid, Zone-dns, ...).
Sous-menu Langue
Français
Anglais
Langue permet de choisir la langue utilisé dans l'interface.
Sous-menu Session
Connecté comme
Déconnexion
Session permet de connaître l'utilisateur courant et de se déconnecter.
La zone Onglet
La zone Onglet, côté gauche de l'interface, présente des onglets de trois types :
les onglets de base sont systématiquement présents au lancement de l'outil
gen_config;les onglets optionnels s'affichent si un paramètre du formulaire est activé.
Exemple : si dans l'onglet
Servicesle paramètreActiver DHCPest passé àoui, l'ongletDhcps'affiche dynamiquement au même niveau que les onglets de base ;
les onglets experts correspondent essentiellement au paramétrage de fichiers de configuration d'outils spécifiques.
Ils sont disponibles si le mode Expert est activé.
L'onglet en cours est en sous-brillance, dans l'image ci-dessous l'onglet Dhcp est actif.
La zone Formulaire
La zone Formulaire est la partie centrale de l'interface. Elle regroupe les paramètres de l'onglet activé.
Le bouton Modifier ou un clic dans le champ de saisie permet de modifier la valeur.
La modification de la valeur affiche deux boutons supplémentaires permettant l'annulation des modifications (pictogramme en forme de croix) et l'autre la réinitialisation de la valeur par défaut (pictogramme en forme de flèche tournant dans le sens anti-horaire).
Truc & astuce
La légende de chaque icône se trouve dans l'aide de l'interface : Aide / Légende.
Regroupement des paramètres par bloc
Les paramètres de chaque onglet sont répartis dans des blocs thématiques.
Chaque bloc regroupe un ou plusieurs paramètres.
Les variables obligatoires
Les variables obligatoires sont des variables pour lesquelles il est nécessaire de spécifier une valeur, sans quoi il sera impossible d'enregistrer le fichier de configuration.
Les variables obligatoires se distinguent à l'aide du pictogramme en forme d'étoile placé devant le champ.
Les variables des modes basiques, normales et expertes
Le mode détermine l'affiche de variable plus ou moins complexes : basiques, normales ou expertes.
Lorsque l'on passe d'un mode à l'autre, un ensemble de nouvelles variables peuvent apparaître ou disparaître de l'interface.
Ces variables sont identifiables grâce au pictogramme B, N ou E qui précède l'étiquette de la variable.
Un code couleur est également utilisé pour le pictogramme et le libellé :
vert pour basique ;
gris pour normale ;
rouge pour experte.
Les variables simples
La valeur des variables simples s'affiche en couleur sur fond blanc :
bleu pour une variable dont la valeur est la valeur par défaut ;
noir pour une variable dont la valeur est modifiée par l'utilisateur et validée ;
gris pour une variable verrouillée (dans le cas d'une ré-édition de la configuration après instanciation du module).
Les variables multiples
Certains paramétrages peuvent accueillir plusieurs valeurs, nous parlons alors de variable multiple.
Les variables multiples se présentent sur fond coloré :
bleu pour une variable dont la valeur est la valeur par défaut ;
noir pour une variable dont la valeur est modifiée par l'utilisateur et validée ;
gris pour une variable sans valeur.
Pour ajouter une valeur, il faut cliquer sur modifier pour faire apparaître le champ de saisie.
Pour supprimer une valeur, il faut d'abord cliquer sur modifier puis sur la croix à droite du champ.
Les variables multiples groupées
Certains groupes de variables réunies au sein d'un même cartouche peuvent accueillir plusieurs valeurs, nous parlons alors de variable multiple groupée.
Les variables multiples groupées se présentent sur fond blanc dont la valeur s'affiche en couleur :
bleu pour une variable dont la valeur est la valeur par défaut ;
noir pour une variable dont la valeur est modifiée par l'utilisateur et validée.
Les variables brouillées
Certaines variables sensibles ont un affichage brouillé dès lors qu’elles sont validées. Le contenu de la variable est remplacé par une série de points.
Ces variables sont de nouveau visibles lorsqu’elles sont éditées.
Validation des variables
Suivant les variables, il est possible que des validations soient faites.
Si la valeur ne correspond pas aux critères de validation de l'interface de configuration du module, un message d'erreur avertira l'utilisateur.
Il existe de nombreux critères de validation : le type de valeur, leur construction (séparateur), etc.
La zone Validation
Cette zone est visible lors de l'enregistrement des modifications. Elle propose un récapitulatif des informations saisies.
Elle affiche également les variables obligatoires qui ne sont pas renseignées.
Lors d'une réédition de la configuration cette zone ne montre que les changements qui ont eu lieu.
Enregistrer la configuration
L'utilisation du mode assistant propose l'enregistrement de la configuration en bas de page avec le bouton Enregistrer la configuration.
Dans les autres cas l'enregistrement de la configuration se fait en cliquant sur Enregistrer la configuration dans le menu Fichier.
Une page récapitulative propose l'enregistrement de la configuration en bas de page avec le bouton Enregistrer la configuration.
Truc & astuce
Un fichier config.eol.bak est sauvegardé dans le répertoire /etc/eole/ à la fin de l'instanciation et à la fin de la reconfiguration du serveur.
Cela permet de conserver la dernière configuration fonctionnelle du serveur.
À chaque reconfiguration du serveur un fichier config.eol.bak.1 est généré. Celui-ci est une copie de la configuration fonctionnelle de l'état précédant.
S'il existe une différence entre config.eol et config.eol.bak c'est que la configuration du serveur a été modifiée mais qu'elle n'a pas encore été appliquée.
L'utilisation de la nouvelle interface de configuration du module sur une petite configuration peut poser problème.
Cela se traduit par des erreurs de timeout[6] avec Nginx ou une erreur 504 (méthode not allowed) dans l'interface de configuration du module et [ERROR] WORKER TIMEOUT (pid:XXXX) dans les logs de Gunicorn[7].
Truc & astuce
La valeur de timeout peut être changée à la ligne timeout = '120' dans le fichier de configuration de eoleflask : /etc/eole/flask/eoleflask.conf. Celui-ci n'est pas templatisé et n'est donc pas écrasé en cas de reconfiguration du serveur.
Le changement de valeur doit être suivi d'une relance du service eoleflask :
# CreoleService eoleflask restart
Le mode Debug
Dans la zone de Menu le sous-menu Mode propose le mode Debug.
Le mode Debug permet d'afficher le nom des variables utilisées dans les dictionnaires (en rouge à droite du libellé).
Les valeurs des variables peuvent être modifiées par différentes applications.
En gris, à droite du nom de la variable, est précisé le nom de l'application et/ou de l'action ayant modifié en dernier sa valeur :
default: valeur par défaut et/ou calculée (n'est jamais enregistrée dans le fichierconfig.eol) ;forced: valeur par défaut enregistrée d'office pour les variables à verrouillage automatique (auto_freeze) ou à enregistrement obligatoire (auto_save) ;gen_config: valeur modifiée par l'interface de configuration du module ;
creoleset: valeur modifiée avec la commandeCreoleSet;zephir: valeur modifiée pour un serveur donné dans l'interface web de Zéphir ;variante: valeur par défaut de la variante Zéphir ;module: valeur par défaut du module dans Zéphir ;import: valeur récupérée depuis un fichier de configuration importé dans l'interface de configuration du module ;zephir_import: valeur récupérée depuis un fichier de configuration importé dans l'interface web de Zéphir ;upgrade: valeur récupérée depuis un fichier de configuration d'une version antérieure d'EOLE ;zephir_upgrade: valeur récupérée depuis un fichier de configuration d'une version antérieure d'EOLE dans l'interface web de Zéphir.
Complément
Cette information est également enregistrée dans le fichier de configuration config.eol du module.
La clé associée à cette valeur est owner :
"numero_etab": {"owner": "gen_config", "val": "0000000A"}
Le mode Debug permet également d’afficher les valeurs des variables verrouillées de type password, dont l’affichage est normalement brouillé.
Lorsque le champ est trop petit par rapport à la valeur, celle-ci est tronquée. L’info-bulle qui s’affiche au survol du champ permet toutefois de prendre connaissance de la valeur complète.
Édition synchronisée avec l'application Zéphir
Lorsque le module est enregistré sur un module Zéphir, il est possible de gérer la configuration en mode synchronisé.
Pour cela, il est nécessaire de se connecter à l’application de configuration du module avec un compte de l’application Zéphir disposant des droits suffisants (Lecture et Configuration et action sur les serveurs). La mire de connexion de l’application de configuration du module propose cette option.
En mode synchronisé, la configuration locale du module est comparée à la configuration associée au module dans l’application Zéphir.
En cas de différence, une page spéciale est affichée avant de pouvoir accéder à la modification de la configuration.
Cette page indique que la configuration a correctement été importée depuis l’application Zéphir en rappelant l’ID associé au module dans cette même application, ainsi que l’adresse du serveur Zéphir interrogé.
Cette page avertit également que le mode synchronisé, activé depuis la mire de connexion, implique que les modifications apportées à la configuration seront appliquées localement et sur l’application Zéphir.
Cette synchronisation interdisant la divergence entre la configuration appliquée localement et la configuration associé au module dans l’application Zéphir, la page propose de choisir quelle version, globalement, doit devenir la nouvelle référence en l’utilisant pour remplacer l’autre.
Les différences sont affichées sous la forme d’un tableau avec l’origine en colonnes et les variables en lignes. Seules les variables dont les valeurs sont différentes localement et dans l’application Zéphir sont affichées.
Sous la colonne de gauche, reprenant les valeurs locales, le bouton rouge permet de remplacer les valeurs de l’application Zéphir par ces valeurs locales.
Symmétriquement, sous la colonne de droite, reprenant les valeurs de l’application Zéphir, le bouton bleu permet de remplacer les valeurs locales par ces valeurs de l’application Zéphir.
Dans le cas très particulier où la synchronisation n’est finalement pas souhaitée, la page des différences permet de se déconnecter et de quitter ainsi le mode synchronisé et donner l’occasion de se connecter avec un compte d’administration local, avant que les configurations, locale et distante, ne soient altérées.
Attention
Les droits attribués aux utilisateurs de l’application Zéphir dissocient la lecture et la sauvegarde de la configuration. Ainsi, le droit Lecture est nécessaire et suffisant pour se connecter en mode synchronisé et afficher la configuration. Par contre il ne permet pas de mettre à jour la configuration associée au module sur l’application Zéphir.
FAQ
- Accéder à l'interface de configuration du module depuis un navigateur web
- Revenir au dernier état fonctionnel du serveur
- Comment modifier la valeur d'une variable verrouillée
- Erreurs de timeout ou erreur 504 avec Nginx
- Interface de configuration en mode console
- Consultation des mots de passe dans l’interface de configuration
Certaines interrogations reviennent souvent et ont déjà trouvées une ou des réponses.
Accéder à l'interface de configuration du module depuis un navigateur web
Je n'arrive pas à accéder à l'interface de configuration du module depuis mon navigateur web.
Truc & astuce
Pour pouvoir accéder à l'interface de configuration du module depuis un navigateur web il faut que les deux pré-requis suivants soient respectés :
activer l'écoute de l'interface sur l'extérieur en passant la variable
En écoute depuis l'extérieuràouidans l'ongletEoleflask.autoriser votre adresse IP pour administrer le serveur dans l'onglet de l'interface réseau concernée.
Après instance ou reconfigure, l'interface de configuration du module est accessible depuis un navigateur web en HTTPS à l'adresse suivante :
https://<adresse_serveur>/genconfig/
ou : https://<adresse_serveur>:7000/genconfig/
Revenir au dernier état fonctionnel du serveur
Un mauvais paramétrage du serveur ne permet plus d'aller au bout de la reconfiguration du module.
Truc & astuce
Un fichier config.eol.bak est sauvegardé dans le répertoire /etc/eole/ à la fin de l'instanciation et à la fin de la reconfiguration du serveur.
Cela permet de conserver la dernière configuration fonctionnelle du serveur.
À chaque reconfiguration du serveur un fichier config.eol.bak.1 est généré. Celui-ci est une copie de la configuration fonctionnelle de l'état précédant.
S'il existe une différence entre config.eol et config.eol.bak c'est que la configuration du serveur a été modifiée mais qu'elle n'a pas encore été appliquée.
Comment modifier la valeur d'une variable verrouillée
Il est vivement recommandé de ne pas éditer manuellement le fichier config.eol pour éviter les erreurs de frappe ou de type de données.
Truc & astuce
Exporter puis importer le fichier de configuration courant permet de passer outre le verrouillage des variables.
Attention
Cette astuce demande une bonne maîtrise des implications que peut avoir le changement d'une valeur verrouillée. Et une valeur n'est jamais verrouillée sans raison.
Par exemple, le changement de l'identifiant de l'établissement ne se répercute pas sur l'annuaire dont le schéma n'est construit qu'une fois au moment de l'instance du serveur.
Exemple
Pour modifier la valeur verrouillée Identifiant de l'établissement :
ouvrir l'interface de configuration du module ;
importer le fichier de configuration courant :
Fichier→Importer une Configuration→/etc/eole/config.eol;modifier la valeur de l'identifiant de l'établissement ;
enregistrer la configuration :
Fichier→Enregistrer la configuration;procéder à une reconfiguration du serveur à l'aide de la commande
reconfigure.
Erreurs de timeout ou erreur 504 avec Nginx
L'utilisation de la nouvelle interface de configuration du module sur une petite configuration peut poser problème.
Cela se traduit par des erreurs de timeout[6] avec Nginx ou une erreur 504 (méthode not allowed) dans l'interface de configuration du module et [ERROR] WORKER TIMEOUT (pid:XXXX) dans les logs de Gunicorn[7].
Truc & astuce
La valeur de timeout peut être changée à la ligne timeout = '120' dans le fichier de configuration de eoleflask : /etc/eole/flask/eoleflask.conf. Celui-ci n'est pas templatisé et n'est donc pas écrasé en cas de reconfiguration du serveur.
Le changement de valeur doit être suivi d'une relance du service eoleflask :
# CreoleService eoleflask restart
Interface de configuration en mode console
Impossible de trouver le mode console de l'interface de configuration du module.
Truc & astuce
Le mode console a été supprimé par contre il est possible :
- d'accéder à distance à l'interface de configuration du module via un navigateur web ;
- d'utiliser la commande CreoleSet pour configurer une variable en ligne de commande.
Consultation des mots de passe dans l’interface de configuration
Sur les versions d'EOLE supérieures à 2.6.0, les valeurs des variables de type password sont masquées lorsque le champ n’est pas en mode édition, donc inaccessibles lorsque le champ est verrouillé.
Truc & astuce
La consultation d’un mot de passe non éditable (stocké dans une variable verrouillée par exemple) est possible en passant en mode Debug. Le mot de passe pouvant malgré tout apparaître tronqué, sa valeur intégrale est accessible dans l’info-bulle qui s’affiche lors du survol du champ.
Configuration en mode Zéphir
La configuration en mode Zéphir permet, au lancement de l'interface de configuration du module à l'aide de la commande gen_config, de faire apparaître un fenêtre d'identification qui permet de s'identifier avec un compte Zéphir. Les modifications apportées dans la configuration locale seront synchronisées avec le serveur Zéphir.
La configuration en mode Zéphir se fait en deux étapes :
configuration :
- soit sur le serveur à enregistrer
- soit sur le serveur Zéphir (utilisation éventuelle de variantes)
enregistrement du serveur et synchronisation de la configuration.
Pré-requis
L'établissement d'appartenance du serveur doit déjà exister dans la base des serveurs.
Attention
La procédure d'enregistrement nécessite d'être en possession du certificat de la CA locale du serveur Zéphir ou d'avoir les droits suffisants pour le récupérer en SSH.
Enregistrement d'un établissement
Pour ajouter un établissement il faut se rendre dans l'application Zéphir et cliquer sur l'entrée établissement du menu.
Puis cliquer sur Ajout d'un établissement.
L'identifiant à saisir correspond au RNE de l'établissement (8 caractères maximum).
Attention
Le RNE est la seule information que l'on ne pourra pas modifier. Il faut donc prendre garde à saisir le bon numéro. En cas d'erreur, la seule solution sera de supprimer l'établissement fraîchement créé et le recréer.
Il faut ensuite renseigner la description de l'établissement (adresse physique, moyens de communication, ...).
Seuls les champs pourvus d'une * sont obligatoires (nom du site, ville, code postal et type d'établissement). Des types d'établissement peuvent être ajoutés dans établissement / Gestion des types d'établissement mais il faut le faire avant d'ajouter un nouvel établissement. Un fois validé avec le bouton OK, l'établissement est créé.
Enregistrement d'un lot d'établissements
Il est possible d'importer un fichier texte comprenant la liste des établissements depuis l'application web Zéphir.
Pour cela il faut cliquer sur le menu établissements et choisir Importer des établissements.
L'importation nécessite un fichier (par exemple extrait de la base de donnée Ramsese[8]) CSV[9] avec comme séparateur un "|".
Les champs suivants sont attendus :
RNE|LIBELLE CODE NATURE|CODE NATURE|LIBELLE ETAB|NOM ETAB|CODE POSTAL|LOCALITE|MAIL|FAX|TEL
Exemple
210024M|CLG|340|COLLEGE|CHAMPOLLION|21000|DIJON|ce.0210024M@ac-dijon.fr|0380732080|0380715585
0210026P|CLG|340|COLLEGE|EPIREY|21000|DIJON|ce.0210026P@ac-dijon.fr|0380732916|0380713554
Après l'importation un rapport est affiché.
L'enregistrement d'un serveur
La procédure d'enregistrement est requise pour tous les serveurs à administrer avec Zéphir. Elle permet de créer les données nécessaires dans la base de données et de configurer la transmission sécurisée entre Zéphir et le serveur. L'enregistrement est effectué manuellement sur le module avec la commande enregistrement_zephir.
Attention
Dans le cas d'utilisation de certificats non reconnus par une autorité de certification la procédure d'enregistrement nécessite d'être en possession du certificat de la CA locale du serveur Zéphir ou d'avoir les droits suffisants pour le récupérer en SSH.
Configuration minimale du réseau
Si le réseau n'est pas paramétré sur le module il est possible d'appeler manuellement le script network_zephir pour une mise en place rapide.
root@eolebase:~# network_zephir
interface connectée sur l'extérieur (ens4 par défaut) :
adresse_ip ens4 : 192.168.240.100
masque de réseau pour ens4 : 255.255.255.0
adresse de la passerelle : 192.168.240.254
adresse du serveur DNS (ou rien) : 192.168.240.1
root@scribe:~#
Attention
Si le réseau n'est pas paramétré sur le module à enregistrer et que vous n'avez pas appelé manuellement le script network_zephir, sa configuration vous sera proposée par le script enregistrement_zephir :
voulez-vous établir une configuration réseau minimale (O/N), répondre oui à la question ;
Truc & astuce
Si une configuration réseau particulière est nécessaire au moment de l'enregistrement, exécuter la commande enregistrement_zephir avec l'option --force.
Déroulement de l'enregistrement
lancer la procédure d'enregistrement à l'aide de la commande
enregistrement_zephir;saisir l'adresse du serveur Zéphir, ainsi qu'un nom d'utilisateur et un mot de passe autorisé en écriture dans l'application web Zéphir ;
dans le cas d'utilisation de certificats non reconnus par une autorité de certification, il faut, pour procéder à l'enregistrement d'un serveur, copier le certificat de la CA locale du serveur Zéphir
/etc/ssl/certs/ca_local.crtsur la machine à enregistrer dans le répertoire/usr/local/share/ca-certificates/et mettre à jour les certificats sur la machine locale à l'aide de la commandeupdate-ca-certificates;relancer la procédure d'enregistrement avec la commande
enregistrement_zephir;si le serveur n'a pas été pré-créé sur le serveur Zéphir, répondre
ouià la questionCréer le serveur dans la base Zéphir ?;saisir le numéro RNE qui doit au préalable exister dans l'application Zéphir ;
saisir le libellé du serveur ;
répondre aux diverses questions sur le matériel ;
répondre aux diverses questions sur l'installateur ;
choisir un module et une variante dans les listes proposées ;
synchronisation de la configuration :
si la configuration a été faite en mode autonome sur le module à enregistrer choisir
Sauver la configuration actuelle sur Zephirsi la configuration a été réalisé sur le serveur Zéphir choisir
Récupérer les fichiers de variante sur Zéphir
un message indiquera que la configuration est bien sauvegardée et que les communications avec Zéphir sont configurées. Dans le cas où des paramètres du serveur ne seraient pas renseignés (paramètres provenant d'une variante), un message vous préviendra que ceux-ci doivent être saisis.
Remarque
Un numéro sera indiqué (id du serveur) à la fin de la procédure d'enregistrement. Ce numéro permettra d'accéder directement aux informations de ce serveur dans l'application web Zéphir.
Exemple
Exemple de l'enregistrement d'un serveur déjà instancié :
root@eolebase:~# enregistrement_zephir Procédure d'enregistrement sur le serveur ZéphirEntrez l'adresse du serveur Zéphir : 192.168.240.254Entrez votre login pour l'application Zéphir (rien pour sortir) : admin_zephirMot de passe pour l'application Zéphir pour admin_zephir :## Saisir l'adresse du serveur Zéphir, le compte et le mot de passe pour l'application Zéphir.Certificat de Zéphir non validé !
utiliser sur Zéphir un certificat signé par une autorité reconnue,
ou
Copier le fichier /etc/ssl/certs/ca_local.crt de Zéphir dans
/usr/local/share/ca-certificates et lancer update-ca-certificates.
root@eolebase:~#root@eolebase:~# scp root@zephir.ac-test.fr:/etc/ssl/certs/ca_local.crt /usr/local/share/ca-certificates/Warning: Permanently added 'zephir.ac-test.fr,192.168.0.20' (ECDSA) to the list of known hosts.root@zephir.ac-test.fr's password: ca_local.crt 100% 1736 1.7KB/s 00:00
root@eolebase:~#root@eolebase:~# update-ca-certificatesUpdating certificates in /etc/ssl/certs...WARNING: Skipping duplicate certificate eole.pem
WARNING: Skipping duplicate certificate eole.pem
WARNING: Skipping duplicate certificate infrastructures.pem
WARNING: Skipping duplicate certificate infrastructures.pem
WARNING: Skipping duplicate certificate ca.crt
WARNING: Skipping duplicate certificate ca.crt
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...done.root@eolebase:~#root@eolebase:~# enregistrement_zephir Procédure d'enregistrement sur le serveur ZéphirEntrez l'adresse du serveur Zéphir : 192.168.240.254Entrez votre login pour l'application Zéphir (rien pour sortir) : admin_zephirMot de passe pour l'application Zéphir pour admin_zephir :## Saisir l'adresse du serveur Zéphir, le compte et le mot de passe pour l'application Zéphir.créer le serveur dans la base du serveur Zéphir (O/N) : o
## Le script détecte que le module n'a jamais été enregistré et demande si vous souhaitez le créer.Etablissement du serveur (n° RNE) (0000G123 par défaut) :
libellé du serveur (eolebase Lycée de Dijon par défaut) :
matériel (Bochs () par défaut) :
processeur ( QEMU Virtual CPU version 1.0 2294 MHz par défaut) :
disque dur (43 Go par défaut) :
nom de l'installateur (admin_zephir par défaut) :telephone de l'installateur :commentaires :
Délai entre deux connexions à zephir
minutes (30 par défaut) :
** liste des modules disponibles **
47 amon-2.446 eolebase-2.442 horus-2.445 scribe-2.443 sentinelle-2.444 sphynx-2.448 thot-2.4module (eolebase-2.4 par défaut):
** liste des variantes de ce module **
45 * standardvariante (45 par défaut):
## Ici les paramètres proposés par défaut sont validés par un retour chariot.** Configuration des communications vers le serveur Zéphir **
1 -> Ne rien faire
2 -> Récupérer les fichiers de variante sur le serveur Zéphir
3 -> Sauver la configuration actuelle sur le serveur Zéphir
4 -> Modifier la variante du serveur
Entrez le numéro de votre choix : 3
Pour l'enregistrement il faut choisir l'option 3.
-- sauvegarde en cours (veuillez patienter) --
-- OK --
--récupération des patchs et dictionnaires (veuillez patienter)--** le numéro attribué à ce serveur sur le serveur Zéphir est : 1 **root@eolebase:~#Le module est correctement enregistré sur le serveur Zéphir.
Enregistrement sans question
À partir d'EOLE 2.8.0, il est possible d'enregistrer un module sans interagir avec la commande enregistrement_zephir.
Pour cela, il suffit de passer en argument les réponses aux questions normalement posées par la commande.
Les arguments possibles à donner dans la commande sont :
-h, --help Affiche le message d'aide
-c, --check Vérification seulement, affiche l'identifiant du serveur stocké dans l'application Zéphir et retourne 0 si le serveur est enregistré, 1 sinon
-p, --pppoe Si le réseau n'est pas encore configuré, cette option permet la mise en place d'une connexion par PPPoE
-f, --force Force la mise en place d'un configuration minimale du réseau même si le serveur est déjà configuré
--adresse_zephir ADRESSE_ZEPHIR Nom DNS du serveur Zéphir
--user USER Login pour l'application Zéphir
--password PASSWORD Mot de passe pour l'application Zéphir
--id_serveur ID_SERVEUR N° identifiant le serveur l'application Zéphir
--choix {1,2,3,4} Numéro de votre choix d'échange avec le Zéphir
--force_enregistrement Force l'enregistrement même si un serveur est déjà enregistré
Les 4 choix possibles sont :
1 -> Ne rien faire
2 -> Utiliser la configuration définie sur le serveur Zéphir
3 -> Sauver la configuration actuelle sur le serveur Zéphir
4 -> Modifier la variante du serveur
Exemple
Exemple : pour enregistrer mon serveur numéro 25 et sauver la configuration actuelle sur le serveur Zéphir, je me connecte sur mon serveur (n°25) puis :
root@eolebase:~# enregistrement_zephir --adresse_zephir zephir.ac-test.fr --user admin_zephir --password mdp_admin_zephir --id_serveur 25 --choix 3 Procédure d'enregistrement sur le serveur Zéphir ** utilisation d'un serveur existant dans la base du serveur Zéphir **Vérification des informations sur le matériel
Mise à jour des informations sur le matériel
** Configuration des communications vers le serveur Zéphir **
-- sauvegarde en cours (veuillez patienter) --
INFO:zephir-client:save_files()
-- OK --
--récupération de la configuration en cours (veuillez patienter)-- ** attente de la mise en place des fichiers **
** Vérification des dictionnaires et de la configuration **
** le numéro attribué à ce serveur sur le serveur Zéphir est : 25 **Attention
Il n'est pas possible de désinscrire un module avec un enregistrement_zephir sans question.
Il n'est pas possible d'enregistrer un module déjà enregistré à moins qu'il n'ait été désinscrit entre temps. Si le module a bien été désinscrit, l'utilisation de l'argument --force_enregistrement est alors nécessaire pour un nouvel enregistrement.
Lancement de l'interface de configuration
Une fois la procédure terminée, la configuration du module peut être effectuée depuis le serveur selon le mode autonome synchronisé ou depuis l’application Zéphir.
Sur l’application Zéphir, l’application de configuration du module est accessible depuis la page d’état du serveur via le lien modifier affiché dans la section Configuration du tableau,
Cette application de configuration du module se comporte de manière semblable à celle exécutée depuis le serveur lui-même à quelques détails près :
certains calculs et contraintes nécessitant l’accès direct au serveur configuré sont désactivés ;
la page de différences entre la configuration appliquée sur le module et la configuration associée au module dans l’application Zéphir n’est disponible que pour les modules à jour à partir de la version 2.8.1 et à condition qu’une première synchronisation ait été effectuée sans erreur.
cette page de différences est simplifiée.
En cas de différences entre la configuration appliquée sur le module et la configuration associée au module dans l’application Zéphir, il est demandé à l’administrateur de choisir quelle version, globalement, servira comme base de configuration pour l’édition.
La configuration éditée via cette application de configuration du module intégrée à l’application Zéphir n’est pas directement synchronisée avec celle du serveur mais nécessite une action pour l’envoyer.
Désinscription d'un serveur
Pour désinscrire un serveur il faut exécuter la commande enregistrement_zephir et la désinscription est proposée.
root@eolebase:~# enregistrement_zephir Procédure d'enregistrement sur le serveur Zéphir ** Ce serveur est déjà enregistré sur le serveur Zéphir **
- n°identifiant : 454 - adresse de Zéphir : zephir.ac-test.fr 1 -> Désinscrire ce serveur du serveur Zéphir
2 -> Relancer l'enregistrement
3 -> Ne rien faire
Entrez le numéro de votre choix : 1
Désinscription auprès du serveur Zéphir terminée
root@eolebase:~#Configuration en mode basique
Dans l'interface de configuration du module voici les onglets propres à la configuration du module AmonEcole :
Général;Services;Firewall;
Interface-0(configuration de l'interface du réseau externe) ;Interface-1(configuration de l'interface du réseau local) ;Active directory ;DHCP * ;Applications web;Messagerie;Directeur bareos;Stockage bareos.
Certains des onglets ne sont disponibles qu'après activation du service dans l'onglet Services et sont marqués avec une * dans la liste ci-dessus.
Dans les onglets Général et Firewall, deux options sont à renseigner avec la plus grande attention : le Nombre d'interfaces à activer et le Modèle de filtrage.
En effet, ces options vont orienter l'architecture de vos réseaux internes ainsi qu'une partie importante de la politique de sécurité qui sera mise en place.
Le nombre d'interfaces doit, bien évidemment, être choisi en fonction du nombre de cartes réseau physiques du serveur mais plus encore en fonction du nombre de sous-réseaux souhaités.
Le modèle de filtrage doit être choisi en fonction du nombre d'interfaces activées et des services que l'on souhaite mettre en place.
Onglet Général
Présentation des différents paramètres de l'onglet Général.
Informations sur l'établissement
Deux informations sont importantes pour l'établissement :
- l'
Identifiant de l'établissement, qui doit être unique ; - le
Nom de l'établissement.
Ces informations sont notamment utiles pour Zéphir, les applications web locales, ....
Sur les modules fournissant un annuaire LDAP[11] local, ces variables sont utilisées pour créer l'arborescence.
Attention
Il est déconseillé de modifier ces informations après l'instanciation du serveur sur les modules utilisant un serveur LDAP local.
Nom DNS du serveur
En premier lieu, il convient de configurer le nom DNS du serveur.
Cette information est découpée en 2 champs :
- le nom de la machine dans l'établissement ;
- le nom DNS du réseau local.
Le Nom de la machine est laissé à l'appréciation de l'administrateur.
Le Nom DNS du serveur utilise fréquemment des domaines de premier niveau du type .lan
C'est ce nom qui configurera le serveur DNS (sur un module Amon par exemple) comme zone de résolution par défaut. Il sera utilisé par les machines pour résoudre l'ensemble des adresses locales.
Rappel : les outils mDNS (Avahi, Bonjour, ... ) utilise la racine '.local'. Pour éviter les problèmes de DNS, nous vous déconseillons d'utiliser cette racine.
Remarque
Les domaines de premier niveau .com, .fr sont en vigueur sur Internet, mais sont le résultat d'un choix arbitraire.
Sur un réseau local les noms de domaine sont privés et on peut tout à fait utiliser des domaines de premier niveau, et leur donner la sémantique que l'on veut.
Remarque
Les informations sur les noms de domaine sont importantes car elles sont notamment utilisées pour l'envoi des courriels et pour la création de l'arborescence de l'annuaire LDAP.
Attention
L'usage d'un domaine de premier niveau utilisé sur Internet n'est pas recommandé, car il existe un risque de collision entre le domaine privé et le domaine public.
Paramètres réseau globaux
En deuxième lieu, il convient de configurer les noms de domaine de la machine.
Cette information est découpée en plusieurs champs :
- le nom du domaine privé utilisé à l'intérieur de l'établissement ;
- le nom de domaine académique et son suffixe.
Proxy
Si le module doit utiliser un proxy pour accéder à Internet, il faut activer cette fonctionnalité en passant la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet à oui.
Il devient alors possible de saisir la configuration du serveur proxy :
- nom de domaine ou adresse IP du serveur proxy ;
- le port du proxy.
Attention
La déclaration du proxy est nécessaire pour effectuer les mises à jour d'un module qui serait protégé par un module Amon.
Déchiffrement et interception du protocole HTTPS
Par rapport au protocole HTTP[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.
Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).
En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.
Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.
Certificat Racine de l'autorité de certification
Un certificat HTTPS est émis par une autorité de certification[13].
Let's Encrypt[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.
À partir de la version 2.8.1, le module Amon est équipé d'une fonctionnalité d'interception du trafic HTTPS. Il est possible de déclarer son certificat racine servant à sur-signer les ressources servies par le protocole HTTPS et transitant par le proxy filtrant. Cette déclaration permet d'en automatiser l'intégration dans le magasin de certificats local.
Si la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet est passée à oui, la variable Le serveur mandataire intercepte les communications HTTPS est proposée et permet elle-même de faire apparaître deux variables permettant d’identifier le certificat racine employé par le proxy filtrant.
En passant la variable Le serveur mandataire intercepte les communications HTTPS à oui, il est possible de renseigner les variables suivantes en utilisant les données affichées par la commande diagnose sur le module Amon :
Type d’empreinte du certificat racine du proxy: SHA256 (par défaut sur Amon 2.8.1)Empreinte du certificat racine du proxy: information donnée par le diagnose du serveur Amon dans le cas où celui-ci fait office de proxy filtrant
Cette configuration est nécessaire uniquement lorsque le module Amon est configuré pour l’interception des communications HTTPS.
Truc & astuce
Sur un module Amon configuré pour l'interception des communications HTTPS, la commande diagnose permet de connaître le chemin et l'empreinte du certificat :
*** Validité du certificat racine du proxy (/etc/eole/squid_CA.crt)
. signingCA.crt => Ok. Empreinte => SHA256 Fingerprint=62:1B:BF:25:28:44:31:02:7E:09:31:A6:EA:FD:A5:A8:7C:D4:EB:B6:3D:83:88:62:0F:98:85:1A:DC:50:99:E0
DNS et fuseau horaire
Choix du certificat SSL
Trois types de certificats peuvent être utilisés pour sécuriser les connexions avec TLS[15] :
autosigné: le certificat est généré localement et signé par une CA[13] locale ;letsencrypt: le certificat est généré et signé par l'autorité Let's Encrypt[14] ;manuel: le certificat est mis en place manuellement par l'administrateur. Pour ce faire, il faut disposer au préalable des certificats fournis par l'autorité de certification, si ce n'est pas encore le cas, le choixautosignépermet d'utiliser le serveur de façon non optimale. Le répertoire/etc/ssl/certs/est recommandé pour placer les certificats.
Remarque
Par défaut, le type de certificat par défaut est autosigné et aucun paramétrage n'est nécessaire.
Cette configuration est déconseillée car elle nécessite l'installation de l'autorité de certification locale sur tous les postes clients.
Truc & astuce
Pour plus d'informations, consulter la partie consacrée à l'onglet expert Certificats ssl.
Onglet Services
L'onglet Services permet d'activer et de désactiver une partie des services proposés par le module.
Suivant le module installé et le mode utilisé pour la configuration, la liste des services activables ou désactivables est très différente.
Truc & astuce
Le principe est toujours le même, l'activation d'un service va, la plupart du temps, ajouter un onglet de configuration propre au service.
En mode basique, seul le service DHCP est activable.
Onglet Firewall
Modèle de filtrage
Le modèle de filtrage doit être choisi en fonction du nombre d'interfaces activées et des services que l'on souhaite mettre en place.
Par convention, le premier caractère des modèles de filtrage proposés est un chiffre qui correspond au nombre d'interfaces désirées.
Les modèles de zone par défaut proposés supportent jusqu'à 5 cartes réseau :
2zones : gestion d'une zone admin ou pedago sur l'interface 1 ;
2zones-amonecole : modèle spécifique au module AmonEcole (pedago sur l'interface 1) ;
3zones : gestion d'une zone admin sur l'interface 1 et d'une zone pedago sur l'interface 2 ;
3zones-dmz : gestion d'une zone pedago sur l'interface 1 et d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 2 ;
4zones : gestion d'une zone admin sur l'interface 1, d'une zone pedago sur l'interface 2 et d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 3 ;
5zones : gestion d'une zone admin sur l'interface 1, d'une zone pedago sur l'interface 2, d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 3 et d'une zone DMZ privée sur l'interface 4.
Complément
Chaque modèle de zone proposé correspond à un modèle de filtrage ERA. Les modèles de filtrage ERA sont la description de pare-feu enregistrés dans des fichiers XML situés par défaut dans le répertoire /usr/share/era/modeles/.
Truc & astuce
Avec ERA il est possible de créer un nouveau modèle personnalisé dans le répertoire /usr/share/era/modeles/. Celui-ci apparaîtra dans la liste des modèles proposés par défaut.
Onglet Interface-0
Configuration de l'interface
Méthode d'attribution statique
Dans le cas de la configuration statique, il faut renseigner l'adresse IP, le masque et la passerelle.
Truc & astuce
EOLE est pleinement fonctionnel avec une connexion en IP fixe. Si vous ne disposez pas d'IP fixe, certaines fonctionnalités ne seront plus disponibles.
Méthode d'attribution DHCP
La configuration DHCP ne nécessite aucun paramétrage particulier.
Attention
Lors du passage d'une configuration statique à une configuration DHCP, il faut procéder à deux reconfigure successifs.
Méthode d'attribution "non géré"
L'utilisation de la nouvelle valeur non gérée permet de déléguer la configuration réseau à cloud-init[18] ou à un autre outil de contextualisation.
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Onglet Interface-1
L'onglet Interface-1 permet de configurer le réseau local de la structure.
Attention
Le module AmonEcole nécessite 4 adresses IP distinctes sur ce réseau.
Configuration de l'interface
L'adresse saisie sera celle du module AmonEcole pour le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- passerelle par défaut ;
- serveur SMTP ;
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Adresse IP pour le proxy
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs internet depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur proxy (port 3128) ;
Adresse IP pour le serveur de fichiers
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs partage depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur de fichiers ;
- serveur de gestion des "clients Scribe" ;
- serveur d'impression (si activé) ;
- serveur DHCP (si activé).
Adresse IP pour le contrôleur de domaine
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs addc depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur DNS ;
- contrôleur de domaine.
Onglet Dhcp : Configuration du serveur DHCP
Sur les modules Seth et Scribe, les adresses servies doivent généralement être sur le réseau local (interface 0).
Sur le module AmonEcole, les adresses servies sont celles du réseau interne (interface 1).
Si le serveur est installé en DMZ, on pourra renseigner des adresses d'un autre réseau mais dans ce cas, il faudra activer le relayage du DHCP[20] sur le pare-feu.
Définition des sous-réseaux
Il faut définir une ou plusieurs plages (en anglais range) d'adresses attribuables par le serveur à l'aide du bouton + Adresse réseau de la plage DHCP.
La plage DHCP doit contenir au moins autant d'adresses que le nombre de stations susceptibles d'être connectées simultanément sur le réseau.
Les champs Adresse réseau de la plage DHCP et Masque de sous-réseau de la plage DHCP permettent de définir le réseau sur lequel les adresses doivent être servies.
Le champ Nom de la plage DHCP, disponible uniquement à partir de la version 2.6.2, permet d'identifier plus facilement la plage DHCP, notamment dans la nouvelle interface d'administration (EAD3). Pour administrer efficacement le DHCP dans l'interface de configuration, il convient de renseigner des noms de plages pertinents. Dans le cas d'une migration depuis une version antérieure d'EOLE, cette variable est arbitrairement initialisée avec les valeurs "plage0", "plage1"…
Les champs IP basse de la plage DHCP et IP haute de la plage DHCP doivent être comprise dans le réseau déclaré ci-dessus.
Le champ IP basse de la plage DHCP correspond, dans un réseau de classe C, à l'adresse IP dont le dernier octet a la valeur la plus petite.
Le champ IP haute de la plage DHCP correspond, dans un réseau de classe C, à l'adresse IP dont le dernier octet a la valeur la plus grande.
Le nombre d'adresses IP servies est déterminé par la différence entre la valeur la plus grande et la valeur la plus petite.
Les champs Nom de domaine à renvoyer aux clients DHCP, Adresse IP du routeur à renvoyer aux clients DHCP et Adresse IP du DNS à renvoyer aux clients DHCP permettent de spécifier des valeurs différentes pour chaque plage déclarée.
Pour la configuration de l'Adresse IP du routeur à renvoyer aux clients DHCP :
dans le mode une carte, l'adresse sera l'adresse IP de la passerelle saisie dans l'onglet
Interface-0;dans le cas du mode deux cartes, l'adresse IP du routeur sera l'adresse IP de l'
Interface-1(eth1).
L'Adresse IP du DNS à renvoyer aux clients DHCP
peut être l'adresse IP du DNS de votre FAI[21] pour une utilisation sans le module Amon. Il est également possible d'utiliser des serveurs DNS disponibles sur Internet.
Si vous disposez d'un module Amon ou d'un module AmonEcole, il est conseillé d'utiliser le module comme relais DNS[3], L'adresse à préciser dans le cas du mode deux cartes sera l'adresse IP du routeur et donc l'adresse IP de l'Interface-1 (eth1).
Truc & astuce
Sur le module AmonEcole, l'adresse IP du DNS à renvoyer correspond à celle renseignée dans Adresse IP pour addc (adresse_ip_domaine_link)de l'onglet Interface-1 de l'interface de configuration du module.
Onglet Applications web : Configuration des applications web
L'onglet Applications web est disponible par défaut sur les modules Scribe et AmonEcole.
Les applications web sont désactivables en passant Activer le serveur web Apache à non, dans l'onglet Services.
L'onglet Applications web permet de régler les paramètres essentiels du serveur web Apache.
Nom de domaine des applications web
Le choix du Nom de domaine des applications web est essentiel.
Pour un bon fonctionnement de toutes les applications, il est impératif d'utiliser un nom de domaine.
Dans la mesure du possible, il faut que celui-ci soit résolvable sur Internet. Si ce n'est pas le cas, il est possible d'utiliser un nom de domaine local diffusé par le serveur DNS[3] de l'établissement.
Ce paramètre ne doit pas être précédé du nom du protocole.
Onglet Messagerie
Même sur les modules ne fournissant aucun service directement lié à la messagerie, il est nécessaire de configurer une passerelle SMTP valide car de nombreux outils sont susceptibles de nécessiter l'envoi de courriers électroniques.
La plupart des besoins concernent l'envoi d'alertes ou de rapports.
Exemples : rapports de sauvegarde, alertes système, ...
Serveur d'envoi/réception (SMTP)
Les paramètres communs à renseigner sont les suivants :
Nom de domaine de la messagerie de l'établissement (ex : monetab.ac-aca.fr), saisir un nom de domaine valide, par défaut un domaine privé est automatiquement créé avec le préfixei-;Adresse électronique d'envoi pour le compte root, saisir l'adresse que l'on souhaite utiliser pour l'envoi de courriers électroniques depuis le compte root.Adresse électronique recevant les courriers électroniques à destination du compte root, permet de configurer une adresse pour recevoir les éventuels messages envoyés par le système.
Attention
Le Nom de domaine de la messagerie de l'établissement (onglet Messagerie) ne peut pas être le même que celui d'un conteneur. Le nom de la machine (onglet Général) donne son nom au conteneur maître aussi le Nom de domaine de la messagerie de l'établissement ne peut pas avoir la même valeur.
Dans le cas contraire les courriers électroniques utilisant le nom de domaine de la messagerie de l'établissement seront réécris et envoyés à l'adresse électronique d'envoi du compte root.
Cette contrainte permet de faire en sorte que les courriers électroniques utilisant un domaine de type @<NOM CONTENEUR>.* soient considérés comme des courriers électroniques systèmes.
Attention
Dans le cas où le Nom de domaine de la messagerie de l’établissement n’est pas le même que la concaténation du Nom de la machine et du Nom DNS du réseau local, il peut être nécessaire d’activer la réécriture des en-têtes pour avoir des informations cohérentes avec l’enveloppe des courriels.
Relai des messages
La variable Passerelle SMTP, permet de saisir l'adresse IP ou le nom DNS de la passerelle SMTP à utiliser.
Remarque
Afin d'envoyer directement des courriers électroniques sur Internet il est possible de désactiver l'utilisation d'une passerelle en passant Router les courriels par une passerelle SMTP à non.
Sur les modules possédant un serveur SMTP (Scribe, AmonEcole), ces paramètres sont légèrement différents et des services supplémentaires sont configurables.
Onglet Directeur Bareos
Le nom du directeur est une information importante, il est utilisé en interne dans le logiciel mais, surtout, il est nécessaire pour configurer un client Bareos ou pour joindre le serveur de stockage depuis un autre module.
À l'enregistrement du fichier de configuration il ne sera plus possible de modifier le nom du directeur, en effet cette variable est utilisée dans les noms des fichiers de sauvegarde.
Onglet Stockage Bareos
Dans l'onglet Stockage bareos il est possible de choisir un mot de passe (générer par défaut) pour le stockage afin que les directeurs distants puissent se connecter au présent serveur de stockage.
Attention
Les sauvegardes sont des informations sensibles. Il ne faut pas utiliser de mot de passe facilement déductible.
Configuration en mode normal
Certains onglets et certaines options ne sont disponibles qu'après avoir activé le mode normal de l'interface de configuration du module.
Dans l'interface de configuration du module voici les onglets propres à la configuration du module AmonEcole :
Général;Services;Firewall;
Interface-0;Interface-1;Interface-n* ;Agrégation** ;Mots de passe;Active directory;Clamav;Annuaire;Dhcp* ;Onduleur* ;Rvp* ;Applications web;Eole sso;Mode restreint;Messagerie;Directeur bareos;Stockage bareos;Authentification;Squid;Proxy authentifié;Proxy authentifié 2*** ;Exceptions proxy;Wpad;Gpo;Nginx;Reverse proxy* ;FreeRadius*** ;Synchronisation aaf;Envole. ;Sonde statistique.
Certains des onglets ne sont disponibles que dans des conditions particulières :
après activation du service dans l'onglet
Servicespour les onglets identifiés avec une * dans la liste ci-dessus ;après activation de la
Répartition de charge entre 2 lignes Internetdans l’ongletInterface-0pour l’onglet identifié avec ** dans la liste ci-dessus ;après activation des fonctionnalités supplémentaires dans l’onglet
Authentificationpour les onglets identifiés avec *** dans la liste ci-dessus.
Onglet Général
Présentation des différents paramètres de l'onglet Général.
Informations sur l'établissement
Deux informations sont importantes pour l'établissement :
- l'
Identifiant de l'établissement, qui doit être unique ; - le
Nom de l'établissement.
Ces informations sont notamment utiles pour Zéphir, les applications web locales, ....
Sur les modules fournissant un annuaire LDAP[11] local, ces variables sont utilisées pour créer l'arborescence.
Attention
Il est déconseillé de modifier ces informations après l'instanciation du serveur sur les modules utilisant un serveur LDAP local.
Nom DNS du serveur
En premier lieu, il convient de configurer le nom DNS du serveur.
Cette information est découpée en 2 champs :
- le nom de la machine dans l'établissement ;
- le nom DNS du réseau local.
Le Nom de la machine est laissé à l'appréciation de l'administrateur.
Si l'authentification NTLM/KERBEROS est activée sur le proxy, le Nom de machine 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.
Le Nom DNS du serveur utilise fréquemment des domaines de premier niveau du type .lan .
C'est ce nom qui configurera le serveur DNS (sur un module Amon par exemple) comme zone de résolution par défaut. Il sera utilisé par les machines pour résoudre l'ensemble des adresses locales.
Rappel : les outils mDNS (Avahi, Bonjour, ... ) utilise la racine '.local'. Pour éviter les problèmes de DNS, nous vous déconseillons d'utiliser cette racine.
Remarque
Les domaines de premier niveau .com, .fr sont en vigueur sur Internet, mais sont le résultat d'un choix arbitraire.
Sur un réseau local les noms de domaine sont privés et on peut tout à fait utiliser des domaines de premier niveau, et leur donner la sémantique que l'on veut.
Remarque
Les informations sur les noms de domaine sont importantes car elles sont notamment utilisées pour l'envoi des courriels et pour la création de l'arborescence de l'annuaire LDAP.
Attention
L'usage d'un domaine de premier niveau utilisé sur Internet n'est pas recommandé, car il existe un risque de collision entre le domaine privé et le domaine public.
Paramètres réseau globaux
En deuxième lieu, il convient de configurer les noms de domaine de la machine.
Cette information est découpée en plusieurs champs :
- le nom du domaine privé utilisé à l'intérieur de l'établissement ;
- le nom de domaine académique et son suffixe.
Nombre d'interfaces
Un module Amon ou AmonEcole peut avoir de 2 à 5 cartes réseau.
Le nombre d'interfaces activées se définit dans l'onglet Général de l'interface de configuration du module.
Cela ajoute autant d'onglets Interface-n que le nombre d'interfaces à activer choisi.
Proxy
Si le module doit utiliser un proxy pour accéder à Internet, il faut activer cette fonctionnalité en passant la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet à oui.
Il devient alors possible de saisir la configuration du serveur proxy :
- nom de domaine ou adresse IP du serveur proxy ;
- le port du proxy.
Attention
La déclaration du proxy est nécessaire pour effectuer les mises à jour d'un module qui serait protégé par un module Amon.
Déchiffrement et interception du protocole HTTPS
Par rapport au protocole HTTP[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.
Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).
En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.
Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.
Certificat Racine de l'autorité de certification
Un certificat HTTPS est émis par une autorité de certification[13].
Let's Encrypt[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.
À partir de la version 2.8.1, le module Amon est équipé d'une fonctionnalité d'interception du trafic HTTPS. Il est possible de déclarer son certificat racine servant à sur-signer les ressources servies par le protocole HTTPS et transitant par le proxy filtrant. Cette déclaration permet d'en automatiser l'intégration dans le magasin de certificats local.
Si la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet est passée à oui, la variable Le serveur mandataire intercepte les communications HTTPS est proposée et permet elle-même de faire apparaître deux variables permettant d’identifier le certificat racine employé par le proxy filtrant.
En passant la variable Le serveur mandataire intercepte les communications HTTPS à oui, il est possible de renseigner les variables suivantes en utilisant les données affichées par la commande diagnose sur le module Amon :
Type d’empreinte du certificat racine du proxy: SHA256 (par défaut sur Amon 2.8.1)Empreinte du certificat racine du proxy: information donnée par le diagnose du serveur Amon dans le cas où celui-ci fait office de proxy filtrant
Cette configuration est nécessaire uniquement lorsque le module Amon est configuré pour l’interception des communications HTTPS.
Truc & astuce
Sur un module Amon configuré pour l'interception des communications HTTPS, la commande diagnose permet de connaître le chemin et l'empreinte du certificat :
*** Validité du certificat racine du proxy (/etc/eole/squid_CA.crt)
. signingCA.crt => Ok. Empreinte => SHA256 Fingerprint=62:1B:BF:25:28:44:31:02:7E:09:31:A6:EA:FD:A5:A8:7C:D4:EB:B6:3D:83:88:62:0F:98:85:1A:DC:50:99:E0
DNS et fuseau horaire
NTP
RemarquePorts utilisés par ntpdate
Le service ntp utilisant et bloquant le port 123, ntpdate utilise un port source aléatoire dans la plage des ports non privilégiés.
Les éventuelles règles de pare-feu ne peuvent donc pas présumer que le port source est le port 123.
Par contre, le port de destination reste inchangé (port : 123).
Choix du certificat SSL
Trois types de certificats peuvent être utilisés pour sécuriser les connexions avec TLS[15] :
autosigné: le certificat est généré localement et signé par une CA[13] locale ;letsencrypt: le certificat est généré et signé par l'autorité Let's Encrypt[14] ;manuel: le certificat est mis en place manuellement par l'administrateur. Pour ce faire, il faut disposer au préalable des certificats fournis par l'autorité de certification, si ce n'est pas encore le cas, le choixautosignépermet d'utiliser le serveur de façon non optimale. Le répertoire/etc/ssl/certs/est recommandé pour placer les certificats.
Remarque
Par défaut, le type de certificat par défaut est autosigné et aucun paramétrage n'est nécessaire.
Cette configuration est déconseillée car elle nécessite l'installation de l'autorité de certification locale sur tous les postes clients.
Truc & astuce
Pour plus d'informations, consulter la partie consacrée à l'onglet expert Certificats ssl.
Mise à jour
Il est possible de définir d'autres adresses pour le serveur de mise à jour EOLE que celles fournies par défaut, dans le cas où vous auriez, par exemple, un miroir des dépôts.
Onglet Services
L'onglet Services permet d'activer et de désactiver une partie des services proposés par le module.
Suivant le module installé et le mode utilisé pour la configuration, la liste des services activables ou désactivables est très différente.
Truc & astuce
Le principe est toujours le même, l'activation d'un service va, la plupart du temps, ajouter un onglet de configuration propre au service.
En mode normal la liste des services activables ou désactivables est beaucoup plus conséquente.
Les services propres au module AmonEcole sont les suivants :
- l'anti-virus ClamAv ;
- le serveur DHCP ;
- le réseau privé virtuel RVP ;
- le serveur web Apache ;
- le serveur d'authentification unique EoleSSO ;
- la sauvegarde ;
- le support de stockage de la sauvegarde ;
- le serveur d'impression avec CUPS ;
- le support de WPAD ;
- l'accès FTP.
Onglet Firewall
Modèle de filtrage
Le modèle de filtrage doit être choisi en fonction du nombre d'interfaces activées et des services que l'on souhaite mettre en place.
Par convention, le premier caractère des modèles de filtrage proposés est un chiffre qui correspond au nombre d'interfaces désirées.
Les modèles de zone par défaut proposés supportent jusqu'à 5 cartes réseau :
2zones : gestion d'une zone admin ou pedago sur l'interface 1 ;
2zones-amonecole : modèle spécifique au module AmonEcole (pedago sur l'interface 1) ;
3zones : gestion d'une zone admin sur l'interface 1 et d'une zone pedago sur l'interface 2 ;
3zones-dmz : gestion d'une zone pedago sur l'interface 1 et d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 2 ;
4zones : gestion d'une zone admin sur l'interface 1, d'une zone pedago sur l'interface 2 et d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 3 ;
5zones : gestion d'une zone admin sur l'interface 1, d'une zone pedago sur l'interface 2, d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 3 et d'une zone DMZ privée sur l'interface 4.
Complément
Chaque modèle de zone proposé correspond à un modèle de filtrage ERA. Les modèles de filtrage ERA sont la description de pare-feu enregistrés dans des fichiers XML situés par défaut dans le répertoire /usr/share/era/modeles/.
Truc & astuce
Avec ERA il est possible de créer un nouveau modèle personnalisé dans le répertoire /usr/share/era/modeles/. Celui-ci apparaîtra dans la liste des modèles proposés par défaut.
Déclaration d'un module Scribe en DMZ
Exemple
Si l'on souhaite mettre en place l'architecture suivante avec Amon :
- un réseau administratif ;
- un réseau pédagogique ;
- une DMZ contenant un serveur Scribe hébergeant des services web à ouvrir depuis l'extérieur.
La configuration recommandée sera :
-
Nombre d'interfaces à activer:4(ongletGénéralen mode basique) ; -
Modèle de filtrage:4zones(ongletFirewallen mode basique) ; -
Activer la gestion d'un Scribe dans la DMZ:oui(ongletFirewallen mode normal).
Interdire des accès réseaux
Par défaut, l'accès à des réseaux extérieurs pour des réseaux autres que l'interface 1 (l'interface 1 étant généralement admin) n'est pas interdit.
Si on passe l'option Interdire les interfaces autres que 1 à accéder à des réseaux extérieurs à oui, il est possible d'interdire l'accès
pour la ou les adresse(s) réseau et le ou les masque(s) souhaités.
Pour les réseaux RVP, il est habituel de ne pas conserver les données téléchargées par les utilisateurs dans le cache du proxy. C'est pour cela que l'option Désactiver le cache du proxy pour les accès à ce réseau est à oui par défaut. Cela signifie qu'en cas de téléchargement de page web, d'image, ... ces informations seront automatiquement re-téléchargées depuis le site source plutôt que conservées dans le cache du proxy.
Enfin, l'option En plus de l'interdiction proxy, interdire tous les protocoles permet de bloquer, via des règles iptables tout accès à ces réseaux.
Onglet Interface-0
Configuration de l'interface
Méthode d'attribution statique
Dans le cas de la configuration statique, il faut renseigner l'adresse IP, le masque et la passerelle.
Truc & astuce
EOLE est pleinement fonctionnel avec une connexion en IP fixe. Si vous ne disposez pas d'IP fixe, certaines fonctionnalités ne seront plus disponibles.
Méthode d'attribution DHCP
La configuration DHCP ne nécessite aucun paramétrage particulier.
Attention
Lors du passage d'une configuration statique à une configuration DHCP, il faut procéder à deux reconfigure successifs.
Méthode d'attribution "non géré"
L'utilisation de la nouvelle valeur non gérée permet de déléguer la configuration réseau à cloud-init[18] ou à un autre outil de contextualisation.
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Configuration des alias sur l'interface
EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.
Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.
Truc & astuce
Il est possible d'ajouter d'autres adresses IP alias sur l'interface en cliquant sur le bouton + Adresse IP alias pour l'interface n.
Configuration des VLAN sur l'interface
Il est possible de configurer des VLAN[26] (réseau local virtuel) sur une interface déterminée du module.
Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :
le numéro du VLAN ;
l'adresse IP de l'interface dans ce VLAN ;
le masque de sous-réseau de l'interface dans ce VLAN.
Il est possible de configurer une passerelle particulière pour un VLAN de l'interface 0.
Truc & astuce
Il est possible d'ajouter d'autres VLAN sur l'interface en cliquant sur le bouton + Numéro d'identifiant du VLAN.
Agrégation de routes IP
L'activation d'un alias IP, fait apparaître un nouveau paramètre : Répartition de charge entre 2 lignes Internet.
Pour activer l'agrégation de routes IP[27] (niveau 3), il faut passer ce nouveau paramètre à oui.
Un nouvel onglet : Agrégation est alors disponible.
Attention
Si l'agrégation de routes IP est activée, il faut obligatoirement configurer une passerelle particulière pour l'alias activé dans la rubrique Configuration des alias sur l'interface.
Onglet Interface-1
- Configuration de l'interface
- Administration à distance
- Configuration des alias sur l'interface
- Configuration des VLAN sur l'interface
- Configuration DNS sur l'interface
- Configuration des zones de filtrage
- Adresse IP pour le proxy
- Adresse IP pour le serveur de fichiers
- Adresse IP pour le contrôleur de domaine
L'onglet Interface-1 permet de configurer le réseau local de la structure.
Attention
Le module AmonEcole nécessite 4 adresses IP distinctes sur ce réseau.
Configuration de l'interface
L'adresse saisie sera celle du module AmonEcole pour le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- passerelle par défaut ;
- serveur SMTP ;
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Configuration des alias sur l'interface
EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.
Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.
Truc & astuce
Il est possible d'ajouter d'autres adresses IP alias sur l'interface en cliquant sur le bouton + Adresse IP alias pour l'interface n.
Configuration des VLAN sur l'interface
Il est possible de configurer des VLAN[26] (réseau local virtuel) sur une interface déterminée du module.
Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :
le numéro du VLAN ;
l'adresse IP de l'interface dans ce VLAN ;
le masque de sous réseau de l'interface dans ce VLAN.
Truc & astuce
Il est possible d'ajouter d'autres VLAN sur l'interface en cliquant sur le bouton + Numéro d'identifiant du VLAN.
Configuration DNS sur l'interface
Il est possible d'ajuster les paramètres du serveur DNS pour chaque interface réseau sauf pour l'interface 0.
Nom de la zone (pour résolution DNS): entrée DNS correspondant à l'adresse IP de l'interface. Le nom (par défaut admin pour l'interface 1) doit être différent pour chacune des interfaces.
Configuration des zones de filtrage
La solution de filtrage permet de différencier 2 zones, ce qui permet de dissocier 2 politiques de filtrage majeures et distinctes comme par exemple une zone réseau administratif et une zone réseau pédagogique.
Il faut choisir à quelle zone appartient une interface. Cela s'effectue dans la configuration de chaque interface réseau en sélectionnant le numéro de la zone souhaité dans le champ Filtre Web à appliquer à cette interface.
Remarque
Les zones Filtre web 1 et Filtre web 2 correspondent chacun à une instance du logiciel de filtrage. La configuration de chacune des instances s'effectue dans l'onglet Filtrage web.
Adresse IP pour le proxy
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs internet depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur proxy (port 3128) ;
Adresse IP pour le serveur de fichiers
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs partage depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur de fichiers ;
- serveur de gestion des "clients Scribe" ;
- serveur d'impression (si activé) ;
- serveur DHCP (si activé).
Adresse IP pour le contrôleur de domaine
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs addc depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur DNS ;
- contrôleur de domaine.
Onglet Interface-n
Nombre d'interfaces
Un module Amon ou AmonEcole peut avoir de 2 à 5 cartes réseau.
Le nombre d'interfaces activées se définit dans l'onglet Général de l'interface de configuration du module.
Cela ajoute autant d'onglets Interface-n que le nombre d'interfaces à activer choisi.
Configuration de l'interface
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Configuration des alias sur l'interface
EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.
Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.
La variable Autoriser cet alias à utiliser les DNS de zones forward additionnelles permet d'autoriser le réseau de cet alias à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres adresses IP alias sur l'interface en cliquant sur le bouton + Adresse IP alias pour l'interface n.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser cet alias à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non cet alias à utiliser les DNS noms d'hôte de la zone AGRIATES.
Configuration des VLAN sur l'interface
Il est possible de configurer des VLAN[26] (réseau local virtuel) sur une interface déterminée du module.
Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :
le numéro du VLAN ;
l'adresse IP de l'interface dans ce VLAN ;
le masque de sous réseau de l'interface dans ce VLAN.
La variable Autoriser ce VLAN à utiliser les DNS des zones forward additionnelles permet d'autoriser le réseau de ce VLAN à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres VLAN sur l'interface en cliquant sur le bouton + Numéro d'identifiant du VLAN.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser ce VLAN à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non ce VLAN à utiliser les DNS noms d'hôte de la zone AGRIATES.
Configuration DNS sur l'interface
Il est possible d'ajuster les paramètres du serveur DNS pour chaque interface réseau sauf pour l'interface 0.
Nom de la zone (pour résolution DNS): entrée DNS correspondant à l'adresse IP de l'interface. Le nom (par défaut admin pour l'interface 1) doit être différent pour chacune des interfaces.
Configuration des zones de filtrage
La solution de filtrage permet de différencier 2 zones, ce qui permet de dissocier 2 politiques de filtrage majeures et distinctes comme par exemple une zone réseau administratif et une zone réseau pédagogique.
Il faut choisir à quelle zone appartient une interface. Cela s'effectue dans la configuration de chaque interface réseau en sélectionnant le numéro de la zone souhaité dans le champ Filtre Web à appliquer à cette interface.
Remarque
Les zones Filtre web 1 et Filtre web 2 correspondent chacun à une instance du logiciel de filtrage. La configuration de chacune des instances s'effectue dans l'onglet Filtrage web.
Onglet Agrégation : Mise en place d'une répartition de charge ou d'une haute disponibilité
Présentation et mise en place de l'agrégation de routes IP
L'agrégation de routes IP (niveau 3) permet la mise en place d'une répartition de charge ou d'une haute disponibilité pour les sorties Internet.
Les deux routeurs sont reliés entre eux par un commutateur (ou un Hub) à la première carte du module Amon.
Dans ce cas :
- pas besoin d'utiliser les protocoles d'annonce de routes RIP[28] et OSPF[29] ;
- il faut un service qui surveille l'état de chacun des liens.
Attention
Il est nécessaire d'activer un alias sur l'interface réseau connectée sur l'extérieur pour utiliser ce service.
Remarque
La configuration de l'agrégation est le résultat de plusieurs contributions de collègues en académie.
La première version a été réalisée par l'académie de Versailles, puis elle a été améliorée successivement par les académies de Nantes et de Lyon.
Onglet Général
Dans la section Adresse IP du serveur DNS de l'onglet Général, ajouter les adresses des serveurs DNS de chacun des fournisseurs, en plaçant, de préférence, le DNS du premier lien en première position.
Onglet Interface-0
Il faut, en premier lieu, déclarer un alias sur l'interface 0 dans la section Configuration des alias sur l'interface.
Les paramètres réseaux (IP, masque et passerelle) doivent être ceux attribués par le fournisseur d'accès du second lien.
L'activation d'un alias IP, fait apparaître un nouveau paramètre, Répartition de charge entre 2 lignes Internet, qu'il faut passer à oui.
Un nouvel onglet, Agrégation, est disponible.
Onglet Agrégation : Configuration de l'agrégation de routes IP
Pour avoir accès à l'onglet concernant l'agrégation, il faut avoir activé la Répartition de charge entre 2 lignes Internet dans l'onglet Interface-0 comme expliqué précédemment.
Modes d'agrégation
Il existe deux modes d'agrégation :
le mode
mode-lb(pour load balancing) correspond à la répartition de charge et fonctionne avec la notion de poids à utiliser sur les différentes passerelles ;le mode
mode-fo, (pour fail-over) un seul lien est utilisé à la fois, il n'y a plus de notion de poids et il n'y a plus qu'une seule route par défaut.
Dans les deux modes il est possible de forcer des destinations IP ou réseau, et dans les deux cas si un lien tombe tous les flux (et également les destinations forcées) sont redirigés vers le second lien.
Quand les deux liens sont fonctionnels, on se retrouve dans la configuration de départ.
Attention
Le VPN, de par son mode de fonctionnement, ne peut pas être réparti entre plusieurs abonnements.
Tout le trafic devant passer par un seul lien, il est nécessaire d'utiliser le mécanisme de destination forcée.
Que le Lien 1 ou le Lien 2 soit choisi pour faire transiter le VPN, s'il devient indisponible, le VPN ne fonctionnera plus.
Adresse des DNS
Les champs Adresse du DNS sur le lien 1 et Adresse du DNS sur le lien 2 sont des champs obligatoires pour le bon fonctionnement de l’agrégation.
Attention
Les adresses DOIVENT être différentes sur chaque lien car c'est avec ces DNS que se font les tests d'état des liens.
Adresse DNS testée
Il est possible de spécifier plusieurs mires de tests qui seront testées afin de déterminer l'état des liens (résolution DNS avec le serveur DNS de chacun des liens).
Attention
L'ensemble des DNS doit être déclaré dans l'onglet Général.
Alerte mail
Lorsque l'un des liens est coupé, le message suivant est envoyé : Seul le lien 2 est actif, redirection des flux sur ce lien.
Quand les deux liens sont de nouveau fonctionnels, le message suivant est envoyé : Rechargement de la répartition sur les 2 liens.
Commandes
L'agrégation peut être suspendue et/ou relancée à l'aide du script agregation :
root@amon:~# agregation status
le service Agregation n'est pas démarré
root@amon:~#
Truc & astuce
L'option -h affiche l'aide de la commande :
root@amon:~# agregation -h
Usage: /usr/share/eole/sbin/agregation {start|stop|status|restart}
root@amon:~#
Onglet Mots de passe : Politique de mot de passe pour les utilisateurs
Contrôle de complexité dans les interfaces de saisie du module
Cet onglet permet de modifier la politique de contrôle des mots de passe Active Directory appliquée lors de la saisie et la modification au travers des interfaces fournies sur le module.
Longueur minimale des mots de passe
Cette variable permet de définir la longueur minimale requise pour un mot de passe.
La longueur minimale est paramétrable de 3 à 12 caractères.
Nombre minimum de classes de caractères
Cette variable permet de choisir le nombre minimum de classes de caractères[30] imposé pour le mot de passe d'un compte utilisateur.
Il est possible d'imposer l'utilisation de 1 à 4 classes différentes parmi :
- caractères minuscules ;
- caractères majuscules ;
- caractères numériques ;
- autres caractères (spéciaux et accentués).
Interdire la présence du nom d’utilisateur dans le mot de passe
La présence du nom d’utilisateur dans le mot de passe affaiblit le mot de passe en permettant qu’une partie des caractères utilisés pour le mot de passe soient prévisibles.
Interdire la présence du nom d’utilisateur dans le mot de passe permet de rejeter un mot de passe lors de son changement si celui-ci contient le nom de l’utilisateur concerné.
Remarque
Attention, un mot de passe sécurisé doit avoir une longueur de 8 caractères et doit contenir au minimum 3 classes différentes de caractères.
Attention
Dans le cadre de l'utilisation d'un serveur Active Directory, la politique de sécurité définie dans ici doit être en accord avec celle du serveur AD.
Politique de sécurité du serveur Active Directory
La gestion des règles de mots de passe du domaine et la gestion fine des règles de mots de passe par groupe via la configuration du module est disponible dès la version 2.7.2 via l’installation du paquet eole-ad-dc-pso.
Ce paquet est pré-installé sur le module à partir de la version 2.8.1.
Règles globales du domaine
Le contrôleur de domaine permet d’établir des règles pour les mots de passe. Ces règles s’appliquent à chaque utilisateur du domaine.
On peut distinguer deux types de règles :
- les règles globales au domaine, s’appliquant par défaut à tous les utilisateurs ;
- les règles spécifiques à des utilisateurs ou groupes d’utilisateurs, prenant le pas sur les règles globales.
Ces règles concernent plusieurs aspects du mot de passe :
- sa complexité, en termes de caractères le composant ;
- sa longueur ;
- sa durée de validité.
L’interface de configuration du module permet de configurer les règles globales du domaine et d’associer des règles spécifiques à des groupes.
Dans le détail, les règles disponibles dans l’interface de configuration du module sont les suivantes :
Longueur minimal du mot de passe: la longueur minimale empêche l’utilisation de mot de passe plus court que le nombre de caractères spécifiésLongueur de l’historique des mots de passe: un mot de passe valide ne doit pas être un mot de passe figurant dans l’historique des mots de passe de l’utilisateur ; une longueur d’historique longue empêche un utilisateur d’utiliser à nouveau un mot de passe employé récemmentÂge minimal du mot de passe: l’âge minimal du mot de passe bloque les changements de mots de passe trop rapprochés dans le tempsÂge maximal du mot de passe: l’âge maximal du mot de passe impose un changement de mot de passe à l’utilisateur avant la fin du délai sous peine de ne plus pouvoir se connecter.
Un utilisateur peut donc changer son mot de passe lorsque ce dernier est plus vieux que l’âge minimal mais moins vieux que l’âge maximal.
ÉcranConfiguration des règles globales du domaine
- 1
Longueur minimal du mot de passe
Détermine la longueur minimale acceptée pour les mots de passe dans la politique globale du domaine (en nombre de caractères)
- 2
Longueur de l’historique des mots de passe
Détermine le nombre de mots de passe conservés pour chaque utilisateur dans la politique globale du domaine
- 3
Âge minimal du mot de passe
Détermine le délai minimal entre deux opérations de changement de mot de passe (en jours)
- 4
Âge maximal du mot de passe
Détermine la durée maximale de validité du mot de passe après laquelle le compte est verrouillé (en jours)
ÉcranConfiguration des règles spécifiques aux groupes du domaine
- 1
Groupe avec ce niveau de complexité
Détermine le groupe auquel seront associées les règles définies
- 2
Longueur minimale du mot de passe
Détermine la longueur minimale des mots de passe des individus du groupe ciblé
- 3
Longueur de l’historique des mots de passe
Détermine le nombre de mots de passe conservés dans l’historique de chaque individu du groupe ciblé
- 4
Âge minimal du mot de passe
Détermine le délai minimal entre deux opérations de changement de mot de passe pour les individus du groupe ciblé (en jours)
- 5
Âge maximal du mot de passe
Détermine la durée maximale de validité du mot de passe des individus du groupe ciblé après laquelle le compte est verrouillé (en jours)
Complexité des mots de passe
En termes de complexité de mots de passe, Samba suit les contraintes référencées dans la documentation sur la mise en place du contrôleur de domaine:
Ces contraintes évaluent la composition du mot de passe caractère par caractère mais également globalement.
Globalement, le mot de passe ne doit pas contenir l’identifiant, si l’identifiant est long de plus de trois caractères, ou des portions de l’identifiant, si l’identifiant peut être découpé en plusieurs parties en suivant certains caractères.
Caractère par caractère, un mot de passe est valide si il contient au moins trois classes de caractères parmi cinq classes prédéfinies (majuscules des lettres des langues européennes, minuscules des lettres des langues européennes, chiffres en base dix, caractères spéciaux non alpha-numériques et caractères unicode identifiés comme caractères alphabétiques sans distinction de casse).
ÉcranConfiguration des règles globales du domaine
- 1
Applique les règles de complexité sur le mot de passe
Détermine si le mot de passe doit valider les règles de construction définies en interne par Samba
ÉcranConfiguration des règles spécifiques aux groupes du domaine
- 1
Applique les règles de complexité sur le mot de passe
Détermine si le mot de passe des individus du groupe ciblé doit valider les règles de complexité internes à Samba
Onglet Active Directory
À partir de la version 2.6.1 d'EOLE, le module Seth utilise la version 4.5 de Samba.
Cette version de samba permet notamment la prise en compte de plusieurs DNS Forwarders[32] :
Ainsi, la liste complète des serveurs DNS renseignés dans l'interface de configuration du module est prise en compte (et plus seulement le premier de la liste).
Nom du serveur dans le domaine AD
ComplémentCaractères autorisés et non autorisés
Les noms d'ordinateur au format NetBIOS[34] peuvent contenir tous les caractères alphanumériques à l'exception des caractères étendus suivants :
- la barre oblique inverse (\) ;
- marque de barre oblique (/) ;
- signe deux-points (:) ;
- astérisque (*) ;
- point d'interrogation (?) ;
- guillemet (") ;
- inférieur à (<) signe ;
- signe supérieur à (>) ;
- barre verticale (|).
Attention, les noms peuvent contenir un point, mais ne peuvent pas commencer par un point.
Pour en savoir plus sur les conventions de nommage dans un domaine, vous pouvez consulter la page :
Rôle du serveur Active Directory
Cette variable permet de choisir le Rôle du serveur :
- contrôleur de domaine ;
- serveur membre d'un domaine existant.
Dans le cas où le serveur à mettre en place a le rôle de contrôleur de domaine, il faut définir si celui-ci est le contrôleur de domaine principal ou si il s'agit d'un contrôleur additionnel.
Forcer le positionnement dans un site AD à l'initialisation
À partir de la version 2.6.2, il est possible de demander à ce qu'un contrôleur de domaine additionnel soit rattaché à un site Active Directory particulier.
Cette demande s'effectue en deux temps :
- en passant la variable
Forcer le positionnement de ce contrôleur de domaine dans un site existantàoui; - en renseignant la variable
Site de destination de ce contrôleur de domaine.
Après sauvegarde et instance, ces deux variables sont verrouillées et ne peuvent plus être modifiées.
Attention
La prise en compte du domaine de rattachement est réalisée lors de l'initialisation de l'annuaire Active Directory.
Cette variable n'a plus d'utilité une fois le module instancié.
Attention
Le site doit impérativement avoir été déclaré au préalable sur le contrôleur de domaine principal.
Truc & astuce
Si le contrôleur de domaine principal est un module Seth, la déclaration d'un site s'effectue facilement grâce à la fonction bash samba_update_site :
. /usr/lib/eole/samba4.sh
samba_update_site monsite 10.1.1.0/24
Environnement réseau
Adresse des contrôleurs du même domaine
Si plusieurs contrôleurs de domaine doivent être mis en place, il est impératif qu'ils se connaissent les uns les autres.
La variable Adresse IP des contrôleurs de domaine en relation avec ce contrôleur de domaine Active Directory permet de déclarer les adresses IP des autres contrôleurs du domaine.
Pour chacun des contrôleurs déclarés, il est possible de préciser si il a le rôle de serveur KDC[35] et/ou DNS[3].
Contrôleur de référence pour le volume SYSVOL
Dans le cas de la mise en œuvre d'un contrôleur de domaine additionnel, il est recommandé de déclarer le contrôleur de domaine principal en tant référence pour le volume SYSVOL.
Remarque
Dans le monde Microsoft, les contrôleurs de domaine sont habituellement tous au même niveau. Ceci est possible grâce à la réplication de l'annuaire Active Directory et à l'utilisation d'un système de fichiers distribué (DFS[36]).
À l'heure actuelle, la réplication du partage SYSVOL[37] n'est pas supportée par Samba. De ce fait, la mise en œuvre d'une architecture multi-DC[38] avec le module Seth nécessite de définir un contrôleur de domaine principal qui héberge les fichiers SYSVOL de référence et des contrôleurs de domaine additionnels sur lesquels ces fichiers sont synchronisés à intervalle régulier via rsync[39].
Résolutions DNS Inversées
À partir d'EOLE 2.7.2, la variable Créer les zones de résolutions DNS Inversées, permet de déclarer des zones de recherche inverse (PTR[40]).
La variable Créer les zones de résolutions DNS Inversées d'après la configuration réseau permet de créer automatiquement la zone associée au réseau local déclaré dans l'onglet Interface-0.
La variable Liste des zones à créer permet de déclarer des zones supplémentaires. Cela est nécessaire si les clients sont situés sur un réseau différent de celui du serveur.
AttentionFormat de saisie
Pour déclarer une zone, il faut saisir les 3 premiers octets IP du sous-réseau dans l'ordre inverse.
Exemple, pour déclarer le réseau 192.168.0.0/24, il faudra saisir : 0.168.192.
Partage de fichiers
Les partages utilisateur et les autres répertoires partagés peuvent être locaux et/ou hébergés sur d'autres serveurs Active Directory.
Sur le serveur local, il est possible d'activer ou non l'hébergement des partages « homes » et « profiles » des utilisateurs.
Dans le cas où l'on ne souhaite pas héberger ces répertoires localement, il est possible d'indiquer le nom d'hôte d'une machine du domaine (un serveur membre par exemple) sur lesquels ils seront stockés.
Archivage et sauvegarde des données
Un problème de corruption de la base Active Directory peut nécessiter de restaurer une sauvegarde sur le contrôleur de domaine principal et de relancer la synchronisation de tous les autres contrôleurs.
Attention
Il est primordial de disposer d'une archive ou d'une sauvegarde récente des données du serveur Active Directory.
Archivage local
La variable Archiver les données du DC permet d'activer l'exécution quotidienne d'un script d'archivage local et de choisir la destination de stockage de l'archive.
Les données du serveur Active Directory sont ainsi régulièrement sauvegardée (par défaut 1 fois par jour) dans le répertoire spécifié dans Destination de la sauvegarde.
Remarque
Le script utilisé pour l'archivage des données est inspiré d'un script mis à disposition par les développeurs du logiciel Samba : https://wiki.samba.org/index.php/Back_up_and_Restoring_a_Samba_AD_DC.
Sauvegarde locale ou distante
Il est possible de mettre œuvre un système de sauvegarde complet en installant le logiciel Bareos[42] sur le serveur.
La mise en place de cet outil s'effectue manuellement à l'aide de la commande suivante :
# apt-eole install eole-bareos
Après installation des paquets, la configuration du service de sauvegarde s'effectue dans l'interface de configuration du module à plusieurs endroits.
L'archivage du DC soit activé dans l'onglet : Archiver les données du DC doit être à oui.
Par défaut la sauvegarde Bareos est activée (Activer la sauvegarde du serveur à oui dans l'onglet Services) et la tâche de sauvegarde des données du serveur Active Directory est prise en compte (Sauvegarder les archives avec Bareos à oui dans l'onglet Active Directory).
Dans cette configuration, les éléments suivants sont directement sauvegardés par Bareos avec le support des ACL :
L'export des bases TDB est quant à lui géré par eole-schedule[43] avant l'exécution des sauvegardes.
La configuration à proprement parler des sauvegardes (distante, locale, durée de rétention, taux de compression…) s'effectue dans les onglets Directeur bareos et Stockage bareos.
Onglet Clamav : Configuration de l'anti-virus
EOLE propose un service anti-virus réalisé à partir du logiciel libre ClamAV.
Activation de l'anti-virus
L'onglet Clamav n'est accessible que si le service est activé dans l'onglet Services. Pour ce faire, passer la variable Activer l'anti-virus ClamAV à oui.
Sur le module AmonEcole, il est possible d'activer l'anti-virus sur le proxy, sur le serveur FTP et sur la messagerie.
Truc & astuce
Si aucun service n'utilise l'anti-virus, il est utile de le désactiver dans l'onglet Services. Il faut passer la variable Activer l'anti-virus ClamAV à non. L'onglet Clamav n'est alors plus visible.
Activation de l'anti-virus sur le proxy
Pour activer l'anti-virus en temps réel sur les fichiers filtrés par le proxy Internet, il faut passer la variable Activer l'anti-virus sur le proxy à oui dans l'onglet Clamav.
L'anti-virus sur le proxy permet d'analyser le trafic HTTP mais ne saurait en aucun cas remplacer la présence d'un anti-virus sur les postes clients.
Activation de l'anti-virus sur FTP
Pour désactiver l'anti-virus en temps réel sur les fichiers mis en ligne par FTP il faut passer la variable Activer l'anti-virus temps réel sur FTP à non dans l'onglet Clamav.
Activation de l'anti-virus sur la messagerie
Pour activer l'anti-virus sur la messagerie il faut passer la variable Activer l'antivirus sur la messagerie à oui dans l'onglet Clamav.
Contribuer
La base de données de virus est mise à jour avec l'aide de la communauté.
Il est possible de faire des signalements :
signaler de nouveaux virus qui ne sont pas détectés par ClamAV ;
signaler des fichiers propres qui ne sont pas correctement détectés par ClamAV (faux-positif).
Pour cela il faut utiliser le formulaire suivant (en) : http://www.clamav.net/contact#reports
L'équipe de ClamAV examinera votre demande et mettra éventuellement à jour la base de données.
En raison d'un nombre élevé de déposants, il ne faut pas soumettre plus de deux fichiers par jour.
Onglet Annuaire
Sur les modules Horus, Scribe et AmonEcole l'annuaire OpenLDAP est local.
Lorsque l'annuaire est configuré comme étant local, l'onglet propose 4 paramètres :
Activer le support du TLS: permet de désactiver le support du TLS :Port du serveur LDAP: permet de changer le port d'écoute du serveur LDAP ;Fichier de mot de passe de l'utilisateur de lecture: permet de changer le fichier de mot de passe de l'utilisateur de lecture :Définir le mot de passe admin de LDAP dans un fichier: permet de stocker et de réutiliser par ailleurs le mot de passe administrateur de l'annuaire dans le fichier/root/.writer.
Onglet Dhcp : Configuration du serveur DHCP
Sur les modules Seth et Scribe, les adresses servies doivent généralement être sur le réseau local (interface 0).
Sur le module AmonEcole, les adresses servies sont celles du réseau interne (interface 1).
Si le serveur est installé en DMZ, on pourra renseigner des adresses d'un autre réseau mais dans ce cas, il faudra activer le relayage du DHCP[20] sur le pare-feu.
Définition des sous-réseaux
Il faut définir une ou plusieurs plages (en anglais range) d'adresses attribuables par le serveur à l'aide du bouton + Adresse réseau de la plage DHCP.
La plage DHCP doit contenir au moins autant d'adresses que le nombre de stations susceptibles d'être connectées simultanément sur le réseau.
Les champs Adresse réseau de la plage DHCP et Masque de sous-réseau de la plage DHCP permettent de définir le réseau sur lequel les adresses doivent être servies.
Le champ Nom de la plage DHCP, disponible uniquement à partir de la version 2.6.2, permet d'identifier plus facilement la plage DHCP, notamment dans la nouvelle interface d'administration (EAD3). Pour administrer efficacement le DHCP dans l'interface de configuration, il convient de renseigner des noms de plages pertinents. Dans le cas d'une migration depuis une version antérieure d'EOLE, cette variable est arbitrairement initialisée avec les valeurs "plage0", "plage1"…
Les champs IP basse de la plage DHCP et IP haute de la plage DHCP doivent être comprise dans le réseau déclaré ci-dessus.
Le champ IP basse de la plage DHCP correspond, dans un réseau de classe C, à l'adresse IP dont le dernier octet a la valeur la plus petite.
Le champ IP haute de la plage DHCP correspond, dans un réseau de classe C, à l'adresse IP dont le dernier octet a la valeur la plus grande.
Le nombre d'adresses IP servies est déterminé par la différence entre la valeur la plus grande et la valeur la plus petite.
Les champs Nom de domaine à renvoyer aux clients DHCP, Adresse IP du routeur à renvoyer aux clients DHCP et Adresse IP du DNS à renvoyer aux clients DHCP permettent de spécifier des valeurs différentes pour chaque plage déclarée.
Pour la configuration de l'Adresse IP du routeur à renvoyer aux clients DHCP :
dans le mode une carte, l'adresse sera l'adresse IP de la passerelle saisie dans l'onglet
Interface-0;dans le cas du mode deux cartes, l'adresse IP du routeur sera l'adresse IP de l'
Interface-1(eth1).
L'Adresse IP du DNS à renvoyer aux clients DHCP
peut être l'adresse IP du DNS de votre FAI[21] pour une utilisation sans le module Amon. Il est également possible d'utiliser des serveurs DNS disponibles sur Internet.
Si vous disposez d'un module Amon ou d'un module AmonEcole, il est conseillé d'utiliser le module comme relais DNS[3], L'adresse à préciser dans le cas du mode deux cartes sera l'adresse IP du routeur et donc l'adresse IP de l'Interface-1 (eth1).
Truc & astuce
Sur le module AmonEcole, l'adresse IP du DNS à renvoyer correspond à celle renseignée dans Adresse IP pour addc (adresse_ip_domaine_link)de l'onglet Interface-1 de l'interface de configuration du module.
Paramètre de plage supplémentaire
Une variable supplémentaire est disponible en mode Normal pour identifier la plage configurée comme associée à des IP statiques.
Écran
- 1
Associer la plage à la distribution d’IP statiques
Par défaut à
non, cette variable permet de signifier, quand elle est passée àoui, que des réservations d’IP peuvent être effectuées dans la plage déclarée.
Cette variable n’a d’incidence que lorsque la gestion des réservations est effectuée grâce à l’action DHCP fournie par l’EAD3 (et non plus via l’EAD2). Il faut donc penser à activer la gestion du DHCP via l’EAD3 comme décrit dans la documentation associée.
Cette spécialisation possible des plages déclarées permet de réserver de manière effective des IP pour des postes. Le comportement précédent associé à l’EAD2 ne garantissait pas la réservation en cas d’extinction des postes concernés et de renouvellement des baux ou d’une requête nécessitant l’assignation de l’IP concernée à un nouveau poste se connectant.
Taux d'occupation des plages DHCP
Le serveur DHCP dispose d'un nombre d'adresses à distribuer pour les clients limité à la plage définie.
Lorsque toutes les adresses IP ont été distribuées, les clients suivants n'obtiennent pas d'adresse IP et ne peuvent accéder au réseau et à Internet.
Lorsque cela se produit, le manque d'adresse IP disponibles sur le serveur DHCP n'est pas forcément la première chose à laquelle on pense.
À partir de la version 2.8.1, un agent Zéphir permet de surveiller l'état d'occupation des plages DHCP dynamiques. Il est possible de paramétrer deux indicateurs d’occupation des plages associées à des IP dynamiques.
La variable Seuil de pourcentage d’adresses libre normal détermine un niveau d’occupation de la plage d’adresses au delà duquel l’administrateur doit se préoccuper. Lorsque le pourcentage d'adresses disponibles est inférieur au seuil, l'agent affiche une diode verte. Lorsque le seuil est dépassé l'agent affiche une diode grise.
Lorsque toutes les adresse IP de la plage DHCP sont occupées deux comportements sont possibles.
La variable Remonter une erreur en cas de plage pleine permet d’associer l’état saturé d’une plage d’adresses IP à un avertissement (variable à non) ou une erreur (variable à oui). Si la remontée d'erreur est à "non", l'agent Zéphir affiche une diode grise. Si la remontée d'erreur est à "oui", l'agent Zéphir affiche une diode rouge et les administrateurs sont notifiés selon la configuration des alertes.
Configurer la continuité de service
À partir de la version 2.6.2, il est possible de mettre en place de la continuité de service pour le DHCP.
Elle permet à deux serveurs DHCP d'opérer sur les mêmes sous-réseaux et mêmes pools d'adresses IP.
Il faut donc un serveur DHCP primaire et un serveur DHCP secondaire.
Truc & astuce
Les ports d'écoute et de contact du serveur primaire doivent être inversés pour le serveur secondaire. Il est également possible d'utiliser le port 647 partout, c'est à dire en écoute et en contact aussi bien sur le serveur primaire que sur le serveur secondaire.
Paramétrage du serveur primaire
Nom de la grappe: le nom de la grappe devra être le même sur le serveur primaire (local) et sur le serveur secondaire (pair) ;Rang du serveur dans la grappe: choisirprimarypour le serveur primaire ;Adresse IP du serveur DHCP local, en écoute du serveur pair: saisir l'adresse IP de l'interface sur laquelle écoute le service DHCP local (IP de l'Interface-0 dans la plupart des cas) ;Port de communication du serveur DHCP local, en écoute du serveur pair: le port par défaut pour un serveur primaire est647;Adresse IP du serveur pair: saisir l'adresse IP du serveur secondaire (pair) ;Port de communication du serveur pair: le port par défaut est847.
Paramétrage du serveur secondaire
Pour un serveur secondaire, les variables à paramétrer sont :
Nom de la grappe: le nom de la grappe doit être le même que pour le serveur primaire (local) ;Rang du serveur dans la grappe: choisirsecondarypour le serveur secondaire ;Adresse IP du serveur DHCP local, en écoute du serveur pair: saisir l'adresse IP de l'interface sur laquelle écoute le service DHCP local (IP de l'Interface-0 dans la plupart des cas) ;Port de communication du serveur DHCP local, en écoute du serveur pair: le port par défaut pour un serveur secondaire est847;Adresse IP du serveur pair: saisir l'adresse IP du serveur secondaire (pair) ;Port de communication du serveur pair: le port par défaut est647.
Onglet Onduleur
Sur chaque module EOLE, il est possible de configurer votre onduleur.
Le logiciel utilisé pour la gestion des onduleurs est NUT[22]. Il permet d'installer plusieurs clients sur le même onduleur. Dans ce cas, une machine aura le contrôle de l'onduleur (le maître/master) et en cas de coupure, lorsque la charge de la batterie devient critique, le maître indiquera aux autres machines (les esclaves) de s'éteindre avant de s'éteindre lui-même.
Certains onduleurs sont assez puissants pour alimenter plusieurs machines.
http://www.networkupstools.org/
Le projet offre une liste de matériel compatible avec le produit mais cette liste est donnée pour la dernière version du produit :
Truc & astuce
Pour connaître la version de NUT qui est installée sur le module :
# apt-cache policy nut
ou encore :
# apt-show-versions nut
Si la version retournée est 2.7.1 on peut trouver des informations sur la prise en charge du matériel dans les notes de version à l'adresse suivante :
http://www.networkupstools.org/source/2.7/new-2.7.1.txt
Si le matériel n'est pas dans la liste, on peut vérifier que sa prise en charge soit faite par une version plus récente et donc non pris en charge par la version actuelle :
L'onglet Onduleur n'est accessible que si le service est activé dans l'onglet Services.
Si l'onduleur est branché directement sur le module il faut laisser la variable Configuration sur un serveur maître à oui, cliquer sur le bouton + Nom de l'onduleur et effectuer la configuration liée au serveur maître.
La configuration sur un serveur maître
Même si le nom de l'onduleur n'a aucune conséquence, il est obligatoire de remplir cette valeur dans le champ Nom pour l'onduleur.
Il faut également choisir le nom du pilote de l'onduleur dans la liste déroulante Pilote de communication de l'onduleur et éventuellement préciser le Port de communication si l'onduleur n'est pas USB.
Les champs Numéro de série de l'onduleur, Productid de l'onduleur et Upstype de l'onduleur sont facultatifs si il n'y a pas de serveur esclave. Il n'est nécessaire d'indiquer ce numéro de série que dans le cas où le serveur dispose de plusieurs onduleurs et de serveurs esclaves.
Remarque
Le nom de l'onduleur ne doit contenir que des chiffres ou des lettres en minuscules : [a-z][0-9] sans espaces, ni caractères spéciaux.
NUT SNMP
À partir d'EOLE 2.7.2, les onduleurs utilisant une connexion SNMP[46] (driver snmp-ups) sont gérés nativement et des variables supplémentaires apparaissent dans l'interface.
La configuration ci-dessous convient, par exemple, pour un onduleur NITRAM Cyberpower :
Si le driver snmp-ups est sélectionné, le paramétrage de la Fréquence d'interrogation de upsmon est également proposé mais en mode expert uniquement.
Configuration d'un second onduleur sur un serveur maître
Si le serveur dispose de plusieurs alimentations, il est possible de les connecter chacune d'elle à un onduleur différent.
Il faut cliquer sur le bouton + Nom de l'onduleur pour ajouter la prise en charge d'un onduleur supplémentaire dans l'onglet Onduleur de l'interface de configuration du module.
Si les onduleurs sont du même modèle et de la même marque, il faut ajouter de quoi permettre au pilote NUT de les différencier.
Cette différenciation se fait par l'ajout d'une caractéristique unique propre à l'onduleur. Ces caractéristiques dépendent du pilote utilisé, la page de man du pilote vous indiquera lesquelles sont disponibles.
Exemple pour le pilote Solis :
# man solis
Afin de récupérer la valeur il faut :
- ne connecter qu'un seul des onduleurs ;
- le paramétrer comme indiqué dans la section précédente ;
- exécuter la commande :
upsc <nomOnduleurDansGenConfig>@localhost|grep <nom_variable>; - débrancher l'onduleur ;
- brancher l'onduleur suivant ;
- redémarrer
nutavec la commande :# service nut restart; - exécuter à nouveau la commande pour récupérer la valeur de la variable.
Une fois les numéros de série connus, il faut les spécifier dans les champ Numéro de série de l'onduleur de chaque onduleur.
ExempleDeux onduleurs de même marque
Pour deux onduleurs de marque MGE, reliés à un module Scribe par câble USB, il est possible d'utiliser la valeur "serial", voici comment la récupérer :
# upsc <nomOnduleurDansGenConfig>@localhost | grep serial
driver.parameter.serial: AV4H4601W
ups.serial: AV4H4601W
ExempleDeux onduleurs différents
Un onduleur sur port série :
- Nom de l'onduleur :
eoleups; - Pilote de communication de l'onduleur :
apcsmart; - Port de communication de l'onduleur :
/dev/ttyS0.
Si l'onduleur est branché sur le port série (en général : /dev/ttyS0), les droits doivent être adaptés.
Cette adaptation est effectuée automatiquement lors de l'application de la configuration.
Onduleur sur port USB :
- Nom de l'onduleur :
eoleups; - Pilote de communication de l 'onduleur :
usbhid-ups; - Port de communication de l'onduleur :
auto.
La majorité des onduleurs USB sont détectés automatiquement.
Attention
Attention, seul le premier onduleur sera surveillé.
Autoriser des esclaves distants à se connecter
Pour déclarer un serveur esclave, il faut passer la variable Autoriser des esclaves distants à se connecter à oui puis ajouter un utilisateur sur le serveur maître afin d'autoriser l'esclave a se connecter avec cet utilisateur.
Idéalement, il est préférable de créer un utilisateur différent par serveur même s'il est possible d'utiliser un unique utilisateur pour plusieurs esclaves. Pour configurer plusieurs utilisateurs il faut cliquer sur le bouton + Utilisateur de surveillance de l'onduleur.
Pour chaque utilisateur, il faut saisir :
un
Utilisateur de surveillance de l'onduleur;
un
Mot de passe de surveillance de l'onduleurassocié à l'utilisateur précédemment créé ;
l'
Adresse IP du réseau de l'esclave(cette valeur peut être une adresse réseau plutôt qu'une adresse IP) ;
le
Masque de l'IP du réseau de l'esclave(comprendre le masque du sous réseau de l'adresse IP de l'esclave)
Remarque
Le nom de l'onduleur ne doit contenir que des chiffres ou des lettres en minuscules : [a-z][0-9] sans espaces, ni caractères spéciaux.
Attention
Chaque utilisateur doit avoir un nom différent.
Les noms root et localmonitor sont réservés.
Complément
Pour plus d'informations, vous pouvez consulter la page de manuel :
man ups.conf
ou consulter la page web suivante : http://manpages.ubuntu.com/manpages/focal/en/man5/ups.conf.5.html
Configurer un serveur esclave
Une fois qu'un serveur maître est configuré et fonctionnel, il est possible de configurer le ou les serveurs esclaves.
Pour configurer le module en tant qu'esclave, il faut activer le service dans l'onglet Services puis, dans l'onglet Onduleur, passer la variable Configuration sur un serveur maître à non.
Il faut ensuite saisir les paramètres de connexion à l'hôte distant :
le
Nom de l'onduleur distant(valeur renseignée sur le serveur maître) ;
l'
Hôte gérant l'onduleur(adresse IP ou nom d'hôte du serveur maître) ;
l'
Utilisateur de l'hôte distant(nom d'utilisateur de surveillance créé sur le serveur maître ) ;
le
Mot de passe de l'hôte distant(mot de passe de l'utilisateur de surveillance créé sur le serveur maître).
Truc & astuce
À partir d'EOLE 2.7.2, il est possible de déclarer plusieurs onduleurs distants.
Exemple de configuration
Exemple
Sur le serveur maître :
- Nom de l'onduleur :
eoleups; - Pilote de communication de l'onduleur :
usbhid-ups; - Port de communication de l'onduleur :
auto; - Utilisateur de surveillance de l'onduleur :
scribe; - Mot de passe de surveillance de l'onduleur :
99JJUE2EZOAI2IZI10IIZ93I187UZ8; - Adresse IP du réseau de l'esclave :
192.168.30.20; - Masque de l'IP du réseau de l'esclave :
255.255.255.255.
Exemple
Sur le serveur esclave :
- Nom de l'onduleur distant :
eoleups; - Hôte gérant l'onduleur :
192.168.30.10; - Utilisateur de l'hôte distant :
scribe; - Mot de passe de l'hôte distant :
99JJUE2EZOAI2IZI10IIZ93I187UZ8.
Onglet Rvp : Mettre en place le réseau virtuel privé
Le réseau virtuel privé[47] (RVP) peut être activé au moment de la configuration et de l'instanciation d'un module Amon ou sur un module Amon déjà en exploitation.
Mise en place du RVP
L'onglet Rvp apparaît après activation du service dans l'onglet Services.
Configuration des tunnels
Attention
Le mode VPN database n'est plus supporté et n'est plus disponible à partir de la version 2.5.1 du module Amon. La configuration des tunnels s'effectue d'office en mode fichier plat.
Paramètres agent Zéphir RVP et diagnose
Le champ Adresses IP à tester dans test-rvp permet de saisir une ou plusieurs adresses IP qui seront utilisées par le diagnose et par l'agent Zéphir pour tester des adresses IP à l'autre extrémité des tunnels.
AGRIATES
Si le serveur est membre d'AGRIATES[48] il faut passer la variable Serveur membre du réseau AGRIATES à oui.
Adresse du DNS permettant de résoudre les in.ac-acad.frpermet de spécifier l'adresse IP du serveur DNS permettant de résoudre les noms de zone AGRIATES (in.ac-académie.fr) ;Nom DNS de la zone résolue par le DNS AGRIATES: permet de spécifier d'autres noms de zones résolues par le DNS AGRIATES.
Application de la configuration et gestion du RVP
Activation du RVP au moment de l'instanciation du serveur Amon
Au lancement de l'instanciation, la question suivante vous est posée :
Voulez-vous configurer le Réseau Virtuel Privé maintenant ? [oui/non]
[non] :
Vous devez répondre oui à cette question.
Deux choix sont alors proposés :
1.Manuel permet de prendre en compte la configuration RVP présente sur une clé USB ;
2.Zéphir active la configuration RVP présente sur le serveur Zéphir. Cela suppose que le serveur est déjà enregistré sur Zéphir. Il sera demandé un compte Zéphir et son code secret ainsi que l'identifiant Zéphir du serveur Sphynx auquel associer le module Amon.
Dans les deux cas, le code secret de la clé privée est demandée. Si le code secret est correct le RVP est configuré pour cette machine et l'instanciation peut se poursuivre...
Activation du RVP sur des modules Amon déjà en exploitation
Pour activer un RVP sur un module Amon déjà instancié, il faut lancer en tant qu'utilisateur root la commande active_rvp init.
Suppression du RVP
Pour supprimer un RVP, il faut lancer en tant qu'utilisateur root la commande active_rvp delete.
Onglet Applications web : Configuration des applications web
Les onglets Applications web et Apache ne sont disponibles qu'après activation du service, Activer le serveur web Apache à oui, dans l'onglet Services.
L'onglet Applications web permet un réglage minimum pour le fonctionnement des applications web. Il permet aussi d'activer/désactiver toutes les applications web EOLE installées sur le module.
Nom de domaine des applications web
Le choix du Nom de domaine des applications web est essentiel.
Pour un bon fonctionnement de toutes les applications, il est impératif d'utiliser un nom de domaine.
Dans la mesure du possible, il faut que celui-ci soit résolvable sur Internet. Si ce n'est pas le cas, il est possible d'utiliser un nom de domaine local diffusé par le serveur DNS[3] de l'établissement.
Ce paramètre ne doit pas être précédé du nom du protocole.
Attention
Application web par défaut
L'application web par défaut sera celle renseignée dans la variable : Application web par défaut (redirection).
Exemple
Si la variable Application web par défaut vaut /webmail, alors l'adresse http://<adresse_serveur>/ pointera vers http://<adresse_serveur>/webmail/
Serveur web et proxy inverse
Lorsque le serveur web est derrière un proxy inverse, c'est l'adresse IP du proxy inverse et non celle de l'utilisateur qui est enregistrée dans les fichiers de journalisation. Pour éviter cela, il est possible de passer la variable Le serveur web est derrière un reverse proxy à oui et de déclarer son adresse (généralement l'adresse IP du module Amon sur la zone) dans Adresse IP du serveur reverse proxy.
Remarque
Sur le module AmonEcole, si le proxy inverse est activé, les variables sont calculées et masquées : Le serveur web est derrière un reverse proxy est à oui et l'Adresse IP du serveur reverse proxy est celle du bridge interne : 192.0.2.1.
Attention
La déclaration du proxy inverse ajoute une entête qui contient une adresse IP qui peut potentiellement être falsifiée depuis la machine source.
En cas d'utilisation d'un proxy, la récupération de l'adresse IP des stations du réseau local n'est pas garantie.
Complément
Sur EOLE 2.6.0 et inférieur, cette fonctionnalité était implémentée via le module Apache additionnel RPAF : https://github.com/gnif/mod_rpaf.
Sur EOLE 2.6.1 et supérieur, cette fonctionnalité est implémentée via le module Apache natif RemoteIP : https://httpd.apache.org/docs/current/fr/mod/mod_remoteip.html
Activer Bareos WebUI (gestion de la sauvegarde)
Bareos WebUI est une application web permettant de surveiller et gérer les sauvegardes Bareos.
Activer Adminer (administration des bases de données)
Adminer permet de gérer les bases de données MySQL hébergées par le module.
Elle vient en remplacement de l'application phpMyAdmin.
Pour activer/désactiver l'application web Adminer il faut passer la variable : Activer Adminer (administration de bases de données) à oui.
Activer nextcloud (gestionnaire de fichiers)
Cette variable permet d'activer/désactiver l'application web Nextcloud sur le module.
Nextcloud est une application web qui permet à l'utilisateur de gérer ses fichiers au travers d'un navigateur.
Une seconde variable permet de personnaliser la taille maximum autorisée pour les fichiers téléversés via l'application.
Truc & astuce
Si un proxy est déclaré dans l'onglet Général, Nextcloud l'utilisera pour accéder à des ressources externes.
La variable du mode expert : Domaines exclus du proxy permet de déclarer des exceptions.
Activer EOE
Cette variable permet d'activer/désactiver l'application web EOE sur le module.
EOE propose une interface simple contenant un ensemble d'outils à destination des élèves.
Activer EOP
Cette variable permet d'activer/désactiver l'application web EOP sur le module.
EOP propose une interface simple contenant un ensemble d'outils à destination des enseignants.
Par défaut, tous les professeurs principaux peuvent accéder à la section Gestion d'EOP.
À partir d'EOLE 2.8.1, la variable Permettre aux enseignants de gérer les élèves et mots de passes permet de désactiver l'accès à cette section à tous les professeurs.
Par défaut, seuls les professeurs principaux peuvent modifier le mot de passe de leurs élèves.
En mode expert, en passant la variable Permettre aux enseignants de changer le mot de passe de tous les élèves à oui, chaque professeur pourra changer le mot de passe de n'importe quel élève dans l'application EOP.
La variable Permettre aux enseignants admin de créer des comptes temporaires permet aux professeurs admin de créer des comptes avec une date d'expiration.
Activer Roundcube (webmail)
Cette variable permet d'activer/désactiver l'application web Rouncube sur le module.
Roundcube est une application web qui permet à l'utilisateur de gérer ses courriers électroniques au travers d'un navigateur.
Une seconde variable permet de définir le thème utilisé pour cette application.
Activer Thèmes
Complément
Toutes les applications web pré-packagées installées manuellement apparaissent dans cet onglet pour éventuellement être désactivées.
Onglet Eole sso : Configuration du service SSO pour l'authentification unique
Le serveur EoleSSO est prévu pour être déployé sur un module EOLE.
Il est cependant possible de l'utiliser dans un autre environnement en modifiant manuellement le fichier de configuration /usr/share/sso/config.py.
Cette section décrit la configuration du serveur depuis l'interface de configuration du module disponible sur tous les modules EOLE. Les valeurs définies par défaut simplifient la configuration dans le cadre d'une utilisation prévue sur les modules EOLE.
Serveur local ou distant
L'activation du serveur EoleSSO s'effectue dans l'onglet Services.
La variable Utiliser un serveur EoleSSO permet :
-
non: de ne pas utiliser de SSO sur le serveur ; -
local: d'utiliser et de configurer le serveur EoleSSO local ; -
distant: d'utiliser un serveur EoleSSO distant (configuration cliente).
Adresse et port d'écoute
L'onglet supplémentaire Eole-sso apparaît si l'on a choisi d'utiliser un serveur EoleSSO local ou distant.
Dans le cas de l'utilisation du serveur EoleSSO local, Nom de domaine du serveur d'authentification SSO doit être renseigné avec le nom DNS du serveur.
Durée de vie d'une session (en secondes): indique la durée de validité d'une session SSO sur le serveur. Cela n'influence pas la durée de la session sur les applications authentifiées, seulement la durée de la validité du cookie utilisé par le serveur SSO. Au delà de cette durée, l'utilisateur devra obligatoirement se ré-authentifier pour être reconnu par le serveur SSO. Par défaut, la durée de la session est de 3 heures (7200 secondes).CSS par défaut du service SSO (sans le .css): permet de spécifier une CSS différente pour le formulaire d'authentification affiché par le serveur EoleSSO. Le fichier CSS doit se trouver dans le répertoire/usr/share/sso/interface/theme/style/<nom_fichier>.css. Se reporter au chapitre personnalisation pour plus de possibilités à ce sujet.
AttentionPort 443
Si le port HTTPS (443) est déclaré pour ce service, alors celui-ci est uniquement accessible via l’URL https://<nom_du_serveur>/sso.
L’URL de la forme https://<nom_du_serveur>:<port>/ reste valable pour les autres valeurs de port que 443.
Dans le cas de l'utilisation d'un serveur EoleSSO distant, seuls les paramètres Nom de domaine du serveur d'authentification SSO et Port utilisé par le service EoleSSO sont requis et les autres options ne sont pas disponibles car elles concernent le paramétrage du serveur local.
Configuration LDAP
Le serveur EoleSSO se base sur des serveurs LDAP[11] pour authentifier les utilisateurs et récupérer leurs attributs.
Il est possible ici de modifier les paramètres d'accès à ceux-ci :
- l'adresse et le port d'écoute du serveur LDAP ;
- le chemin de recherche correspond à l'arborescence de base dans laquelle rechercher les utilisateurs (basedn) ;
- un libellé à afficher dans le cas où un utilisateur aurait à choisir entre plusieurs annuaires/établissements pour s'authentifier (voir le chapitre
Gestion des sources d'authentifications multiples) ; - un fichier d'informations à afficher dans le cadre qui est présenté en cas d'homonymes. Ces informations apparaîtront si l'utilisateur existe dans l'annuaire correspondant. Les fichiers doivent être placés dans le répertoire
/usr/share/sso/interface/info_homonymes; - DN[50] et mot de passe d'un utilisateur en lecture pour cet annuaire ;
- attribut de recherche des utilisateurs : indique l'attribut à utiliser pour rechercher l'entrée de l'utilisateur dans l'annuaire (par défaut, uid)
- choix de la disponibilité ou non de l'authentification par clé OTP[51] si disponible (voir plus loin).
Attention
Dans le cas où vous désirez fédérer EoleSSO avec d'autres fournisseurs de service ou d'identité (ou 2 serveurs EoleSSO entre eux), il est nécessaire de configurer un utilisateur ayant accès en lecture au serveur LDAP configuré.
Il sera utilisé pour récupérer les attributs des utilisateurs suite à réception d'une assertion d'un fournisseur d'identité (ou dans le cas d'une authentification par OTP).
Cet utilisateur est pré-configuré pour permettre un accès à l'annuaire local sur les serveurs EOLE.
Sur les modules EOLE, la configuration recommandée est la suivante :
- utilisateur :
cn=reader,o=gouv,c=fr - fichier de mot de passe :
/root/.reader
Si vous connectez EoleSSO à un annuaire externe, vous devez définir vous même cet utilisateur :
Utilisateur de lecture des comptes ldap: renseignez son dn complet dans l'annuairefichier de mot de passe de l'utilisateur de lecture: entrez le chemin d'un fichier ou vous stockerez son mot de passe (modifiez les droits de ce fichier pour qu'il soit seulement accessible par l'utilisateurroot)
Passer la variable Information LDAP supplémentaires (applications) à oui permet de configurer pour chaque annuaire LDAP déclaré des attributs supplémentaires qui seront utilisés par les applications web (DN racine de l'arbre utilisateurs, DN racine de l'arbre groupes, Champ 'nom d'affichage' de l'utilisateur, Champ 'mail' de l'utilisateur, Champ 'fonction' de l'utilisateur, Champ 'categorie' de l'utilisateur, Champ 'rne' de l'utilisateur, Champ 'fredurne' de l'utilisateur…).
Passer la variable Permettre le changement de mot de passe sur un serveur AD à oui permet à l'utilisateur de changer son mot de passe depuis la mire SSO si ce dernier à expiré.
Il est alors nécessaire de renseigner le nom du domaine AD et le nom du serveur AD sur lequel changer le mot de passe.
Serveur SSO parent
Un autre serveur EoleSSO peut être déclaré en tant que serveur parent dans la configuration (adresse et port). Se reporter au chapitre traitant de la fédération pour plus de détails sur cette notion.
Si un utilisateur n'est pas connu dans le référentiel du serveur EoleSSO, le serveur essayera de l'authentifier auprès de son serveur parent (dans ce cas, la liaison entre les 2 serveurs s'effectue par l'intermédiaire d'appels XML-RPC[52] en HTTPS, sur le port défini pour le serveur EoleSSO).
Si le serveur parent authentifie l'utilisateur, il va créer un cookie de session local et rediriger le navigateur client sur le serveur parent pour qu'une session y soit également créée (le cookie de session est accessible seulement par le serveur l'ayant créé).
Attention
Ce mode de fonctionnement n'est plus recommandé aujourd'hui. Il faut préférer à cette solution la mise en place d'une fédération par le protocole SAML.
Fédération d'identité
Le serveur EoleSSO permet de réaliser une fédération vers un autre serveur EoleSSO ou vers d'autre types de serveurs compatibles avec le protocole SAML[53] (version 2).
Nom d'entité SAML du serveur eole-sso (ou rien) : nom d'entité du serveur EoleSSO local à indiquer dans les messages SAML. Si le champ est laissé à vide, une valeur est calculée à partir du nom de l'académie et du nom de la machine.
Cacher le formulaire lors de l'envoi des informations de fédération : permet de ne pas afficher le formulaire de validation lors de l'envoi des informations de fédération à un autre système. Ce formulaire est affiché par défaut et indique la liste des attributs envoyés dans l'assertion SAML permettant la fédération.
Authentification OTP
Il est possible de configurer EoleSSO pour gérer l'authentification par clé OTP à travers le protocole securID[54] de la société EMC (précédemment RSA).
Pour cela il faut :
installer et configurer le client PAM/Linux proposé par EMC (voir annexes)
Répondre
ouià la questionGestion de l'authentification OTP (RSA SecurID)
Des champs supplémentaires apparaissent :
Pour chaque annuaire configuré, un champ permet de choisir la manière dont les identifiants à destination du serveur OTP sont gérés. '
inactifs' (par défaut) indique que l'authentification OTP n'est pas proposée à l'utilisateur. Avec'identiques', le login local (LDAP) de l'utilisateur sera également utilisé comme login OTP. La dernière option est 'configurables', et indique que les utilisateurs doivent renseigner eux même leur login OTP. Dans ce dernier cas, l'identifiant est conservé sur le serveur EoleSSO pour que l'utilisateur n'ait pas à le renseigner à chaque fois (fichier/usr/share/sso/securid_users/securid_users.ini).Le formulaire d'authentification détecte automatiquement si le mot de passe entré est un mot de passe OTP. Il est possible de modifier la reconnaissance si elle ne convient pas en réglant les tailles minimum et maximum du mot de passe et en donnant une expression régulière qui sera vérifiée si la taille correspond. Les options par défaut correspondent à un mot de passe de 10 à 12 caractères uniquement numériques.
Certificats
Les communications de et vers le serveur EoleSSO sont chiffrées.
Sur les modules EOLE, des certificats auto-signés sont générés à l'instanciation[55] du serveur et sont utilisés par défaut.
Il est possible de renseigner un chemin vers une autorité de certification et un certificat serveur dans le cas de l'utilisation d'autres certificats (par exemple, des certificat signés par une entité reconnue).
Les certificats doivent être au format PEM.
Onglet Mode Restreint : Configuration des restrictions de navigation
Le mode restreint ou safe search[56] permet d'activer la navigation restreinte, soit bloquer les contenus "sensibles" pour les utilisateurs du domaine.
Les différentes cibles du mode restreint
L'activation du mode restreint s'effectue dans l'onglet Mode restreint.
Il est possible d'activer le mode restreint pour certaines applications
-
Forcer le "mode restreint" pour les recherches Google: bloque les contenus à caractères sensibles pour les résultat de recherche sur Google ; -
Forcer le "mode restreint" pour les vidéos Youtube: bloque les contenus à caractères sensibles pour les vidéos Youtube ; -
Forcer le "mode restreint" pour les recherches Bing: bloque les contenus à caractères sensibles pour les résultat de recherche sur Bing ; -
Forcer le "mode restreint" pour les recherches Duckduckgo: bloque les contenus à caractères sensibles pour les résultat de recherche sur Duckduckgo ; -
Forcer le "mode restreint" pour les recherches Qwant: bloque les contenus à caractères sensibles pour les résultats de recherche sur Qwant ;
Remarque
Sur les versions précédentes, la mise en œuvre du mode restreint s'appuyait sur des réécritures d'URL gérées directement dans le logiciel de filtrage e2guardian[2].
À partir d'EOLE 2.8.1, ce sont des redirections DNS[3] qui sont utilisées. Cela nécessite d'avoir la main sur ce service, ce qui n'est pas le cas sur le module Eolebase+Proxy.
Onglet Messagerie
Même sur les modules ne fournissant aucun service directement lié à la messagerie, il est nécessaire de configurer une passerelle SMTP valide car de nombreux outils sont susceptibles de nécessiter l'envoi de courriers électroniques.
La plupart des besoins concernent l'envoi d'alertes ou de rapports.
Exemples : rapports de sauvegarde, alertes système, ...
Service anti-spam
Activer le service anti-spam SpamAssassin permet d'activer/désactiver le service SpamAssasin. Le but de ce logiciel est de filtrer les courriers électroniques reconnus comme étant indésirables.
Service de récupération de courrier électronique (POP/IMAP)
Activer le serveur de courrier permet de désactiver le service d'échange de courrier ou de choisir le ou les protocoles supportés : POP, IMAP ou POP -IMAP.
Serveur de listes
Activer le serveur de listes de diffusion Sympa permet de désactiver le gestionnaire de publipostage.
Serveur d'envoi/réception (SMTP)
Les paramètres communs à renseigner sont les suivants :
Nom de domaine de la messagerie de l'établissement (ex : monetab.ac-aca.fr), saisir un nom de domaine valide, par défaut un domaine privé est automatiquement créé avec le préfixei-;Adresse électronique d'envoi pour le compte root, saisir l'adresse que l'on souhaite utiliser pour l'envoi de courriers électroniques depuis le compte root.Adresse électronique recevant les courriers électroniques à destination du compte root, permet de configurer une adresse pour recevoir les éventuels messages envoyés par le système.Taille maximale d'un message à envoyer en Mo, indiquer la taille maximale des courrier électroniques qui seront envoyés par exim.
Attention
Le Nom de domaine de la messagerie de l'établissement (onglet Messagerie) ne peut pas être le même que celui d'un conteneur. Le nom de la machine (onglet Général) donne son nom au conteneur maître aussi le Nom de domaine de la messagerie de l'établissement ne peut pas avoir la même valeur.
Dans le cas contraire les courriers électroniques utilisant le nom de domaine de la messagerie de l'établissement seront réécris et envoyés à l'adresse électronique d'envoi du compte root.
Cette contrainte permet de faire en sorte que les courrier électroniques utilisant un domaine de type @<NOM CONTENEUR>.* soient considérés comme des courriers électroniques systèmes.
Attention
Dans le cas où le Nom de domaine de la messagerie de l’établissement n’est pas le même que la concaténation du Nom de la machine et du Nom DNS du réseau local, il peut être nécessaire d’activer la réécriture des en-têtes pour avoir des informations cohérentes avec l’enveloppe des courriels.
En mode normal, il est possible de configurer le nom de l'émetteur des messages pour le compte root.
Attention
Certaines passerelles n'acceptent que des adresses de leur domaine.
Il est également possible de configurer la taille maximale des messages électroniques.
Attention
Sur les modules utilisant le webmail Roundcube, elle ne devrait pas dépasser la taille maximale d'un fichier à charger définie pour Apache.
Il est possible de changer la taille des quotas de boîtes aux lettres électroniques qui est fixé par défaut à 20 Mo.
Relai des messages
La variable Passerelle SMTP, permet de saisir l'adresse IP ou le nom DNS de la passerelle SMTP à utiliser.
Remarque
Afin d'envoyer directement des courriers électroniques sur Internet il est possible de désactiver l'utilisation d'une passerelle en passant Router les courriels par une passerelle SMTP à non.
Sur les modules possédant un serveur SMTP (Scribe, AmonEcole), ces paramètres sont légèrement différents et des services supplémentaires sont configurables.
Il est possible d'activer le support du TLS[15] pour l'envoi de messages.
Si la passerelle SMTP[57] accepte le TLS, il faut choisir le port en fonction de la prise en charge de la commande STARTTLS[58].
Pour cela il suffit d'indiquer le port spécifique dans l'option Utilisation de TLS (SSL) par la passerelle SMTP il y a cinq possibilités.
nonport 25port 465port 587port personnalisé
Le dernier choix permet à l'utilisateur de saisir un port différent de ceux proposés dans une nouvelle option appelée Port de la passerelle SMTP.
Dans le cas où la passerelle nécessiterait une authentification il est nécessaire de le signaler en passant la variable La passerelle requiert une authentification à oui.
Cette action affiche deux nouvelles variables :
Onglet Directeur bareos
Le nom du directeur est une information importante, il est utilisé en interne dans le logiciel mais, surtout, il est nécessaire pour configurer un client Bareos ou pour joindre le serveur de stockage depuis un autre module.
À l'enregistrement du fichier de configuration il ne sera plus possible de modifier le nom du directeur. En effet, cette variable est utilisée dans les noms des fichiers de sauvegarde.
AttentionMigration de version EOLE
À partir d'EOLE 2.8.1, Bareos fonctionne avec PostgreSQL[59] tandis que sur les versions précédentes, il était possible de choisir entre MySQL et SQLite.
Il n'existe pas de migration de données entre ces bases.
Dans le cas d'une montée de version vers 2.8.1, il vous faudra penser à effectuer une nouvelle sauvegarde dès que possible.
Configuration des durées de rétention
Les trois types de sauvegarde, complète, différentielle, incrémentale, disposent chacune d’un pool de volumes distinct. Cela permet de paramétrer des durées de rétention[60] et des tailles pour ces volumes différents pour chaque type de sauvegarde.
La sauvegarde du catalogue est également gérée avec un pool de volume distinct. Seule la taille des volumes est paramétrable cependant.
Écran
- 1
Configuration du pool du catalogue
Taille des volumes pour la sauvegarde du catalogue (taille illimitée si à 0)
- 2
Configuration du pool pour la sauvegarde complète
Durée de rétention et taille des volumes pour la sauvegarde complète
- 3
Configuration du pool pour la sauvegarde différentielle
Durée de rétention et taille des volumes pour la sauvegarde différentielle
- 4
Configuration du pool pour la sauvegarde incrémentale
Durée de rétention et taille des volumes pour la sauvegarde incrémentale
La durée de rétention des fichiers détermine le temps de conservation avant l'écrasement.
Plus les durées de rétention sont importantes, plus l'historique sera important et plus l'espace de stockage nécessaire sera important.
L’espace alloué à un volume n’est pas recyclé (réutilisé pour une autre sauvegarde) avant que le volume ne soit complet et que les durées de rétention ne soient atteintes.
Limiter la taille des volumes est utile dans deux cas :
le système de fichier hébergeant les volumes impose une contrainte sur la taille des fichiers (typiquement les systèmes FAT montés via le protocole SMB, à l’origine de la contrainte de 2 Go) ;
on souhaite pouvoir recycler plus rapidement les volumes (de petite taille, les volumes sont associés à moins de jobs ; il faut donc moins de temps pour purger l’ensemble des jobs associés et pouvoir recycler les volumes).
Sur les serveurs avec un historique de sauvegarde conséquent, il n’est pas rare que la limite par défaut de 2 Go pour le pool du Catalogue finisse par poser problème : ce pool n’autorise qu’un volume qui doit être d’une taille suffisante pour contenir la sauvegarde du catalogue.
Exemple
Il peut être intéressant de conserver un historique long mais avec peu d'états intermédiaires.
Pour cela, voici un exemple de configuration :
- 6 mois de sauvegardes totales ;
- 5 semaines de sauvegardes différentielles ;
- 10 jours de sauvegardes incrémentales.
Avec la politique de sauvegarde suivante :
- une sauvegarde totale par mois ;
- une sauvegarde différentielle par semaine ;
- une sauvegarde incrémentale du lundi au vendredi.
Dans l'historique, il y aura donc une sauvegarde par jour de conservée pendant 10 jours, une sauvegarde par semaine pendant 5 semaines et une sauvegarde mensuelle pendant 6 mois.
Attention
Une modification de la durée de rétention en cours de production n'aura aucun effet sur les sauvegardes déjà effectuées, elles seront conservées et recyclées mais sur la base de l'ancienne valeur, stockée dans la base de données.
Afin de prendre en compte la nouvelle valeur pour les sauvegardes suivantes, il faut utiliser les outils Bareos pour mettre à jour la base de données :
# bconsole
*update
*2
*<numéro du pool de volumes de sauvegarde>
Une autre solution consiste à vider le support de sauvegarde ou prendre un support de sauvegarde ne contenant aucun volume et à ré-initialiser la base de données Bareos avec la commande :
# bareosregen.sh
La regénération du catalogue de bareos va écraser l'ancienne base, confirmez-vous ? [oui/non]
[non] : oui
Onglet Stockage bareos
Dans l'onglet Stockage bareos il est possible de choisir un nom de serveur de stockage et d'autoriser des directeurs distants à se connecter au présent serveur de stockage.
Autoriser un ou plusieurs directeurs distants à se connecter
Pour autoriser un ou plusieurs directeurs distants à se connecter il faut cliquer sur + Nom du directeur Bareos distant, le détail de l'autorisation s'affiche.
Pour ce faire il faut se munir des paramètres du directeur distant :
son nom ;
son adresse IP ;
son mot de passe.
Attention
Les sauvegardes sont des informations sensibles. Il ne faut pas utiliser de mot de passe facilement déductible.
Onglet Authentification : Configuration du proxy authentifié et de FreeRADIUS
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é.
Activer une deuxième instance de Squid
Activer une deuxième instance de Squid permet une double authentification, c'est à dire la possibilité de pouvoir configurer deux types distincts d'authentification proxy.
Par exemple, pouvoir utiliser à la fois une authentification NTLM/SMB et une authentification LDAP.
L'implémentation retenue est d'utiliser une instance du logiciel Squid par type d'authentification.
Pour profiter de cette fonctionnalité, il faut passer Activer une deuxième instance de Squid à oui.
Cela fera apparaître l'onglet Proxy authentifié 2.
Activer le service FreeRADIUS
Onglets Squid et Squid2 : activation du déchiffrement HTTPS
Déchiffrement et interception du protocole HTTPS
Par rapport au protocole HTTP[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.
Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).
En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.
Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.
Certificat Racine de l'autorité de certification
Un certificat HTTPS est émis par une autorité de certification[13].
Let's Encrypt[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.
En revanche, le certificat racine utilisé par Amon pour déchiffrer le protocole HTTPS n'est pas public et il faut donc l'installer sur les postes clients dont le trafic doit être déchiffré et intercepté. La procédure est détaillée plus bas.
AttentionATTENTION AUX LIMITATIONS LÉGALES
Dans la mesure où les connexions sont déchiffrées par le proxy, il convient de prévenir les utilisateurs, en particulier les adultes et le personnel. En effet, la loi reconnaît un droit à la vie privée même sur le lieu de travail : article 9 du Code civil et article L 1121-1 du Code du travail, entre autres.
Dans certains cas, comme par exemple lors des accès aux sites bancaires ou aux sites médicaux, il ne semble pas évident que le déchiffrement HTTPS soit légal.
Mise en œuvre
Deux variables ont été ajoutées dans les onglets Squid et Squid2 :
Activer le déchiffrement HTTPS;Activer le déchiffrement HTTPS sur la seconde instance de Squid.
Ces deux variables permettent d’activer le déchiffrements des flux HTTPS transitant à travers le proxy.
Une fois le déchiffrement des flux HTTPS activé, le proxy a la capacité de connaître l’ensemble des URL consultées par l’utilisateur. Dans les journaux figureront donc les URL complètes et non uniquement les noms de domaines, comme c’est le cas sans le déchiffrement.
Dans ce mode de fonctionnement, le proxy génère un nouveau certificat pour chaque domaine visité et propose celui-ci à l’utilisateur. Tous ces certificats sont signés par une autorité de certification propre au proxy.
Pour que ces certificats soient perçus comme valides par les différentes applications utilisant le proxy, il est nécessaire de diffuser l’autorité de certification propre au proxy auprès de ces applications.
Truc & astuce
Sur un module Amon configuré pour l'interception des communications HTTPS, la commande diagnose permet de connaître le chemin et l'empreinte du certificat :
*** Validité du certificat racine du proxy (/etc/eole/squid_CA.crt)
. signingCA.crt => Ok. Empreinte => SHA256 Fingerprint=62:1B:BF:25:28:44:31:02:7E:09:31:A6:EA:FD:A5:A8:7C:D4:EB:B6:3D:83:88:62:0F:98:85:1A:DC:50:99:E0
Intégration de l’autorité de certification sur distributions Debian et dérivées
Copier le fichier /etc/eole/squid_CA.crt dans le répertoire du client : /usr/local/share/ca-certificates/ et exécuter la commande :
sudo update-ca-certificates
Intégration de l’autorité de certification sur Windows
Copier le fichier /etc/eole/squid_CA.crt sur le poste. Cliquer droit dessus et faire "installer le certificat". Le certificat doit être mis dans le "magasin de certificat" : "Autorités de certification racines de confiance".
Les applications communes comme Edge, Chromium, les mises à jours, ... reconnaîtront ainsi cette autorité.
Intégration de l’autorité de certification dans le magasin du navigateur Firefox
Dans le "gestionnaire de certificats", présent dans l'onglet "Vie privée" des préférences du logiciel, se rendre dans l'onglet "Autorités". Il est alors nécessaire d'importer le fichier /etc/eole/squid_CA.crt disponible sur l'Amon. Lors de l'importation, penser à cocher "Confirmer cette AC pour identifier des sites web".
Remarque
L’intégration du certificat peut être automatisée pour les postes joints à un domaine contrôlé par un module EOLE avec le paquet eole-workstation-manager installé.
Dans ce cas précis, la configuration du module contrôleur de domaine propose l’option Activer la configuration de Firefox qui met en place la procédure de déploiement du certificat sur les postes clients salt.
Pour plus d’informations, se reporter à la documentation des modules AmonEcole et Scribe, onglet Workstation.
Onglet Proxy authentifié : 5 méthodes d'authentification
- Authentification NTLM/KERBEROS
- Authentification NTLM/KERBEROS poste hors domaine
- Authentification NTLM/SMB
- Authentification NTLM/SMB poste hors domaine
- Authentification LDAP
- Authentification LDAP (Active Directory)
- Authentification sur Fichier local
- Désactivation de l'authentification sur une interface
- Notes techniques
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[62].
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 NTLM/SMB poste hors domaine
En mode normal, l'authentification NTLM[64] peut être facilitée par l'utilisation d'un proxy. Le proxy NTLM proposé par EOLE utilise le logiciel libre Cntlm[65].
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 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)
Onglets Proxy authentifié 2 : Double authentification
Par double authentification, nous entendons la possibilité de pouvoir configurer deux types distincts d'authentification proxy.
Par exemple, pouvoir utiliser à la fois une authentification NTLM/SMB et une authentification LDAP.
L'implémentation retenue est d'utiliser une instance du logiciel Squid par type d'authentification.
Configuration pas à pas
1. Activation de la deuxième instance de Squid dans l'onglet Authentification :
2. Configuration du type d'authentification dans l'onglet Proxy authentifié 2 :
Remarque
L'enregistrement au domaine est proposé lors de l'instanciation du module, de ce fait l'authentification NTLM/SMB n'est plus proposée pour une deuxième authentification.
Notes techniques
Les fichiers de logs spécifiques au second type d'authentification sont les suivants :
-
/var/log/rsyslog/local/squid/squid2.info.log→ 2ème instance de squid /var/log/rsyslog/local/e2guardian/e2guardian2.info.log→ 3ème instance de e2guardian (filtre web 3)
Dans l'état actuel, ces logs ne sont pas consultables au travers de l'interface EAD et seule la première configuration proxy est distribuée par WPAD (voir partie dédiée).
Onglet Exceptions proxy
Dans l'onglet Exceptions proxy de l'interface de configuration du module il est possible d'ajouter des exclusions dans la configuration automatique du proxy.
Il est possible de déclarer différents types d'exceptions.
Exception de proxy pour des domaines de destination
Cette exception commune à ERA et à WPAD permet de déclarer un domaine de destination pour lequel on ne passe pas par le proxy.
Il est possible d'ajouter plusieurs exceptions sur une même interface.
Il est également possible de fournir une liste de noms de domaine ou d'IP à inclure dans les exceptions au proxy depuis une URL, en activant la variable Télécharger et appliquer des exceptions de domaine depuis une URL.
Attention
Si vous utilisez une copie des modèles ERA fournis, il faudra l'adapter pour obtenir les règles supplémentaires
Exception au niveau de l'authentification des domaines de destination
Cette exception permet de déclarer des sites pour lesquels le proxy ne demandera pas l'authentification à l'utilisateur qui souhaite y accéder.
Si cNTLM et WPAD sur activés sur l'interface réseau, les utilisateurs utiliseront directement Squid (sans passer par cNTLM) pour accéder à ces sites.
Remarque
Les domaines commençants par un . sont gérés, le domaine lui-même et les sous-domaines ne sont pas authentifiés.
Exemple
Si on spécifie la valeur .ac-dijon.fr alors ac-dijon.fr et www.ac-dijon.fr seront autorisés sans authentification.
Complément
Une liste de sites à ne pas authentifier par défaut est stockée dans la variable cachée proxy_noauth_auto.
Il est possible de l'afficher dans l'onglet Exceptions proxy de l'interface de configuration du module en activant le mode Debug.
Cette variable reprend la liste des sites qui étaient dans le template domaines_noauth des versions EOLE antérieures à 2.5.2.
Exceptions de proxy pour des IP et adresses réseaux de destination
Cette exception commune à ERA et à WPAD permet de déclarer une adresse IP ou une plage d'adresses IP de destination pour laquelle on ne passe pas par le proxy.
Le bouton Exceptions de type réseau pour l'interface n permet d'ajouter plusieurs exceptions sur une même interface.
Exceptions de proxy pour des IP et adresses réseaux source
Cette exception spécifique à ERA permet de déclarer une adresse IP ou une plage d'adresses IP source pour laquelle on ne passe pas par le proxy.
Le bouton + Exception source de type réseau pour l'interface n permet d'ajouter plusieurs exceptions sur une même interface.
Attention
Cette fonctionnalité permet à une machine de contourner le proxy ce qui constitue un non respect des règles légales de sécurité. Elle peut servir pour effectuer des tests de proxy et d'exceptions de filtrage.
Exception sur un nom d'hôte (spécifique à WPAD)
L'exception sur un nom d'hôte s'effectue sur le nom d'hôte et sur le nom d'hôte complet.
Il faut choisir une interface ou toutes les interfaces sur lesquelles l'exception sera appliquée. Le bouton + Ne pas passer par le proxy pour l'hôte ou le domaine permet d'ajouter plusieurs exceptions sur une même interface.
Ce type d'exception étant spécifique à WPAD, il n'est pas prise en compte par les autres services gérant des exceptions au niveau du proxy.
Exemple
Si le champ Ne pas passer par le proxy pour l'hôte ou le domaine a comme valeur www.ac-monacad.fr, le fichier WPAD.dat généré contiendra la ligne || localHostOrDomainIs(host, "www.ac-monacad.fr") qui permet d'exclure simplement des URLs.
Complément
Compléments sur Ne pas passer par le proxy pour le domaine (dnsDomainIs) :
http://findproxyforurl.com/netscape-documentation/#dnsDomainIs
Compléments sur Ne pas passer par le proxy pour l'hôte ou le domaine (localHostOrDomainIs) :
http://findproxyforurl.com/netscape-documentation/#localHostOrDomainIs
Onglet Wpad : découverte automatique du proxy
WPAD est mis à disposition sur les modules Amon et AmonEcole au travers du paquet eole-wpad.
Sur un module personnalisé, il n'est fonctionnel que si le paquet eole-proxy est installé.
Pour fonctionner correctement, il faut que l'URL wpad.<nom_domaine_local> correspondre à l'adresse IP du serveur web.
Le support de WPAD doit être activé et correctement configuré sur le module Amon.
Dans l'onglet Services de l'interface de configuration du module Activer le support de WPAD doit être placé à oui.
Cela rend disponible l'onglet Wpad au sein duquel le Nom de domaine du service WPAD doit être rempli avec la même valeur que le Nom de domaine privé du réseau local présent dans l'onglet Général.
Attention
Si vous souhaitez utiliser un autre nom de domaine qui ne correspondrait pas au Nom de domaine privé du réseau local de l'onglet Général, il faut le déclarer dans le champ Nom domaine local supplémentaire ou rien de l'onglet Zones-dns.
Attention
Pour être pris en compte, les changements doivent être enregistrés et suivis de la commande reconfigure sur le module.
Truc & astuce
WPAD supporte les VLAN et les alias, Nginx renvoie le bon fichier WPAD si des VLAN ou des alias sont déclarés.
En mode expert, Il est également possible de changer le port du proxy diffusé par défaut pour une interface, un VLAN ou un alias donné.
Onglet Gpo
Les GPO additionnelles permettent de paramétrer des GPO à appliquer à l'ensemble du domaine. On peut forcer l'utilisation d'un proxy pour tous les postes clients.
Onglet Nginx
L'onglet Nginx est disponible si au moins l'un des deux paramètres suivants est activé dans l'onglet Services :
Activer la publication d’applications web par Nginx;Activer le reverse proxy Nginx.
Nom de domaine par défaut
En mode normal, cet onglet permet de saisir le Nom de domaine par défaut vers lequel sera redirigé un client qui accède au serveur avec un nom de domaine non déclaré.
Restriction Nginx
À partir d'EOLE 2.8.1, la variable : Appliquer des restrictions pour les ports Nginx permet de restreindre l'accès aux ports ouverts pour Nginx aux adresses autorisées à administrer le serveur.
Remarque
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans le bloc Administration à distance de l'onglet Interface-0.
Onglet Reverse proxy : Configuration du proxy inverse
EOLE propose un serveur proxy inverse (reverse proxy) basé sur le logiciel libre Nginx[23].
Le proxy inverse est un type de serveur proxy, habituellement placé en frontal de serveurs web, qui permet de relayer des requêtes web provenant de l'extérieur vers les serveurs internes (situés en DMZ[25] par exemple). Cela le différencie grandement d'un proxy classique comme Squid[1].
Concrètement, le proxy inverse permet d'ouvrir des services web installés sur des serveurs situées "derrière" le pare-feu l'accès sur Internet sans avoir recours à des règles iptables[67]/DNAT.
Le proxy inverse EOLE peut relayer des requêtes vers les services suivants :
Avant toute chose, le proxy inverse doit être activé dans l'onglet Services en passant Activer le reverse proxy Nginx à oui.
L'activation du service fait apparaître un nouvel onglet.
Redirection de services particuliers
Pour un fonctionnement optimal des applications web hébergées sur le module AmonEcole, il est impératif d'utiliser un nom de domaine[69] (exemple : monetab.ac-acad.fr) résolvable sur Internet et de le renseigner partout où cela est nécessaire.
Ce nom de domaine sera à utiliser tant depuis l'extérieur de l'établissement que depuis l'intérieur.
La configuration recommandée est donc la suivante :
-
Services: Activer le reverse proxy Nginx :oui; Firewall: Modèle de filtrage :2-zones-amonecole;Applications web: Nom de domaine des applications web (sans http://) :etab.ac-acad.fr;Eole sso: Nom de domaine du serveur d'authentification SSO :etab.ac-acad.fr;Nginx: Nom de domaine par défaut :etab.ac-acad.fr;Reverse proxy: Activer la configuration automatique pour les applications locales :oui.
Le paramètre Activer la configuration automatique pour les applications locales configure automatiquement l'accès aux applications web activées localement sur le module AmonEcole.
Redirection HTTP et HTTPS
Pour rediriger HTTP et HTTPS il est nécessaire de passer la variable Activer le reverse proxy Nginx pour le http/https à oui et de renseigner plus d'informations :
le
Nom de domaine ou IP à rediriger: le nom de domaine diffusé auprès des utilisateurs. Ce nom de domaine est celui qui permet d'accéder au module Amon ou AmonEcole ;Activer la redirection pour tous les sous-domaines: cette variable est disponible à partir de la version 2.6.2 d'EOLE, elle permet la prise en charge de tous les sous-domaines par le proxy inverse ;Demander un certificat à Let's Encrypt pour ce domaine ?: cette variable est disponible à partir de la version 2.6.2 d'EOLE si la redirection pour tous les sous-domaines n'est pas activé et que le certificat SSL est Let's Encrypt ;le
Répertoire ou nom de la page à redirigerpermet de rediriger un sous-répertoire vers une machine. La valeur par défaut est/;l'
IP ou domaine de destination (avec http:// ou https://) ou URI complètepermet de saisir l'adresse IP (exemple :http://192.168.10.1), le nom de domaine (exemple :http://scribe.monetab.fr) ou l'URI[70] (exemple :http://scribe.monetab.fr/webmail/) du serveur de destination hébergeant la ou les applications.
Il est possible de forcer l'utilisation du protocole HTTPS pour les requêtes utilisant le protocole HTTP de façon transparente. De cette manière, un utilisateur web se connectant à l'adresse http://monetab.fr sera automatiquement redirigé vers https://monetab.fr
Ainsi les communications sont automatiquement chiffrées protégeant la transmission de données sensibles (nom d'utilisateur, mot de passe, etc.).
Le proxy inverse peut être utilisé pour ne rediriger que le HTTPS en passant les valeurs Reverse proxy HTTP à non et Reverse proxy HTTPS à oui.
Il est possible d'ajouter plusieurs redirections en cliquant sur le bouton + Nom de domaine ou IP à rediriger.
Truc & astuce
Un répertoire déterminé peut également être redirigé vers un serveur différent. Par exemple le lien vers l'application Pronote[71], https://monetab.fr/pronote/ peut être redirigé vers http://pronote.monetab.fr/ (attention, le "/" final est important, puisqu'il faut rediriger à la racine du serveur de destination).
Redirection de domaines
Le reverse proxy permet de rediriger automatiquement les utilisateurs voulant accéder à une page particulière vers une autre page.
L'exemple ci-dessus illustre le remplacement de SquirrelMail par Roundcube : si l'utilisateur cherche à accéder à l'adresse http://etb1.ac-test.fr/squirrelmail/, la page se recharge automatiquement avec l'URL de la nouvelle messagerie : http://etb1.ac-test.fr/roundcube/.
Onglet Freeradius : Configuration de l'authentification Radius
Proxy RADIUS
L'activation du proxy RADIUS permet de relayer les requêtes d'authentification vers un autre serveur RADIUS.
Le paramétrage fin du serveur proxy RADIUS n'est pas implémenté. La configuration est celle proposée par défaut dans le logiciel.
Modes de fonctionnement
Il est possible de choisir entre 2 modes d'utilisation de FreeRADIUS :
802.1x ;
accounting.
Le mode 802.1x
Numéro de l'interface sur laquelle FreeRADIUS écoutera : définition de l'interface d'écoute de FreeRADIUS.
Configuration des NAS
Adresse IP du serveur d'accès (NAS) : adresse IP du switch.
Nom court du serveur d'accès (NAS) : libellé du switch.
Secret partagé avec le serveur d'accès (NAS) : secret partagé entre FreeRADIUS et le switch.
Type du serveur d'accès (NAS) : type de switch.
Configuration LDAP
Authentifier les comptes utilisateurs sur un annuaire LDAP : L'authentification LDAP permet de s'assurer que l'utilisateur est autorisé à accéder aux réseaux. Mais si on gère une flotte de machine, l'authentification par clé TLS peut être jugée comme suffisante. Pour désactiver l'authentification LDAP, sélectionner non.
Adresse IP du serveur LDAP permettant de récupérer les comptes utilisateurs : adresse IP LDAP.
Suffixe racine de l'annuaire LDAP (base DN) : ou=education,o=gouv,c=fr par exemple.
Configuration des groupes et des VLAN
Groupe d'utilisateurs à récupérer dans l'annuaire LDAP : saisir ou choisir un groupe existant dans l'annuaire.
Numéro de VLAN à attribuer à ce groupe : les machines se connectant avec un utilisateur appartenant au groupe indiqué ci-dessus verra son port marqué avec ce numéro de VLAN.
Le mode accounting
Le mode accounting permet de créer un réseau Wi-Fi WPA enterprise sur une borne Wi-Fi (NAS) ayant pour identifiants autorisés les compte/motDePasse de l'annuaire LDAP déclaré.
Adresse IP sur laquelle FreeRADIUS écoutera : l'adresse IP d'une des interfaces du serveur.
Configuration des NAS
Adresse IP du serveur d'accès (NAS) : adresse IP de la borne Wi-Fi.
Masque de sous réseau (notation CIDR) du serveur d'accès (NAS) : 24 (en notation CIDR[74]) si le réseau est de classe C.
Nom court du serveur d'accès (NAS) : libellé de la borne Wi-Fi.
Secret partagé avec le serveur d'accès (NAS) : secret partagé entre FreeRADIUS et la borne Wi-Fi.
Type du serveur d'accès (NAS) : type de borne (other en général).
Configuration LDAP
Authentifier les comptes utilisateurs sur un annuaire LDAP : L'authentification LDAP permet de s'assurer que l'utilisateur est autorisé à accéder aux réseaux. Mais si on gère une flotte de machine, l'authentification par clé TLS peut être jugée comme suffisante. Pour désactiver l'authentification LDAP, sélectionner non.
Adresse IP du serveur LDAP permettant de récupérer les comptes utilisateurs : adresse IP ldap.
Suffixe racine de l'annuaire LDAP (base DN) : ou=education,o=gouv,c=fr par exemple.
Clé d'accès reader à la base ldap sur Scribe (/root/.reader) : à récupérer sur le serveur LDAP.
Truc & astuce
Pour tester la connexion à Freeradius en mode accounting il est possible d'utiliser la commande radtest :
root@amon:~# radtest -x admin <mdp admin> <Adresse IP sur laquelle FreeRADIUS écoute> <port d'écoute du NAS> <Secret partagé avec le serveur d'accès>
ou encore
root@amon:~# radtest -x admin <mdp admin> $(CreoleGet "freerad_listen_addr") <port d'écoute du NAS> $(CreoleGet "freerad_nas_passwd")
Les journaux systèmes sont disponibles dans /var/log/rsyslog/local/freeradius/ :
root@amon:/usr/share/eole/creole# tail -f /var/log/rsyslog/local/freeradius/freeradius.notice.log 2017-06-09T16:49:36.420151+02:00 amon.etb1.lan freeradius[32240]: Login OK: [admin] (from client other port 10)2017-06-09T16:49:57.807213+02:00 amon.etb1.lan freeradius[32240]: Login OK: [admin] (from client other port 10)
Choix du protocole d'authentification
FreeRADIUS supporte plusieurs versions du protocole EAP (Extensible Authentication Protocol) :
MD5
La version historique et la plus basique est la version MD5[75].
Le client est authentifié par le serveur qui utilise une authentification défi réponse. Une valeur aléatoire constituant le défi est envoyée au client, qui concatène à ce défi le mot de passe et en calcule, en utilisant l'algorithme MD5, le hash, une empreinte qu'il renvoie au serveur. Le serveur calcule sa propre empreinte connaissant le mot de passe, puis il compare les deux et valide ou non l'authentification.
La sécurité de cette version est faible. En cas d'écoute du trafic, il est possible de retrouver le mot de passe via force brute.
EAP-TLS
La version EAP-TLS[15] permet d'avoir un trafic chiffré entre le client et le serveur mais permet aussi, d'identifier le certificat présent sur le poste client.
Le serveur et le client possèdent chacun leur certificat qui va servir à les authentifier mutuellement, dans un fonctionnement similaire au protocole https.
Pour activer EAP-TLS, sélectionner tls dans la variable Type de protocole d'authentification.
RemarqueVersion TLS
La version TLS 1.1 est désactivée au profit de la version 1.2 !
AttentionMD5
Ce mode n'est plus considéré comme sécurisé et ne permet pas d'identifier le poste.
Onglet Synchronisation aaf
Permet de placer des quotas d'espace sur les comptes importé d'une base aaf.
Configuration des quotas sur les nouveaux compte importé
Écran
- 1
activation des options d'importation
La valeur est à non par défaut son passage à oui ouvre la partie inférieur pour le paramétrage des variables
- 2
Quotas "soft" des élèves
La variables
aaf_quotas_studentpermet d'indiquer la limite douce d'utilisation d'espace disque de l'utilisateur élèves, lorsque l'utilisateur atteindra cette valeur une alerte pourra être remonté pour avertir l'administrateur et l’utilisateur - 3
Quotas "hard" des élèves
La variables
aaf_quotas_hard_studentpermet d'indiquer la limite dur d'utilisation d'espace disque de l'utilisateur élèves, valeurs qu'il ne pourra pas dépasser. - 4
Quotas "soft" des enseignants
La variables
aaf_quotas_teacherpermet d'indiquer la limite douce d'utilisation d'espace disque de l'utilisateur enseignant, lorsque l'utilisateur atteindra cette valeur une alerte pourra être remonté pour avertir l'administrateur et l’utilisateur - 5
Quotas "hard" des enseignants
La variables
aaf_quotas_hard_teacherpermet d'indiquer la limite dur d'utilisation d'espace disque de l'utilisateur enseignant, valeurs qu'il ne pourra pas dépasser. - 6
Quotas "soft" des administratifs
La variables
aaf_quotas_administrativepermet d'indiquer la limite douce d'utilisation d'espace disque de l'utilisateur administratif, lorsque l'utilisateur atteindra cette valeur une alerte pourra être remonté pour avertir l'administrateur et l’utilisateur - 7
Quotas "hard" des administratifss
La variables
aaf_quotas_hard_administrativepermet d'indiquer la limite dur d'utilisation d'espace disque de l'utilisateur administratif, valeurs qu'il ne pourra pas dépasser.
Les différentes variables :
les variables concerne trois type d'utilisateurs :
etudiantenseignantadministratif
Pour chacun de ces utilisateur il y a deux quotas, un "doux" et un "bloquant".
Le quotas "doux" renvoi une alerte lorsqu'il est atteint, le quotas "bloquant" interdit à l'utilisateur de rajouter de la donnée sur son espace à la limite fixé. Si la limite "bloquante" est à 200Mo, l'utilisateur ne pourra jamais dépassé 200 Mo de donnée sur son espace.
Onglet Envole
L'onglet Envole est disponible par défaut sur les modules Scribe (>=2.8.1) et AmonEcole.
Écran
- 1 Activation de Posh Profil
Variable :
activer_poshprofilActiver ou non la synchronisation entre les service web Envole et eole-db.
- 2 Affecter par défaut les nouvelles applications au profil
Variable :
poshprofil_newitemAccorde un accès par défaut pour tout le monde à l'applicatif Envole eportail.
- 3 Type de synchronisation
Variable :
poshprofil_typesynchroIdentifie le type d'annuaire qui sera utilisé.
- 4 Ajouter un uid de type administrateur envole
Variable :
activer_addadminAjouter un second administrateur.
- 5 UID de votre second administrateur envole
Variable :
uid_addadminIdentifiant du second administrateur.
- 6 Alias apache pour posh-profil
Variable :
alias_poshprofilAlias à utiliser pour les connexions à Posh-Profil.
Affecter par défaut les nouvelles applications au profil
Cette option permet d'affecter les applications à de nouveaux profils.
Deux possibilités :
Tout le monde ;
Administrateur.
En choisissant Tout le monde, tous les utilisateurs auront accès aux applications par défaut. Par conséquent, une fois un nouvel utilisateur créé celui-ci aura accès aux applications sans nécessiter d'action supplémentaire.
En choisissant Administrateur, cette fonctionnalité est limitée aux seuls profils administrateur. Pour les autres utilisateurs il faudra effectuer des actions pour chaque application.
Type de synchronisation
Deux types de bases sont prévus par EOLE.
En choisissant la base ENT vous indiquez l’utilisation d'une base type Scribe. Base par défaut du module Scribe gérée via l'EAD.
En choisissant la base annuaire vous spécifiez l'utilisation d'une base différente de la base par défaut de Scribe, de type annuaire. (correspond à une base PIA par exemple)
Ajouter un uid de type administrateur envole
Il est possible de donner à une tierce personne un compte administrateur sur l'ensemble d'Envole.
Pour se faire il suffit de sélectionner oui, puis de saisir l'identifiant dans la nouvelle variable.
Exemplenouvelle variable : uid_addadmin
Alias apache pour posh-profil
Cette variable ne doit être modifiée que dans le cas où il y aurait au moins deux bases différentes utilisées par des applications situées au même endroit.
L'alias permet aux applicatifs et au proxy inverse de savoir à quelle base de données s'adresser.
Dans le cas où il n'y a qu'une seule base de données, il est préférable de ne pas modifier cette variable.
ExempleExemple de cas d'usage ou la variable externe est nécessaire.
Dans le cas où il y aurait plusieurs bases de données auxquelles se connecter, se situant toutes dans un même domaine (ou sous-domaine), derrière un HAProxy.
Attention
En cas de modification de la variable, bien reporter celle-ci dans les applications le nécessitant.
Onglet Sonde statistique
L’onglet Sonde statistique permet d’activer et de configurer la récolte de renseignements sur l’utilisation des applications web du portail Envole.
Il est possible de récolter ces informations localement ou bien de configurer une remontée des informations sur des serveurs nationaux si un partenariat a été préalablement établi avec le Ministère.
Écran
- 1
Activer la connexion au serveur de statistiques local
Permet d’afficher les paramètres nécessaires à l’utilisation du serveur de statistiques local et active ce dernier.
- 2
Activer Sonde DNMA
Permet d’afficher les paramètres nécessaires à l’utilisation des sondes DNMA en partenariat avec le Ministère.
Ce mécanisme nécessite la mise en place du partenariat au préalable.
Serveur de statistiques local
Le passage de la variable Activer la connexion au serveur de statistiques local permet de renseigner les paramètres de connexion au serveur local.
Serveur de statistiques national
Il est possible, si un partenariat a été conclu avec le Ministère, de faire remonter les informations d’utilisation du portail sur un serveur national.
Informations d’identifications associées aux remontées statistiques
Le passage de la variable Activer la connexion au serveur de statistiques local permet de renseigner les paramètres de connexion au serveur local.
Écran
- 1
Adresse postale
Adresse postale de l’établissement
- 2
Code postal
Code postal de l’établissement
- 3
Ville
Ville de l’établissement
- 4
Pays
Pays de l’établissement
- 5
Type de serveur
Type du serveur parmi les choix suivants :
- école
- collège
- lycée
- supérieur
- autre_etab
- rectorat
- dsden
- entreprise
- autre
- 6
Nature de serveur
Rôle du serveur dans l’infrastructure, parmi les choix suivants :
- production
- recette
- développement
- 7
Fonction du serveur
La finalité du portail, parmi les choix suivants :
- ENT
- PIA
Configuration en mode expert
Certains onglets et certaines options ne sont disponibles qu'après avoir activé le mode expert de l'interface de configuration du module.
Dans l'interface de configuration du module voici les onglets propres à la configuration du module Amon :
Général;Services;Firewall;Système;Sshd;Ntp;Logs* ;Interface-0;Interface-1;Interface-n* ;Réseau avancé;Certificats ssl;Dépôt tiers;Schedule;Apt-cacher;Agregation** ;Eoledb;Mots de passe;Active directory;Clamav;Annuaire;Samba;Dhcp* ;Tftp* ;Onduleur* ;Ead3*;Rvp* ;Application web;Apache;Workstation;bareos-webui;Eole sso* ;Ead-web ;Mode restreint;Mysql;Postgresql;Messagerie;Directeur bareos;Stockage bareos;Client bareos;Authentification;Filtrage web;Squid;Squid2*;Proxy authentifié;Proxy authentifié 2***;Cups;Exceptions proxy;Proxy parent;Wpad;Gpo;Nginx;Applications web nginx* ;Reverse proxy;Proftpd;Freeradius***;Nextcloud;Synchronisation aaf;Eoleflask;
Envole;Posh-profil;Sonde statistique;Roundcube.
Certains des onglets ne sont disponibles que dans des conditions particulières :
après activation du service dans l'onglet
Servicespour les onglets identifiés avec une * dans la liste ci-dessus ;après activation de la
Répartition de charge entre 2 lignes Internetdans l’ongletInterface-0pour l’onglet identifié avec ** dans la liste ci-dessus ;après activation des fonctionnalités supplémentaires dans l’onglet
Authentificationpour les onglets identifiés avec *** dans la liste ci-dessus.
Onglet Général
Présentation des différents paramètres de l'onglet Général.
Informations sur l'établissement
Deux informations sont importantes pour l'établissement :
- l'
Identifiant de l'établissement, qui doit être unique ; - le
Nom de l'établissement.
Ces informations sont notamment utiles pour Zéphir, les applications web locales, ....
Sur les modules fournissant un annuaire LDAP[11] local, ces variables sont utilisées pour créer l'arborescence.
Attention
Il est déconseillé de modifier ces informations après l'instanciation du serveur sur les modules utilisant un serveur LDAP local.
Nom DNS du serveur
En premier lieu, il convient de configurer le nom DNS du serveur.
Cette information est découpée en 2 champs :
- le nom de la machine dans l'établissement ;
- le nom DNS du réseau local.
Le Nom de la machine est laissé à l'appréciation de l'administrateur.
Si l'authentification NTLM/KERBEROS est activée sur le proxy, le Nom de machine 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.
Le Nom DNS du serveur utilise fréquemment des domaines de premier niveau du type .lan .
C'est ce nom qui configurera le serveur DNS (sur un module Amon par exemple) comme zone de résolution par défaut. Il sera utilisé par les machines pour résoudre l'ensemble des adresses locales.
Rappel : les outils mDNS (Avahi, Bonjour, ... ) utilise la racine '.local'. Pour éviter les problèmes de DNS, nous vous déconseillons d'utiliser cette racine.
Remarque
Les domaines de premier niveau .com, .fr sont en vigueur sur Internet, mais sont le résultat d'un choix arbitraire.
Sur un réseau local les noms de domaine sont privés et on peut tout à fait utiliser des domaines de premier niveau, et leur donner la sémantique que l'on veut.
Remarque
Les informations sur les noms de domaine sont importantes car elles sont notamment utilisées pour l'envoi des courriels et pour la création de l'arborescence de l'annuaire LDAP.
Attention
L'usage d'un domaine de premier niveau utilisé sur Internet n'est pas recommandé, car il existe un risque de collision entre le domaine privé et le domaine public.
Paramètres réseau globaux
En deuxième lieu, il convient de configurer les noms de domaine de la machine.
Cette information est découpée en plusieurs champs :
- le nom du domaine privé utilisé à l'intérieur de l'établissement ;
- le nom de domaine académique et son suffixe.
Nombre d'interfaces
Un module Amon ou AmonEcole peut avoir de 2 à 5 cartes réseau.
Le nombre d'interfaces activées se définit dans l'onglet Général de l'interface de configuration du module.
Cela ajoute autant d'onglets Interface-n que le nombre d'interfaces à activer choisi.
Proxy
Si le module doit utiliser un proxy pour accéder à Internet, il faut activer cette fonctionnalité en passant la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet à oui.
Il devient alors possible de saisir la configuration du serveur proxy :
- nom de domaine ou adresse IP du serveur proxy ;
- le port du proxy.
Attention
La déclaration du proxy est nécessaire pour effectuer les mises à jour d'un module qui serait protégé par un module Amon.
Déchiffrement et interception du protocole HTTPS
Par rapport au protocole HTTP[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.
Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).
En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.
Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.
Certificat Racine de l'autorité de certification
Un certificat HTTPS est émis par une autorité de certification[13].
Let's Encrypt[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.
À partir de la version 2.8.1, le module Amon est équipé d'une fonctionnalité d'interception du trafic HTTPS. Il est possible de déclarer son certificat racine servant à sur-signer les ressources servies par le protocole HTTPS et transitant par le proxy filtrant. Cette déclaration permet d'en automatiser l'intégration dans le magasin de certificats local.
Si la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet est passée à oui, la variable Le serveur mandataire intercepte les communications HTTPS est proposée et permet elle-même de faire apparaître deux variables permettant d’identifier le certificat racine employé par le proxy filtrant.
En passant la variable Le serveur mandataire intercepte les communications HTTPS à oui, il est possible de renseigner les variables suivantes en utilisant les données affichées par la commande diagnose sur le module Amon :
Type d’empreinte du certificat racine du proxy: SHA256 (par défaut sur Amon 2.8.1)Empreinte du certificat racine du proxy: information donnée par le diagnose du serveur Amon dans le cas où celui-ci fait office de proxy filtrant
Cette configuration est nécessaire uniquement lorsque le module Amon est configuré pour l’interception des communications HTTPS.
Truc & astuce
Sur un module Amon configuré pour l'interception des communications HTTPS, la commande diagnose permet de connaître le chemin et l'empreinte du certificat :
*** Validité du certificat racine du proxy (/etc/eole/squid_CA.crt)
. signingCA.crt => Ok. Empreinte => SHA256 Fingerprint=62:1B:BF:25:28:44:31:02:7E:09:31:A6:EA:FD:A5:A8:7C:D4:EB:B6:3D:83:88:62:0F:98:85:1A:DC:50:99:E0
DNS et fuseau horaire
NTP
RemarquePorts utilisés par ntpdate
Le service ntp utilisant et bloquant le port 123, ntpdate utilise un port source aléatoire dans la plage des ports non privilégiés.
Les éventuelles règles de pare-feu ne peuvent donc pas présumer que le port source est le port 123.
Par contre, le port de destination reste inchangé (port : 123).
Choix du certificat SSL
Trois types de certificats peuvent être utilisés pour sécuriser les connexions avec TLS[15] :
autosigné: le certificat est généré localement et signé par une CA[13] locale ;letsencrypt: le certificat est généré et signé par l'autorité Let's Encrypt[14] ;manuel: le certificat est mis en place manuellement par l'administrateur. Pour ce faire, il faut disposer au préalable des certificats fournis par l'autorité de certification, si ce n'est pas encore le cas, le choixautosignépermet d'utiliser le serveur de façon non optimale. Le répertoire/etc/ssl/certs/est recommandé pour placer les certificats.
Remarque
Par défaut, le type de certificat par défaut est autosigné et aucun paramétrage n'est nécessaire.
Cette configuration est déconseillée car elle nécessite l'installation de l'autorité de certification locale sur tous les postes clients.
Truc & astuce
Pour plus d'informations, consulter la partie consacrée à l'onglet expert Certificats ssl.
Mise à jour
Il est possible de définir d'autres adresses pour le serveur de mise à jour EOLE que celles fournies par défaut, dans le cas où vous auriez, par exemple, un miroir des dépôts.
Il est possible de définir d'autres adresses pour le serveur de mise à jour Ubuntu que celles fournies par défaut, dans le cas où vous auriez, par exemple, un miroir des dépôts.
La variable Événements de mise à jour à notifier par courriel permet d'activer les notifications par courriel pour certains événements liés à la mise à jour :
aucun: aucune notification ;queryauto: notification en cas de mise à jour disponible (nécessite l'activation de la tâche schedulequeryautodans l'ongletSchedule) ;kernel: notification en cas de redémarrage nécessaire suite à l'installation d'un nouveau noyau[77] ;tous: notification en cas de mise à jour disponible ou de redémarrage nécessaire.
Le champ Adresse web de mise à jour des blacklists permet de personnaliser l'adresse à utiliser pour le téléchargement des bases de filtres (blacklists[78]).
Onglet Services
L'onglet Services permet d'activer et de désactiver une partie des services proposés par le module.
Suivant le module installé et le mode utilisé pour la configuration, la liste des services activables ou désactivables est très différente.
Truc & astuce
Le principe est toujours le même, l'activation d'un service va, la plupart du temps, ajouter un onglet de configuration propre au service.
En mode normal la liste des services activables ou désactivables est beaucoup plus conséquente.
Les services propres au module AmonEcole sont les suivants :
- l'anti-virus ClamAv ;
- le serveur DHCP ;
- le réseau privé virtuel RVP ;
- le serveur web Apache ;
- le serveur d'authentification unique EoleSSO ;
- la sauvegarde ;
- le support de stockage de la sauvegarde ;
- le serveur d'impression avec CUPS ;
- le support de WPAD ;
- l'accès FTP.
En mode expert, les services de base communs à tous les modules sont :
Truc & astuce
Une fois le module instancié, l'accès web à l'interface de configuration du module est activé par défaut sur le port 443.
L'interface reste également accessible en https sur le port historique 7000.
Les services propres au module AmonEcole en mode expert sont :
- l'activation du cache APT ;
- l'utilisation du service de gestion de bases de données EoleDB ;
- le service PXE/TFTP, il est désactivé par défaut ;
- le filtrage sur le proxy.
Onglet Firewall
Modèle de filtrage
Le modèle de filtrage doit être choisi en fonction du nombre d'interfaces activées et des services que l'on souhaite mettre en place.
Par convention, le premier caractère des modèles de filtrage proposés est un chiffre qui correspond au nombre d'interfaces désirées.
Les modèles de zone par défaut proposés supportent jusqu'à 5 cartes réseau :
2zones : gestion d'une zone admin ou pedago sur l'interface 1 ;
2zones-amonecole : modèle spécifique au module AmonEcole (pedago sur l'interface 1) ;
3zones : gestion d'une zone admin sur l'interface 1 et d'une zone pedago sur l'interface 2 ;
3zones-dmz : gestion d'une zone pedago sur l'interface 1 et d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 2 ;
4zones : gestion d'une zone admin sur l'interface 1, d'une zone pedago sur l'interface 2 et d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 3 ;
5zones : gestion d'une zone admin sur l'interface 1, d'une zone pedago sur l'interface 2, d'une zone DMZ publique pouvant accueillir un module Scribe sur l'interface 3 et d'une zone DMZ privée sur l'interface 4.
Complément
Chaque modèle de zone proposé correspond à un modèle de filtrage ERA. Les modèles de filtrage ERA sont la description de pare-feu enregistrés dans des fichiers XML situés par défaut dans le répertoire /usr/share/era/modeles/.
Truc & astuce
Avec ERA il est possible de créer un nouveau modèle personnalisé dans le répertoire /usr/share/era/modeles/. Celui-ci apparaîtra dans la liste des modèles proposés par défaut.
Onglet Système
Les paramètres de l'onglet Système permettent de régler le comportement de la console et de déterminer le niveau de complexité requis pour les mots de passe des utilisateurs système.
Paramétrage de la console
Activer l'auto-complétion étendue sur la console: l'auto-complétion facilite l'utilisation de la ligne de commande mais peut ralentir son affichage, elle est activée par défaut ;-
Temps d'inactivité avant déconnexion bash: si aucune activité n'est constatée sur la console utilisateur pendant cette durée (en secondes), sa session est automatiquement coupée, avec le message : attente de données expirée : déconnexion automatique. La valeur0permet de désactiver cette fonctionnalité. Activer le reboot sur ctrl-alt-suppr: si cette variable est passée ànon, la séquencectrl - alt - supprest désactivée.Nuance du fond d’écran dans VIM: l’éditeur VIM peut utiliser différents thèmes pour la coloration syntaxique et adapter ceux-ci en fonction de la valeur de la couleur d’arrière-plan pour en améliorer la lisibilité. La variable prend une valeur parmi dark et light, permettant d’adapter la coloration syntaxique à un arrière-plan sombre et clair respectivement.
Optimisations système
Poids relatif de l'utilisation de la swap par rapport à la mémoire vive: Le swappiness est un paramètre du noyau Linux permettant de définir avec quelle sensibilité il va écrire dans la swap si la quantité de RAM à utiliser devient trop importante. Le système accepte des valeurs comprises entre 0 et 100. La valeur0empêchera au maximum le système d'utiliser la partition d'échange.
Truc & astuce
La commande suivante permet de connaître les réglages de swappiness appliqués :
cat /proc/sys/vm/swappiness
Activer le service de génération de nombres aléatoires rng-tools: Le démonrngdagit comme une passerelle entre un vrai générateur de nombres aléatoires, matériel (TRNG), tel que ceux que l'on peut trouver dans les puces Intel/AMD/VIA et le pseudo-générateur de nombres aléatoires du noyau (PRNG).
Attention
Sur les serveurs virtualisés, le service rngd ne sera généralement pas fonctionnel et affichera, au démarrage, un message du type :
erreur Starting Hardware RNG entropy gatherer daemon: (failed)
Validation des mots de passe
EOLE propose un système de vérification des mots de passe évolué pour les utilisateurs système.
Un paramétrage par défaut est proposé mais il est possible d'adapter.
La complexité des mots de passe peut être réglée finement à l'aide des paramètres suivants :
-
Taille minimum du mot de passe utilisant une seule classe de caractères; -
Taille minimum du mot de passe utilisant deux classes de caractères; -
Taille minimum du mot de passe utilisant trois classes de caractères; -
Taille minimum du mot de passe utilisant quatre classes de caractères; -
Taille maximale du mot de passe.
La valeur 0 permet de désactiver une classe de caractères.
Exemple
Pour obliger l'utilisation de 2 classes de caractères minimum et d'un minimum de 7 caractères :
Taille minimum du mot de passe utilisant une seule classe de caractères: 0-
Taille minimum du mot de passe utilisant deux classes de caractères: 7 -
Taille minimum du mot de passe utilisant trois classes de caractères: 7 -
Taille minimum du mot de passe utilisant quatre classes de caractères: 7
Exemple
Pour obliger l'utilisation de 3 classes de caractères minimum et d'un minimum de 7 caractères :
Taille minimum du mot de passe utilisant une seule classe de caractères: 0-
Taille minimum du mot de passe utilisant deux classes de caractères: 0 -
Taille minimum du mot de passe utilisant trois classes de caractères: 7 -
Taille minimum du mot de passe utilisant quatre classes de caractères: 7
Exemple
Il est impossible d'obliger l'utilisation de 3 classes minimum sans obliger l'utilisation de 2 classes minimum, exemple de valeur impossible :
Taille minimum du mot de passe utilisant une seule classe de caractères: 7-
Taille minimum du mot de passe utilisant deux classes de caractères: 0 -
Taille minimum du mot de passe utilisant trois classes de caractères: 7 -
Taille minimum du mot de passe utilisant quatre classes de caractères: 7
Les valeurs doivent être respectivement : 0, 0, 7 et 7.
Truc & astuce
Deux librairie sont utilisées pour vérifier la validité des mots de passe : pam_passwdqc.so et pam_unix.so.
Les réglages de la première librairie s'effectuent via les variables proposées. Si les règles établies par la première librairie ne sont pas suffisamment sécurisées, d'autres règles seront imposées par la seconde :
le mot de passe ne peut être basé sur l'identifiant du compte ;
le mot de passe ne peut être basé sur l'ancien mot de passe ;
le mot de passe ne peut pas comporter des mots du dictionnaire ;
le mot de passe ne peut être basé sur une séquence connue (suite de lettre sur le clavier par exemple) ;
le mot de passe doit contenir suffisamment de caractères différents ;
les lettres majuscules au début du mot de passe et les chiffres à la fin du mot de passe ne comptent pas comme l'utilisation d'une classe de caractère.
Truc & astuce
Plus d'informations sur le site du projet : http://www.openwall.com/passwdqc/
Attention
Il est possible de désactiver la validation des mots de passe en passant Vérifier la complexité des mots de passe à non.
Il ne faut bien évidement pas désactiver cette fonctionnalité dans un contexte de production.
Cette fonctionnalité est intéressante pour faciliter la mise en place d'une infrastructure de test.
Attention
Ce paramétrage concerne uniquement les comptes système du serveur. Les utilisateurs LDAP ne sont pas soumis aux mêmes restrictions.
Ajustement du partitionnement
Attention
L'ajustement du partitionnement est disponible dans l'interface de configuration du module en mode expert et ce uniquement :
- avant l'instance
- si le partitionnement à l’installation depuis l’ISO n’a pas été modifié
Pour maîtriser correctement ce qui va être fait il faut consulter l'état du partitionnement avant de saisir les paramètres souhaités à l'aide de la commande df -h / et des commandes vgdisplay et lvdisplay.
root@eolebase:~# df -hSys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 980M 0 980M 0% /dev
tmpfs 200M 3,2M 197M 2% /run
/dev/mapper/eolebase--vg-root 9,1G 2,1G 6,5G 25% /
tmpfs 1000M 28K 1000M 1% /dev/shmtmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 1000M 0 1000M 0% /sys/fs/cgroup
/dev/sda1 687M 107M 531M 17% /boot/dev/mapper/eolebase--vg-tmp 1,8G 2,9M 1,7G 1% /tmp
tmpfs 200M 0 200M 0% /run/user/0
root@eolebase:~#root@scribe:~# vgdisplay --- Volume group ---
VG Name scribe-vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 8
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 5
Open LV 5
Max PV 0
Cur PV 1
Act PV 1
VG Size 39,30 GiB PE Size 4,00 MiBTotal PE 10060
Alloc PE / Size 5550 / 21,68 GiB
Free PE / Size 4510 / 17,62 GiB
VG UUID ctPVcP-76Se-EpMp-FLO3-13aR-Ghg9-PdIdUW
root@scribe:~#root@scribe:~# lvdisplay--- Logical volume ---
LV Path /dev/scribe-vg/root
LV Name root
VG Name scribe-vg
LV UUID uN8emF-hD9j-eNwv-zdaC-mEeK-9XGe-uBu2OU
LV Write Access read/write
LV Creation host, time scribe, 2017-10-05 18:37:11 +0200
LV Status available
# open 1 LV Size 8,94 GiBCurrent LE 2288
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:0[...]
Ajuster le partitionnement
Ajuster le partitionnement permet d'ajouter un ou plusieurs volumes logiques et d'ajouter de l'espace à des partitions existantes.
Pour ajuster le partitionnement à partir de la version 2.6.2 d'EOLE, ouvrir l'interface de configuration du module, passer en mode Expert et se rendre dans l'onglet Système. Puis il faut passer Utiliser le modèle d'extension standard EOLE à non pour ajuster le partitionnement.
Après avoir passer Ajuster le partitionnement à oui, les partitions existantes sont affichées et un certain nombre de paramètres s'affichent.
nom du volume ;
pourcentage de l'espace disponible à utiliser ;
format du système de fichier à utiliser : sans précision le système de fichier est
ext4;point de montage ;
les options du montage (indispensable pour la gestion des quotas par exemple).
Pour ajouter un nouveau volume logique, cliquer sur le bouton + Nom du volume à créer.
Attention
Les nouveaux volumes ne sont pas montés automatiquement, il faut renseigner le fichier /etc/fstab.
Allouer l'espace restant
Positionner la variable Allouer l'espace restant à oui permet de choisir un volume existant auquel ajouter la totalité de l'espace libre restant.
La valeur à saisir est la partie du nom du volume qui permet d'identifier le point de montage, par exemple pour le volume /dev/mapper/eolebase--vg-root il faut saisir root dans le nom du Volume logique à étendre. S’il ne reste pas d’espace, ce jeu de paramètres est sans effet.
Résultat après instance
Le paramétrage est effectif après l'instanciation du module.
root@eolebase:~# df -hSys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev 980M 0 980M 0% /dev
tmpfs 200M 3,2M 197M 2% /run
/dev/mapper/eolebase--vg-root 9,1G 1,9G 6,7G 22% /
tmpfs 1000M 0 1000M 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 1000M 0 1000M 0% /sys/fs/cgroup
/dev/sda1 687M 107M 531M 17% /boot/dev/mapper/eolebase--vg-tmp 1,8G 3,6M 1,7G 1% /tmp
tmpfs 200M 0 200M 0% /run/user/0
/dev/mapper/eolebase--vg-var 27G 311M 25G 2% /varroot@eolebase:~#Le nouveau volume logique est présent et la partition /root s'est vu augmentée du reste de l'espace libre.
Onglet Sshd : Gestion SSH avancée
Les paramètres disponibles dans cet onglet permettent d'affiner la configuration des accès SSH au serveur et viennent en complément des variables définissant les autorisations d'administration à distance saisies au niveau de chacune des interfaces (onglets Interface-n).
Autoriser les connexions SSH pour l'utilisateur root
Permet d'interdire les connexions SSH avec le compte utilisateur root (paramètre PermitRootLogin).
Autoriser les connexions SSH par mot de passe (si non clef RSA obligatoire)
Permet d'interdire les connexions SSH par mot de passe. Dans ce cas, seules les connexions par clef RSA seront autorisées (paramètre PasswordAuthentication).
Remarque
Si les connexions par mots de passe sont interdites, une tentative de connexion sans clé valide entraînera l'affichage du message suivant :
Permission denied (publickey).
Autoriser les connexions SSH pour les groupes
Permet de déclarer des groupes Unix supplémentaires autorisés à se connecter en SSH au serveur (paramètre AllowGroups).
Par défaut, les groupes Unix autorisés sont root et adm.
Critères à appliquer pour le blocage des tentatives de connexions par force brute
La première valeur est le nombre de tentatives de connexions échouées tolérées. La dernière valeur est le nombre de connexions échouées maximales. La deuxième valeur fixe le pourcentage de refus aléatoire une fois le nombre de connexions tolérées atteint. Ce pourcentage de refus augmente à chaque échec supplémentaire jusqu'à ce que le nombre de connexions maximales soit atteint (paramètre MaxStartups).
Onglet Logs : Gestion des journaux
La journalisation des événements des applications est un élément important de la maintenance et de l’analyse du fonctionnement d'un module.
Les modules disposent de deux dispositifs de journalisation en partie complémentaire pour la conservation des événements localement. En outre, ils proposent la configuration avancée de Rsyslog pour la centralisation des journaux de plusieurs modules.
Conservation locale des journaux
En plus d’être envoyés a Rsyslog[80], la plupart des événements des applications sont également stockés dans des fichiers binaires par journald[81].
Sur les modules EOLE, les journaux de référence sont ceux gérés via Rsyslog.
journald offre néanmoins d'autres modalités de recherche, utiles notamment pour l'analyse des incidents. Aussi, les modules mettent en place une configuration permettant de conserver une quantité restreinte de journaux binaires afin de limiter la place occupée mais néanmoins permettre de profiter de capacités d'interrogation étendues sur les journaux récents.
L’espace occupé par les journaux gérés par journald[81] est configuré via deux variables disponibles en mode expert dans l’onglet Logs.
Taille maximale du journal (Mo): définit une limite de taille du journal en Mo.Objectif de nombre maximal de journaux à conserver: définit la cible du nombre de journaux à conserver, étant donné que seuls les journaux archivés peuvent être supprimés pour atteindre cet objectif.
Remarque
Une configuration équivalente des fichiers gérés par Rsyslog et logrotate n’est pas disponible pour l’administrateur et répond, notamment, aux exigences légales.
Centralisation des journaux
La possibilité de centraliser des logs a été dissociée de la mise en place d'un serveur ZéphirLog[82]. Cela rend possible un transfert croisé des journaux ou une centralisation.
Le support des logs centralisés peut être activé dans l'onglet Service en mode expert.
Cette activation affiche un nouvel onglet nommé Logs dans l'interface de configuration du module.
Les options de cet onglet sont réparties en plusieurs sections :
la configuration de la réception des logs permet de spécifier les protocoles de communication entre des machines distantes émettrices identifiées par leur adresse IP et le poste configuré ;
la configuration de l'envoi des logs permet de spécifier l'adresse de la machine distante réceptrice. Le protocole (TCP[83] ou RELP[84]) utilisé est contraint par l'activation ou non du chiffrement (TLS[15]) ;
la configuration des journaux à envoyer permet de sélectionner les journaux à envoyer ainsi que l'heure de début et de fin de transfert.
Réception des journaux
Si la réception des journaux est activée (Activer la réception des logs de machines distantes à oui), il faut activer au moins l'un des 3 protocoles de réception : RELP, UDP et TLS over TCP.
L'activation des protocoles ouvre les ports adéquats sur le module.
Attention
Pour les clients EOLE, l'envoi de journaux avec le protocole TCP n'est possible que si le TLS est activé.
Envoi des journaux
L'activation de l'envoi des journaux (Activer l'envoi des logs à une machine distante à oui) nécessite la saisie de l'adresse IP du serveur centralisateur de journaux.
Le protocole (TLS over TCP ou RELP) utilisé est contraint par l'activation ou non du chiffrement (TLS).
Certificats
Si le protocole utilisé pour la réception ou l'envoi des journaux nécessite un chiffrement (TLS), il est possible de spécifier les chemins associés aux certificats utilisés par rsyslog.
Par défaut, les certificats du module sont utilisés et leur validité n'est pas vérifiée.
Choix des journaux à envoyer
Si l'envoi des journaux est activé, il est possible d'envoyer tous les journaux ou de choisir les journaux à envoyer.
Il est également possible d'envoyer les journaux en temps réel ou en différé. L'heure de début et de fin (plage temporelle) de transfert des journaux est également paramétrable.
Configuration de journald
En plus d’être envoyés a Rsyslog, la plupart des événements des applications sont également stockés dans des fichiers binaires par journald.
Sur les modules EOLE, les journaux de référence sont ceux gérés via Rsyslog. journald offre néanmoins d’autres modalités de recherche, utile notamment pour l’analyse des incidents. Aussi, les modules mettent en place une configuration permettant de conserver une quantité restreinte de journaux binaires pour limiter la place occupée mais néanmoins permettre de profiter de capacités d’interrogation étendues sur les journaux récents.
Onglet Interface-0
Configuration de l'interface
Méthode d'attribution statique
Dans le cas de la configuration statique, il faut renseigner l'adresse IP, le masque et la passerelle.
Truc & astuce
EOLE est pleinement fonctionnel avec une connexion en IP fixe. Si vous ne disposez pas d'IP fixe, certaines fonctionnalités ne seront plus disponibles.
Méthode d'attribution DHCP
La configuration DHCP ne nécessite aucun paramétrage particulier.
Attention
Lors du passage d'une configuration statique à une configuration DHCP, il faut procéder à deux reconfigure successifs.
Méthode d'attribution "non géré"
L'utilisation de la nouvelle valeur non gérée permet de déléguer la configuration réseau à cloud-init[18] ou à un autre outil de contextualisation.
En mode expert quelques variables supplémentaires sont disponibles.
Nom de l'interface réseau
Afin de respecter la convention Consistent Network Device Naming[86], le nom de l'interface réseau proposé dans l'interface de configuration du module correspond à son emplacement physique.
L'ordre de chargement des cartes réseau n'est donc plus susceptible d'être modifié en cas de changement matériel, contrairement aux versions précédentes qui utilisaient les adresses MAC[87] des cartes pour les identifier.
De ce fait, l'ancien fichier de configuration /etc/udev/rules.d/70-persistent-net.rules n'existe plus.
Truc & astuce
Ajouter des interfaces physiques supplémentaires à la variable Nom de l'interface réseau permet d’activer l’agrégation de liens Ethernet[88].
Remarque
Les noms réels des interfaces sont visibles dans le répertoire /sys/class/net/ :
# ls -d /sys/class/net/*
/sys/class/net/ens4 /sys/class/net/lo
Les interfaces gérées par EOLE sont enregistrées dans le fichier spécial : /var/lib/eole/config/persistent-net.cfg.
Nom de l'interface réseau de la zone
Ce champ permet de personnaliser le nom de l'interface logique associée à l'interface physique pour cette zone.
Mode de connexion pour l'interface
Le paramètre nommé Mode de connexion pour l'interface pour l'interface-0 et nommé Mode de connexion pour l'interface interne-x pour les autres interfaces permet de forcer les propriétés de la carte réseau.
Par défaut, toutes les interfaces sont en mode auto négociation.
Ces paramètres ne devraient être modifiés que s'il y a un problème de négociation entre un élément actif et une des cartes réseau, tous les équipements modernes gérant normalement l'auto-négociation.
Liste des valeurs possibles :
speed 100 duplex full autoneg off: permet de forcer la vitesse à 100Mbits/s en full duplex sans chercher à négocier avec l'élément actif en face ;
autoneg on: active l'auto-négociation (mode par défaut) :
speed 10 duplex half autoneg off: permet de forcer la vitesse à 10Mbits/s en half duplex et désactiver l'auto-négociation ;
speed 1000 duplex full autoneg off: permet de forcer la vitesse à 1Gbits/s en full duplex et désactiver l'auto-négociation.
Remarque
Plus d'informations : http://fr.wikipedia.org/wiki/Auto-négociation_(ethernet).
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Configuration des alias sur l'interface
EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.
Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.
Truc & astuce
Il est possible d'ajouter d'autres adresses IP alias sur l'interface en cliquant sur le bouton + Adresse IP alias pour l'interface n.
Configuration des VLAN sur l'interface
Il est possible de configurer des VLAN[26] (réseau local virtuel) sur une interface déterminée du module.
Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :
le numéro du VLAN ;
l'adresse IP de l'interface dans ce VLAN ;
le masque de sous-réseau de l'interface dans ce VLAN.
Il est possible de configurer une passerelle particulière pour un VLAN de l'interface 0.
Truc & astuce
Il est possible d'ajouter d'autres VLAN sur l'interface en cliquant sur le bouton + Numéro d'identifiant du VLAN.
Agrégation de routes IP
L'activation d'un alias IP, fait apparaître un nouveau paramètre : Répartition de charge entre 2 lignes Internet.
Pour activer l'agrégation de routes IP[27] (niveau 3), il faut passer ce nouveau paramètre à oui.
Un nouvel onglet : Agrégation est alors disponible.
Attention
Si l'agrégation de routes IP est activée, il faut obligatoirement configurer une passerelle particulière pour l'alias activé dans la rubrique Configuration des alias sur l'interface.
Configuration DNS sur l'interface-0
Sur une installation en mode une carte (exemple : EoleBase + eole-dns), le DNS est activable ou désactivable dans l'onglet Interface-0 avec la variable : Activer le serveur DNS sur cette zone.
Sur les modules Amon et AmonEcole cette question est également présente dans l'onglet Interface-0.
Pour chacune des interfaces configurées, il est possible de préciser si le DNS est maître de la zone en passant la variable Serveur master DNS sur cette zone à oui.
Attention
Au moins une des zones doit être configurée en maître de la zone.
Accès au backend EAD
Remarque
Si le pare-feu est désactivé (mode expert dans l'onglet Réseau avancé), ces autorisations ne sont plus visibles et l'accès est autorisé à tous les frontend depuis toutes les interfaces.
Onglet Interface-1
- Configuration de l'interface
- Administration à distance
- Configuration des alias sur l'interface
- Configuration des VLAN sur l'interface
- Configuration DNS sur l'interface
- Configuration des zones de filtrage
- Adresse IP pour le proxy
- Adresse IP pour le serveur de fichiers
- Adresse IP pour le contrôleur de domaine
- Accès au backend EAD
- Configuration de la détection automatique du proxy
L'onglet Interface-1 permet de configurer le réseau local de la structure.
Attention
Le module AmonEcole nécessite 4 adresses IP distinctes sur ce réseau.
Configuration de l'interface
L'adresse saisie sera celle du module AmonEcole pour le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- passerelle par défaut ;
- serveur SMTP ;
En mode expert quelques variables supplémentaires sont disponibles.
Nom de l'interface réseau
Afin de respecter la convention Consistent Network Device Naming[86], le nom de l'interface réseau proposé dans l'interface de configuration du module correspond à son emplacement physique.
L'ordre de chargement des cartes réseau n'est donc plus susceptible d'être modifié en cas de changement matériel, contrairement aux versions précédentes qui utilisaient les adresses MAC[87] des cartes pour les identifier.
De ce fait, l'ancien fichier de configuration /etc/udev/rules.d/70-persistent-net.rules n'existe plus.
Truc & astuce
Ajouter des interfaces physiques supplémentaires à la variable Nom de l'interface réseau permet d’activer l’agrégation de liens Ethernet[88].
Remarque
Les noms réels des interfaces sont visibles dans le répertoire /sys/class/net/ :
# ls -d /sys/class/net/*
/sys/class/net/ens4 /sys/class/net/lo
Les interfaces gérées par EOLE sont enregistrées dans le fichier spécial : /var/lib/eole/config/persistent-net.cfg.
Nom de l'interface réseau de la zone
Ce champ permet de personnaliser le nom de l'interface logique associée à l'interface physique pour cette zone.
Mode de connexion pour l'interface
Le paramètre nommé Mode de connexion pour l'interface pour l'interface-0 et nommé Mode de connexion pour l'interface interne-x pour les autres interfaces permet de forcer les propriétés de la carte réseau.
Par défaut, toutes les interfaces sont en mode auto négociation.
Ces paramètres ne devraient être modifiés que s'il y a un problème de négociation entre un élément actif et une des cartes réseau, tous les équipements modernes gérant normalement l'auto-négociation.
Liste des valeurs possibles :
speed 100 duplex full autoneg off: permet de forcer la vitesse à 100Mbits/s en full duplex sans chercher à négocier avec l'élément actif en face ;
autoneg on: active l'auto-négociation (mode par défaut) :
speed 10 duplex half autoneg off: permet de forcer la vitesse à 10Mbits/s en half duplex et désactiver l'auto-négociation ;
speed 1000 duplex full autoneg off: permet de forcer la vitesse à 1Gbits/s en full duplex et désactiver l'auto-négociation.
Remarque
Plus d'informations : http://fr.wikipedia.org/wiki/Auto-négociation_(ethernet).
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Configuration des alias sur l'interface
EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.
Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.
La variable Autoriser cet alias à utiliser les DNS de zones forward additionnelles permet d'autoriser le réseau de cet alias à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres adresses IP alias sur l'interface en cliquant sur le bouton + Adresse IP alias pour l'interface n.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser cet alias à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non cet alias à utiliser les DNS noms d'hôte de la zone AGRIATES.
En mode expert, si WPAD est activé, il est possible de modifier le port du proxy diffusé pour un alias donné.
Remarque
Par défaut, le port du proxy est défini à 3128 mais si le proxy NTLM est activé sur cette interface, il passe à 3127.
Configuration des VLAN sur l'interface
Il est possible de configurer des VLAN[26] (réseau local virtuel) sur une interface déterminée du module.
Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :
le numéro du VLAN ;
l'adresse IP de l'interface dans ce VLAN ;
le masque de sous réseau de l'interface dans ce VLAN.
La variable Autoriser ce VLAN à utiliser les DNS des zones forward additionnelles permet d'autoriser le réseau de ce VLAN à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres VLAN sur l'interface en cliquant sur le bouton + Numéro d'identifiant du VLAN.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser ce VLAN à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non ce VLAN à utiliser les DNS noms d'hôte de la zone AGRIATES.
En mode expert, si WPAD est activé, il est possible de modifier le port du proxy diffusé pour un VLAN donné.
Remarque
Par défaut, le port du proxy est défini à 3128 mais si le proxy NTLM est activé sur cette interface, il passe à 3127.
Configuration DNS sur l'interface
Il est possible d'ajuster les paramètres du serveur DNS pour chaque interface réseau sauf pour l'interface 0.
Nom de la zone (pour résolution DNS): entrée DNS correspondant à l'adresse IP de l'interface. Le nom (par défaut admin pour l'interface 1) doit être différent pour chacune des interfaces.
Configuration des zones de filtrage
La solution de filtrage permet de différencier 2 zones, ce qui permet de dissocier 2 politiques de filtrage majeures et distinctes comme par exemple une zone réseau administratif et une zone réseau pédagogique.
Il faut choisir à quelle zone appartient une interface. Cela s'effectue dans la configuration de chaque interface réseau en sélectionnant le numéro de la zone souhaité dans le champ Filtre Web à appliquer à cette interface.
Remarque
Les zones Filtre web 1 et Filtre web 2 correspondent chacun à une instance du logiciel de filtrage. La configuration de chacune des instances s'effectue dans l'onglet Filtrage web.
Adresse IP pour le proxy
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs internet depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur proxy (port 3128) ;
Adresse IP pour le serveur de fichiers
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs partage depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur de fichiers ;
- serveur de gestion des "clients Scribe" ;
- serveur d'impression (si activé) ;
- serveur DHCP (si activé).
Adresse IP pour le contrôleur de domaine
Cette adresse est celle qui permet d'accéder directement au groupe de conteneurs addc depuis le réseau local de la structure.
Truc & astuceServices du réseau local à configurer avec cette adresse
- serveur DNS ;
- contrôleur de domaine.
Accès au backend EAD
Remarque
Si le pare-feu est désactivé (mode expert dans l'onglet Réseau avancé), ces autorisations ne sont plus visibles et l'accès est autorisé à tous les frontend depuis toutes les interfaces.
Configuration de la détection automatique du proxy
En mode expert, si WPAD est activé, il est possible de modifier le port du proxy diffusé pour l'interface.
Remarque
Par défaut, le port du proxy est défini à 3128 mais si le proxy NTLM est activé sur cette interface, il passe à 3127.
Si le proxy NTLM est activé, la variable Activer le proxy NTLM sur cette interface permet de le désactiver pour cette interface de façon spécifique.
Onglet Interface-n
Nombre d'interfaces
Un module Amon ou AmonEcole peut avoir de 2 à 5 cartes réseau.
Le nombre d'interfaces activées se définit dans l'onglet Général de l'interface de configuration du module.
Cela ajoute autant d'onglets Interface-n que le nombre d'interfaces à activer choisi.
Configuration de l'interface
En mode expert quelques variables supplémentaires sont disponibles.
Nom de l'interface réseau
Afin de respecter la convention Consistent Network Device Naming[86], le nom de l'interface réseau proposé dans l'interface de configuration du module correspond à son emplacement physique.
L'ordre de chargement des cartes réseau n'est donc plus susceptible d'être modifié en cas de changement matériel, contrairement aux versions précédentes qui utilisaient les adresses MAC[87] des cartes pour les identifier.
De ce fait, l'ancien fichier de configuration /etc/udev/rules.d/70-persistent-net.rules n'existe plus.
Truc & astuce
Ajouter des interfaces physiques supplémentaires à la variable Nom de l'interface réseau permet d’activer l’agrégation de liens Ethernet[88].
Remarque
Les noms réels des interfaces sont visibles dans le répertoire /sys/class/net/ :
# ls -d /sys/class/net/*
/sys/class/net/ens4 /sys/class/net/lo
Les interfaces gérées par EOLE sont enregistrées dans le fichier spécial : /var/lib/eole/config/persistent-net.cfg.
Nom de l'interface réseau de la zone
Ce champ permet de personnaliser le nom de l'interface logique associée à l'interface physique pour cette zone.
Mode de connexion pour l'interface
Le paramètre nommé Mode de connexion pour l'interface pour l'interface-0 et nommé Mode de connexion pour l'interface interne-x pour les autres interfaces permet de forcer les propriétés de la carte réseau.
Par défaut, toutes les interfaces sont en mode auto négociation.
Ces paramètres ne devraient être modifiés que s'il y a un problème de négociation entre un élément actif et une des cartes réseau, tous les équipements modernes gérant normalement l'auto-négociation.
Liste des valeurs possibles :
speed 100 duplex full autoneg off: permet de forcer la vitesse à 100Mbits/s en full duplex sans chercher à négocier avec l'élément actif en face ;
autoneg on: active l'auto-négociation (mode par défaut) :
speed 10 duplex half autoneg off: permet de forcer la vitesse à 10Mbits/s en half duplex et désactiver l'auto-négociation ;
speed 1000 duplex full autoneg off: permet de forcer la vitesse à 1Gbits/s en full duplex et désactiver l'auto-négociation.
Remarque
Plus d'informations : http://fr.wikipedia.org/wiki/Auto-négociation_(ethernet).
Administration à distance
Par défaut les accès SSH[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.
Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.
Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.
Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….
Truc & astuce
Le masque réseau d'une station isolée est 255.255.255.255.
Dans le cadre de test sur un module l'utilisation de la valeur 0.0.0.0 dans les champs Adresse IP réseau autorisée pour les connexions SSH et Masque du sous réseau pour les connexions SSH autorise les connexions SSH depuis n'importe quelle adresse IP.
Truc & astuce
La commande suivante permet d'observer les connexions SSH arrivant sur un serveur EOLE : tcpdump -ni $(CreoleGet nom_carte_eth0) port 22
Complément
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans l'onglet Onglet Interface-0 partie Administration à distance
Configuration des alias sur l'interface
EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.
Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.
La variable Autoriser cet alias à utiliser les DNS de zones forward additionnelles permet d'autoriser le réseau de cet alias à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres adresses IP alias sur l'interface en cliquant sur le bouton + Adresse IP alias pour l'interface n.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser cet alias à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non cet alias à utiliser les DNS noms d'hôte de la zone AGRIATES.
En mode expert, si WPAD est activé, il est possible de modifier le port du proxy diffusé pour un alias donné.
Remarque
Par défaut, le port du proxy est défini à 3128 mais si le proxy NTLM est activé sur cette interface, il passe à 3127.
Configuration des VLAN sur l'interface
Il est possible de configurer des VLAN[26] (réseau local virtuel) sur une interface déterminée du module.
Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :
le numéro du VLAN ;
l'adresse IP de l'interface dans ce VLAN ;
le masque de sous réseau de l'interface dans ce VLAN.
La variable Autoriser ce VLAN à utiliser les DNS des zones forward additionnelles permet d'autoriser le réseau de ce VLAN à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres VLAN sur l'interface en cliquant sur le bouton + Numéro d'identifiant du VLAN.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser ce VLAN à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non ce VLAN à utiliser les DNS noms d'hôte de la zone AGRIATES.
En mode expert, si WPAD est activé, il est possible de modifier le port du proxy diffusé pour un VLAN donné.
Remarque
Par défaut, le port du proxy est défini à 3128 mais si le proxy NTLM est activé sur cette interface, il passe à 3127.
Configuration DNS sur l'interface
Il est possible d'ajuster les paramètres du serveur DNS pour chaque interface réseau sauf pour l'interface 0.
Nom de la zone (pour résolution DNS): entrée DNS correspondant à l'adresse IP de l'interface. Le nom (par défaut admin pour l'interface 1) doit être différent pour chacune des interfaces.
Configuration des zones de filtrage
La solution de filtrage permet de différencier 2 zones, ce qui permet de dissocier 2 politiques de filtrage majeures et distinctes comme par exemple une zone réseau administratif et une zone réseau pédagogique.
Il faut choisir à quelle zone appartient une interface. Cela s'effectue dans la configuration de chaque interface réseau en sélectionnant le numéro de la zone souhaité dans le champ Filtre Web à appliquer à cette interface.
Remarque
Les zones Filtre web 1 et Filtre web 2 correspondent chacun à une instance du logiciel de filtrage. La configuration de chacune des instances s'effectue dans l'onglet Filtrage web.
Accès au backend EAD
Remarque
Si le pare-feu est désactivé (mode expert dans l'onglet Réseau avancé), ces autorisations ne sont plus visibles et l'accès est autorisé à tous les frontend depuis toutes les interfaces.
Configuration de la détection automatique du proxy
En mode expert, si WPAD est activé, il est possible de modifier le port du proxy diffusé pour l'interface.
Remarque
Par défaut, le port du proxy est défini à 3128 mais si le proxy NTLM est activé sur cette interface, il passe à 3127.
Si le proxy NTLM est activé, la variable Activer le proxy NTLM sur cette interface permet de le désactiver pour cette interface de façon spécifique.
Onglet Réseau avancé
Présentation des différents paramètres de l'onglet Réseau avancé accessible en mode expert.
Configuration IP
Si la variable Activer le routage IPv4 entre les interfaces est à oui, alors le routage IPv4 est activé au niveau du noyau (/proc/sys/net/ipv4/ip_forward passe à 1)
Sécurité
Si la variable Journaliser les "martian sources" est à oui, tous les passages de paquets utilisant des adresses IP réservées à un usage particulier (http://tools.ietf.org/html/rfc5735) seront enregistrées dans les journaux.
Par défaut, l'anti-spoofing[89] est activé sur l'interface-0 des modules EOLE.
Sur les serveurs ayant 2 interfaces réseau ou plus d'activées (cas par défaut sur les modules Amon, Sphynx et Hâpy), il est possible de demander l'activation de l'anti-spoofing sur les autres interfaces en passant la variable Activer l'anti-spoofing sur toutes les interfaces à oui.
Ajout d'hôtes
Passer la variable Déclarer des noms d'hôtes supplémentaires à oui, permet de déclarer des noms d'hôtes qui seront ajoutés au fichier /etc/hosts.
Il est possible d'ajouter plusieurs hôtes supplémentaires en cliquant sur le bouton +Adresse IP de l'hôte.
Le champ Nom court de l'hôte est optionnel.
Attention
Sur les serveurs EOLE faisant office de serveur DNS, comme les modules Amon et AmonEcole, pour que le logiciel BIND[90] puisse résoudre un nom, il faut que le suffixe DNS de ce nom long corresponde au Nom de domaine privé du réseau local saisi dans l'onglet Général.
Si ce n'est pas le cas, il faut déclarer un Nom de domaine local supplémentaire dans l'onglet Zones-dns pour permettre au serveur de résoudre ce nom d'hôte.
Ajout de routes statiques
Ce bloc de paramètres permet d'ajouter, manuellement, des routes afin d'accéder à des adresses ou à des plages d'adresses par un chemin différent de celui par défaut (défini par le routeur par défaut).
Après avoir passé la variable Ajouter des routes statiques à oui il faut configurer les paramètres suivants :
Adresse IP ou réseau à ajouter dans la table de routage: permet de définir l'adresse de sous-réseau (ou l'adresse de l'hôte) vers lequel le routage doit s'effectuer ;
Masque de sous réseau: permet de définir le masque du réseau défini ci-dessus (s'il s'agit d'une machine seule, il faut mettre l'adresse du masque à 255.255.255.255) ;
Adresse IP de la passerelle pour accéder à ce réseau: permet de renseigner l'adresse de la passerelle permettant d'accéder au sous-réseau ou à l'hôte défini ci-dessus.
Interface réseau reliée à la passerelle: permet d'associer la route à une interface donnée ;Numéro d'identifiant du VLAN ou rien: permet d'associer une route à un VLAN ;
Les deux paramètres suivants apparaissent uniquement si le service eole-dns est installé sur le module :
Autoriser ce réseau à utiliser les DNS du serveur: les postes du réseau cible peuvent interroger le service DNS du serveur ;Autoriser ce réseau à utiliser les DNS des zones forward additionnelles: les postes du réseau cible sont autorisés à interroger les DNS des zones de forward.
Le paramètre suivant apparaît uniquement si le réseau virtuel privé RVP est activé :
Passer par le VPN pour accéder à ce réseau: ce réseau n'est pas un réseau local. C'est un réseau distant accessible par le VPN.
Remarque
Si le support du RVP est activé, des options supplémentaires sont disponibles :
Passer par le VPN pour accéder à ce réseau: Il est possible d'indiquer si l'accès à ce réseau doit passer ou non par le VPN.
Configuration du MTU
La variable Configurer manuellement le MTU permet d'activer ou non le path MTU discovery[91] (paramètre : /proc/sys/net/ipv4/ip_no_pmtu_disc).
Cette option est à non par défaut (ip_no_pmtu_disc=0) ce qui est le fonctionnement normal.
Cette valeur peut poser problème, notamment avec le réseau virtuel privé (VPN), lorsque les paquets ICMP[92] de type 3 (Destination Unreachable) / code 4 (Fragmentation Needed and Don't Fragment was Set) sont bloqués quelque part sur le réseau.
Truc & astuce
Un des phénomènes permettant de diagnostiquer un problème lié au PMTU discovery est que l'accès à certains sites (ou certaines pages d'un site) n'aboutit pas (la page reste blanche) ou que les courriels n'arrivent pas dans le client de messagerie.
Si vous rencontrez des problèmes d'accès à certains sites (notamment messagerie ou site intranet via le VPN, Gmail ou Gmail Apps), vous pouvez passer ce paramètre à oui (ip_no_pmtu_disc=1).
Attention
Truc & astuce
Les commandes ping, ip route et tracepath sont utilisées pour ajuster les valeurs.
Configuration de la "neighbour table"
Les variables ipv4_neigh_default_gc_thresh1, ipv4_neigh_default_gc_thresh2 et ipv4_neigh_default_gc_thresh3 servent à gérer la façon dont la table ARP évolue :
- gc_thresh1 : seuil en-deçà duquel aucun recyclage des entrées de la table qui ne sont plus utilisées n'est effectué ;
- gc_thresh2 : seuil qui, s'il est dépassé depuis un certain temps (5 secondes par défaut), déclenche le recyclage des entrées de la table qui ne sont plus utilisées ;
- gc_thresh3 : seuil au-delà duquel le recyclage est immédiatement déclenché pour contenir la taille de la table.
Test de l'accès distant
Cette variable permet de définir le ou les domaines qui sont utilisés lorsque le module EOLE a besoin de tester son accès à Internet.
En pratique, seul l'accès au premier domaine déclaré est testé sauf dans le cas où il n'est pas accessible.
Les domaines définis sont utilisés dans les outils diagnose et dans l'agent Zéphir.
Onglet Certificats ssl : gestion des certificats SSL
Afin de faciliter la mise en œuvre des certificats, leur gestion a été standardisée.
Le choix du type de certificat à mettre en place sur le serveur s'effectue dans l'onglet Général.
Certificat de type Let's Encrypt
L'autorité de certification[13] Let's Encrypt[14] permet de mettre en place, gratuitement, des certificats dont la distribution et le renouvellement sont automatisés.
Vous pouvez à présent gérer des certificats Let's Encrypt pour des serveurs accessibles depuis Internet ou au travers d'un proxy inverse.
Nom DNS supplémentaires
Il est possible de faire des requêtes supplémentaires pour d'autres noms DNS connus d'Internet que celui du serveur en renseignant la variable Nom de domaines supplémentaires.
Remarque
Il y aura autant de certificats supplémentaires que de noms DNS déclarés dans la variable Nom de domaines supplémentaires.
Paramètres du client Let's Encrypt
L'utilisation de certificats Let's Encrypt requiert l'utilisation de noms DNS connus d'Internet.
Le certificat sera créé avec le nom DNS résultant de la concaténation du nom de la machine et du nom de DNS du réseau local saisis dans l'onglet Général.
Seule la variable Mode de fonctionnement du client Let's Encrypt nécessite un paramétrage en fonction de l'accessibilité du serveur :
accessible depuis Internet → utiliser la valeur
standalone;accessible au travers d'un proxy inverse → utiliser la valeur
webroot.
Écran
- 1
le_config_dirChemin du répertoire du client Let's Encrypt
- 2
le_log_dirChemin du répertoire de travail du client Let's Encrypt
- 3
le_logs_dirChemin du répertoire de journalisation du client Let's Encrypt
- 4
le_server_addrAdresse du serveur Let's Encrypt
- 5
le_server_portPort d'écoute du serveur Let's Encrypt
- 6
le_client_modeMode de fonctionnement du client Let's Encrypt
- 7
le_http_01_portPort d'écoute pour http-01
- 8
le_tls_sni_portPort d'écoute pour TLS
- 9
le_expire_delayNombre de jours avant le déclenchement du renouvellement des certificats
Détail
- Les trois premiers points concernent l'emplacement des fichiers/données gérés par le client Let's Encrypt qui peuvent êtres modifiés.
- Les point 4 et 5 sont utiles dans le cas où vous souhaitez spécifier un serveur Let's Encrypt spécifique.
- Les points 7 et 8 permettent de modifier les ports associés aux défis
http-01etTLS-SNI. - Le point 9 permet de déclencher le renouvellement des certificats avant la fin de validité des certificats Let's Encrypt déjà acquis.
Mode Let's Encrypt
Le point 6 permet de spécifier le mode de fonctionnement de Let's Encrypt, soit :
webroot
standalone
Le choix du mode de vérification n’est pas anodin, et peut engendrer des effets de bord.
webroot : Obtenir un certificat en écrivant dans la racine d'un serveur web fonctionnel.
standalone : Obtenir un certificat en lançant un serveur web autonome (le port 80 doit être disponible)
Conseil
Pour plus d'information consulter la documentation Let's Encrypt
Certificat de type manuel
Le type manuel vous permet d'utiliser le certificat de votre choix (en général, un certificat signé par une autorité tierce).
Pour que les services d'un module EOLE l'utilisent, il faut placer vos fichiers aux endroits définis au préalable dans la section Choix du certificat SSL de l'onglet Général.
Dans le cas d'un certificat signé par une autorité externe, il faut copier le certificat de la CA en question dans /etc/ssl/local_ca/ afin qu'il soit pris en compte automatiquement (non nécessaire pour les certificats de l'IGC nationale).
Pour appliquer les modifications, utiliser la commande reconfigure.
Attention
Le répertoire /etc/ssl/local_ca/ accueille uniquement des certificats CA.
Attention
Si les certificats configurés ne sont pas trouvés, ils sont générés à partir de la CA locale.
Emplacement et contenu des fichiers
Chemin du fichier contenant le certificat SSL
Le certificat SSL est contenu dans un fichier au format PEM.
Ce fichier débute par la chaîne :
-----BEGIN CERTIFICATE-----
et se termine par :
-----END CERTIFICATE-----
Le chemin doit pointer vers le fichier contenant le certificat ainsi que les éventuels certificats intermédiaires.
Si la chaîne de certification du serveur contient une ou plusieurs autorités intermédiaires, vous devez concaténer le certificat du serveur avec les certificats des autorités intermédiaires en respectant l'ordre depuis la chaîne de certification vers l'autorité racine.
ExempleConstruction du fichier avec plusieurs autorités intermédiaires
Soit la chaîne de certification suivante :
CA-ROOTCA-SUB1signée parCA-ROOTCA-SUB2signée parCA-SUB1mon-serveursigné parCA-SUB1
Si le chemin du fichier contenant le certificat SSL est /etc/ssl/cert/mon-serveur.crt, les différents certificats devront être concaténés dans l'ordre suivant :
cat mon-serveur.crt ca-sub2.crt ca-sub1.crt > /etc/ssl/cert/mon-serveur.crt
Chemin du fichier contenant la clé privée du certificat SSL
</etc/ssl/private/ca.key>
La clé privée débute par la chaîne :
-----BEGIN RSA PRIVATE KEY-----
et se termine par :
-----END RSA PRIVATE KEY----
Chemin du fichier contenant la chaîne de certification
Ce fichier est la concaténation du fichier du certificat (sans les intermédiaires) et de la clé privée.
Cette dernière est au format PEM et est généralement fournie dans un fichier avec l'extension .pem.
Obtention d'un certificat signé par l'IGC de l’Éducation nationale
Étapes à suivre :
récupérer la requête du certificat située dans le répertoire
/etc/ssl/req/:eole.p10;se connecter sur l'interface web de demande des certificats et suivre la procédure ;
récupérer le certificat depuis l'interface (copier/coller dans un fichier) ;
copier le fichier dans le répertoire
/etc/ssl/certs/.
Attention
Seuls les ISR/OSR des académies sont accrédités pour effectuer les demandes.
Attention
En attendant que la prise en compte des certificats intermédiaires soit automatisée pour l'ensemble des services de base (fixme #13362), les manipulations nécessaires pour éviter des avertissements dans les navigateurs sont documentées dans la page wiki suivante : https://dev-eole.ac-dijon.fr/projects/modules-eole/wiki/Gestion_certificats
Certificat de type autosigné
En mode autosigné le certificat est généré localement et signé par une autorité de certification[13] locale.
Paramètres SSL
Taille de la clé
Cette variable permet de définir le paramètre default_bits de la section [req] du fichier de configuration d'OpenSSL.
Par défaut la taille de la clé est de 2048 bits.
Durée de validité du certificat
Cette variable permet de définir le paramètre default_days des sections [ CA_default ] et [req] du fichier de configuration d'OpenSSL.
Par défaut la CA et les certificats générés expirent au bout de 3 ans (1096 jours).
Sujet du certificat
Les variables de la section Subject (DN) permettent de configurer le nom complet du serveur (distinguished name[50]) à utiliser pour générer les certificats auto-signés.
Nom du pays (C=)
Cette variable permet de définir le paramètre countryName de la section [req_distinguished_name] du fichier de configuration d'OpenSSL.
Il s'agit du code du nom de pays sur deux lettres, par défaut FR pour la France.
Nom de l'organisation (O=)
Cette variable permet de définir le paramètre organizationName de la section [req_distinguished_name] du fichier de configuration d'OpenSSL.
Il s'agit du nom de la structure, par défaut Ministere Education Nationale (MENESR) dans le cadre de l'Éducation Nationale.
Nom de l'unité de l'organisation (OU=)
Cette variable est utilisée pour ajouter des unités organisationnelles[94] dans le paramètre organizationalUnitName de la section [req_distinguished_name] du fichier de configuration d'OpenSSL.
La valeur par défaut 110 043 015 représente le numéro SIREN du Ministère de l'Éducation Nationale.
Nom DNS du serveur (CN=)
Truc & astuce
La commande suivante permet d'afficher les DN de l'émetteur et du sujet du certificat généré :
root@dc1:~# openssl x509 -in /etc/ssl/certs/eole.crt -noout -issuer -subjectissuer=C = FR, O = Ministere Education Nationale (MENESR), OU = 110 043 015, OU = ac-test, CN = CA-dc1.domseth.ac-test.fr
subject=C = FR, O = Ministere Education Nationale (MENESR), OU = 110 043 015, OU = ac-test, CN = dc1.domseth.ac-test.fr
Nom DNS alternatif
La section Nom Alternatif de la machine permet de renseigner tous les noms DNS associés au serveur.
Nom DNS alternatif du serveur
Attention
Pour que les modifications soient prises en compte, il faut reconfigurer le serveur puis re-générer les certificats.
Création de nouveaux certificats
Le script /usr/share/creole/gen_certif.py permet de générer rapidement un nouveau certificat SSL.
ExempleGénération d'un certificat avec gen_certif.py
root@eole:~# /usr/share/creole/gen_certif.py -fc /etc/ssl/certs/test.crt
Generation du certificat machine
* Certificat /etc/ssl/certs/test.crt généré
Re-génération des certificats
Si les certificats auto-signés sont expirés ou si ils ne sont plus adaptés à la configuration du serveur, il est possible de les re-générer à l'aide de la commande suivante :
/usr/share/creole/gen_certif.py -f
Certificats par défaut
Un certain nombre de certificats sont mis en place lors de la mise en œuvre d'un module EOLE :
-
/etc/ssl/certs/ca_local.crt: autorité de certification propre au serveur (certificats auto-signés) ; -
/etc/ssl/private/ca.key: clef privée de la CA ci-dessus ; /etc/ssl/certs/ACInfraEducation.pem: contient les certificats de la chaîne de certification de l'Éducation nationale (igca/education/infrastructure) ;-
/etc/ssl/req/eole.p10: requête de certificat au format pkcs10, ce fichier contient l'ensemble des informations nécessaires à la génération d'un certificat ; -
/etc/ssl/certs/eole.crt: certificat serveur signé par la CA locale, il est utilisé par les applications (apache, ead2, eole-sso, ...) ; -
/etc/ssl/private/eole.key: clé du certificat serveur ci-dessus.
Après génération de la CA locale, un fichier /etc/ssl/certs/ca.crt est créé qui regroupe les certificats suivants :
-
ca_local.crt; ACInfraEducation.pem;- tout certificat présent dans le répertoire
/etc/ssl/local_ca.
Truc & astuce
Les certificats émis par l'IGC/A[96] suivants sont déployés par défaut sur les modules EOLE :
menesr/igca.crtpour le Ministère de l'Éducation nationale ;medde/antsv3racine.crtpour le Ministère de l'Ecologie, de l'Energie, du Développement durable et de la Mer.
Pour plus d'informations sur ces certificats, consulter le site de l'ANSSI[85] : https://www.ssi.gouv.fr/administration/services-securises/igca/certificats-emis-par-ligca-rsa-2048/.
Attention
À partir d'EOLE 2.7.1, la chaîne de certificats dépréciée ACInfraEducation.crt n'est plus fournie.
Onglet Dépôt tiers
L’utilisation de dépôts tiers permet d’ajouter de nouveaux paquets absents des dépôts officiels, ou de proposer des versions plus récentes.
Attention
L'introduction de paquets tiers n'est pas sans risque et peut présenter des dangers pour votre système.
Cette onglet permet la prise en charge de dépôts de paquet de type .deb.
Un dépôt nouvellement configuré s'ajoute dans le fichier /etc/apt/sources.list.d/additional.list.
root@scribe:~# cat /etc/apt/sources.list.d/additional.list #template genere par Maj-Auto## dépôt Scenarideb https://download.scenari.org/deb xenial main
# dépôt Firefox - teamdeb http://ppa.launchpad.net/mozillateam/firefox-next/ubuntu xenial main
root@scribe:~#L'ajout du dépôt est effectif après l'exécution de Query-Auto ou de Maj-Auto. L'installation d'un paquet supplémentaire s'effectue en ligne de commande.
Il est possible d'ajouter plusieurs dépôts en cliquant sur le bouton + Libellé du dépôt.
La clé de signature d'un paquet permet de vérifier l'émetteur et l'intégrité du paquet, 2 méthodes sont disponibles pour récupérer la clé publique :
serveur de clés ;
URL de la clé.
ExempleMéthode de téléchargement de la clé publique : URL de la clé
Libellé du dépôt : Scenari
Déclaration du dépôt : deb https://download.scenari.org/deb xenial main
Méthode de récupération de la clé publique du dépôt : URL
URL de la clé : https://download.scenari.org/deb/scenari.asc
ExempleMéthode de téléchargement de la clé publique : serveur de clés
Libellé du dépôt : Firefox - team
Déclaration du dépôt : deb http://ppa.launchpad.net/mozillateam/firefox-next/ubuntu xenial main
Méthode de récupération de la clé publique du dépôt : serveur de clés
URL du serveur de clés : hkp://keyserver.ubuntu.com:80/
Empreinte de la clé : 0AB215679C571D1C8325275B9BDB3D89CE49EC21
Remarque
Si le serveur fonctionne conjointement avec le module Amon et que le proxy est activé, il faut paramétrer une exception pour le domaine du dépôt dans le champ Liste des domaines de destination à ne pas authentifier de l'onglet Exceptions proxy.
ExemplePrise en charge du nouveau dépôt
root@scribe:~# Query-Auto Mise à jour le jeudi 13 avril 2017 11:01:17
*** scribe 2.6.1 (0000000A) ***Configuration du dépôt Ubuntu avec la source test-eole.ac-dijon.frConfiguration du dépôt EOLE avec la source test-eole.ac-dijon.frConfiguration du dépôt Envole avec la source test-eole.ac-dijon.frConfiguration du dépôt Scenari avec la source download.scenari.orgConfiguration du dépôt Firefox - team avec la source ppa.launchpad.net
Action update pour root
Action list-upgrade pour root
Mise à jour OK
Aucun paquet à installer.
root@scribe:~#Utiliser un fichier meta-release-lts alternatif
Le fichier meta-release-lts contient les adresses de tous les dépôts Ubuntu.
Dans un environnement sans accès direct à internet, on peut définir, via ce fichier, l'emplacement interne des dépôts à utiliser par Upgrade-Auto.
Dans l'interface de configuration du module, en mode expert, aller dans l'onglet Dépôt tiers.
La variable upgrade_auto_meta_release_repo permet de définir où est téléchargé le fichier meta-release-lts.
Onglet Schedule
L'onglet Schedule permet de personnaliser la fréquence ou de désactiver les tâches eole-schedule[43] liées à la mise à jour.
La tâche schedule queryauto sert à vérifier la disponibilité des mises à jour. Il est possible de lui associer une notification par courriel dans l'onglet Général.
La tâche schedule majauto installe les mises à jour, reconfigure et redémarre le serveur si nécessaire. Une variable permet de désactiver le redémarrage automatique du serveur dans l'onglet Général.
Attention
Si la fréquence des tâches Schedule est personnalisée dans l'interface de configuration du module, c'est cette dernière qui prévaut et l'activation/désactivation de la mise à jour hebdomadaire via l'EAD ou la commande manage_schedule n'est plus possible.
Onglet Apt-cacher
Pour mettre en œuvre les services du module Amon et du module Scribe sur une même machine le module AmonEcole est en mode conteneur.
Le mode conteneur utilise dorénavant le service apt-cacher-ng pour mettre en cache les paquets Debian. Le service est installé sur le maître et est utilisé par le maître et les conteneurs LXC.
Il est possible dans cet onglet de changer le port d'écoute par défaut de ce service.
Onglet Agrégation : Mise en place d'une répartition de charge ou d'une haute disponibilité
Présentation et mise en place de l'agrégation de routes IP
L'agrégation de routes IP (niveau 3) permet la mise en place d'une répartition de charge ou d'une haute disponibilité pour les sorties Internet.
Les deux routeurs sont reliés entre eux par un commutateur (ou un Hub) à la première carte du module Amon.
Dans ce cas :
- pas besoin d'utiliser les protocoles d'annonce de routes RIP[28] et OSPF[29] ;
- il faut un service qui surveille l'état de chacun des liens.
Attention
Il est nécessaire d'activer un alias sur l'interface réseau connectée sur l'extérieur pour utiliser ce service.
Remarque
La configuration de l'agrégation est le résultat de plusieurs contributions de collègues en académie.
La première version a été réalisée par l'académie de Versailles, puis elle a été améliorée successivement par les académies de Nantes et de Lyon.
Onglet Général
Dans la section Adresse IP du serveur DNS de l'onglet Général, ajouter les adresses des serveurs DNS de chacun des fournisseurs, en plaçant, de préférence, le DNS du premier lien en première position.
Onglet Interface-0
Il faut, en premier lieu, déclarer un alias sur l'interface 0 dans la section Configuration des alias sur l'interface.
Les paramètres réseaux (IP, masque et passerelle) doivent être ceux attribués par le fournisseur d'accès du second lien.
L'activation d'un alias IP, fait apparaître un nouveau paramètre, Répartition de charge entre 2 lignes Internet, qu'il faut passer à oui.
Un nouvel onglet, Agrégation, est disponible.
Onglet Agrégation : Configuration de l'agrégation de routes IP
Pour avoir accès à l'onglet concernant l'agrégation, il faut avoir activé la Répartition de charge entre 2 lignes Internet dans l'onglet Interface-0 comme expliqué précédemment.
Modes d'agrégation
Il existe deux modes d'agrégation :
le mode
mode-lb(pour load balancing) correspond à la répartition de charge et fonctionne avec la notion de poids à utiliser sur les différentes passerelles ;le mode
mode-fo, (pour fail-over) un seul lien est utilisé à la fois, il n'y a plus de notion de poids et il n'y a plus qu'une seule route par défaut.
Dans les deux modes il est possible de forcer des destinations IP ou réseau, et dans les deux cas si un lien tombe tous les flux (et également les destinations forcées) sont redirigés vers le second lien.
Quand les deux liens sont fonctionnels, on se retrouve dans la configuration de départ.
Attention
Le VPN, de par son mode de fonctionnement, ne peut pas être réparti entre plusieurs abonnements.
Tout le trafic devant passer par un seul lien, il est nécessaire d'utiliser le mécanisme de destination forcée.
Que le Lien 1 ou le Lien 2 soit choisi pour faire transiter le VPN, s'il devient indisponible, le VPN ne fonctionnera plus.
Adresse des DNS
Les champs Adresse du DNS sur le lien 1 et Adresse du DNS sur le lien 2 sont des champs obligatoires pour le bon fonctionnement de l’agrégation.
Attention
Les adresses DOIVENT être différentes sur chaque lien car c'est avec ces DNS que se font les tests d'état des liens.
Adresse DNS testée
Il est possible de spécifier plusieurs mires de tests qui seront testées afin de déterminer l'état des liens (résolution DNS avec le serveur DNS de chacun des liens).
Attention
L'ensemble des DNS doit être déclaré dans l'onglet Général.
Alerte mail
Lorsque l'un des liens est coupé, le message suivant est envoyé : Seul le lien 2 est actif, redirection des flux sur ce lien.
Quand les deux liens sont de nouveau fonctionnels, le message suivant est envoyé : Rechargement de la répartition sur les 2 liens.
Commandes
L'agrégation peut être suspendue et/ou relancée à l'aide du script agregation :
root@amon:~# agregation status
le service Agregation n'est pas démarré
root@amon:~#
Truc & astuce
L'option -h affiche l'aide de la commande :
root@amon:~# agregation -h
Usage: /usr/share/eole/sbin/agregation {start|stop|status|restart}
root@amon:~#
Onglet Eoledb : Gestion des bases de données
EoleDB est disponible depuis la version 2.5.2 d'EOLE. C'est une re-implémentation de l'ancien gestionnaire des bases de données EOLE (eole-sql) dont les objectifs principaux sont :
n'utiliser qu'un seul fichier de configuration ;
supporter nativement plusieurs types de bases de données (MySQL, PostgreSQL, SQLite, ...) ;
supporter nativement l'externalisation des bases de données sur d'autres serveurs ;
ne plus avoir à fournir des scripts python dans les paquets d'application web du projet EOLE pour pouvoir générer ou mettre à jour des bases de données (cf eole-sql :
/usr/share/eole/applications/gen/,/usr/share/eole/applications/passwords/,/usr/share/eole/applications/updates/).
EoleDB rend possible l'externalisation des bases de données d'un module EOLE.
Remarque
Pour le moment, EoleDB gère uniquement les bases de données MySQL[97] et PostgreSQL[59].
Cet onglet est disponible en mode expert sur les modules Scribe et AmonEcole.
Sur les autres modules, il est possible d'installer manuellement le paquet eole-db :
# apt-eole install eole-db
Par défaut le serveur de base de données est paramétré comme étant local. Dans le cas où le serveur est distant quelques variables sont à renseigner.
Adresse du serveur de base de données: adresse IP, nom de machine ou nom de domaine du serveur de base de données distant. Cette valeur est utilisée pour toutes les applications web qui ne définiront pas elles-mêmes un serveur de base de données.Port du serveur de base de données: port du serveur de base de données utilisé, par exemple3306pour le serveur MySQL fourni par EOLE.Nom d'utilisateur d'administration: identifiant du gestionnaire de la base de données distante.Fichier de mot de passe: chemin d'accès vers le fichier qui contient le mot de passe du gestionnaire, par exemple/root/bdpass.txt. Ce fichier doit être accessible par EoleDB, idéalement le fichier doit avoir les droits 600.Machines qui peuvent utiliser le serveur de BDD: permet d'autoriser des machines à accéder à l'administration des bases distantes #fixme, si rien n'est renseigné l'adresse IP du serveur utilisant EoleDB est ajoutée automatiquement dans le fichier de configuration.
Paramètre Eoledb associés aux applications liées
Par défaut, le serveur de base de données est paramétré comme étant local.
Pour chaque application installée et activée (notamment les application Envole), une ligne de paramétrage supplémentaire s'ajoute dans l'onglet EoleDB.
Exemple
De base, trois applications sont disponibles : Posh-Profile, Roundcube et Nextcloud (depuis EOLE 2.8.1).
Les applications ont leur serveur pré-configuré à défaut, ce qui induit qu'elles reprennent la configuration indiquée plus haut dans la section Configuration l'onglet EoleDB.
Comprendre posh-profile
En laissant la valeurs sur default, les informations de configuration de l'onglet EoleDB seront automatiquement reprises. Il s'agit de la configuration la plus répandue correspondant à la majorité des cas.
Posh-profile permet la synchronisation des comptes utilisateurs entre les différentes applications web EOLE et la base utilisateur EoleDB. Exemple d'application web : eole-nextcloud (toutes les applications envole utilisent cette mécaniques)
Valeurs : <externe>
Écran
- 1
Variable EOLE : <poshprofil_db_mode>
Emplacement de la base de donnée utilisé par Posh-profile.
- 2
Variable EOLE : <poshprofil_dbserver>
Adresse du serveur de base de données.
- 3
Variable EOLE : <poshprofil_dbport>
Port d'accès à la base de donnée distante, par défaut 3306.
- 4
Variable EOLE : <poshprofil_allow_hosts>
Identification des hôtes autorisé à accéder à la base de donnée.
- 5
Variable EOLE : <poshprofil_db_mode>
Identifiant de l'utilisateur à utiliser sur la base de donnée.
- 6
Variable EOLE : <poshprofil_dbpass>
Emplacement du fichier de mot de passe de la base de donnée, exemple :
/root/.mysql
Plusieurs base de données.
Dans le cas ou il y aurait plusieurs bases de données auxquelles se connecter, il est nécessaire de sélectionner la variable "externe".
Indiquer l'emplacement de la base de donnée.
Renseigner l'adresse de la base de donnée. Attention dans le cas ou ces bases de données ce trouvent dans le même domaine, il sera nécessaire de leur donner différents Alias afin de les distinguer.
Remplir avec le port renseigné pour la base de donnée EoleDB distante. (par défaut
3306)Indiquer Tous les hôtes autoriser à ce connecter à la base de données distantes. Lors de la première connexion ils seront ajouté dans la base et autorisé à communiquer avec celle-ci.
Renseigner l'identifiant de l'utilisateur permettant l'accès à la base de données.
Emplacement du fichier de mot de passe de la base de donnée, couramment :
/root/.mysql
ExempleExemple de cas d'usage où la variable externe est nécessaire.
Dans ce cas il est nécessaire de changer la variable pour Appli_WEB4 qui utilise une autre base de données eole-db.
Base de type local
Écran
Truc & astuce
Dans le cas ou vous avez plusieurs applications web mais que certaines ne doivent pas avoir accès à la base EoleDB locale, vous avez la possibilité de les spécifier dans l'option Hôtes autorisés à utiliser la base de données.
Onglet Mots de passe : Politique de mot de passe pour les utilisateurs
Contrôle de complexité dans les interfaces de saisie du module
Cet onglet permet de modifier la politique de contrôle des mots de passe Active Directory appliquée lors de la saisie et la modification au travers des interfaces fournies sur le module.
Longueur minimale des mots de passe
Cette variable permet de définir la longueur minimale requise pour un mot de passe.
La longueur minimale est paramétrable de 3 à 12 caractères.
Nombre minimum de classes de caractères
Cette variable permet de choisir le nombre minimum de classes de caractères[30] imposé pour le mot de passe d'un compte utilisateur.
Il est possible d'imposer l'utilisation de 1 à 4 classes différentes parmi :
- caractères minuscules ;
- caractères majuscules ;
- caractères numériques ;
- autres caractères (spéciaux et accentués).
Interdire la présence du nom d’utilisateur dans le mot de passe
La présence du nom d’utilisateur dans le mot de passe affaiblit le mot de passe en permettant qu’une partie des caractères utilisés pour le mot de passe soient prévisibles.
Interdire la présence du nom d’utilisateur dans le mot de passe permet de rejeter un mot de passe lors de son changement si celui-ci contient le nom de l’utilisateur concerné.
Remarque
Attention, un mot de passe sécurisé doit avoir une longueur de 8 caractères et doit contenir au minimum 3 classes différentes de caractères.
Attention
Dans le cadre de l'utilisation d'un serveur Active Directory, la politique de sécurité définie dans ici doit être en accord avec celle du serveur AD.
Politique de sécurité du serveur Active Directory
La gestion des règles de mots de passe du domaine et la gestion fine des règles de mots de passe par groupe via la configuration du module est disponible dès la version 2.7.2 via l’installation du paquet eole-ad-dc-pso.
Ce paquet est pré-installé sur le module à partir de la version 2.8.1.
Règles globales du domaine
Le contrôleur de domaine permet d’établir des règles pour les mots de passe. Ces règles s’appliquent à chaque utilisateur du domaine.
On peut distinguer deux types de règles :
- les règles globales au domaine, s’appliquant par défaut à tous les utilisateurs ;
- les règles spécifiques à des utilisateurs ou groupes d’utilisateurs, prenant le pas sur les règles globales.
Ces règles concernent plusieurs aspects du mot de passe :
- sa complexité, en termes de caractères le composant ;
- sa longueur ;
- sa durée de validité.
L’interface de configuration du module permet de configurer les règles globales du domaine et d’associer des règles spécifiques à des groupes.
Dans le détail, les règles disponibles dans l’interface de configuration du module sont les suivantes :
Longueur minimal du mot de passe: la longueur minimale empêche l’utilisation de mot de passe plus court que le nombre de caractères spécifiésLongueur de l’historique des mots de passe: un mot de passe valide ne doit pas être un mot de passe figurant dans l’historique des mots de passe de l’utilisateur ; une longueur d’historique longue empêche un utilisateur d’utiliser à nouveau un mot de passe employé récemmentÂge minimal du mot de passe: l’âge minimal du mot de passe bloque les changements de mots de passe trop rapprochés dans le tempsÂge maximal du mot de passe: l’âge maximal du mot de passe impose un changement de mot de passe à l’utilisateur avant la fin du délai sous peine de ne plus pouvoir se connecter.
Un utilisateur peut donc changer son mot de passe lorsque ce dernier est plus vieux que l’âge minimal mais moins vieux que l’âge maximal.
ÉcranConfiguration des règles globales du domaine
- 1
Longueur minimal du mot de passe
Détermine la longueur minimale acceptée pour les mots de passe dans la politique globale du domaine (en nombre de caractères)
- 2
Longueur de l’historique des mots de passe
Détermine le nombre de mots de passe conservés pour chaque utilisateur dans la politique globale du domaine
- 3
Âge minimal du mot de passe
Détermine le délai minimal entre deux opérations de changement de mot de passe (en jours)
- 4
Âge maximal du mot de passe
Détermine la durée maximale de validité du mot de passe après laquelle le compte est verrouillé (en jours)
ÉcranConfiguration des règles spécifiques aux groupes du domaine
- 1
Groupe avec ce niveau de complexité
Détermine le groupe auquel seront associées les règles définies
- 2
Longueur minimale du mot de passe
Détermine la longueur minimale des mots de passe des individus du groupe ciblé
- 3
Longueur de l’historique des mots de passe
Détermine le nombre de mots de passe conservés dans l’historique de chaque individu du groupe ciblé
- 4
Âge minimal du mot de passe
Détermine le délai minimal entre deux opérations de changement de mot de passe pour les individus du groupe ciblé (en jours)
- 5
Âge maximal du mot de passe
Détermine la durée maximale de validité du mot de passe des individus du groupe ciblé après laquelle le compte est verrouillé (en jours)
Complexité des mots de passe
En termes de complexité de mots de passe, Samba suit les contraintes référencées dans la documentation sur la mise en place du contrôleur de domaine:
Ces contraintes évaluent la composition du mot de passe caractère par caractère mais également globalement.
Globalement, le mot de passe ne doit pas contenir l’identifiant, si l’identifiant est long de plus de trois caractères, ou des portions de l’identifiant, si l’identifiant peut être découpé en plusieurs parties en suivant certains caractères.
Caractère par caractère, un mot de passe est valide si il contient au moins trois classes de caractères parmi cinq classes prédéfinies (majuscules des lettres des langues européennes, minuscules des lettres des langues européennes, chiffres en base dix, caractères spéciaux non alpha-numériques et caractères unicode identifiés comme caractères alphabétiques sans distinction de casse).
ÉcranConfiguration des règles globales du domaine
- 1
Applique les règles de complexité sur le mot de passe
Détermine si le mot de passe doit valider les règles de construction définies en interne par Samba
ÉcranConfiguration des règles spécifiques aux groupes du domaine
- 1
Applique les règles de complexité sur le mot de passe
Détermine si le mot de passe des individus du groupe ciblé doit valider les règles de complexité internes à Samba
Onglet Active Directory
À partir de la version 2.6.1 d'EOLE, le module Seth utilise la version 4.5 de Samba.
Cette version de samba permet notamment la prise en compte de plusieurs DNS Forwarders[32] :
Ainsi, la liste complète des serveurs DNS renseignés dans l'interface de configuration du module est prise en compte (et plus seulement le premier de la liste).
Nom du serveur dans le domaine AD
ComplémentCaractères autorisés et non autorisés
Les noms d'ordinateur au format NetBIOS[34] peuvent contenir tous les caractères alphanumériques à l'exception des caractères étendus suivants :
- la barre oblique inverse (\) ;
- marque de barre oblique (/) ;
- signe deux-points (:) ;
- astérisque (*) ;
- point d'interrogation (?) ;
- guillemet (") ;
- inférieur à (<) signe ;
- signe supérieur à (>) ;
- barre verticale (|).
Attention, les noms peuvent contenir un point, mais ne peuvent pas commencer par un point.
Pour en savoir plus sur les conventions de nommage dans un domaine, vous pouvez consulter la page :
Rôle du serveur Active Directory
Cette variable permet de choisir le Rôle du serveur :
- contrôleur de domaine ;
- serveur membre d'un domaine existant.
Dans le cas où le serveur à mettre en place a le rôle de contrôleur de domaine, il faut définir si celui-ci est le contrôleur de domaine principal ou si il s'agit d'un contrôleur additionnel.
Imposer le SID du domaine AD à son initialisation
Forcer le SID s'effectue en deux temps :
- en passant la variable
Imposer le SID du domaine AD à son initialisationàoui; - en renseignant la variable
SID du domaine AD.
Après sauvegarde et instance, ces deux variables sont verrouillées et ne peuvent plus être modifiées.
Attention
La prise en compte du SID forcé est réalisée lors de l'initialisation de l'annuaire Active Directory.
Cette variable n'a plus d'utilité une fois le module instancié.
Attention
Le SID n’est pas validé au moment de la saisie. Il est nécessaire de s’assurer qu’il est correct avant de sauvegarder.
Contrôleur de domaine en lecture seule
Forcer le positionnement dans un site AD à l'initialisation
À partir de la version 2.6.2, il est possible de demander à ce qu'un contrôleur de domaine additionnel soit rattaché à un site Active Directory particulier.
Cette demande s'effectue en deux temps :
- en passant la variable
Forcer le positionnement de ce contrôleur de domaine dans un site existantàoui; - en renseignant la variable
Site de destination de ce contrôleur de domaine.
Après sauvegarde et instance, ces deux variables sont verrouillées et ne peuvent plus être modifiées.
Attention
La prise en compte du domaine de rattachement est réalisée lors de l'initialisation de l'annuaire Active Directory.
Cette variable n'a plus d'utilité une fois le module instancié.
Attention
Le site doit impérativement avoir été déclaré au préalable sur le contrôleur de domaine principal.
Truc & astuce
Si le contrôleur de domaine principal est un module Seth, la déclaration d'un site s'effectue facilement grâce à la fonction bash samba_update_site :
. /usr/lib/eole/samba4.sh
samba_update_site monsite 10.1.1.0/24
Méthode de calcul des uid-gid
Dans le cas d'un serveur membre d'un domaine existant, il est possible de personnaliser la méthode de calcul des UID / GID (IDMAP[99]) en passant la variable Utiliser la méthode par défaut de calcul des uid-gid à non.
Plusieurs domaines cibles avec des limites haute et basse d'adresse IP et des méthodes de calcul différentes (rid, autorid, ad, ldpa, tdb, nss) peuvent être déclarés.
Remarque
Depuis la version 4.4.6 de Samba, la personnalisation du calcul des identifiants pose problème sur un contrôleur de domaine.
Mise en œuvre du service DNS
Choix du composant
Le choix du composant à utiliser s'effectue à l'aide de la variable : Utiliser le service DNS interne de Samba.
À partir d'EOLE 2.7.1, Bind9 est utilisé par défaut (choix non).
Il est possible de forcer l'utilisation du composant interne de Samba en passant la variable à oui.
La commande reconfigure permet de passer d'un composant à l'autre de façon transparente.
Le comportement des deux services est similaire. L’utilisation de Bind9 ne change pas la manière d’ajouter les machines à la base de données DNS de Samba qui en garde la gestion. Bind9 interroge cette base via un greffon.
Attention
Dans une infrastructure mettant en œuvre plusieurs contrôleurs de domaine et la synchronisation des données de l’AD, il est impératif de mettre en œuvre le même type de service DNS pour tous les contrôleurs de domaine.
Dans le cas contraire, la réplication avec la commande samba-tool drs provoquera une erreur.
Transfert de zone
Dans le cas où le service DNS est délégué à Bind, il est possible de restreindre les machines autorisées à demander un transfert de zone[100] auprès du serveur DNS.
Attention
Le paramètre dns zone transfer clients est issu d'une contribution qui n'était pas intégrée nativement dans Samba :
https://gitlab.com/samba-team/samba/-/merge_requests/169.
La contribution a finalement été intégrée dans Samba 4.15 sous la forme de deux nouveaux paramètres :
dns zone transfer clients allowdns zone transfer clients deny
Empreintes de mot de passe supplémentaires
A partir de la version samba 4.7, il est possible de générer des Hash de mot de passe supplémentaires qui seront stockés dans l'attribut Active Directory : SupplementalCredentials.
L'interface permet d'activer la génération d'empreintes aux formats CryptSHA256 et CryptSHA512.
Pour chaque format sélectionné, il faut préciser le nombre d'itérations à utiliser.
Remarque
Après activation, les empreintes supplémentaires ne seront générées qu'à partir du prochain changement de mot de passe.
Remarque
Ces variables agissent sur le paramètre Samba : password hash userPassword schemes.
Attention
Sur Seth >= 2.8.0, ces deux paramètres semblent dysfonctionnels et sont susceptibles d'empêcher l'instanciation du module.
Environnement réseau
Adresse des contrôleurs du même domaine
Si plusieurs contrôleurs de domaine doivent être mis en place, il est impératif qu'ils se connaissent les uns les autres.
La variable Adresse IP des contrôleurs de domaine en relation avec ce contrôleur de domaine Active Directory permet de déclarer les adresses IP des autres contrôleurs du domaine.
Pour chacun des contrôleurs déclarés, il est possible de préciser si il a le rôle de serveur KDC[35] et/ou DNS[3].
Contrôleur de référence pour le volume SYSVOL
Dans le cas de la mise en œuvre d'un contrôleur de domaine additionnel, il est recommandé de déclarer le contrôleur de domaine principal en tant référence pour le volume SYSVOL.
Remarque
Dans le monde Microsoft, les contrôleurs de domaine sont habituellement tous au même niveau. Ceci est possible grâce à la réplication de l'annuaire Active Directory et à l'utilisation d'un système de fichiers distribué (DFS[36]).
À l'heure actuelle, la réplication du partage SYSVOL[37] n'est pas supportée par Samba. De ce fait, la mise en œuvre d'une architecture multi-DC[38] avec le module Seth nécessite de définir un contrôleur de domaine principal qui héberge les fichiers SYSVOL de référence et des contrôleurs de domaine additionnels sur lesquels ces fichiers sont synchronisés à intervalle régulier via rsync[39].
Résolutions DNS Inversées
À partir d'EOLE 2.7.2, la variable Créer les zones de résolutions DNS Inversées, permet de déclarer des zones de recherche inverse (PTR[40]).
La variable Créer les zones de résolutions DNS Inversées d'après la configuration réseau permet de créer automatiquement la zone associée au réseau local déclaré dans l'onglet Interface-0.
La variable Liste des zones à créer permet de déclarer des zones supplémentaires. Cela est nécessaire si les clients sont situés sur un réseau différent de celui du serveur.
AttentionFormat de saisie
Pour déclarer une zone, il faut saisir les 3 premiers octets IP du sous-réseau dans l'ordre inverse.
Exemple, pour déclarer le réseau 192.168.0.0/24, il faudra saisir : 0.168.192.
Type du contrôleur de référence
En mode expert, toujours dans le cas de la mise en œuvre d'un contrôleur de domaine additionnel, il est possible de préciser le type du serveur de référence.
Cette variable est particulièrement utile dans le cas où le contrôleur de domaine de référence n'est pas un module Seth.
#FIXME
Restrictions d'accès réseau
Le bon fonctionnement d’une infrastructure basée sur un serveur Active Directory nécessite un certain nombre d’interactions avec d’autres serveurs et les postes clients.
Les ports suivants sont concernés par ces interactions :
53 (DNS)
5353 (broadcast DNS)
123 (NTP)
88 (Kerberos)
445 (SMB CIFS)
135 (MSRPC)
3268 (Global Catalog)
3269 (Global Catalog)
464 (kpasswd)
389 (ldap)
636 (ldaps)
Les ports suivants peuvent être ouverts si nécessaire mais concernent un protocole obsolète :
137 (NetBIOS)
138 (NetBIOS)
139 (NetBIOS)
Sur un module Seth, l'accès aux services Samba et LDAP est ouvert à toutes les sources par défaut.
En mode expert, il est possible de restreindre l'accès réseau sur les services Samba et LDAP à des sources spécifiques.
Personnalisation des ports
Ports NetBIOS
En mode expert, il est possible d'autoriser ou non l'accès au serveur via les ports NetBIOS.
Remarque
Personnalisation des ports RPC
Remarque
Ces variables agissent sur le paramètre Samba : rpc server port.
Si ils ne sont pas configurés explicitement, le comportement antérieur, à savoir l'utilisation du premier port libre dans la plage 1024-5000, est conservé.
Partage de fichiers
Attributs étendus
Samba permet d’utiliser le module acl_xattr pour stocker les règles d’accès au contenu des partages sous la forme d’attributs étendus compatibles avec le système de fichiers du serveur.
Cette fonctionnalité permet d'utiliser des utilitaires du système pour gérer les règles d'accès aux fichiers et dossiers.
Il est possible de désactiver ce type de stockage dans le cas très particulier où les attributs étendus posent des problèmes pour la gestion des droits.
Cependant, son utilisation reste vivement recommandée sur les serveurs de fichiers :
Activation du module de prise en charge des corbeilles
Par défaut lorsque l'on supprime un fichier depuis un partage Samba, il est directement supprimé.
L'option Charger le module recycle pour la prise en charge des corbeilles paramètre Samba afin que les fichiers supprimés soient déplacés dans un répertoire tampon avant la suppression définitive.
Le nom proposé par défaut, .corbeille, définit un répertoire qui sera masqué pour les utilisateurs.
Il est possible de rendre ce répertoire accessible en supprimant le . dans le nom du répertoire.
La durée de conservation des fichiers supprimés est paramétrable.
Remarque
Les fichiers déplacés dans la corbeille sont inclus dans le calcul de l'espace disque occupé par l'utilisateur. Pour limiter les dépassements de quota disque, il est conseillé de paramétrer une durée de conservation assez courte.
Attention
L'activation du module Samba recycle, n'active pas automatiquement la corbeille sur les répertoires partagés.
Pour activer la corbeille sur les répertoires personnels des utilisateurs, il faut passer la variable Activer la corbeille pour le partage "homes" à oui.
Il est également possible de l'activer sur les répertoires partagés, mais cela s'effectue au cas par cas.
Partages utilisateur
Les partages utilisateur et les autres répertoires partagés peuvent être locaux et/ou hébergés sur d'autres serveurs Active Directory.
Sur le serveur local, il est possible d'activer ou non l'hébergement des partages « homes » et « profiles » des utilisateurs.
Dans le cas où l'on ne souhaite pas héberger ces répertoires localement, il est possible d'indiquer le nom d'hôte d'une machine du domaine (un serveur membre par exemple) sur lesquels ils seront stockés.
En mode expert, si les partages et/ou les profils sont gérés localement, il est possible de personnaliser le répertoire dans lequel ils seront stockés sur le serveur.
Si le module recycle est activé, il est également possible d'activer la corbeille Samba pour les répertoires personnels des utilisateurs
Répertoires partagés
Passer la variable Configurer des répertoires partagés à oui permet de déclarer un ou plusieurs partages additionnels. Pour ajouter un ou plusieurs partages il faut cliquer sur le bouton + Nom du répertoire partagé.
Les options à renseigner pour chaque partage supplémentaire sont :
- le
Nom du répertoire partagé; - le
Chemin du partage: le chemin Unix du répertoire à partager ; - la
Description du partage; Le partage peut être écrit: le partage peut être défini en lecture/écriture ou en lecture seule (optionwriteable) ;Le partage peut être parcouru: le partage est visible dans le voisinage réseau ou non (optionbrowseable) ;- le
Masque de permissions pour les fichiers(optionnel) : masque par défaut des fichiers créés (optioncreate mask) ; - le
Masque de permissions pour les répertoires(optionnel) : masque par défaut des répertoires créés (optiondirectory mask) ; - la possibilité d'
Activer la corbeille pour le partage(proposé uniquement si le modulerecycleest activé).
Remarque
Les répertoires déclarés sont pris en compte et créés sur le disque lors de l'instanciation ou la reconfiguration du module.
Truc & astucePartages manuels
Le fichier de configuration /etc/samba/smb.conf est re-généré à chaque reconfiguration du serveur (commande reconfigure).
Il est possible de déclarer des partages supplémentaires manuellement en plaçant un fichier (possédant l'extension .conf) décrivant le partage dans le répertoire /etc/samba/conf.d/ .
Sa prise en compte nécessite un reconfigure.
Options de journalisation
La version samba 4.9 améliore la journalisation des événements et leur complétude.
À partir d'EOLE 2.7.1, il est possible de paramétrer le niveau de journalisation global mais également d'en spécifier un spécifique pour un ou plusieurs événements samba.
Attention
Le nom des variables EOLE associées aux catégories d'événements à journaliser contient des mots clés qui susceptibles d'être détectés par les bloqueurs de publicité des navigateurs.
En cas d'erreur lors de l'édition de ces variables, vérifier que les bloqueurs sont bien désactivés pour ce formulaire.
Remarque
Ces variables agissent sur le paramètre Samba : log level.
Truc & astuce
Pour une modification temporaire du niveau de journalisation, il est préférable d'utiliser la commande smbcontrol :
root@dc1:~# smbcontrol smbd debuglevelPID 860: all:0 tdb:0 printdrivers:0 lanman:0 smb:0 rpc_parse:0 rpc_srv:0 rpc_cli:0 passdb:0 sam:0 auth:0 winbind:0 vfs:0 idmap:0 quota:0 acls:0 locking:0 msdfs:0 dmapi:0 registry:0 scavenger:0 dns:0 ldb:0 tevent:0 auth_audit:0 auth_json_audit:0 kerberos:0 drs_repl:0 smb2:0 smb2_credits:0 dsdb_audit:0 dsdb_json_audit:0 dsdb_password_audit:0 dsdb_password_json_audit:0 dsdb_transaction_audit:0 dsdb_transaction_json_audit:0 dsdb_group_audit:0 dsdb_group_json_audit:0root@dc1:~# smbcontrol smbd debug "3 kerberos:4"root@dc1:~# smbcontrol smbd debuglevelPID 860: all:3 tdb:3 printdrivers:3 lanman:3 smb:3 rpc_parse:3 rpc_srv:3 rpc_cli:3 passdb:3 sam:3 auth:3 winbind:3 vfs:3 idmap:3 quota:3 acls:3 locking:3 msdfs:3 dmapi:3 registry:3 scavenger:3 dns:3 ldb:3 tevent:3 auth_audit:3 auth_json_audit:3 kerberos:4 drs_repl:3 smb2:3 smb2_credits:3 dsdb_audit:3 dsdb_json_audit:3 dsdb_password_audit:3 dsdb_password_json_audit:3 dsdb_transaction_audit:3 dsdb_transaction_json_audit:3 dsdb_group_audit:3 dsdb_group_json_audit:3Options avancées
À partir d'EOLE 2.7.1, il est possible de modifier le format de la base de données interne à Samba et de désactiver le chiffrement des mots de passe qui est appliqué par défaut à partir de la version 4.8 de Samba.
Ces deux paramètres doivent être choisis avant la première instance du module, ils ne sont plus modifiables par la suite.
Format de la base de données interne à Samba
Chiffrement des mots de passe
Les attributs sensibles doivent être chiffrés. Certains outils externes (synchronisation) nécessitent des mots de passe en clair, d'où la possibilité de désactiver ce chiffrement.
Nombre maximum de clients winbind
Nom de variable : ad_winbind_max_clients
Nombre maximum de clients acceptés par le serveur winbind. Une fois cette limite atteinte le serveur commence à fermer les connexions des clients en attente. cette variable définit la valeur de l'option de configuration samba winbind max clients. Sa valeur par défaut est de 400 mais pour une annuaire centralisé il est préférable de définir une valeur plus importante comme 3000 par exemple en fonction de la taille et des besoins de la structure.
Délai d’exécution des requêtes winbind en secondes
Nom de variable : ad_winbind_request_timeout
Délai d'attente en secondes avant l'arrêt d'une requête winbind. Si la requête n’aboutit pas après ce délai, elle est considérée comme échouée. Cette variable définit la valeur de l'option de configuration samba winbind request timeout. La valeur par défaut est de 30 secondes.
Remarque
La clé de chiffrement est enregistrée dans le fichier /var/lib/samba/private/encrypted_secrets.key. Elle ne doit jamais être révélée.
Utilisateurs
Lier les utilisateurs AD directement dans la base des utilisateurs systèmes.
La variable Proposer les utilisateurs/groupes via la commande getent (ad_enum_users_groups) est une variable en mode expert qui permet de lister les utilisateurs AD directement dans la base des utilisateurs systèmes.
En passant la variable à oui, si on exécute la commande getent passwd on peut voir les utilisateurs systèmes mais également les utilisateurs de l'AD.
Si cette variable est à non, il sera toujours possible d'avoir les informations de l'utilisateur (getent passwd nom_utilisateur) mais ce dernier n’apparaîtra plus dans la liste complète des utilisateurs (getent passwd). Techniquement, il sera toujours possible de placer des ACL sur des fichiers ou d'un appliquer un quota disque pour un utilisateur spécifique.
Cette liste est appelée à différents moments de la vie du système. Lister tous les utilisateurs de l'AD étant potentiellement très long, cela implique des ralentissements conséquents sur le système.
Remarque
Cette variable est actuellement à oui sur les modules AmonEcole et Scribe ainsi que sur le module Seth en mode membre.
Elle est, par contre à non sur un module Seth configuré en tant que contrôleur de domaine.
Archivage et sauvegarde des données
Un problème de corruption de la base Active Directory peut nécessiter de restaurer une sauvegarde sur le contrôleur de domaine principal et de relancer la synchronisation de tous les autres contrôleurs.
Attention
Il est primordial de disposer d'une archive ou d'une sauvegarde récente des données du serveur Active Directory.
Archivage local
La variable Archiver les données du DC permet d'activer l'exécution quotidienne d'un script d'archivage local et de choisir la destination de stockage de l'archive.
Les données du serveur Active Directory sont ainsi régulièrement sauvegardée (par défaut 1 fois par jour) dans le répertoire spécifié dans Destination de la sauvegarde.
Remarque
Le script utilisé pour l'archivage des données est inspiré d'un script mis à disposition par les développeurs du logiciel Samba : https://wiki.samba.org/index.php/Back_up_and_Restoring_a_Samba_AD_DC.
En mode expert, il est possible de spécifier la périodicité et la durée de rétention[60] de la sauvegarde locale.
Sauvegarde locale ou distante
Il est possible de mettre œuvre un système de sauvegarde complet en installant le logiciel Bareos[42] sur le serveur.
La mise en place de cet outil s'effectue manuellement à l'aide de la commande suivante :
# apt-eole install eole-bareos
Après installation des paquets, la configuration du service de sauvegarde s'effectue dans l'interface de configuration du module à plusieurs endroits.
L'archivage du DC soit activé dans l'onglet : Archiver les données du DC doit être à oui.
Par défaut la sauvegarde Bareos est activée (Activer la sauvegarde du serveur à oui dans l'onglet Services) et la tâche de sauvegarde des données du serveur Active Directory est prise en compte (Sauvegarder les archives avec Bareos à oui dans l'onglet Active Directory).
Dans cette configuration, les éléments suivants sont directement sauvegardés par Bareos avec le support des ACL :
L'export des bases TDB est quant à lui géré par eole-schedule[43] avant l'exécution des sauvegardes.
Lorsque la sauvegarde des archives avec Bareos est activée la durée de rétention configurable en mode expert ne concerne que le script d'export des bases TDB de Samba.
La configuration à proprement parler des sauvegardes (distante, locale, durée de rétention, taux de compression…) s'effectue dans les onglets Directeur bareos et Stockage bareos.
Onglet Clamav : Configuration de l'anti-virus
EOLE propose un service anti-virus réalisé à partir du logiciel libre ClamAV.
Activation de l'anti-virus
L'onglet Clamav n'est accessible que si le service est activé dans l'onglet Services. Pour ce faire, passer la variable Activer l'anti-virus ClamAV à oui.
Sur le module AmonEcole, il est possible d'activer l'anti-virus sur le proxy, sur le serveur FTP et sur la messagerie.
Truc & astuce
Si aucun service n'utilise l'anti-virus, il est utile de le désactiver dans l'onglet Services. Il faut passer la variable Activer l'anti-virus ClamAV à non. L'onglet Clamav n'est alors plus visible.
Activation de l'anti-virus sur le proxy
Pour activer l'anti-virus en temps réel sur les fichiers filtrés par le proxy Internet, il faut passer la variable Activer l'anti-virus sur le proxy à oui dans l'onglet Clamav.
L'anti-virus sur le proxy permet d'analyser le trafic HTTP mais ne saurait en aucun cas remplacer la présence d'un anti-virus sur les postes clients.
Activation de l'anti-virus sur FTP
Pour désactiver l'anti-virus en temps réel sur les fichiers mis en ligne par FTP il faut passer la variable Activer l'anti-virus temps réel sur FTP à non dans l'onglet Clamav.
Activation de l'anti-virus sur la messagerie
Pour activer l'anti-virus sur la messagerie il faut passer la variable Activer l'antivirus sur la messagerie à oui dans l'onglet Clamav.
Forcer l'activation du service clamd
Si Activer l'anti-virus ClamAV est à oui dans l'onglet Service mais qu'aucun service EOLE ne l'utilise alors seul le service de mise à jour de la base de signatures (freshclam) sera actif sur le serveur.
Il est possible de forcer l'activation du service anti-virus (clamd) en passant la variable du mode expert Forcer l'activation du démon clam sur le serveur à oui dans l'onglet Clamav.
Configuration avancée du service anti-virus
En mode expert, l'onglet Clamav comporte de nombreuses variables qui permettent d'affiner la configuration du service anti-virus ClamAV.
Taille maximum pour un fichier à scanner (en Mo);Quantité de données maximum à scanner pour une archive (en Mo);Profondeur maximale pour le scan des archives;Profondeur maximale pour le scan des répertoires;Nombre maximum de fichiers à scanner dans une archive;Arrêter le démon en cas de surcharge mémoire;Détection des applications indésirables;Scan du contenu des fichiers PDF;Scan des fichiers courriels;Détection des fichiers exécutables corrompus(déprécié par clamav).
Configuration avancée du service de mise à jour de l'anti-virus
En mode expert, l'onglet Clamav comporte des variables qui permettent d'affiner la configuration de Freshclam, le service de mise à jour de la base de signatures.
Nom de domaine du serveur DNS de mise à jourpermet de spécifier un miroir interne pour les signatures ;Forcer un serveur de mise à jour freshclampermet d'ajouter un ou plusieurs miroirs pour les signatures ;Code IANA pour la mise à jour de la base de signaturepermet de sélectionner le miroir le plus proche en se saisissant un code pays dans le cas où on n'ajoute pas manuellement de miroirs ;Nombre de tentatives de mise à jour par miroirpermet de réduire le nombre de tentatives de mise à jour, en effet des fichiers sont récupérés systématiquement à chaque tentative ;Nombre de mises à jour quotidiennespermet de réduire le nombre de mises à jour quotidiennes.
Passer Forcer un serveur de mise à jour freshclam à oui donne accès à un groupe de deux variables supplémentaires permettant de renseigner le nom de domaine d’un miroir et son type.
Lorsqu’un miroir est ajouté manuellement, il est nécessaire d’indiquer quel est son type : DatabaseMirror ou PrivateMirror. La distinction porte sur le protocole utilisé pour établir la connexion avec le miroir. DatabaseMirror implique l’utilisation du protocole https alors que PrivateMirror implique l’utilisation du protocole http.
Attention
L’établissement d’une connexion avec le protocole https, impliqué par le type DatabaseMirror, suppose que le certificat identifiant le miroir soit valide.
Contribuer
La base de données de virus est mise à jour avec l'aide de la communauté.
Il est possible de faire des signalements :
signaler de nouveaux virus qui ne sont pas détectés par ClamAV ;
signaler des fichiers propres qui ne sont pas correctement détectés par ClamAV (faux-positif).
Pour cela il faut utiliser le formulaire suivant (en) : http://www.clamav.net/contact#reports
L'équipe de ClamAV examinera votre demande et mettra éventuellement à jour la base de données.
En raison d'un nombre élevé de déposants, il ne faut pas soumettre plus de deux fichiers par jour.
Onglet Annuaire
Sur les modules Horus, Scribe et AmonEcole l'annuaire OpenLDAP est local.
Lorsque l'annuaire est configuré comme étant local, l'onglet propose 4 paramètres :
Activer le support du TLS: permet de désactiver le support du TLS :Port du serveur LDAP: permet de changer le port d'écoute du serveur LDAP ;Fichier de mot de passe de l'utilisateur de lecture: permet de changer le fichier de mot de passe de l'utilisateur de lecture :Définir le mot de passe admin de LDAP dans un fichier: permet de stocker et de réutiliser par ailleurs le mot de passe administrateur de l'annuaire dans le fichier/root/.writer.
Les variables du mode expert pour l'annuaire sont identiques qu'il soit distant ou local, elles permettent de modifier finement le comportement de l'annuaire.
La variable Fichier de mot de passe de l'utilisateur admin permet de modifier le fichier par défaut contenant le mot de passe de l'administrateur de l'annuaire.
L'attribut de recherche par défaut peut également être modifié.
Les filtres, les DN racine et les attributs LDAP renvoyés par l'annuaire peuvent être personnalisés.
Attention
Le paramétrage d'un serveur LDAP local s'effectue dans l'onglet Openldap.
Onglet Samba
L'onglet Samba permet d'activer certaines options liées aux comptes des utilisateurs.
Écran
- 1
quota_hard_limit_percentValeur permettant le calcul de la limite dure du quota associé aux nouveaux utilisateurs.
- 2
ead_import_write_optionsActiver ou non la création automatique des groupes "options" lors de l'importation des comptes.
- 3
ead_import_write_priveActiver ou non la création du dossier privé qui est accessible uniquement par l'élève.
Configuration
Quotas
Avec samba il est possible de définir des limites associées aux quotas. Une limite dite "douce" et une limite dite "dure" qui est calculée via un pourcentage sur la limite "douce", celui-ci ne peut donc être inférieur à 100, et est par défaut à 200%.
Comptes
Un utilisateur type "élève" est associé à une classe et à des options.
Il est possible :
- de désactiver la création automatique des groupes "options" lors de l'importation des comptes ;
- de désactiver la création du dossier privé qui est accessible uniquement par l'élève.
Devoirs
Il est possible de modifier l'identification des élèves présentée aux enseignants au niveau du nommage des devoirs élèves ramassés.
Afin de faciliter les interactions, la possibilité d'inverser le prénom et le nom dans le login à été implémenté.
Attention
L'inversion prénom/nom ne peut être fonctionnelle que dans le cas où les login sont générés avec un "."
Soit au format : prenom.nom, p.nnn ou prenom.n
Concrètement, sur les postes clients cela se traduit uniquement par un changement du nom des répertoires des élèves dans le partage "classe" et/ou le nom des fichiers de "devoir".
Onglet Dhcp : Configuration du serveur DHCP
Sur les modules Seth et Scribe, les adresses servies doivent généralement être sur le réseau local (interface 0).
Sur le module AmonEcole, les adresses servies sont celles du réseau interne (interface 1).
Si le serveur est installé en DMZ, on pourra renseigner des adresses d'un autre réseau mais dans ce cas, il faudra activer le relayage du DHCP[20] sur le pare-feu.
Définition des sous-réseaux
Il faut définir une ou plusieurs plages (en anglais range) d'adresses attribuables par le serveur à l'aide du bouton + Adresse réseau de la plage DHCP.
La plage DHCP doit contenir au moins autant d'adresses que le nombre de stations susceptibles d'être connectées simultanément sur le réseau.
Les champs Adresse réseau de la plage DHCP et Masque de sous-réseau de la plage DHCP permettent de définir le réseau sur lequel les adresses doivent être servies.
Le champ Nom de la plage DHCP, disponible uniquement à partir de la version 2.6.2, permet d'identifier plus facilement la plage DHCP, notamment dans la nouvelle interface d'administration (EAD3). Pour administrer efficacement le DHCP dans l'interface de configuration, il convient de renseigner des noms de plages pertinents. Dans le cas d'une migration depuis une version antérieure d'EOLE, cette variable est arbitrairement initialisée avec les valeurs "plage0", "plage1"…
Les champs IP basse de la plage DHCP et IP haute de la plage DHCP doivent être comprise dans le réseau déclaré ci-dessus.
Le champ IP basse de la plage DHCP correspond, dans un réseau de classe C, à l'adresse IP dont le dernier octet a la valeur la plus petite.
Le champ IP haute de la plage DHCP correspond, dans un réseau de classe C, à l'adresse IP dont le dernier octet a la valeur la plus grande.
Le nombre d'adresses IP servies est déterminé par la différence entre la valeur la plus grande et la valeur la plus petite.
Les champs Nom de domaine à renvoyer aux clients DHCP, Adresse IP du routeur à renvoyer aux clients DHCP et Adresse IP du DNS à renvoyer aux clients DHCP permettent de spécifier des valeurs différentes pour chaque plage déclarée.
Pour la configuration de l'Adresse IP du routeur à renvoyer aux clients DHCP :
dans le mode une carte, l'adresse sera l'adresse IP de la passerelle saisie dans l'onglet
Interface-0;dans le cas du mode deux cartes, l'adresse IP du routeur sera l'adresse IP de l'
Interface-1(eth1).
L'Adresse IP du DNS à renvoyer aux clients DHCP
peut être l'adresse IP du DNS de votre FAI[21] pour une utilisation sans le module Amon. Il est également possible d'utiliser des serveurs DNS disponibles sur Internet.
Si vous disposez d'un module Amon ou d'un module AmonEcole, il est conseillé d'utiliser le module comme relais DNS[3], L'adresse à préciser dans le cas du mode deux cartes sera l'adresse IP du routeur et donc l'adresse IP de l'Interface-1 (eth1).
Truc & astuce
Sur le module AmonEcole, l'adresse IP du DNS à renvoyer correspond à celle renseignée dans Adresse IP pour addc (adresse_ip_domaine_link)de l'onglet Interface-1 de l'interface de configuration du module.
Paramètres globaux et surcharge
En mode expert, les champs Nom de domaine à renvoyer aux clients DHCP, Adresse IP du routeur à renvoyer aux clients DHCP, Adresse IP du DNS à renvoyer aux clients DHCP et Adresse IP du DNS secondaire à renvoyer aux clients DHCP permettent de spécifier des valeurs pour les paramètres globaux. Ils peuvent être surchargés pour un sous-réseau spécifique.
Un certain nombre de paramètres peuvent être spécifiés ou modifiés dans les paramètres globaux et/ou pour les sous-réseaux.
Il est possible de spécifier les adresses IP de Wins primaire et secondaire à renvoyer aux clients.
L'adresse d'un serveur de temps à renvoyer aux clients peut être spécifié : Adresse IP du serveur NTP à renvoyer aux clients.
Passer Interdire cette zone aux hôtes inconnus à oui permet d'activer l'option deny unknown-clients qui interdit l'attribution d'une adresse IP à une station dont l'adresse MAC est inconnue du serveur (gestion des adresses MAC connues au travers de l'EAD).
Il est possible de modifier les durées du bail DHCP : Temps du bail par défaut (sec) et Temps maximum du bail (sec).
Mode PXE
Il est possible de configurer le mode PXE[104] pour des clients en mode legacy et/ou UEFI[105].
Pour cela il faut au préalable avoir activé l'option Activer l'utilisation d'un serveur PXE/TFTP dans l'onglet Services.
Deux variables permettent de spécifier indépendamment le fichier de boot pour les deux modes. Par défaut, les valeurs sont recopiées des variables de l’onglet Tftp :
Chemin vers le fichier de boot PXE initial(ongletTftp) est recopié dansFichier pour le boot PXE;Chemin vers le fichier de boot PXE UEFI initial(ongletTftp) est recopié dansFichier pour le boot PXE UEFI.
Pour chaque définition de sous-réseaux, il est possible de surcharger ces valeurs par défaut. La fonctionnalité de distribution du fichier de boot est dépendante de la présence d’une valeur pour chaque sous-réseau. Un champ vide dans une définition de sous-réseau désactive la fonctionnalité de distribution pour ce sous-réseau indépendamment des valeurs par défaut dans l’onglet Tftp.
Domaine WPAD
Attention
Même s'il est possible d'utiliser n'importe quel domaine, il est conseillé d'utiliser la même valeur que celle utilisée pour le nom de domaine local.
Remarque
Pour les postes de travail Windows c'est la valeur du champ Nom de domaine du serveur WPAD qui sera utilisée pour accéder au fichier WPAD tandis que pour des postes de travail GNU/Linux c'est le nom de domaine local qui sera utilisé pour accéder au fichier WPAD.
Configurer la continuité de service
À partir de la version 2.6.2, il est possible de mettre en place de la continuité de service pour le DHCP.
Elle permet à deux serveurs DHCP d'opérer sur les mêmes sous-réseaux et mêmes pools d'adresses IP.
Il faut donc un serveur DHCP primaire et un serveur DHCP secondaire.
Truc & astuce
Les ports d'écoute et de contact du serveur primaire doivent être inversés pour le serveur secondaire. Il est également possible d'utiliser le port 647 partout, c'est à dire en écoute et en contact aussi bien sur le serveur primaire que sur le serveur secondaire.
Paramétrage du serveur primaire
Nom de la grappe: le nom de la grappe devra être le même sur le serveur primaire (local) et sur le serveur secondaire (pair) ;Rang du serveur dans la grappe: choisirprimarypour le serveur primaire ;Adresse IP du serveur DHCP local, en écoute du serveur pair: saisir l'adresse IP de l'interface sur laquelle écoute le service DHCP local (IP de l'Interface-0 dans la plupart des cas) ;Port de communication du serveur DHCP local, en écoute du serveur pair: le port par défaut pour un serveur primaire est647;Adresse IP du serveur pair: saisir l'adresse IP du serveur secondaire (pair) ;Port de communication du serveur pair: le port par défaut est847.
En mode expert, un certain nombre de variables permettent d'ajuster finement la configuration du failover et de la répartition de charge.
Paramétrage du serveur secondaire
Pour un serveur secondaire, les variables à paramétrer sont :
Nom de la grappe: le nom de la grappe doit être le même que pour le serveur primaire (local) ;Rang du serveur dans la grappe: choisirsecondarypour le serveur secondaire ;Adresse IP du serveur DHCP local, en écoute du serveur pair: saisir l'adresse IP de l'interface sur laquelle écoute le service DHCP local (IP de l'Interface-0 dans la plupart des cas) ;Port de communication du serveur DHCP local, en écoute du serveur pair: le port par défaut pour un serveur secondaire est847;Adresse IP du serveur pair: saisir l'adresse IP du serveur secondaire (pair) ;Port de communication du serveur pair: le port par défaut est647.
En mode expert, un certain nombre de variables permettent d'ajuster finement la configuration du failover.
Support de l'API OMAPI
Personnaliser la configuration DHCP
À partir d'EOLE 2.8.1, il est possible d'ajouter des fichiers d'options qui seront pris en compte par le DHCP et dont le contenu sera distribué aux clients.
Dans global
Pour inclure dans la section globale, il faut créer le répertoire :
/etc/dhcp/dhcpd.d/global
Puis mettre dedans tous les fichiers qui seront inclus et distribués à tous les clients.
Dans les subnet
Pour inclure dans tous les subnets il faut créer le répertoire :
/etc/dhcp/dhcpd.d/subnets/global/
Pour inclure dans un subnet précis il faut créer le répertoire :
/etc/dhcp/dhcpd.d/subnets/{adresse_network_dhcp}_{adresse_netmask_dhcp}/
Puis mettre dedans tous les fichiers qui seront inclus et distribués aux clients dans le subnet.
Dans les pool
Pour inclure dans tous les pools il faut créer le répertoire :
/etc/dhcp/dhcpd.d/pools/global/
Pour inclure dans un pool précis il faut créer le répertoire :
/etc/dhcp/dhcpd.d/pools/name_{nom_plage_dhcp}/
Puis mettre dedans tous les fichiers qui seront inclus et distribués aux clients dans le pool.
ExempleExemple : ajout via l'option d'un serveur ntp différent
Créer un fichier comme suit :
/etc/dhcp/dhcpd.d/pools/global/ntp
L'ouvrir et ajouter l'option correspondante :
option ntp-servers 10.1.3.5;
Enregistrer le contenu.
Désormais cette option sera envoyée à tous nouveaux clients réalisant une demande de bail au serveur DHCP.
Truc & astuceAstuce
adresse_network_dhcp , adresse_netmask_dhcp et nom_plage_dhcp sont des variables EOLE, il est donc possible d'afficher leur contenu avec la commande CreoleGet.
Onglet Tftp : Configuration d'un serveur PXE/TFTP
Il est possible d'activer un service d'amorçage PXE[104] sur le module. Une station de travail pourra alors démarrer depuis le réseau en récupérant une image de système d'exploitation qui se trouve sur un serveur.
La configuration du serveur PXE/TFTP se trouve dans l'onglet Tftp. Celui-ci est disponible uniquement en mode expert après activation du service dans l'onglet Services.
L'adresse IP du serveur PXE/TFTP proposée par défaut est celle de l'interface 0 précédemment configurée.
Si le service DHCP local est activé et que l'adresse d'un serveur TFTP distant est saisie, le service DHCP renverra les stations qui le demandent vers ce serveur (directive : next-server).
Si le serveur TFTP est local, la variable Répertoire sur le serveur PXE/TFTP définit le répertoire dans lequel se trouve le ou les fichiers de boot PXE.
Si le service DHCP local est activé :
- la variable
Chemin vers le fichier de boot PXE initialdéfinit le nom du fichier de boot PXE initial renvoyé par le service DHCP (directive :filename) ; - la variable
Chemin vers le fichier de boot PXE UEFI initialdéfinit le nom du fichier de boot PXE initial pour les client UEFI[105] qui sera renvoyé par le service DHCP (directive :filename).
Cette fonctionnalité permet notamment la mise en place d'un logiciel de clonage permettant de restaurer des images sauvegardées de poste clients.
ExempleFOG
Installation de FOG[108] sur Eolebase 2.8 : https://pcll.ac-dijon.fr/eole/installation-de-fog-sur-eolebase-2-8/
ExempleOSCAR
OSCAR[109], outil de clonage édité par l'ex CRDP de Lyon :
Un procédure pour la mise en place d'OSCAR est disponible sur la forge EOLE à l'adresse :
Une documentation sur l'utilisation d'OSCAR est disponible à l'adresse :
https://dane.ac-lyon.fr/spip/IMG/scenari/FCDeploiementOscar/co/A150_-_Presentation_OSCAR.html
Onglet Onduleur
Sur chaque module EOLE, il est possible de configurer votre onduleur.
Le logiciel utilisé pour la gestion des onduleurs est NUT[22]. Il permet d'installer plusieurs clients sur le même onduleur. Dans ce cas, une machine aura le contrôle de l'onduleur (le maître/master) et en cas de coupure, lorsque la charge de la batterie devient critique, le maître indiquera aux autres machines (les esclaves) de s'éteindre avant de s'éteindre lui-même.
Certains onduleurs sont assez puissants pour alimenter plusieurs machines.
http://www.networkupstools.org/
Le projet offre une liste de matériel compatible avec le produit mais cette liste est donnée pour la dernière version du produit :
Truc & astuce
Pour connaître la version de NUT qui est installée sur le module :
# apt-cache policy nut
ou encore :
# apt-show-versions nut
Si la version retournée est 2.7.1 on peut trouver des informations sur la prise en charge du matériel dans les notes de version à l'adresse suivante :
http://www.networkupstools.org/source/2.7/new-2.7.1.txt
Si le matériel n'est pas dans la liste, on peut vérifier que sa prise en charge soit faite par une version plus récente et donc non pris en charge par la version actuelle :
L'onglet Onduleur n'est accessible que si le service est activé dans l'onglet Services.
Si l'onduleur est branché directement sur le module il faut laisser la variable Configuration sur un serveur maître à oui, cliquer sur le bouton + Nom de l'onduleur et effectuer la configuration liée au serveur maître.
La configuration sur un serveur maître
Même si le nom de l'onduleur n'a aucune conséquence, il est obligatoire de remplir cette valeur dans le champ Nom pour l'onduleur.
Il faut également choisir le nom du pilote de l'onduleur dans la liste déroulante Pilote de communication de l'onduleur et éventuellement préciser le Port de communication si l'onduleur n'est pas USB.
Les champs Numéro de série de l'onduleur, Productid de l'onduleur et Upstype de l'onduleur sont facultatifs si il n'y a pas de serveur esclave. Il n'est nécessaire d'indiquer ce numéro de série que dans le cas où le serveur dispose de plusieurs onduleurs et de serveurs esclaves.
Remarque
Le nom de l'onduleur ne doit contenir que des chiffres ou des lettres en minuscules : [a-z][0-9] sans espaces, ni caractères spéciaux.
NUT SNMP
À partir d'EOLE 2.7.2, les onduleurs utilisant une connexion SNMP[46] (driver snmp-ups) sont gérés nativement et des variables supplémentaires apparaissent dans l'interface.
La configuration ci-dessous convient, par exemple, pour un onduleur NITRAM Cyberpower :
Si le driver snmp-ups est sélectionné, le paramétrage de la Fréquence d'interrogation de upsmon est également proposé mais en mode expert uniquement.
Configuration d'un second onduleur sur un serveur maître
Si le serveur dispose de plusieurs alimentations, il est possible de les connecter chacune d'elle à un onduleur différent.
Il faut cliquer sur le bouton + Nom de l'onduleur pour ajouter la prise en charge d'un onduleur supplémentaire dans l'onglet Onduleur de l'interface de configuration du module.
Si les onduleurs sont du même modèle et de la même marque, il faut ajouter de quoi permettre au pilote NUT de les différencier.
Cette différenciation se fait par l'ajout d'une caractéristique unique propre à l'onduleur. Ces caractéristiques dépendent du pilote utilisé, la page de man du pilote vous indiquera lesquelles sont disponibles.
Exemple pour le pilote Solis :
# man solis
Afin de récupérer la valeur il faut :
- ne connecter qu'un seul des onduleurs ;
- le paramétrer comme indiqué dans la section précédente ;
- exécuter la commande :
upsc <nomOnduleurDansGenConfig>@localhost|grep <nom_variable>; - débrancher l'onduleur ;
- brancher l'onduleur suivant ;
- redémarrer
nutavec la commande :# service nut restart; - exécuter à nouveau la commande pour récupérer la valeur de la variable.
Une fois les numéros de série connus, il faut les spécifier dans les champ Numéro de série de l'onduleur de chaque onduleur.
ExempleDeux onduleurs de même marque
Pour deux onduleurs de marque MGE, reliés à un module Scribe par câble USB, il est possible d'utiliser la valeur "serial", voici comment la récupérer :
# upsc <nomOnduleurDansGenConfig>@localhost | grep serial
driver.parameter.serial: AV4H4601W
ups.serial: AV4H4601W
ExempleDeux onduleurs différents
Un onduleur sur port série :
- Nom de l'onduleur :
eoleups; - Pilote de communication de l'onduleur :
apcsmart; - Port de communication de l'onduleur :
/dev/ttyS0.
Si l'onduleur est branché sur le port série (en général : /dev/ttyS0), les droits doivent être adaptés.
Cette adaptation est effectuée automatiquement lors de l'application de la configuration.
Onduleur sur port USB :
- Nom de l'onduleur :
eoleups; - Pilote de communication de l 'onduleur :
usbhid-ups; - Port de communication de l'onduleur :
auto.
La majorité des onduleurs USB sont détectés automatiquement.
Attention
Attention, seul le premier onduleur sera surveillé.
Autoriser des esclaves distants à se connecter
Pour déclarer un serveur esclave, il faut passer la variable Autoriser des esclaves distants à se connecter à oui puis ajouter un utilisateur sur le serveur maître afin d'autoriser l'esclave a se connecter avec cet utilisateur.
Idéalement, il est préférable de créer un utilisateur différent par serveur même s'il est possible d'utiliser un unique utilisateur pour plusieurs esclaves. Pour configurer plusieurs utilisateurs il faut cliquer sur le bouton + Utilisateur de surveillance de l'onduleur.
Pour chaque utilisateur, il faut saisir :
un
Utilisateur de surveillance de l'onduleur;
un
Mot de passe de surveillance de l'onduleurassocié à l'utilisateur précédemment créé ;
l'
Adresse IP du réseau de l'esclave(cette valeur peut être une adresse réseau plutôt qu'une adresse IP) ;
le
Masque de l'IP du réseau de l'esclave(comprendre le masque du sous réseau de l'adresse IP de l'esclave)
Remarque
Le nom de l'onduleur ne doit contenir que des chiffres ou des lettres en minuscules : [a-z][0-9] sans espaces, ni caractères spéciaux.
Attention
Chaque utilisateur doit avoir un nom différent.
Les noms root et localmonitor sont réservés.
Complément
Pour plus d'informations, vous pouvez consulter la page de manuel :
man ups.conf
ou consulter la page web suivante : http://manpages.ubuntu.com/manpages/focal/en/man5/ups.conf.5.html
Configurer un serveur esclave
Une fois qu'un serveur maître est configuré et fonctionnel, il est possible de configurer le ou les serveurs esclaves.
Pour configurer le module en tant qu'esclave, il faut activer le service dans l'onglet Services puis, dans l'onglet Onduleur, passer la variable Configuration sur un serveur maître à non.
Il faut ensuite saisir les paramètres de connexion à l'hôte distant :
le
Nom de l'onduleur distant(valeur renseignée sur le serveur maître) ;
l'
Hôte gérant l'onduleur(adresse IP ou nom d'hôte du serveur maître) ;
l'
Utilisateur de l'hôte distant(nom d'utilisateur de surveillance créé sur le serveur maître ) ;
le
Mot de passe de l'hôte distant(mot de passe de l'utilisateur de surveillance créé sur le serveur maître).
Truc & astuce
À partir d'EOLE 2.7.2, il est possible de déclarer plusieurs onduleurs distants.
Exemple de configuration
Exemple
Sur le serveur maître :
- Nom de l'onduleur :
eoleups; - Pilote de communication de l'onduleur :
usbhid-ups; - Port de communication de l'onduleur :
auto; - Utilisateur de surveillance de l'onduleur :
scribe; - Mot de passe de surveillance de l'onduleur :
99JJUE2EZOAI2IZI10IIZ93I187UZ8; - Adresse IP du réseau de l'esclave :
192.168.30.20; - Masque de l'IP du réseau de l'esclave :
255.255.255.255.
Exemple
Sur le serveur esclave :
- Nom de l'onduleur distant :
eoleups; - Hôte gérant l'onduleur :
192.168.30.10; - Utilisateur de l'hôte distant :
scribe; - Mot de passe de l'hôte distant :
99JJUE2EZOAI2IZI10IIZ93I187UZ8.
Onglet Ead3
L'onglet Ead3 est uniquement disponible après avoir passé Activer l'interface d'administration du module (EAD3) à oui dans l'onglet Services.
Il permet de personnaliser la configuration Saltstack[110] de l'EAD3.
Le port d'écoute par défaut de l'API Saltstack est 8880.
Le choix du chemin de téléversement des fichiers EAD3 est par défaut /var/lib/eole/ead3files.
Onglet Rvp : Mettre en place le réseau virtuel privé
Le réseau virtuel privé[47] (RVP) peut être activé au moment de la configuration et de l'instanciation d'un module Amon ou sur un module Amon déjà en exploitation.
Mise en place du RVP
L'onglet Rvp apparaît après activation du service dans l'onglet Services.
Configuration des tunnels
Attention
Le mode VPN database n'est plus supporté et n'est plus disponible à partir de la version 2.5.1 du module Amon. La configuration des tunnels s'effectue d'office en mode fichier plat.
Paramètres agent Zéphir RVP et diagnose
Le champ Adresses IP à tester dans test-rvp permet de saisir une ou plusieurs adresses IP qui seront utilisées par le diagnose et par l'agent Zéphir pour tester des adresses IP à l'autre extrémité des tunnels.
AGRIATES
Si le serveur est membre d'AGRIATES[48] il faut passer la variable Serveur membre du réseau AGRIATES à oui.
Adresse du DNS permettant de résoudre les in.ac-acad.frpermet de spécifier l'adresse IP du serveur DNS permettant de résoudre les noms de zone AGRIATES (in.ac-académie.fr) ;Nom DNS de la zone résolue par le DNS AGRIATES: permet de spécifier d'autres noms de zones résolues par le DNS AGRIATES.
Paramètres propres au mode expert
Le mode Expert permet de personnaliser le fonctionnement de strongSwan[111].
Forcer l'encapsulation (Détection NAT), si la valeur est à oui, cela force la socket UDP/4500 pour l'établissement des connexions. Si la valeur est à non, le socket est fixé à UDP/500 sauf s'il y a détection de NAT (UDP/4500).
Autoriser le changement d'adresse IP d'une extrémité de connexion (MOBIKE IKEv2 extension - RFC 4555) permet à une extrémité de changer d'adresse IP pour une connexion donnée. Dans ce cas, la connexion se fera toujours sur UDP/4500.
Paramètres strongSwan
Nombre d'essais de retransmission avant Dead Peer Detection indique à strongSwan le nombre d'essais de reconnexion avant l'abandon.
Timeout pour le process stroke permet de fixer le nombre de millisecondes avant l'arrêt forcé de processus qui se seraient figés.
Remarque
La variable Configuration des tunnels en mode database n'est plus disponible dans la version 2.5 d'EOLE, ce mode a été supprimé au profit du mode fichier plat.
Gestion des Routes VPN
Gestion des routes par strongSwan permet si la valeur est passée à non de faire gérer la mise en place des routes concernant les tunnels par un script.
Exemple, dans notre cas et sur le module Amon uniquement :
/etc/ipsec.d/ipsec_updown
Forcer l'adresse IP source de l'interface permet de forcer l'adresse IP que le serveur utilisera pour entrer dans les tunnels. Cette option est utilisée sur les serveurs Amon afin d'éviter qu'ils utilisent aléatoirement l'adresse IP de l'une de ses interfaces lorsqu'ils passent dans un tunnel.
Avec la valeur auto, l’adresse IP source est définie automatiquement en fonction du réseau source.
Gestion des threads
Nombre de threads disponibles pour strongSwan permet d'allouer un nombre de fils d'exécution maximum pour ses différentes tâches. Une valeur trop petite peut entraîner des mises en file d'attente importantes.
Nombre de threads à réserver pour les jobs HIGH priority réserve un nombre de fils d'exécution minimum pour les tâches HIGH priority (ipsec stroke et DPD). La valeur 1 ou 2 maximum est idéale.
Nombre de threads à réserver pour les jobs MEDIUM priority réserve un nombre de fils d'exécution minimum pour les tâches MEDIUM priority (Initialisation de connexion entre autres).
Gestion de la fragmentation
Taille maximum d'un fragment IKE : valeur utilisée par strongSwan si la configuration IPSec est générée dans ARV avec l'activation de la fragmentation IKE ;
MSS à positionner sur les routes (0 pour désactiver) : valeur MSS[112] à positionner sur les routes (indépendant de la fragmentation IKE) ;
MTU à positionner sur les routes (0 pour désactiver) : valeur MTU[91] à positionner sur les routes (indépendant de la fragmentation IKE).
Paramètres IPsec
Contrôle du status des certificats dans la CRL : active ou non la vérification de la validité d'un certificat dans la liste de révocation (CRL[113]) ;
Forcer l'encapsulation (Détection NAT) :
- UDP/500 si valeur est à
nonet qu'il n'y a pas de NAT détecté ; - UDP/4500 si valeur à
nonet qu'il y a du NAT détecté ou si valeur àoui.
Autoriser le changement d'adresse IP d'une extrémité de connexion :
- UDP/500 si valeur est à
non; - UDP/4500 si valeur est à
oui.
Application de la configuration et gestion du RVP
Activation du RVP au moment de l'instanciation du serveur Amon
Au lancement de l'instanciation, la question suivante vous est posée :
Voulez-vous configurer le Réseau Virtuel Privé maintenant ? [oui/non]
[non] :
Vous devez répondre oui à cette question.
Deux choix sont alors proposés :
1.Manuel permet de prendre en compte la configuration RVP présente sur une clé USB ;
2.Zéphir active la configuration RVP présente sur le serveur Zéphir. Cela suppose que le serveur est déjà enregistré sur Zéphir. Il sera demandé un compte Zéphir et son code secret ainsi que l'identifiant Zéphir du serveur Sphynx auquel associer le module Amon.
Dans les deux cas, le code secret de la clé privée est demandée. Si le code secret est correct le RVP est configuré pour cette machine et l'instanciation peut se poursuivre...
Activation du RVP sur des modules Amon déjà en exploitation
Pour activer un RVP sur un module Amon déjà instancié, il faut lancer en tant qu'utilisateur root la commande active_rvp init.
Suppression du RVP
Pour supprimer un RVP, il faut lancer en tant qu'utilisateur root la commande active_rvp delete.
Onglet Applications web : Configuration des applications web
Les onglets Applications web et Apache ne sont disponibles qu'après activation du service, Activer le serveur web Apache à oui, dans l'onglet Services.
L'onglet Applications web permet un réglage minimum pour le fonctionnement des applications web. Il permet aussi d'activer/désactiver toutes les applications web EOLE installées sur le module.
Nom de domaine des applications web
Le choix du Nom de domaine des applications web est essentiel.
Pour un bon fonctionnement de toutes les applications, il est impératif d'utiliser un nom de domaine.
Dans la mesure du possible, il faut que celui-ci soit résolvable sur Internet. Si ce n'est pas le cas, il est possible d'utiliser un nom de domaine local diffusé par le serveur DNS[3] de l'établissement.
Ce paramètre ne doit pas être précédé du nom du protocole.
Attention
Application web par défaut
L'application web par défaut sera celle renseignée dans la variable : Application web par défaut (redirection).
Exemple
Si la variable Application web par défaut vaut /webmail, alors l'adresse http://<adresse_serveur>/ pointera vers http://<adresse_serveur>/webmail/
Serveur web et proxy inverse
Lorsque le serveur web est derrière un proxy inverse, c'est l'adresse IP du proxy inverse et non celle de l'utilisateur qui est enregistrée dans les fichiers de journalisation. Pour éviter cela, il est possible de passer la variable Le serveur web est derrière un reverse proxy à oui et de déclarer son adresse (généralement l'adresse IP du module Amon sur la zone) dans Adresse IP du serveur reverse proxy.
Remarque
Sur le module AmonEcole, si le proxy inverse est activé, les variables sont calculées et masquées : Le serveur web est derrière un reverse proxy est à oui et l'Adresse IP du serveur reverse proxy est celle du bridge interne : 192.0.2.1.
Attention
La déclaration du proxy inverse ajoute une entête qui contient une adresse IP qui peut potentiellement être falsifiée depuis la machine source.
En cas d'utilisation d'un proxy, la récupération de l'adresse IP des stations du réseau local n'est pas garantie.
Complément
Sur EOLE 2.6.0 et inférieur, cette fonctionnalité était implémentée via le module Apache additionnel RPAF : https://github.com/gnif/mod_rpaf.
Sur EOLE 2.6.1 et supérieur, cette fonctionnalité est implémentée via le module Apache natif RemoteIP : https://httpd.apache.org/docs/current/fr/mod/mod_remoteip.html
Activer Bareos WebUI (gestion de la sauvegarde)
Bareos WebUI est une application web permettant de surveiller et gérer les sauvegardes Bareos.
Activer Adminer (administration des bases de données)
Adminer permet de gérer les bases de données MySQL hébergées par le module.
Elle vient en remplacement de l'application phpMyAdmin.
Pour activer/désactiver l'application web Adminer il faut passer la variable : Activer Adminer (administration de bases de données) à oui.
Activer nextcloud (gestionnaire de fichiers)
Cette variable permet d'activer/désactiver l'application web Nextcloud sur le module.
Nextcloud est une application web qui permet à l'utilisateur de gérer ses fichiers au travers d'un navigateur.
Une seconde variable permet de personnaliser la taille maximum autorisée pour les fichiers téléversés via l'application.
Truc & astuce
Si un proxy est déclaré dans l'onglet Général, Nextcloud l'utilisera pour accéder à des ressources externes.
La variable du mode expert : Domaines exclus du proxy permet de déclarer des exceptions.
Activer EOE
Cette variable permet d'activer/désactiver l'application web EOE sur le module.
EOE propose une interface simple contenant un ensemble d'outils à destination des élèves.
Activer EOP
Cette variable permet d'activer/désactiver l'application web EOP sur le module.
EOP propose une interface simple contenant un ensemble d'outils à destination des enseignants.
Par défaut, tous les professeurs principaux peuvent accéder à la section Gestion d'EOP.
À partir d'EOLE 2.8.1, la variable Permettre aux enseignants de gérer les élèves et mots de passes permet de désactiver l'accès à cette section à tous les professeurs.
Par défaut, seuls les professeurs principaux peuvent modifier le mot de passe de leurs élèves.
En mode expert, en passant la variable Permettre aux enseignants de changer le mot de passe de tous les élèves à oui, chaque professeur pourra changer le mot de passe de n'importe quel élève dans l'application EOP.
La variable Permettre aux enseignants admin de créer des comptes temporaires permet aux professeurs admin de créer des comptes avec une date d'expiration.
Activer Roundcube (webmail)
Cette variable permet d'activer/désactiver l'application web Rouncube sur le module.
Roundcube est une application web qui permet à l'utilisateur de gérer ses courriers électroniques au travers d'un navigateur.
Une seconde variable permet de définir le thème utilisé pour cette application.
Activer Thèmes
Complément
Toutes les applications web pré-packagées installées manuellement apparaissent dans cet onglet pour éventuellement être désactivées.
Mode expert
Certificats
En mode expert il est possible d'activer la vérification de l'autorité de certification pour les applications web cassifiées et de modifier le chemin des certificats utilisés par le serveur web Apache.
Onglet Apache : Configuration avancée du serveur web
Les onglets Applications web et Apache ne sont disponibles qu'après activation du service, Activer le serveur web Apache à oui, dans l'onglet Services.
L'onglet expert Apache permet de déclarer des applications web supplémentaires et d'affiner la configuration du serveur web.
Applications supplémentaires
Pour déclarer de nouvelles applications web, il faut tout d'abord passer la variable Déclarer des applications web supplémentaires à oui.
Il est ensuite possible d'ajouter des déclarations en cliquant sur le bouton + Chemin complet l'application (exemple : /var/www/html/appli), puis remplir les 2 paramètres :
Chemin complet l'application (exemple : /var/www/html/appli);Alias de l'application (exemple : /appli).
La variable Fichier à rechercher lorsqu'un client envoie une requête pour l'index d'un répertoire permet de définir le fichier ressource à rechercher lorsqu'un client envoie une requête pour l'index d'un répertoire, en ajoutant un '/' à la fin du nom de ce dernier (directive : DirectoryIndex).
Exemple
Chemin complet l'application (exemple : /var/www/html/appli): /var/www/html/egroupwareAlias de l'application (exemple : /appli): /egw
Après instanciation ou reconfiguration du module, le logiciel doit répondre à l'adresse : http://<adresse_serveur>/egw
Remarque
La déclaration a pour effet la création d'un fichier de configuration Apache dans /etc/apache2/sites-enabled/. Elle n'installe pas et ne suffit en aucun cas à faire fonctionner une nouvelle application web.
Une section de la documentation décrit le processus complet d'ajout d'applications web.
Configuration Apache
Les variables permettent de modifier et de fixer une sélection de paramètres disponibles pour la configuration Apache MPM (module multi-processus) prefork dans différents fichiers de configuration : /etc/apache2/.
Permettre de lister les répertoires et leur contenu: impacte le fichier/etc/apache2/sites-available/defaulten ajoutant la directiveOptions -Indexes.Temps en secondes pendant lequel le serveur va attendre des entrées/sorties avant de considérer qu'une requête a échoué.Autoriser les connexions persistantes: Passer ce paramètre àOffpermet d'empêcher tout client de consommer trop de ressources du serveur.Nombre de processus enfants du serveur créés au démarrage: Cette directive permet de définir le nombre de processus enfants du serveur créés au démarrage.Nombre minimum de processus serveurs enfants inactifs: Cette directive permet de définir le nombre minimum désiré de processus serveurs enfants inactifs. Un processus inactif est un processus qui ne traite pas de requête. S'il y a moins processus inactifs que la valeur saisie, le processus parent va créer de nouveaux enfants de la manière suivante : il en crée un, attend une seconde, il en crée deux, attend une seconde, il en crée quatre, puis continue ainsi exponentiellement jusqu'à ce que son taux de création de processus enfants soit de 32 par seconde. Il ne s'arrête que lorsque le nombre de processus enfants correspond au chiffre saisi dans la directive.Nombre maximum de processus serveurs enfants inactifs: Cette directive permet de définir le nombre maximum souhaité de processus serveurs enfants inactifs. Un processus inactif est un processus qui ne traite pas de requête. S'il y a plus processus inactifs que le chiffre saisi, le processus parent arrêtera les processus excédentaires.Nombre maximum de connexions pouvant être traitées simultanément: Si la limite maximum est atteinte, toute tentative de connexion sera mise dans une file d'attente (la valeur de la directive ServerLimit ne doit pas être supérieur à la valeur de cette variable, aussi elle est automatiquement adaptée dans le template).Nombre maximum de connexions qu'un processus enfant va traiter au cours de son fonctionnement: Si ce nombre est défini à 0, il n'y a plus aucune limite sur le nombre de connexions que le processus pourra traiter.
Truc & astuce
Les nom des paramètres de configuration Apache impactés se retrouvent dans le nom des variables Creole et sont préfixés par la chaîne "mpm_".
L'affichage du nom des variables s'obtient dans le mode debug de l'interface de configuration du module.
Pour plus d'informations, vous pouvez consulter la liste des directives de la version MPM d'Apache : https://httpd.apache.org/docs/2.4/fr/mod/prefork.html
Configuration PHP
Les autres variables permettent de modifier et de fixer une sélection de paramètres disponibles dans le fichier de configuration : /etc/php5/apache2/php.ini.
Taille maximale des données reçues par la méthode POST (en Mo): Définit la taille maximale des données reçues par la méthode POST. Cette option affecte également le chargement des fichiers. Pour charger de gros fichiers, cette valeur doit être plus grande que la valeur de laTaille maximale d'un fichier à charger (en Mo).
Attention
Si le module Scribe fonctionne avec un module Amon il faut également régler la Taille maximale des données reçues par la méthode POST (en Mo) en mode expert dans l'onglet Reverse proxy du module Amon.
Taille maximale d'un fichier à charger (en Mo): Définit la taille maximale d'un fichier à charger.Temps maximal d'exécution d'un script (en secondes): Fixe le temps maximal d'exécution d'un script. Cela permet d'éviter que des scripts en boucles infinies saturent le serveur. La configuration par défaut est de 30 secondes.Durée maximale pour analyser les données d'entrée (en secondes): Cette option spécifie la durée maximale pour analyser les données d'entrée via les méthodes POST et GET. Cette durée est mesurée depuis le moment où PHP est invoqué sur le serveur jusqu'au début de l'exécution du script.Taille mémoire maximale qu'un script est autorisé à allouer (en Mo): Cette option détermine la mémoire limite qu'un script est autorisé à allouer. Cela permet de prévenir l'utilisation de toute la mémoire par un script mal codé. Notez que pour n'avoir aucune limite, vous devez définir cette directive à -1.Affichage des erreurs à l'écran: Affiche les messages d'erreur PHP directement sur les pages consultées, attention cette option ne doit pas être utilisée en production et s'applique à toutes les applications web hébergées sur le serveur.Durée de vie des données sur le serveur (en secondes): Spécifie la durée de vie des données sur le serveur. Après cette durée, les données seront considérées comme obsolètes, et supprimées.Nombre d'octets à lire dans le fichier utilisé comme source additionnelle d'entropie: Spécifie le nombre d'octets qui seront lus dans le fichier/dev/urandom. Par défaut, il vaut 0 , c'est à dire inactif.
Attention
La directive session.entropy_length n'existe plus depuis PHP 7.1.0.
La variable EOLE associée (Nombre d'octets à lire dans le fichier utilisé comme source additionnelle d'entropie) est supprimée sur EOLE 2.8.
Activer la directive de configuration browscap: La directive de configuration browscap permet d'obtenir plus d'information sur les capacités du navigateur client grâce à la fonction get_browser() : http://browscap.org/.
Truc & astuce
Les nom des paramètres de configuration PHP impactés se retrouvent dans le nom des variables Creole et sont préfixés par la chaîne "php_".
L'affichage du nom des variables s'obtient dans le mode debug de l'interface de configuration du module.
Pour plus d'informations, vous pouvez consulter la liste des directives du fichier php.ini en ligne : http://www.php.net/manual/fr/ini.list.php
Onglet Workstation : configuration avancée de la prise de contrôle des postes clients
Écran
- 1
Activer la jonction automatique au domaine
L’activation automatique de jonction au domaine permet d’appliquer aux clients salt enregistrés un état qui exécute l’opération de jonction au domaine si le poste est encore hors-domaine.
Remarque
Cette option n’est disponible qu’à partir de la version 2.8.1
Conseil
L’application de l’état par le client salt nécessite que celui-ci dispose du mot de passe d’un compte avec les droits suffisants pour l’opération de jonction au domaine. Le mot de passe de ce compte est modifié au reconfigure pour limiter l’impact de sa diffusion. Il est conseillé de s’assurer que les reconfigure sont exécutés fréquemment si cette option est activée.
Attention
Cette option n’est pas compatible avec l’option d’acceptation automatique des certificats des clients salt.
- 2
Activation de Veyon
Activée par défaut, l’application Veyon peut être désactivée si les fonctionnalités de visualisation et prise de contrôle à distance ne sont pas souhaitées
- 3
Groupes autorisés à accéder aux fonctionnalités de Veyon
Un filtre utilisant les CN (common name) des groupes permet de limiter l’accès aux fonctionnalités de Veyon aux membres des groupes correspondants
- 4
Restriction des fonctionnalités de Veyon
La fonctionnalité de prise de contrôle à distance est désactivée par défaut, contrairement à la visualisation.
- 5
Activer la configuration de Firefox
Permet le configuration du proxy et la diffusion du certificat pour l’utilisation du mode MITM.
Remarque
Cette option n’est disponible qu’à partir de la version 2.8.1.
La désactivation de la jonction automatique au domaine donne la possibilité d’activer l’automatisation du renouvellement des certificats salt des postes clients.
Attention
L’option est activée par défaut dès lors que l’option Activer la jonction automatique au domaine est désactivée.
Comme décrit dans le détail de cette option, elle présente un risque en terme de sécurité. Il est conseillé de la désactiver en dehors de cas d’usage très précis.
Écran
- 1
Accepter automatiquement le renouvellement d’un certificat SALT en ne se basant que sur l’ID du certificat (solution peu sécurisé)
Lors de la première connexion d’un client salt sur le maître, le certificat est placé en attente de validation pour finaliser le lien. Cette option active une validation automatique d’un certificat si le nom du poste est déjà connu du maître.
Attention
Le critère qui déclenche l’acceptation automatique du certificat n’apporte aucune garantie sur l’identité du client. Ce mécanisme permet donc un appariement d’un client salt quelconque si celui-ci se présente avec le nom d’un client déjà accepté. L’ancien certificat associé au nom du client est, quant à lui, invalidé. En plus de la validation d’un certificat illégitime, il est donc également possible que la procédure invalide un certificat légitime.
Remarque
Cette option ne peut pas être activée si l’option de jonction automatique est elle-même activée.
Remarque
Cette option n’est disponible qu’à partir de la version 2.8.1.
onglet bareos-webui
Configuration
Le serveur web apache doit être activé sur le module. Dans l'interface de configuration du module, dans l'onglet Services, Activer le serveur web Apache doit être à oui.
Dans l'onglet Applications web, il faut passer Activer Bareos WebUI (gestion de la sauvegarde) à oui.
Un nouvel onglet Bareos webui apparaît dans l'interface de configuration du module.
Il est possible de créer un ou plusieurs comptes autorisés à se connecter à l'interface bareos-webui en cliquant sur le bouton + Utilisateur autorisé à se connecter à l'interface web de gestion de la sauvegarde.
Le mot de passe de la base de données MySQL peut éventuellement être personnalisé mais par défaut il est généré automatiquement. Une fois la configuration enregistrée, il ne sera plus possible de le modifier.
Remarque
L'application n'est pas disponible immédiatement après l'installation.
L'opération nécessite une reconfiguration du serveur avec la commande reconfigure.
Onglet Eole sso : Configuration du service SSO pour l'authentification unique
Le serveur EoleSSO est prévu pour être déployé sur un module EOLE.
Il est cependant possible de l'utiliser dans un autre environnement en modifiant manuellement le fichier de configuration /usr/share/sso/config.py.
Cette section décrit la configuration du serveur depuis l'interface de configuration du module disponible sur tous les modules EOLE. Les valeurs définies par défaut simplifient la configuration dans le cadre d'une utilisation prévue sur les modules EOLE.
Serveur local ou distant
L'activation du serveur EoleSSO s'effectue dans l'onglet Services.
La variable Utiliser un serveur EoleSSO permet :
-
non: de ne pas utiliser de SSO sur le serveur ; -
local: d'utiliser et de configurer le serveur EoleSSO local ; -
distant: d'utiliser un serveur EoleSSO distant (configuration cliente).
Adresse et port d'écoute
L'onglet supplémentaire Eole-sso apparaît si l'on a choisi d'utiliser un serveur EoleSSO local ou distant.
Dans le cas de l'utilisation du serveur EoleSSO local, Nom de domaine du serveur d'authentification SSO doit être renseigné avec le nom DNS du serveur.
Durée de vie d'une session (en secondes): indique la durée de validité d'une session SSO sur le serveur. Cela n'influence pas la durée de la session sur les applications authentifiées, seulement la durée de la validité du cookie utilisé par le serveur SSO. Au delà de cette durée, l'utilisateur devra obligatoirement se ré-authentifier pour être reconnu par le serveur SSO. Par défaut, la durée de la session est de 3 heures (7200 secondes).CSS par défaut du service SSO (sans le .css): permet de spécifier une CSS différente pour le formulaire d'authentification affiché par le serveur EoleSSO. Le fichier CSS doit se trouver dans le répertoire/usr/share/sso/interface/theme/style/<nom_fichier>.css. Se reporter au chapitre personnalisation pour plus de possibilités à ce sujet.
AttentionPort 443
Si le port HTTPS (443) est déclaré pour ce service, alors celui-ci est uniquement accessible via l’URL https://<nom_du_serveur>/sso.
L’URL de la forme https://<nom_du_serveur>:<port>/ reste valable pour les autres valeurs de port que 443.
Dans le cas de l'utilisation d'un serveur EoleSSO distant, seuls les paramètres Nom de domaine du serveur d'authentification SSO et Port utilisé par le service EoleSSO sont requis et les autres options ne sont pas disponibles car elles concernent le paramétrage du serveur local.
Configuration LDAP
Le serveur EoleSSO se base sur des serveurs LDAP[11] pour authentifier les utilisateurs et récupérer leurs attributs.
Il est possible ici de modifier les paramètres d'accès à ceux-ci :
- l'adresse et le port d'écoute du serveur LDAP ;
- le chemin de recherche correspond à l'arborescence de base dans laquelle rechercher les utilisateurs (basedn) ;
- un libellé à afficher dans le cas où un utilisateur aurait à choisir entre plusieurs annuaires/établissements pour s'authentifier (voir le chapitre
Gestion des sources d'authentifications multiples) ; - un fichier d'informations à afficher dans le cadre qui est présenté en cas d'homonymes. Ces informations apparaîtront si l'utilisateur existe dans l'annuaire correspondant. Les fichiers doivent être placés dans le répertoire
/usr/share/sso/interface/info_homonymes; - DN[50] et mot de passe d'un utilisateur en lecture pour cet annuaire ;
- attribut de recherche des utilisateurs : indique l'attribut à utiliser pour rechercher l'entrée de l'utilisateur dans l'annuaire (par défaut, uid)
- choix de la disponibilité ou non de l'authentification par clé OTP[51] si disponible (voir plus loin).
Attention
Dans le cas où vous désirez fédérer EoleSSO avec d'autres fournisseurs de service ou d'identité (ou 2 serveurs EoleSSO entre eux), il est nécessaire de configurer un utilisateur ayant accès en lecture au serveur LDAP configuré.
Il sera utilisé pour récupérer les attributs des utilisateurs suite à réception d'une assertion d'un fournisseur d'identité (ou dans le cas d'une authentification par OTP).
Cet utilisateur est pré-configuré pour permettre un accès à l'annuaire local sur les serveurs EOLE.
Sur les modules EOLE, la configuration recommandée est la suivante :
- utilisateur :
cn=reader,o=gouv,c=fr - fichier de mot de passe :
/root/.reader
Si vous connectez EoleSSO à un annuaire externe, vous devez définir vous même cet utilisateur :
Utilisateur de lecture des comptes ldap: renseignez son dn complet dans l'annuairefichier de mot de passe de l'utilisateur de lecture: entrez le chemin d'un fichier ou vous stockerez son mot de passe (modifiez les droits de ce fichier pour qu'il soit seulement accessible par l'utilisateurroot)
Passer la variable Information LDAP supplémentaires (applications) à oui permet de configurer pour chaque annuaire LDAP déclaré des attributs supplémentaires qui seront utilisés par les applications web (DN racine de l'arbre utilisateurs, DN racine de l'arbre groupes, Champ 'nom d'affichage' de l'utilisateur, Champ 'mail' de l'utilisateur, Champ 'fonction' de l'utilisateur, Champ 'categorie' de l'utilisateur, Champ 'rne' de l'utilisateur, Champ 'fredurne' de l'utilisateur…).
Passer la variable Permettre le changement de mot de passe sur un serveur AD à oui permet à l'utilisateur de changer son mot de passe depuis la mire SSO si ce dernier à expiré.
Il est alors nécessaire de renseigner le nom du domaine AD et le nom du serveur AD sur lequel changer le mot de passe.
Serveur SSO parent
Un autre serveur EoleSSO peut être déclaré en tant que serveur parent dans la configuration (adresse et port). Se reporter au chapitre traitant de la fédération pour plus de détails sur cette notion.
Si un utilisateur n'est pas connu dans le référentiel du serveur EoleSSO, le serveur essayera de l'authentifier auprès de son serveur parent (dans ce cas, la liaison entre les 2 serveurs s'effectue par l'intermédiaire d'appels XML-RPC[52] en HTTPS, sur le port défini pour le serveur EoleSSO).
Si le serveur parent authentifie l'utilisateur, il va créer un cookie de session local et rediriger le navigateur client sur le serveur parent pour qu'une session y soit également créée (le cookie de session est accessible seulement par le serveur l'ayant créé).
Attention
Ce mode de fonctionnement n'est plus recommandé aujourd'hui. Il faut préférer à cette solution la mise en place d'une fédération par le protocole SAML.
Fédération d'identité
Le serveur EoleSSO permet de réaliser une fédération vers un autre serveur EoleSSO ou vers d'autre types de serveurs compatibles avec le protocole SAML[53] (version 2).
Nom d'entité SAML du serveur eole-sso (ou rien) : nom d'entité du serveur EoleSSO local à indiquer dans les messages SAML. Si le champ est laissé à vide, une valeur est calculée à partir du nom de l'académie et du nom de la machine.
Cacher le formulaire lors de l'envoi des informations de fédération : permet de ne pas afficher le formulaire de validation lors de l'envoi des informations de fédération à un autre système. Ce formulaire est affiché par défaut et indique la liste des attributs envoyés dans l'assertion SAML permettant la fédération.
Authentification OTP
Il est possible de configurer EoleSSO pour gérer l'authentification par clé OTP à travers le protocole securID[54] de la société EMC (précédemment RSA).
Pour cela il faut :
installer et configurer le client PAM/Linux proposé par EMC (voir annexes)
Répondre
ouià la questionGestion de l'authentification OTP (RSA SecurID)
Des champs supplémentaires apparaissent :
Pour chaque annuaire configuré, un champ permet de choisir la manière dont les identifiants à destination du serveur OTP sont gérés. '
inactifs' (par défaut) indique que l'authentification OTP n'est pas proposée à l'utilisateur. Avec'identiques', le login local (LDAP) de l'utilisateur sera également utilisé comme login OTP. La dernière option est 'configurables', et indique que les utilisateurs doivent renseigner eux même leur login OTP. Dans ce dernier cas, l'identifiant est conservé sur le serveur EoleSSO pour que l'utilisateur n'ait pas à le renseigner à chaque fois (fichier/usr/share/sso/securid_users/securid_users.ini).Le formulaire d'authentification détecte automatiquement si le mot de passe entré est un mot de passe OTP. Il est possible de modifier la reconnaissance si elle ne convient pas en réglant les tailles minimum et maximum du mot de passe et en donnant une expression régulière qui sera vérifiée si la taille correspond. Les options par défaut correspondent à un mot de passe de 10 à 12 caractères uniquement numériques.
Certificats
Les communications de et vers le serveur EoleSSO sont chiffrées.
Sur les modules EOLE, des certificats auto-signés sont générés à l'instanciation[55] du serveur et sont utilisés par défaut.
Il est possible de renseigner un chemin vers une autorité de certification et un certificat serveur dans le cas de l'utilisation d'autres certificats (par exemple, des certificat signés par une entité reconnue).
Les certificats doivent être au format PEM.
Configuration en mode expert
Autres options
En mode expert plusieurs nouvelles variables sont disponibles :
Alias d'accès au service SSO (paramètre : __CAS_FOLDER)permet de créer un alias spécifique en plus du domaine et du port pour certains serveurs SSO tels que lemonLDAP[115] ou keycloak[116].Cette variable est disponible uniquement à partir de la version 2.6.2 d'EOLE.
Nom du cookie EoleSSOetDomaine du cookie EoleSSOpermettent la gestion d'un cluster EoleSSO.
Générer des statistiques d'usage du serviceest ànonpar défaut.Si ce paramètre est à
oui, EoleSSO va générer des statistiques sur l'usage du service (consommation mémoire, nombre de session...). Ces statistiques sont générées par la librairie python prometheus-client. Elles peuvent être intégrées à un outil tel que Grafana, et sont disponibles sur l'URL suivante : https://<adresse_serveur>:8443/metric.
Activer la balise meta viewport (CSS responsive)permet d'inclure la balise HTML metaviewportdans les pages de l'application (avec content="width=device-width, initial-scale=1"). Elle est à activer en cas d'utilisation d'une feuille de style CSS responsive.
Ne pas répondre aux demandes CAS des applications inconnuesest ànonpar défautSi ce paramètre est à
oui, seules les applications renseignées dans les fichiers d'applications (/usr/share/sso/app_filters/*_apps.ini) sont autorisées à recevoir des réponses du serveur en mode CAS. Si il est à non, le filtre par défaut leur sera appliqué ;Nombre maximum de sessions en attente (backlog)permet de définir la taille de la file d'attente des sessions.Augmenter cette valeur est susceptible de résoudre des problèmes de lenteur voir de rejet des demandes d'authentification ;
Décalage de temps (en secondes) dans les messages de fédération SAMLest à-300secondes par défautCe décalage est appliqué aux dates dans les messages de fédération SAML. Cela permet d'éviter le rejet des messages lorsque le serveur partenaire n'est pas tout à fait synchrone (par défaut, on décale de 5 minutes dans le passé). Ce délai est aussi pris en compte pour la validation des messages reçus ;
Taille du pool de traitement (thread pool size)permet de configurer la valeur du paramètre THREAD_POOL_SIZE.Augmenter cette valeur est susceptible de résoudre les problèmes de charge rencontrés sur certaines infrastructures ;
Utiliser l'authentification SSO pour l'EADest àouipar défaut.Le passer à
nonpermet de ne plus utiliser le serveur SSO pour l'authentification de l'EAD.
Authentification OpenID Connect
Autoriser l'authentification OpenID Connectest ànonpar défautSi ce paramètre est à
oui, il devient possible de configurer un ou plusieurs fournisseurs d'identité OpenID Connect ;Référence du fournisseur d'identité OpenID: renseigner un libellé pour identifier le fournisseur. Ce libellé est interne à l'application EoleSSO. Il est utilisé pour définir le nom des fichiers contenant les logos/boutons du fournisseur :/usr/share/sso/interface/images/<libelle>.png: bouton de connexion présenté sur la page de login (par exemple : "se connecter avec France Connect") ;/usr/share/sso/interface/images/logo-<libelle>.png: logo du fournisseur qui sera affiché sur la page d'association de comptes.
Libellé du fournisseur d'identité OpenID: libellé à destination des utilisateurs pour décrire le fournisseur ("France Connect", "Google", ...) ;URL d'accès (issuer): URL décrivant le fournisseur d'identité (la plupart du temps, l'URL de base de son service d'authentification) ;URL de demande d'autorisation (authorization endpoint): URL permettant au client d'initier le processus d'authentification ;URL de récupération de jeton d'accès (token endpoint): URL permettant de récupérer un jeton (éventuellement l'identifiant de l'utilisateur) après authentification ;URL de déconnexion (logout endpoint): URL permettant de demander une déconnexion. Ce paramètre est ignoré pour les fournisseurs utilisant une cinématique de déconnexion spécifique comme Google, Facebook et Microsoft ;URL de lecture des informations (userinfo endpoint): URL permettant de récupérer les informations de l'utilisateur à l'aide du jeton fourni ;URL de description des certificats de signature (jwks URI): URL décrivant les certificats utilisés par le fournisseur (si disponible) ;
Définition de l'identifiant client (Client ID) et clé secrète (Client secret)
Attention
L'identifiant client (Client ID) et la clé privée secrète ( Client secret) renvoyés par le fournisseur d'identité utilisés pour valider les échanges doivent être, pour des raisons de sécurité, stockés dans un fichier à part avec des droits restreints.
Pour chaque fournisseur d'identité, ajouter une ligne dans le fichier /etc/eole/eolesso_openid.conf :
<nom_fournisseur> = "<client id> :<client secret>"
Le nom_fournisseur doit correspondre au paramètre Référence du fournisseur d'identité OpenID renseigné dans l'interface de configuration du module.
Si ces informations ne sont pas renseignées pour l'un des fournisseurs déclarés, un message l'indiquera au lancement de la commande diagnose.
Version du serveur SSO
Dans le cas où le serveur SSO est déclaré en SAML, de nouvelles variables permettent de déclarer les correspondances (mapping) permettant de récupérer les principaux attributs des utilisateurs parmi celle transmises par le serveur.
Onglet Ead-web : EAD et proxy inverse
Si l'interface web de l'EAD est activée sur le module (onglet Services), les paramètres de l'onglet Ead-web permettent de régler le port d'accès à l'interface EAD depuis l'extérieur si un proxy inverse est utilisé.
Par défaut l'utilisation d'un proxy inverse pour accéder à l'EAD est à non.
Si la variable est passée à oui, le port proposé pour accéder à l'EAD depuis l'extérieur est par défaut 4203.
Onglet Mode Restreint : Configuration des restrictions de navigation
Le mode restreint ou safe search[56] permet d'activer la navigation restreinte, soit bloquer les contenus "sensibles" pour les utilisateurs du domaine.
Les différentes cibles du mode restreint
L'activation du mode restreint s'effectue dans l'onglet Mode restreint.
Il est possible d'activer le mode restreint pour certaines applications
-
Forcer le "mode restreint" pour les recherches Google: bloque les contenus à caractères sensibles pour les résultat de recherche sur Google ; -
Forcer le "mode restreint" pour les vidéos Youtube: bloque les contenus à caractères sensibles pour les vidéos Youtube ; -
Forcer le "mode restreint" pour les recherches Bing: bloque les contenus à caractères sensibles pour les résultat de recherche sur Bing ; -
Forcer le "mode restreint" pour les recherches Duckduckgo: bloque les contenus à caractères sensibles pour les résultat de recherche sur Duckduckgo ; -
Forcer le "mode restreint" pour les recherches Qwant: bloque les contenus à caractères sensibles pour les résultats de recherche sur Qwant ;
Remarque
Sur les versions précédentes, la mise en œuvre du mode restreint s'appuyait sur des réécritures d'URL gérées directement dans le logiciel de filtrage e2guardian[2].
À partir d'EOLE 2.8.1, ce sont des redirections DNS[3] qui sont utilisées. Cela nécessite d'avoir la main sur ce service, ce qui n'est pas le cas sur le module Eolebase+Proxy.
Onglet Mysql : Configuration du serveur MySQL
Sur les modules Scribe et AmonEcole, le serveur de base de données MySQL est obligatoirement activé.
Sur les autres modules, il est activable/désactivable dans l'onglet Services par l'intermédiaire de l'option : Activer le serveur de bases de données MySQL. L'onglet expert Mysql apparaît uniquement si le service est activé.
L'onglet expert Mysql permet de modifier et de fixer une sélection de paramètres disponibles dans le fichier de configuration : /etc/mysql/my.cnf
Les paramètres en question se retrouvent dans le nom des variables Creole et sont généralement préfixés par la chaîne "mysql_".
Nombre maximum de connexions simultanées
Ce paramètre permet d'augmenter le nombre de connexions clientes maximum simultanées.
Cela peut s'avérer nécessaire sur des sites où la fréquentation des applications web est très importante et où l'erreur MySQL Too many connections apparaît fréquemment.
Adresses autorisées à accéder à MySQL
Il est possible de déclarer les adresses IP ou les réseaux autorisés à accéder au serveur MySQL local.
Pour autoriser des adresses à accéder au serveur MySQL, il faut passer la variable Permettre l'accès au serveur depuis l'extérieur à oui puis ajouter les couples d'adresse réseau/masque souhaités.
Dans le cas où le serveur possède plusieurs interfaces réseau, il est possible de préciser l'interface par laquelle les adresses définies ont le droit de se connecter.
Remarque
Sur le module Horus, l'Adresse IP réseau autorisée pour les connexions distantes au serveur MYSQL est pré-renseignée avec l'adresse du réseau local.
Remarque
Gestion des logs
Il est possible d'activer les logs binaires permettant de rejouer les transactions SQL (attention, logs volumineux). Les logs seront à l'emplacement suivant /var/lib/mysql/, nommés sur la forme binlog.0000XX
Écran
- 1
nom de la variable :
mysql_activer_binlogActivation des logs binaires permettant de rejouer les transactions SQL (attention, logs volumineux)
- 2
nom de la variable :
mysql_binlog_retentionDurée de rétention des logs en heures définissant un paramètre du serveur ainsi qu'une consigne de nettoyage au reconfigure (valeur maximale utilisable : 1193046).
Remarque
Complément
Pour plus d'informations, vous pouvez consulter les exemples de configuration fournis dans :
/usr/share/doc/mysql-server-5.7/examples/
ou consulter :
Onglet Postgresql : Paramètres de fonctionnement du serveur PostgreSQL
La configuration porte sur une sélection de paramètres globaux et d’options d’optimisation du service.
Paramètres globaux
Nombre maximum de connexions: permet de définir le nombre maximum de connexions concurrentes au serveur de base de données ;Délai de connexion maximum (en secondes): permet de définir le temps maximum pour terminer l'authentification du client ;Emplacement de la clé SSL du serveur PostgreSQL: permet de changer le chemin par défaut de la clé SSL ;Emplacement du certificat du serveur PostgreSQL: permet de changer le chemin par défaut du certificat ;Répertoire contenant les bases de données PostgreSQL: par défaut/var/lib/postgresql/9.5/main.
Méthode de sauvegarde personnalisée
Il est possible de paramétrer une méthode de sauvegarde personnalisée en indiquant l’emplacement d’un script et la liste des paramètres, avec les valeurs souhaitées. Cette méthode de sauvegarde personnalisée peut-être limitée à une liste de bases de données.
Chemin du script de sauvegarde personnalisé: emplacement personnalisé du script de sauvegarde prenant le pas sur la sauvegarde normale des bases de données spécifiées ;Paramètre pour le script: nom du paramètre à fournir au script de sauvegarde ;Valeur pour le paramètre: valeur à fournir au script pour le paramètre associé ;Il est possible d'ajouter autant de paramètres que souhaité en cliquant sur le bouton
+ Paramètre pour le script.Base de données à sauvegarder: nom des bases de données à sauvegarder via le script personnalisé (ces bases seront exclues de la gestion des sauvegardes EOLE).
Complément
L’utilité d’une méthode personnalisée se justifie dans le cas des bases avec des tailles trop importantes ou au contenu inadéquat pour le système classique.
Paramètres d’optimisation
Mémoire tampon allouée aux opérations de tri et tables de hash: quantité de mémoire allouée à chaque opération avant écriture sur le disque (par défaut 4MB sur PostgreSQL 9.5)Unité de la mémoire tampon: permet de choisir l'unité kB ou MB utilisée pour le paramètre ci-dessus ;Mémoire tampon allouée pour les opérations de maintenance ;
Unité de la mémoire tampon: permet de choisir l'unité kB ou MB utilisée pour le paramètre ci-dessus ;Mémoire tampon allouée pour les journaux: quantité de mémoire allouée à chaque opération avant écriture sur le disque (par défaut 64MB sur PostgreSQL 9.5) ;Limite douce du Write Ahead Log: quantité de mémoire allouée avant écriture sur le disque (par défaut : -1, soit 1/32ème de la valeur de shared_buffers) ;Unité de la limite douce du Write Ahead Log: permet de choisir l'unité kB, MB ou GB utilisée pour le paramètre ci-dessus ;Quantité de mémoire pour les buffers partagés: permet de définir la quantité de mémoire cache utilisée par le serveur, ce paramètre contribue le plus au gain de performance ;Unité de la quantité de mémoire pour les buffers partagés: permet de choisir l'unité kB ou MB utilisée pour le paramètre ci-dessus ;Taille du cache (blocs de 8ko): taille de la mémoire de mise en cache, une grosse valeur aura tendance à augmenter l'utilisation des index, l'accès disque sera rendu plus rapide ;Unité de la taille du cache: permet de choisir l'unité kB ou MB utilisée pour le paramètre ci-dessus.
Complément
Pour plus d'informations, vous pouvez consulter la documentation officielle du logiciel :
Onglet Messagerie
Même sur les modules ne fournissant aucun service directement lié à la messagerie, il est nécessaire de configurer une passerelle SMTP valide car de nombreux outils sont susceptibles de nécessiter l'envoi de courriers électroniques.
La plupart des besoins concernent l'envoi d'alertes ou de rapports.
Exemples : rapports de sauvegarde, alertes système, ...
Service anti-spam
Activer le service anti-spam SpamAssassin permet d'activer/désactiver le service SpamAssasin. Le but de ce logiciel est de filtrer les courriers électroniques reconnus comme étant indésirables.
Service de récupération de courrier électronique (POP/IMAP)
Activer le serveur de courrier permet de désactiver le service d'échange de courrier ou de choisir le ou les protocoles supportés : POP, IMAP ou POP -IMAP.
En ce qui concerne le serveur de récupération de courrier électronique, il est possible de changer l'adresse du serveur IMAP utilisé pour le client CAS/IMAP et de désactiver l'autorisation de l'authentification CAS sur le serveur IMAP de Courier.
Serveur de listes
Activer le serveur de listes de diffusion Sympa permet de désactiver le gestionnaire de publipostage.
Serveur d'envoi/réception (SMTP)
Les paramètres communs à renseigner sont les suivants :
Nom de domaine de la messagerie de l'établissement (ex : monetab.ac-aca.fr), saisir un nom de domaine valide, par défaut un domaine privé est automatiquement créé avec le préfixei-;Adresse électronique d'envoi pour le compte root, saisir l'adresse que l'on souhaite utiliser pour l'envoi de courriers électroniques depuis le compte root.Adresse électronique recevant les courriers électroniques à destination du compte root, permet de configurer une adresse pour recevoir les éventuels messages envoyés par le système.Taille maximale d'un message à envoyer en Mo, indiquer la taille maximale des courrier électroniques qui seront envoyés par exim.
Attention
Le Nom de domaine de la messagerie de l'établissement (onglet Messagerie) ne peut pas être le même que celui d'un conteneur. Le nom de la machine (onglet Général) donne son nom au conteneur maître aussi le Nom de domaine de la messagerie de l'établissement ne peut pas avoir la même valeur.
Dans le cas contraire les courriers électroniques utilisant le nom de domaine de la messagerie de l'établissement seront réécris et envoyés à l'adresse électronique d'envoi du compte root.
Cette contrainte permet de faire en sorte que les courrier électroniques utilisant un domaine de type @<NOM CONTENEUR>.* soient considérés comme des courriers électroniques systèmes.
Attention
Dans le cas où le Nom de domaine de la messagerie de l’établissement n’est pas le même que la concaténation du Nom de la machine et du Nom DNS du réseau local, il peut être nécessaire d’activer la réécriture des en-têtes pour avoir des informations cohérentes avec l’enveloppe des courriels.
En mode normal, il est possible de configurer le nom de l'émetteur des messages pour le compte root.
Attention
Certaines passerelles n'acceptent que des adresses de leur domaine.
Il est également possible de configurer la taille maximale des messages électroniques.
Attention
Sur les modules utilisant le webmail Roundcube, elle ne devrait pas dépasser la taille maximale d'un fichier à charger définie pour Apache.
En mode expert, il est possible d'écraser les en-têtes des courriers électroniques.
La réécriture des adresses doit prendre en compte la distinction entre l'enveloppe SMTP (« MAIL FROM » et « RCPT TO ») et les en-têtes des messages (« From: », « Reply-To:», « To: », « Cc: », « Bcc: »).
Les adresses électroniques systèmes ont par défaut une des formes suivante :
user@%%domaine_messagerie_etabsi l'expéditeur ne précise pas le nom de domaine, par exemple :root@internet:~# echo "Test" | mail -s "Test mail from shell" -r root root
user@%%nom_machine.%%domaine_messagerie_etabpour le maître si l'expéditeur utilise la configuration définie dans/etc/mailname
user@%%conteneur.%%nom_machine.%%domaine_messagerie_etabpour les conteneurs[119] si l'expéditeur utilise la configuration définie dans/etc/mailname
Si la valeur de %%nom_domaine_local est différente de la valeur de %%domaine_messagerie_etab, alors on force les formes suivantes pour le maître et les conteneurs uniquement :
user@%%nom_machine.%%domaine_messagerie_etabpour le maître
user@%%conteneur.%%nom_machine.%%domaine_messagerie_etabpour les conteneurs
Les adresses destinataires root@%%nom_domaine_local et root@%%domaine_messagerie_etab sont remplacées par %%system_mail_to si cette dernière est définie.
Les adresses expéditeurs et destinataires systèmes sont ensuite réécrites selon les tableaux suivants en fonction de variables expertes :
system_mail_from_for_headers: écraser les en-têtes « From: », « Reply-To: » et « Sender: » du message, par défaut ànon
system_mail_to_for_headers: écraser les en-têtes « To: », « Cc: » et « Bcc: » du message, par défaut ànon
Réécriture de l’expéditeur :
system_mail_from_for_headers = non | system_mail_from_for_headers = oui | |
MAIL FROM | system_mail_from | system_mail_from |
From : | user@conteneur.machine.domaine | system_mail_from |
Reply-To : | user@conteneur.machine.domaine | system_mail_from |
Sender : | user@conteneur.machine.domaine | system_mail_from |
Réécriture du destinataire :
system_mail_to_for_headers = non | system_mail_to_for_headers = oui | |
RCPT TO | system_mail_to | system_mail_to |
To : | user@conteneur.machine.domaine | system_mail_to |
Cc : | user@conteneur.machine.domaine | system_mail_to |
Bcc : | user@conteneur.machine.domaine | system_mail_to |
Par défaut, la distribution locale des messages est désactivée, sauf sur les modules Scribe et AmonEcole sur lesquels cette variable est masquée.
Son activation (forcée sur les modules Scribe et AmonEcole) permet d’avoir un domaine local et un domaine privé.
Lorsqu'elle est activée, il est possible d'agir sur le quota et sur le pourcentage d'occupation des boîtes, qui entraîne un message électronique d'avertissement.
Si le service anti-spam est activé, il est possible de modifier le seuil à partir duquel un courrier électronique est considéré en tant que spam. La valeur attendue par SpamAssassin doit être multipliée par 10 dans le champ Seuil de détection d'un spam (multiplié par 10) afin de faire des comparaisons sur des entiers.
La variable Nombre de jours avant de rejeter les messages non distribués permet d'ajuster la durée de rétention des messages qui n'ont pas pu être envoyés (frozen).
Truc & astuce
La commande exiqgrep permet d'afficher la liste des messages en attente.
La ligne de commande suivante permet de purger la file d'attente :
exiqgrep -i | xargs exim -Mrm
Attention
Passer cette variable à non rend l'authentification SMTP impossible ce qui empêche les utilisateurs d'envoyer des messages.
Relai des messages
La variable Passerelle SMTP, permet de saisir l'adresse IP ou le nom DNS de la passerelle SMTP à utiliser.
Remarque
Afin d'envoyer directement des courriers électroniques sur Internet il est possible de désactiver l'utilisation d'une passerelle en passant Router les courriels par une passerelle SMTP à non.
Sur les modules possédant un serveur SMTP (Scribe, AmonEcole), ces paramètres sont légèrement différents et des services supplémentaires sont configurables.
Il est possible d'activer le support du TLS[15] pour l'envoi de messages.
Si la passerelle SMTP[57] accepte le TLS, il faut choisir le port en fonction de la prise en charge de la commande STARTTLS[58].
Pour cela il suffit d'indiquer le port spécifique dans l'option Utilisation de TLS (SSL) par la passerelle SMTP il y a cinq possibilités.
nonport 25port 465port 587port personnalisé
Le dernier choix permet à l'utilisateur de saisir un port différent de ceux proposés dans une nouvelle option appelée Port de la passerelle SMTP.
Dans le cas où la passerelle nécessiterait une authentification il est nécessaire de le signaler en passant la variable La passerelle requiert une authentification à oui.
Cette action affiche deux nouvelles variables :
Par défaut le relai des messages n'est pas activé sur les modules sauf sur le module Seshat. Si la variable est passée à oui, elle active les listes d'adresses IP autorisées à utiliser ce serveur comme relai de messagerie et la liste des noms de domaines autorisés à être relayés par ce serveur.
Configuration experte
Dans la rubrique Configuration experte plusieurs paramètres peuvent être modifiés.
FQDN utilisé par EximPersonnalisation du nom de domaine complètement qualifié utilisé par Exim dans le protocole SMTP. C'est utile pour les vérifications anti-spam des MX externes
Les valeurs possibles sont :
- automatique : laisser Exim décider ;
- nom_machine.domaine_messagerie_etab : utiliser le nom de la machine complété par le nom de domaine de la messagerie établissement ;
- nom_machine.nom_domaine_local : utiliser le nom de la machine complété par le nom de domaine local.
Domaine utilisé pour qualifier les adressesNom de domaine ajouté aux adresses :
- nom de domaine local ;
- domaine privé de messagerie établissement ;
- domaine public de messagerie établissement.
Envoyer les logs à rsyslogPermet de désactiver l'envoi des logs.
Dupliquer les logs dans des fichiersDupliquer les logs dans des fichiers gérés directement par Exim. Si vous envoyez les logs à syslog, vous pouvez conserver la gestion des fichiers traditionnelle d'Exim. Ces fichiers étant gérés directement par Exim, ils se trouveront dans le conteneur du service.
Activer les règles de réécriture étenduePermettre de définir des règles de réécriture personnalisées. Si non, seuls les courriers électroniques en
localhostsont réécrits avec lenom_domain_local.http://exim.org/exim-html-current/doc/html/spec_html/ch31.html.
Les trois variables à saisir sont :
- Modèle de correspondance des adresses courriers électroniques à réécrire : http://exim.org/exim-html-current/doc/html/spec_html/ch31.html#SECID151
- Valeur de remplacement des adresses électroniques : http://exim.org/exim-html-current/doc/html/spec_html/ch31.html#SECID152
- Drapeau contrôlant la réécriture des adresses électroniques : http://exim.org/exim-html-current/doc/html/spec_html/ch31.html#SECID153
Fermeture de la messagerie
Le service de messagerie peut-être coupé sur la base de la présence d’un drapeau (fichier sur le système de fichiers).
Optionnellement, lorsque le serveur de messagerie est configuré pour accéder à l’annuaire (via la configuration du client LDAP), la coupure peut être conditionnée sur l’appartenance de l’utilisateur émetteur à un groupe de l’annuaire.
La configuration de la coupure repose sur l’identification du ou des drapeaux et sur l’identification optionnelle d'un groupe d’utilisateurs par drapeau.
L’accès à ces paramètres est conditionné à la variable Conditionner la coupure du service de courriels.
Drapeau: nom du fichier qui sera recherché dans le répertoire/var/run/eole/flagspar le serveur de courriels.La présence du fichier est interprétée par le serveur de courriels comme un ordre de coupure du service. La coupure affecte tous les utilisateurs sauf si le paramètre optionnel suivant est renseigné.
Groupe ciblé: groupe de l’annuaire permettant de restreindre la coupure à ses membres.
Onglet Directeur bareos
Le nom du directeur est une information importante, il est utilisé en interne dans le logiciel mais, surtout, il est nécessaire pour configurer un client Bareos ou pour joindre le serveur de stockage depuis un autre module.
À l'enregistrement du fichier de configuration il ne sera plus possible de modifier le nom du directeur. En effet, cette variable est utilisée dans les noms des fichiers de sauvegarde.
AttentionMigration de version EOLE
À partir d'EOLE 2.8.1, Bareos fonctionne avec PostgreSQL[59] tandis que sur les versions précédentes, il était possible de choisir entre MySQL et SQLite.
Il n'existe pas de migration de données entre ces bases.
Dans le cas d'une montée de version vers 2.8.1, il vous faudra penser à effectuer une nouvelle sauvegarde dès que possible.
En mode expert, il est possible de modifier le répertoire utilisé par défaut pour l'extraction de la base de données du catalogue. Ce changement permet éventuellement de ne pas surcharger l'espace occupé dans /var.
Le champ Mot de passe du directeur contient le mot de passe à transmettre aux applications distantes pour leur permettre de s'authentifier auprès du directeur.
Configuration des durées de rétention
Les trois types de sauvegarde, complète, différentielle, incrémentale, disposent chacune d’un pool de volumes distinct. Cela permet de paramétrer des durées de rétention[60] et des tailles pour ces volumes différents pour chaque type de sauvegarde.
La sauvegarde du catalogue est également gérée avec un pool de volume distinct. Seule la taille des volumes est paramétrable cependant.
Écran
- 1
Configuration du pool du catalogue
Taille des volumes pour la sauvegarde du catalogue (taille illimitée si à 0)
- 2
Configuration du pool pour la sauvegarde complète
Durée de rétention et taille des volumes pour la sauvegarde complète
- 3
Configuration du pool pour la sauvegarde différentielle
Durée de rétention et taille des volumes pour la sauvegarde différentielle
- 4
Configuration du pool pour la sauvegarde incrémentale
Durée de rétention et taille des volumes pour la sauvegarde incrémentale
La durée de rétention des fichiers détermine le temps de conservation avant l'écrasement.
Plus les durées de rétention sont importantes, plus l'historique sera important et plus l'espace de stockage nécessaire sera important.
L’espace alloué à un volume n’est pas recyclé (réutilisé pour une autre sauvegarde) avant que le volume ne soit complet et que les durées de rétention ne soient atteintes.
Limiter la taille des volumes est utile dans deux cas :
le système de fichier hébergeant les volumes impose une contrainte sur la taille des fichiers (typiquement les systèmes FAT montés via le protocole SMB, à l’origine de la contrainte de 2 Go) ;
on souhaite pouvoir recycler plus rapidement les volumes (de petite taille, les volumes sont associés à moins de jobs ; il faut donc moins de temps pour purger l’ensemble des jobs associés et pouvoir recycler les volumes).
Sur les serveurs avec un historique de sauvegarde conséquent, il n’est pas rare que la limite par défaut de 2 Go pour le pool du Catalogue finisse par poser problème : ce pool n’autorise qu’un volume qui doit être d’une taille suffisante pour contenir la sauvegarde du catalogue.
Exemple
Il peut être intéressant de conserver un historique long mais avec peu d'états intermédiaires.
Pour cela, voici un exemple de configuration :
- 6 mois de sauvegardes totales ;
- 5 semaines de sauvegardes différentielles ;
- 10 jours de sauvegardes incrémentales.
Avec la politique de sauvegarde suivante :
- une sauvegarde totale par mois ;
- une sauvegarde différentielle par semaine ;
- une sauvegarde incrémentale du lundi au vendredi.
Dans l'historique, il y aura donc une sauvegarde par jour de conservée pendant 10 jours, une sauvegarde par semaine pendant 5 semaines et une sauvegarde mensuelle pendant 6 mois.
Attention
Une modification de la durée de rétention en cours de production n'aura aucun effet sur les sauvegardes déjà effectuées, elles seront conservées et recyclées mais sur la base de l'ancienne valeur, stockée dans la base de données.
Afin de prendre en compte la nouvelle valeur pour les sauvegardes suivantes, il faut utiliser les outils Bareos pour mettre à jour la base de données :
# bconsole
*update
*2
*<numéro du pool de volumes de sauvegarde>
Une autre solution consiste à vider le support de sauvegarde ou prendre un support de sauvegarde ne contenant aucun volume et à ré-initialiser la base de données Bareos avec la commande :
# bareosregen.sh
La regénération du catalogue de bareos va écraser l'ancienne base, confirmez-vous ? [oui/non]
[non] : oui
Paramètres supplémentaires
En mode expert d'autres paramètres sont disponibles.
La durée maximale pour l'exécution complète d'une sauvegarde permet d'annuler le job si il n’est pas terminé avant ce délai, exprimé en secondes, en comptant à partir de l’heure programmée. Par défaut le job est limité à 86 400 secondes soit 24 heures (la valeur 0 lève cette limite de temps).
Plus l'algorithme de compression est efficace, moins il nécessite d'espace mais plus il alourdit la charge système et allonge la durée du processus de sauvegarde. Deux algorithmes de compression sont proposés : GZIP et LZ4.
L'algorithme GZIP[120] permet plusieurs niveaux de compression de 1 à 9. Au delà de 6, le gain en place est faible par rapport aux niveaux immédiatement inférieurs, tandis que la durée de traitement s'allonge sensiblement.
L'algorithme LZ4[121] offre un taux de compression moindre que le niveau de compression 6 de GZIP mais est significativement plus rapide.
Remarque
L’utilisation de l’algorithme de compression LZ4 nécessite que Bareos ait été compilé avec le support de ce dernier. Dans le cas où Bareos n’aurait pas été compilé avec celui-ci, un message d’avertissement est émis au moment de la sauvegarde et aucune compression n’est effectuée. Les modules EOLE en version supérieure ou égale à 2.7.1 bénéficient d’une version de Bareos avec le support de LZ4 activé. Pour les autres clients, l’administrateur système doit s’assurer que ce support est également activé.
Le champ
Mot de passe du directeurcontient le mot de passe à transmettre aux applications distantes pour leur permettre de s'authentifier auprès du directeur.
Configuration du stockage
Le service de stockage gérant l'écriture des volumes de sauvegardes (bareos-sd ) peut être local ou distant, il est local par défaut. Dans ce cas aucun paramètre supplémentaire n'est à configurer dans cet onglet (Directeur Bareos).
Dans le cas d'un serveur de stockage distant (Le gestionnaire du stockage est local à non), il faut configurer le nom, l'adresse IP et le mot de passe du serveur de stockage distant.
Pour autoriser des directeurs à se connecter au présent stockage des paramètres se trouvent dans l'onglet Stockage bareos.
Attention
Certaines infrastructures nécessitent une dégradation des fonctionnalités des modules EOLE comme la désactivation des mises à jour automatiques pour que la sauvegarde distante fonctionne correctement.
Le déport du service bareos-sd sur un autre serveur que bareos-dir ne permet pas de gérer correctement les verrous des tâches d'administration sur ce serveur : bareos-dir ne permet pas de signaler efficacement à bareos-sd qu'une sauvegarde est lancée et qu'il doit poser un verrou empêchant les autres tâches d'administration.
Configuration de la sauvegarde de fichiers distants
Il est possible de déclarer plusieurs clients distants pour gérer la sauvegarde des fichiers d’autres serveurs.
Cette déclaration de clients distants peut être effectuée une fois la variable Activer la sauvegarde de fichiers distants passée à oui.
La déclaration d’un client distant nécessite de fournir plusieurs informations obligatoires.
Identifiant du client distant: identifiant interne unique utilisé pour distinguer la configuration du client, composé de lettres non accentuées et de chiffres ;Nom du client distant: le nom du service bareos-fd tel que renseigné sur le serveur distant l’hébergeant ;Adresse du client distant: l’adresse IP à laquelle ce client peut être joint ;Mot de passe du client distant: le mot de passe, identique à celui déclaré sur le client distant (cf. configuration d’un client indépendant).
Remarque
L’activation du service de lecture/écriture de fichiers (file server, bareos-fd) sur le serveur lui-même pour sauvegarder les fichiers locaux s’effectue dans l’onglet Services.
Onglet Stockage bareos
Dans l'onglet Stockage bareos il est possible de choisir un nom de serveur de stockage et d'autoriser des directeurs distants à se connecter au présent serveur de stockage.
Autoriser un ou plusieurs directeurs distants à se connecter
Pour autoriser un ou plusieurs directeurs distants à se connecter il faut cliquer sur + Nom du directeur Bareos distant, le détail de l'autorisation s'affiche.
Pour ce faire il faut se munir des paramètres du directeur distant :
son nom ;
son adresse IP ;
son mot de passe.
Attention
Les sauvegardes sont des informations sensibles. Il ne faut pas utiliser de mot de passe facilement déductible.
Onglet Client bareos
L'onglet Clients bareos apparaît dans l'interface de configuration du module si la sauvegarde des fichiers locaux est activée (Activer la sauvegarde des fichiers locaux à oui).
L'onglet permet de configurer le nom du serveur de sauvegarde des fichiers locaux.
Le service de lecture/écriture de fichiers (file server, bareos-fd) de Bareos, autrement appelé client, ne nécessite pas de configuration dans le cas où le directeur (service director, bareos-dir) est également activé localement.
Dans le cas où on souhaite que la sauvegarde des fichiers du serveur soit gérée par un directeur distant, il est nécessaire de désactiver le service director local en passant la variable Activer le directeur de sauvegarde à non puis d’activer le service file local en passant la variable Activer la sauvegarde des fichiers locaux à oui, en mode expert, dans l’onglet Services.
À l’issue de cette manipulation, l’onglet Client Bareos est disponible.
Dans l’onglet Client Bareos, le service directeur distant est configuré au moyen de trois variables obligatoires :
l’adresse du directeur Bareos distant ;
le nom du directeur Bareos distant tel qu’il est défini dans la configuration du directeur dans l'onglet
Directeur bareos;le mot de passe distant, identique à celui déclaré dans la configuration du directeur dans l'onglet
Directeur bareos.
Attention
Les services Bareos partagent certaines variables de configuration et il faut veiller à la cohérence des valeurs entrées, notamment pour les noms des services et les mots de passe.
Onglet Authentification : Configuration du proxy authentifié et de FreeRADIUS
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é.
Activer une deuxième instance de Squid
Activer une deuxième instance de Squid permet une double authentification, c'est à dire la possibilité de pouvoir configurer deux types distincts d'authentification proxy.
Par exemple, pouvoir utiliser à la fois une authentification NTLM/SMB et une authentification LDAP.
L'implémentation retenue est d'utiliser une instance du logiciel Squid par type d'authentification.
Pour profiter de cette fonctionnalité, il faut passer Activer une deuxième instance de Squid à oui.
Cela fera apparaître l'onglet Proxy authentifié 2.
En mode expert cela fera apparaître également l'onglet Squid2.
Activer le service FreeRADIUS
Onglet Filtrage web : Configuration du filtrage web
Le module Amon intègre le logiciel libre e2guardian[2] pour réaliser le filtrage web.
Configuration des zones de filtrage
La solution de filtrage permet de différencier 2 zones, ce qui permet de dissocier 2 politiques de filtrage majeures et distinctes comme par exemple une zone réseau administratif et une zone réseau pédagogique.
Il faut choisir à quelle zone appartient une interface. Cela s'effectue dans la configuration de chaque interface réseau en sélectionnant le numéro de la zone souhaité dans le champ Filtre Web à appliquer à cette interface.
Remarque
Les zones Filtre web 1 et Filtre web 2 correspondent chacun à une instance du logiciel de filtrage. La configuration de chacune des instances s'effectue dans l'onglet Filtrage web.
En fonction de la configuration du filtrage effectuée dans l'interface de configuration du module deux sections nommées filtre web peuvent être disponibles dans l'EAD : Filtre web 1 et Filtre web 2.
Le paramétrage par défaut de e2guardian convient à un établissement de taille moyenne sans modification particulière.
Il peut être néanmoins intéressant de modifier ce paramétrage pour satisfaire les besoins de l'établissement (notamment dans le cas où le serveur ne peut plus répondre aux requêtes, la fenêtre d'authentification apparaît de façon intempestive, ...).
Sur un petit établissement, il sera possible d'économiser des ressources.
Sur un gros établissement, il pourra répondre à un plus grand nombre de requêtes.
Un certain nombre de paramétrages sont proposés pour contrôler les ressources de e2guardian.
Exemple
Il est possible d'affecter des politiques spécifiques en fonction de l'utilisation qui est faite des machines :
machines du foyer (politique plus laxiste) ;
machines du CDI (politique moins permissive).
Politiques de filtrage
Une politique de filtrage correspond à un ensemble d'autorisations ou interdictions d'accès à des sites, suivant différents critères.
Il existe 4 politiques prédéfinies :
- une politique « défaut » de filtrage par défaut ;
- une politique « modérateur » (permet d'outrepasser les interdictions) ;
- une politique « interdits » (permet d'interdire toute navigation) ;
- une politique « liste blanche » (navigation limitée aux sites de cette même liste).
Seule la politique de filtrage prédéfinie défaut est modifiable via l'EAD.
En plus de ces politiques, il est possible d'ajouter de 1 à 4 autres politiques de filtrage (il y en a 3 par défaut).
Ces politiques de filtrage additionnelles seront alors paramétrables dans l'EAD.
Les politiques défaut, modérateur, interdits, liste blanche, et 1, 2, 3 et 4 si elles ont été activées, sont visibles dans l'EAD dans le filtrage par machine ou par groupe de machine.
Les politiques 1, 2, 3 et 4 si elles ont été activées, sont visibles dans l'EAD dans les filtres web 1 et/ou 2 dans les rubriques filtrage par bases de filtres optionnels, filtrage syntaxique, interdiction et autorisation des domaines, interdiction des extensions et des types MIME.
Configuration du nombre de politique
Pour modifier le nombre de politiques de filtrage par zone, il faut utiliser le paramètre Nombre de politiques optionnelles de filtrage par zone :
la valeur 0 revient à n'utiliser que les 4 politiques par défaut proposées ci-dessus ;
l'ajout de politiques optionnelles (valeur 1,2,3,4) permet d'ajouter des filtres supplémentaires, associables à des groupes de machines ou des comptes utilisateur.
Attention
Plus vous définissez de politiques, plus e2guardian utilisera de ressources.
Adaptez le nombre de politiques activées en fonction de vos besoins.
L'observatoire des navigations
L'observatoire des navigations est un outil de consultation des logs de l'outil de filtrage e2guardian[2].
La question Autoriser la consultation des logs liés au filtrage web dans l'EAD propose plusieurs options :
oui: accès autorisé pour les utilisateurs EAD possédant les actionsnavigation_visit_adminet/ounavigation_visit_pedago;non: accès interdit pour tout le monde, personne ne voit le lienVisites des sites(configuration par défaut) ;admin seulement: accès autorisé uniquement pour le rôleadmin.
Complément
La consultation des visites de sites se fait au travers de l'EAD, menu : Filtre web X / Visites des sites.
Paramétrage de e2guardian
Le logiciel e2guardian offre de nombreuses options de configuration.
Plusieurs sont paramétrables dans l'interface de configuration du module.
Seule l'expérience «à tâtons»[122] permet de définir des valeurs adaptées à votre installation.
L'objectif est d'utiliser le plus de mémoire possible sans que le serveur n'utilise la partition d'échange (swap[123]) .
Truc & astuce
La commande top en console permet d'observer l'évolution de l'utilisation de la partition d'échange de façon dynamique.
Truc & astuce
Options de configuration communes
Les options de configuration proposées dans la première partie de l'interface de configuration sont communes à toutes les zones configurables :
Proxy Timeout (ex: Doc Body Timeout)
Délai d'attente TCP entre le proxy et e2guardian (en secondes).
Proxy header exchange (ex: Doc Header Timeout)
Délai d'attente entre le proxy et e2guardian (en secondes).
Pconn timeout (ex: Header Timeout)
Délai pendant lequel une connexion persistante attend de nouvelles requêtes (en secondes).
Options de configuration spécifiques à chacune des zones
Les options de configuration proposées dans les sections suivantes permettent de personnaliser la configuration de chacune des zones configurables.
Libellé du filtre web dans l'EAD
Il est possible de personnaliser le nom des zones de filtrages configurées affiché dans l'EAD.
Nombre de processus disponibles pour traiter les connexions
Depuis la version 4 du logiciel e2guardian, l'ensemble des paramètres liés à la gestion des processus a été remplacé par un seul.
Ce paramètre (httpworkers) définit le nombre de processus lancés au démarrage de l'instance de e2guardian.
Si le nombre de connexions dépasse sa valeur, les nouvelles connexions seront placées en file d'attente jusqu'à ce qu'un processus se libère.
Les variables Nombre de processus disponibles pour traiter les connexions permettent de personnaliser sa valeur pour chacune des instance de e2guardian.
Une valeur de 1000 processus convient pour une centaine d'utilisateurs, il est possible d'augmenter le nombre de processus à 5000 pour une structure de taille moyenne, 10000 pour une grosse structure.
La valeur est également dépendante du nombre de règles et de la quantité de mémoire RAM disponible.
Le nombre maximum de processus est limité à 20000.
Répertoire de cache
Permet de choisir le chemin du répertoire de cache, par défaut /var/spool/guardianX.
Remarque
Le script /usr/share/eole/schedule/scripts/purgecache purge les fichiers vieux de plus d'un jour du répertoire de cache de e2guardian.
La taille maximum de fichier conservé en mémoire
Cette variable n'est utilisée que si vous utilisez un greffon d'anti-virus.
C'est la taille maximale des fichiers en kibibytes[125] que e2guardian va télécharger et mettre en cache dans la RAM. Après que cette limite soit atteinte, e2guardian met en cache sur le disque.
Cette valeur doit être inférieure ou égale à la valeur de La taille maximum de fichier conservé sur le disque.
Utiliser la valeur 0 permet de définir le même réglage que La taille maximum de fichier conservé sur le disque.
La taille maximum de fichier conservé sur le disque
Cette variable n'est utilisée que si vous utilisez un greffon d'anti-virus.
C'est la taille maximale des fichiers en kibibytes[125] que e2guardian va télécharger de sorte qu'ils soient vérifiés par l'anti-virus.
Cette valeur doit être supérieure ou égale à La taille maximum de fichier conservé en mémoire.
Limite de pondération du filtrage
La limite de pondération est paramétrable pour chacun des filtres, la valeur par défaut (50) correspond à la valeur qui était appliquée avec le filtrage configuré pour s'appliquer sur les balises méta.
Chaque élément d'une page reçoit un score, la somme est faite et si le score est supérieur à la limite fixée alors la page est bloquée (jeunes enfants : 50, enfants : 100, jeunes adultes : 160).
Options de configuration spécifiques au filtrage associé à la deuxième instance de Squid
Le Filtre web 3 permet de contrôler les ressources de e2guardian lorsqu'une seconde instance de Squid et le filtrage web sont activés.
La variable Port d'écoute pour le 3ème filtre web permet de personnaliser le port du second proxy (3129 par défaut).
Adresse électronique à utiliser en cas de réclamation
Lorsque la consultation d'une page est refusée à l'utilisateur, une page d'erreur affichant les détails de l'interdiction apparaît.
Celle-ci propose également une adresse électronique à utiliser pour signaler les interdictions injustifiées.
Cette adresse se configure par l'intermédiaire de la variable Adresse courriel du cachemaster disponible dans l'onglet Messagerie.
Désactivation du filtrage web
Dans certaines configurations (utilisation d'un proxy académique, ...), il peut s'avérer utile de désactiver complétement le filtrage web.
Cela est possible en allant dans l'interface de configuration du module en mode expert et en répondant non à la question de l'onglet Services, Activer le filtrage sur le proxy.
Attention
Dans cette configuration, le proxy Squid écoute sur le port 3128 en lieu et place du logiciel de filtrage e2guardian.
Onglets Squid et Squid2 : activation du déchiffrement HTTPS
Déchiffrement et interception du protocole HTTPS
Par rapport au protocole HTTP[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.
Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).
En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.
Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.
Certificat Racine de l'autorité de certification
Un certificat HTTPS est émis par une autorité de certification[13].
Let's Encrypt[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.
En revanche, le certificat racine utilisé par Amon pour déchiffrer le protocole HTTPS n'est pas public et il faut donc l'installer sur les postes clients dont le trafic doit être déchiffré et intercepté. La procédure est détaillée plus bas.
AttentionATTENTION AUX LIMITATIONS LÉGALES
Dans la mesure où les connexions sont déchiffrées par le proxy, il convient de prévenir les utilisateurs, en particulier les adultes et le personnel. En effet, la loi reconnaît un droit à la vie privée même sur le lieu de travail : article 9 du Code civil et article L 1121-1 du Code du travail, entre autres.
Dans certains cas, comme par exemple lors des accès aux sites bancaires ou aux sites médicaux, il ne semble pas évident que le déchiffrement HTTPS soit légal.
Mise en œuvre
Deux variables ont été ajoutées dans les onglets Squid et Squid2 :
Activer le déchiffrement HTTPS;Activer le déchiffrement HTTPS sur la seconde instance de Squid.
Ces deux variables permettent d’activer le déchiffrements des flux HTTPS transitant à travers le proxy.
Une fois le déchiffrement des flux HTTPS activé, le proxy a la capacité de connaître l’ensemble des URL consultées par l’utilisateur. Dans les journaux figureront donc les URL complètes et non uniquement les noms de domaines, comme c’est le cas sans le déchiffrement.
Dans ce mode de fonctionnement, le proxy génère un nouveau certificat pour chaque domaine visité et propose celui-ci à l’utilisateur. Tous ces certificats sont signés par une autorité de certification propre au proxy.
Pour que ces certificats soient perçus comme valides par les différentes applications utilisant le proxy, il est nécessaire de diffuser l’autorité de certification propre au proxy auprès de ces applications.
Truc & astuce
Sur un module Amon configuré pour l'interception des communications HTTPS, la commande diagnose permet de connaître le chemin et l'empreinte du certificat :
*** Validité du certificat racine du proxy (/etc/eole/squid_CA.crt)
. signingCA.crt => Ok. Empreinte => SHA256 Fingerprint=62:1B:BF:25:28:44:31:02:7E:09:31:A6:EA:FD:A5:A8:7C:D4:EB:B6:3D:83:88:62:0F:98:85:1A:DC:50:99:E0
Intégration de l’autorité de certification sur distributions Debian et dérivées
Copier le fichier /etc/eole/squid_CA.crt dans le répertoire du client : /usr/local/share/ca-certificates/ et exécuter la commande :
sudo update-ca-certificates
Intégration de l’autorité de certification sur Windows
Copier le fichier /etc/eole/squid_CA.crt sur le poste. Cliquer droit dessus et faire "installer le certificat". Le certificat doit être mis dans le "magasin de certificat" : "Autorités de certification racines de confiance".
Les applications communes comme Edge, Chromium, les mises à jours, ... reconnaîtront ainsi cette autorité.
Intégration de l’autorité de certification dans le magasin du navigateur Firefox
Dans le "gestionnaire de certificats", présent dans l'onglet "Vie privée" des préférences du logiciel, se rendre dans l'onglet "Autorités". Il est alors nécessaire d'importer le fichier /etc/eole/squid_CA.crt disponible sur l'Amon. Lors de l'importation, penser à cocher "Confirmer cette AC pour identifier des sites web".
Remarque
L’intégration du certificat peut être automatisée pour les postes joints à un domaine contrôlé par un module EOLE avec le paquet eole-workstation-manager installé.
Dans ce cas précis, la configuration du module contrôleur de domaine propose l’option Activer la configuration de Firefox qui met en place la procédure de déploiement du certificat sur les postes clients salt.
Pour plus d’informations, se reporter à la documentation des modules AmonEcole et Scribe, onglet Workstation.
Onglet Squid : Configuration du proxy
En mode expert, l'onglet Squid permet de modifier et de fixer une sélection des principaux paramètres du fichier de configuration : /etc/squid/squid.conf.
Les paramètres de ce fichier de configuration se retrouvent explicitement dans le nom des variables Creole (mode Debug de l'interface de configuration du module).
Paramétrer l'analyse de logs LightSquid
Les options Générer les statistiques Squid automatiquement, Port d'écoute du CGI LightSquid et Méthode d’anonymisation des rapports LightSquid servent à configurer l'outil d'analyse de logs LightSquid permettant d'afficher sous forme de pages web l'utilisation du proxy.
Sa configuration fait l'objet d'une section dédiée.
Paramétrer les ports de Squid
Port d'écoute standard
Ports d'écoute HTTPS spécifique
Il est possible de paramétrer Squid pour qu'il écoute les requêtes HTTPS des clients.
Ceci est particulièrement utile dans les situations où Squid est utilisé comme accélérateur des requêtes. Il faut alors saisir le numéro de port choisi dans le champ Port d'écoute HTTPS de Squid.
SSL_ports
Par défaut, seuls les ports de destination (sortants) des connexions SSL 443, 563, 631, 4000-5000, 6080, 8062, 8070, 8090, 8443, 8753 et 7070 sont autorisés.
Il est possible d'en ajouter autant que souhaité dans le champ "SSL_ports" supplémentaire.
Safe_ports
De même, seuls les ports de destination (sortants) non SSL 80, 21, 443, 563, 70, 210, 631 et 1025-65535 sont autorisés.
Il est possible d'en ajouter autant que souhaité dans le champ "Safe_ports" supplémentaire.
Personnaliser la durée des caches
L'option Personnaliser sélectivement la durée des caches permet de personnaliser l'algorithme de gestion du rafraîchissement du cache par site.
La gestion du cache de Squid peut ne pas correspondre à tous les sites. Par exemple, pour les sites antiviraux, il vaut mieux augmenter la durée de conservation du cache des fichiers téléchargés par les postes clients.
Voici un exemple la configuration à mettre en place pour conserver en cache les signatures de l'anti-virus Trend :
Truc & astuce
L'expression rationnelle décrit la chaîne de caractères et les règles qui permettent de construire l'URL :
^ marque le début d'une chaîne ;
$ marque la fin d'une chaîne ;
| marque l'alternative ;
. indique n'importe quel caractère ;
* aucune, une ou plusieurs occurrences du caractère.
Les variables qui permettent de régler le comportement du cache de Squid sont :
Temps maximum de cache;Rapport entre l'âge de l'objet dans le cache et son âge sur le site;Temps minimum de cache.
Exemple
Cette configuration générera la ligne de configuration suivante :
refresh_pattern -i <url_regexp> "Temps maximum de cache" "Rapport entre l'âge de l'objet dans le cache et son âge sur le site" "Temps minimum de cache" <options>
refresh_pattern -i /.*\.trendmicro\.com/.* 180 100% 300 reload-into-ims ignore-reload
L'option -i permet de ne pas tenir compte de la casse des caractères dans l'expression régulière.
Complément
La personnalisation sélective de la durée du cache est basée sur la directive refresh_pattern de Squid. Cette directive permet un contrôle très fin de la validité des objets mis en cache.
Lors d'une requête, Squid décide du comportement à adopter en fonction de l'état de l'objet dans son cache :
si l'objet n'est pas dans le cache, Squid le demande au serveur qui héberge l'objet, le met en cache et le fournit au client ;
si l'objet est dans le cache et qu'il est considéré comme étant encore à jour, Squid le fournit directement au client ;
s'il n'est plus considéré comme à jour, alors une requête
If-modified-sinceest envoyée au serveur qui héberge l'objet.
Pour déterminer si un objet est à jour, Squid utilise plusieurs paramètres :
la valeur liée à l'objet enregistré :
- age correspond au temps en seconde écoulé depuis l'entrée de l'objet dans le cache (objet_age = maintenant - objet_date)
- lm_age correspond à l'age de l'objet au moment de l'entrée dans le cache, temps, en secondes, écoulé entre la dernière modification de l'objet sur le serveur hébergeur et son entrée dans le cache. (lm_age = objet_date - objet_lastmod)
- expires est la date d'expiration de l'objet éventuellement fournie par le serveur hébergeur au moment de l'entrée de l'objet dans le cache. Si elle est renseignée, la valeur de
Temps minimum de cacheprend le pas sur cette valeur.
la valeur fournie par le client ;
Squid tient compte de la variable client_max_age éventuellement fournie par le client, elle indique l'âge maximal de l'objet accepté par le client. Si cette valeur est fournie par le client elle prend le pas sur la valeur
Temps maximum de cachedu fichier de configuration de Squid.les valeurs du fichier de configuration de Squid :
temps écoulé depuis le téléchargement (age), temps maximum et minimum de cache :
- si
Temps maximum de cacheest défini et que le temps écoulé depuis le téléchargement est supérieur, l'objet est périmé et devra être mis à jour ; - si le temps écoulé depuis le téléchargement est inférieur ou égal au
Temps minimum de cache, l'objet est considéré comme étant à jour.
- si
date d'expiration de l'objet fournie par le serveur hébergeur :
- si la date d'expiration de l'objet (expires) est définie par le serveur hébergeur et qu'elle est dépassée, l'objet est périmé et devra être mis à jour ;
- si la date d'expiration de l'objet (expires) est définie par le serveur hébergeur mais qu'elle n'est pas encore dépassée, l'objet est considéré comme étant à jour.
rapport (lm_factor) entre le temps, en secondes, écoulé depuis l'entrée de l'objet dans le cache et son âge au moment de l'entrée dans le cache :
Plus le score du rapport entre le temps écoulé depuis l'entrée de l'objet dans le cache et son âge au moment de l'entrée dans le cache (age/lm_age) est élevé plus l'objet risque d'être périmé :
- peu de temps écoulé (10) / objet vieux (1000) = rapport faible (0.01) → objet probablement à jour
- beaucoup de temps écoulé (1000) / objet vieux (1000) = rapport élevé (1) → objet probablement périmé
- peu de temps écoulé (10) / objet jeune (10) = rapport élevé (1) → objet probablement périmé
- beaucoup de temps écoulé (1000) / objet jeune (10) = ce cas de figure n'arrive pas car géré par des règles en amont.
Si le rapport est inférieur au pourcentage (percent) saisi dans
Rapport entre l'âge de l'objet dans le cache et son âge sur le site, l'objet est considéré comme à jour. Diminuer la valeur du pourcentage diminue la probabilité (rapport faible) qu'un objet soit périmé.
Enfin, si aucune règle n’aboutit à considérer l'objet comme étant à jour, celui-ci est considéré comme périmé et devra être mis à jour.
Augmenter le nombre de redirections
Certains sites ont besoin de faire un grand nombres de redirections avant de fournir le contenu souhaité à l'utilisateur.
Par défaut, Squid n'accepte que 10 redirections (variable forward_max_tries du fichier de configuration de Squid) ce qui peut entraîner l'abandon des redirections et donc bloquer l'accès au site.
Il est possible à partir de la version 2.5.2 d'EOLE d'augmenter cette valeur en modifiant la variable Nombre maximum de redirections testées de l'onglet.
Paramètre Half_closed_clients
Certains clients peuvent arrêter leur connexion TCP d'envoi tout en laissant leur connexion de réception ouverte. Parfois, Squid ne peut pas faire la différence entre une connexion à demi-fermée et une connexion entièrement fermée :
- si le paramètre
Half_closed_clientsest àOn, les connexions demi-fermées sont maintenues ouvertes jusqu'à ce qu'une erreur de lecture ou d'écriture apparaisse ; - si le paramètre
Half_closed_clientsest àOff, les connexions sont fermées dès qu'il n'y a plus de données à lire (valeur recommandée sur Squid >= 3.0).
Historiquement paramétrée à On sur les modules EOLE, sa valeur par défaut a été passée à Off sur les versions d'EOLE >= 2.5.1 depuis avril 2016.
Personnaliser les valeurs de délai d'attente
De nombreuses variables sont disponibles afin de paramétrer finement les valeurs de délai d'attente (timeout) de Squid.
Remarque
À partir d'EOLE 2.6.2, l'unité de temps associée à plusieurs d'entre elles a été transformée de minute en seconde afin de permettre un paramétrage encore plus précis.
Ajustements ICAP
Le protocole ICAP permet de chaîner les traitements sur les requêtes adressées au proxy. Le filtrage de contenu est mis en œuvre en exploitant cette fonctionnalité. Deux variables sont proposées pour adapter le fonctionnement.
La limite d’échec du service ICAP avant de le considérer en erreur définit le nombre de tentatives de connexion infructueuses au service de filtrage de contenu avant abandon. Un nombre négatif désactive la limite et implique que le service de filtrage de contenu n’est jamais considéré en erreur.
Accepter l’accès aux services sans filtrage en cas d’échec du service ICAP définit si une erreur de communication avec le service de filtrage de contenu entraîne le rejet de la requête. En d’autre terme, si le filtrage de contenu est une étape optionnelle de traitement de la requête.
Autres paramètres
L'onglet expert Squid permet de modifier et de fixer un nombre conséquent de paramètres optionnels du fichier de configuration : /etc/squid/squid.conf.
Pour plus d'informations sur la modification de ces paramètres, vous pouvez consulter :
les exemples de configuration dans le fichier de documentation de Squid :
/usr/share/doc/squid-common/squid.conf.documented.gz
la documentation en ligne des différents paramètres : http://www.squid-cache.org/Doc/config/
Onglet Proxy authentifié : 5 méthodes d'authentification
- Authentification NTLM/KERBEROS
- Authentification NTLM/KERBEROS poste hors domaine
- Authentification NTLM/SMB
- Authentification NTLM/SMB poste hors domaine
- Authentification LDAP
- Authentification LDAP (Active Directory)
- Authentification sur Fichier local
- Désactivation de l'authentification sur une interface
- Notes techniques
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[62].
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 NTLM/SMB poste hors domaine
En mode normal, l'authentification NTLM[64] peut être facilitée par l'utilisation d'un proxy. Le proxy NTLM proposé par EOLE utilise le logiciel libre Cntlm[65].
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).
En mode expert il est possible de changer le port d'écoute par défaut du proxy NTLM.
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)
Onglets Squid2 et Proxy authentifié 2 : Double authentification
Par double authentification, nous entendons la possibilité de pouvoir configurer deux types distincts d'authentification proxy.
Par exemple, pouvoir utiliser à la fois une authentification NTLM/SMB et une authentification LDAP.
L'implémentation retenue est d'utiliser une instance du logiciel Squid par type d'authentification.
Configuration pas à pas
1. Activation de la deuxième instance de Squid dans l'onglet Authentification :
2. Configuration du type d'authentification dans l'onglet Proxy authentifié 2 :
Remarque
L'enregistrement au domaine est proposé lors de l'instanciation du module, de ce fait l'authentification NTLM/SMB n'est plus proposée pour une deuxième authentification.
3. Paramétrage de la seconde instance de Squid dans l'onglet expert Squid2
4. Paramétrage du filtrage web associé dans l'onglet expert Filtrage web (section Filtre web 3)
Remarque
Si le filtrage web est activé (Activer le filtrage sur le proxy à non dans l'onglet Services), le port du second proxy (3129 par défaut) est personnalisable dans l'onglet Filtrage web, section Filtre web 3, présenté au pas n°4.
Dans le cas contraire (filtrage web désactivé), la personnalisation de ce port s'effectue dans l'onglet Squid2, présenté au pas n°3.
Notes techniques
Les fichiers de logs spécifiques au second type d'authentification sont les suivants :
-
/var/log/rsyslog/local/squid/squid2.info.log→ 2ème instance de squid /var/log/rsyslog/local/e2guardian/e2guardian2.info.log→ 3ème instance de e2guardian (filtre web 3)
Dans l'état actuel, ces logs ne sont pas consultables au travers de l'interface EAD et seule la première configuration proxy est distribuée par WPAD (voir partie dédiée).
Onglet Cups : Configuration du serveur d'impression
CUPS, pour Common Unix Printing System, est un système modulaire d'impression informatique pour les systèmes d'exploitation Unix et assimilés. Ce serveur d'impression accepte des documents envoyés par des ordinateurs clients, les traite, et les envoie à l'imprimante qui convient.
Le serveur d'impression est activable/désactivable dans l'onglet Services par l'intermédiaire de l'option : Activer le serveur d'impression CUPS.
L'onglet Cups apparaît en mode expert uniquement si le service est activé.
L'onglet expert Cups permet de configurer l'imprimante virtuelle PDF.
Il est possible de désactiver l'imprimante virtuelle PDF, de changer son nom et de ne pas la partager.
L'onglet expert Cups permet de modifier et de fixer une sélection de paramètres disponibles dans le fichier de configuration : /etc/cups/cupsd.conf.
Truc & astuce
Le nom des paramètres en question est utilisé dans le nom des variables Creole. Ils sont généralement préfixés par la chaîne "cups_".
Pour les faire apparaître il faut activer le mode debug de l'interface de configuration du module.
Niveau de log
Le niveau de journalisation est par défaut à warn. Celui-ci peut être modifié afin d'obtenir plus ou moins de verbosité.
Activer la récupération des informations des imprimantes distantes
Indique si oui ou non les imprimantes partagées doivent être annoncés.
Nombre maximum de copies qu'un utilisateur peut effectuer pour un travail d'impression
Indique le nombre maximum de copies qu'un utilisateur peut imprimer de chaque travail.
Nombre maximum de travaux simultanés
Indique le nombre maximum de travaux simultanés supportés.
Nombre maximum de clients simultanés
Indique le nombre maximum de clients simultanés supportés.
Conserver l'historique des demandes d'impression
Indique s'il faut ou non préserver l'historique des demandes d'impression.
Conserver les fichiers après impression
Indique s'il faut ou non conserver les fichiers de travail après leur impression.
Purger automatiquement l'historique des travaux
Indique s'il faut ou non purger automatiquement l'historique des travaux lorsqu'il n'est plus utilisé pour la gestion des quotas.
Générer le fichier printcap
Cette variable permet de générer un fichier printcap.
Le fichier /var/run/cups/printcap contient la configuration pour vos imprimantes. Chaque entrée définit une imprimante, lui donne un nom pour vous et pour les utilisateurs. Vous pouvez avoir plusieurs imprimantes dans ce fichier qui correspondent à la même imprimante physique, mais qui utilisent des fonctionnalités différentes. Il y a au minimum une entrée printcap par imprimante physique présente sur votre système.
Charger le module d'impression d'imprimante sur port parallèle (incompatible avec les conteneurs)
Active / désactive le chargement du module permettant le support d'imprimante parallèle au démarrage du service CUPS.
Complément
Pour plus d'informations, vous pouvez consulter la page de manuel avec la commande man :
# man cupsd.conf
ou en visitant la page suivante :
http://manpages.ubuntu.com/manpages/focal/en/man5/cupsd.conf.5.html
Onglet Exceptions proxy
Dans l'onglet Exceptions proxy de l'interface de configuration du module il est possible d'ajouter des exclusions dans la configuration automatique du proxy.
Il est possible de déclarer différents types d'exceptions.
Exception de proxy pour des domaines de destination
Cette exception commune à ERA et à WPAD permet de déclarer un domaine de destination pour lequel on ne passe pas par le proxy.
Il est possible d'ajouter plusieurs exceptions sur une même interface.
Il est également possible de fournir une liste de noms de domaine ou d'IP à inclure dans les exceptions au proxy depuis une URL, en activant la variable Télécharger et appliquer des exceptions de domaine depuis une URL.
Attention
Si vous utilisez une copie des modèles ERA fournis, il faudra l'adapter pour obtenir les règles supplémentaires
Exception au niveau de l'authentification des domaines de destination
Cette exception permet de déclarer des sites pour lesquels le proxy ne demandera pas l'authentification à l'utilisateur qui souhaite y accéder.
Si cNTLM et WPAD sur activés sur l'interface réseau, les utilisateurs utiliseront directement Squid (sans passer par cNTLM) pour accéder à ces sites.
Remarque
Les domaines commençants par un . sont gérés, le domaine lui-même et les sous-domaines ne sont pas authentifiés.
Exemple
Si on spécifie la valeur .ac-dijon.fr alors ac-dijon.fr et www.ac-dijon.fr seront autorisés sans authentification.
Complément
Une liste de sites à ne pas authentifier par défaut est stockée dans la variable cachée proxy_noauth_auto.
Il est possible de l'afficher dans l'onglet Exceptions proxy de l'interface de configuration du module en activant le mode Debug.
Cette variable reprend la liste des sites qui étaient dans le template domaines_noauth des versions EOLE antérieures à 2.5.2.
Exceptions de proxy pour des IP et adresses réseaux de destination
Cette exception commune à ERA et à WPAD permet de déclarer une adresse IP ou une plage d'adresses IP de destination pour laquelle on ne passe pas par le proxy.
Le bouton Exceptions de type réseau pour l'interface n permet d'ajouter plusieurs exceptions sur une même interface.
Exceptions de proxy pour des IP et adresses réseaux source
Cette exception spécifique à ERA permet de déclarer une adresse IP ou une plage d'adresses IP source pour laquelle on ne passe pas par le proxy.
Le bouton + Exception source de type réseau pour l'interface n permet d'ajouter plusieurs exceptions sur une même interface.
Attention
Cette fonctionnalité permet à une machine de contourner le proxy ce qui constitue un non respect des règles légales de sécurité. Elle peut servir pour effectuer des tests de proxy et d'exceptions de filtrage.
Exception sur un nom d'hôte (spécifique à WPAD)
L'exception sur un nom d'hôte s'effectue sur le nom d'hôte et sur le nom d'hôte complet.
Il faut choisir une interface ou toutes les interfaces sur lesquelles l'exception sera appliquée. Le bouton + Ne pas passer par le proxy pour l'hôte ou le domaine permet d'ajouter plusieurs exceptions sur une même interface.
Ce type d'exception étant spécifique à WPAD, il n'est pas prise en compte par les autres services gérant des exceptions au niveau du proxy.
Exemple
Si le champ Ne pas passer par le proxy pour l'hôte ou le domaine a comme valeur www.ac-monacad.fr, le fichier WPAD.dat généré contiendra la ligne || localHostOrDomainIs(host, "www.ac-monacad.fr") qui permet d'exclure simplement des URLs.
Complément
Compléments sur Ne pas passer par le proxy pour le domaine (dnsDomainIs) :
http://findproxyforurl.com/netscape-documentation/#dnsDomainIs
Compléments sur Ne pas passer par le proxy pour l'hôte ou le domaine (localHostOrDomainIs) :
http://findproxyforurl.com/netscape-documentation/#localHostOrDomainIs
Onglet Proxy parent : Chaînage du proxy
L'onglet expert Proxy parent permet de déclarer un ou plusieurs serveurs proxy à utiliser en amont de celui activé sur le module EOLE.
Cette fonctionnalité est à utiliser dans le cas de la mise en place d'un proxy centralisé au niveau d'une académie ou d'un groupe d'établissements.
Si plusieurs proxy parents sont déclarés, un mécanisme de type round-robin[127] est utilisé afin de répartir la charge sur les différents serveurs.
Attention
Les proxy déclarés ici ne seront pas utilisés par le serveur lui-même.
La déclaration d'un proxy à utiliser par le module EOLE s'effectue dans l'onglet Général en passant la variable : Utiliser un serveur mandataire (proxy) pour accéder à Internet à oui.
Proxy parent global
Le ou les proxy parents peuvent être déclarés de façon globale en passant la variable Utiliser un proxy web parent global à oui.
Si le réseau virtuel privé est actif la variable supplémentaire Accès aux zones RVP en passant par le serveur proxy web parent global est disponible. Elle permet de forcer l'utilisation du proxy web parent pour l'accès aux zones RVP.
Proxy parent par zone
Pour des besoins spécifiques, des proxy parents peuvent être déclarés pour des zones DNS particulières en passant la variable Utiliser un proxy web parent par zone à oui.
Les zones DNS de destination peuvent être :
- soit renseignées directement dans la variable
Nom DNS ou nom de fichier de la zone accessible via ce serveur web parentsi laMéthode d'utilisation de la zone accessible via ce serveur web parentestDNS; - soit renseignées dans un fichier texte dont le chemin est à indiquer dans la variable
Nom DNS ou nom de fichier de la zone accessible via ce serveur web parentsi laMéthode d'utilisation de la zone accessible via ce serveur web parentestnom fichier;
Truc & astuce
Pour que ces sous-domaines soient également pris en compte, le nom DNS du domaine doit impérativement être précédé d'un point.
Il est possible de renseigner directement plusieurs zones DNS en les séparant par des espaces, exemple : .domain1 .domain2 .domain3.
Coopération des caches
Si on a plusieurs proxy cache, il peut être intéressant de les faire collaborer pour partager le cache.
Cela se fait via le mécanisme de proxy sibling[128].
Onglet Wpad : découverte automatique du proxy
WPAD est mis à disposition sur les modules Amon et AmonEcole au travers du paquet eole-wpad.
Sur un module personnalisé, il n'est fonctionnel que si le paquet eole-proxy est installé.
Pour fonctionner correctement, il faut que l'URL wpad.<nom_domaine_local> correspondre à l'adresse IP du serveur web.
Le support de WPAD doit être activé et correctement configuré sur le module Amon.
Dans l'onglet Services de l'interface de configuration du module Activer le support de WPAD doit être placé à oui.
Cela rend disponible l'onglet Wpad au sein duquel le Nom de domaine du service WPAD doit être rempli avec la même valeur que le Nom de domaine privé du réseau local présent dans l'onglet Général.
Attention
Si vous souhaitez utiliser un autre nom de domaine qui ne correspondrait pas au Nom de domaine privé du réseau local de l'onglet Général, il faut le déclarer dans le champ Nom domaine local supplémentaire ou rien de l'onglet Zones-dns.
Attention
Pour être pris en compte, les changements doivent être enregistrés et suivis de la commande reconfigure sur le module.
Truc & astuce
WPAD supporte les VLAN et les alias, Nginx renvoie le bon fichier WPAD si des VLAN ou des alias sont déclarés.
En mode expert, Il est également possible de changer le port du proxy diffusé par défaut pour une interface, un VLAN ou un alias donné.
Onglet Gpo
Les GPO additionnelles permettent de paramétrer des GPO à appliquer à l'ensemble du domaine. On peut forcer l'utilisation d'un proxy pour tous les postes clients.
Onglet Nginx
L'onglet Nginx est disponible si au moins l'un des deux paramètres suivants est activé dans l'onglet Services :
Activer la publication d’applications web par Nginx;Activer le reverse proxy Nginx.
Nom de domaine par défaut
En mode normal, cet onglet permet de saisir le Nom de domaine par défaut vers lequel sera redirigé un client qui accède au serveur avec un nom de domaine non déclaré.
Restriction Nginx
À partir d'EOLE 2.8.1, la variable : Appliquer des restrictions pour les ports Nginx permet de restreindre l'accès aux ports ouverts pour Nginx aux adresses autorisées à administrer le serveur.
Remarque
Des restrictions supplémentaires au niveau des connexions SSH sont disponibles dans le bloc Administration à distance de l'onglet Interface-0.
En mode expert, la configuration du service peut être affinée.
Dégrader la sécurité en HTTP
Il est possible de dégrader la sécurité du service Nginx en désactivant l'utilisation du HTTPS.
Remarque
Si le protocole HTTPS est désactivé, certaines applications critiques publiées par Nginx telles que l'outil d'administration EAD3 ou l'interface de configuration du module ne seront plus disponibles.
Longueur maximum pour un nom de domaine
Sur une installation recevant de très nombreuses connexions, diminuer la valeur de la Longueur maximum pour un nom de domaine (server_names_hash_bucket_size) pourra améliorer les performances du proxy inverse. La valeur optimale varie d'une installation à l'autre.
Attention
Avec une valeur trop basse, le service Nginx refusera de démarrer et affichera un message d'erreur ressemblant à :
could not build the server_names_hash, you should increase server_names_hash_bucket_size: 32
Nginx Optimization : http://nginx.org/en/docs/http/server_names.html#optimization
Taille maximale des données reçues par la méthode POST
L'option Taille maximale des données reçues par la méthode POST (en Mo) permet de spécifier la taille des données HTTP au delà de laquelle Nginx renverra une erreur (message : Request Entity Too Large).
Remarque
Sur les versions antérieures à 2.6.2, cette variable était située dans l'onglet Reverse Proxy.
Dans le cas où, sur un module, le service eole-web est installé en plus du service eole-reverseproxy (ce qui est le cas sur les modules AmonEcole), le paramétrage de cette option s'effectue dans l'onglet Apache. Sa valeur est alors utilisée à la fois pour le serveur web Apache et pour le proxy inverse Nginx.
Onglet Applications web nginx
L'onglet Applications web nginx n'est visible qu'après activation de l'une des applications utilisant ce service (interface de configuration du module, interface d'administration du module…) dans l'onglet Services en mode expert. Dans cet onglet Activer la publication d'applications web par Nginx doit également être à oui ce qui est le cas par défaut.
Le chemin d'accès aux applications activées est personnalisable.
Onglet Reverse proxy : Configuration du proxy inverse
EOLE propose un serveur proxy inverse (reverse proxy) basé sur le logiciel libre Nginx[23].
Le proxy inverse est un type de serveur proxy, habituellement placé en frontal de serveurs web, qui permet de relayer des requêtes web provenant de l'extérieur vers les serveurs internes (situés en DMZ[25] par exemple). Cela le différencie grandement d'un proxy classique comme Squid[1].
Concrètement, le proxy inverse permet d'ouvrir des services web installés sur des serveurs situées "derrière" le pare-feu l'accès sur Internet sans avoir recours à des règles iptables[67]/DNAT.
Le proxy inverse EOLE peut relayer des requêtes vers les services suivants :
Avant toute chose, le proxy inverse doit être activé dans l'onglet Services en passant Activer le reverse proxy Nginx à oui.
L'activation du service fait apparaître un nouvel onglet.
Redirection de services particuliers
Pour un fonctionnement optimal des applications web hébergées sur le module AmonEcole, il est impératif d'utiliser un nom de domaine[69] (exemple : monetab.ac-acad.fr) résolvable sur Internet et de le renseigner partout où cela est nécessaire.
Ce nom de domaine sera à utiliser tant depuis l'extérieur de l'établissement que depuis l'intérieur.
La configuration recommandée est donc la suivante :
-
Services: Activer le reverse proxy Nginx :oui; Firewall: Modèle de filtrage :2-zones-amonecole;Applications web: Nom de domaine des applications web (sans http://) :etab.ac-acad.fr;Eole sso: Nom de domaine du serveur d'authentification SSO :etab.ac-acad.fr;Nginx: Nom de domaine par défaut :etab.ac-acad.fr;Reverse proxy: Activer la configuration automatique pour les applications locales :oui.
Le paramètre Activer la configuration automatique pour les applications locales configure automatiquement l'accès aux applications web activées localement sur le module AmonEcole.
Redirection HTTP et HTTPS
Pour rediriger HTTP et HTTPS il est nécessaire de passer la variable Activer le reverse proxy Nginx pour le http/https à oui et de renseigner plus d'informations :
le
Nom de domaine ou IP à rediriger: le nom de domaine diffusé auprès des utilisateurs. Ce nom de domaine est celui qui permet d'accéder au module Amon ou AmonEcole ;Activer la redirection pour tous les sous-domaines: cette variable est disponible à partir de la version 2.6.2 d'EOLE, elle permet la prise en charge de tous les sous-domaines par le proxy inverse ;Demander un certificat à Let's Encrypt pour ce domaine ?: cette variable est disponible à partir de la version 2.6.2 d'EOLE si la redirection pour tous les sous-domaines n'est pas activé et que le certificat SSL est Let's Encrypt ;le
Répertoire ou nom de la page à redirigerpermet de rediriger un sous-répertoire vers une machine. La valeur par défaut est/;l'
IP ou domaine de destination (avec http:// ou https://) ou URI complètepermet de saisir l'adresse IP (exemple :http://192.168.10.1), le nom de domaine (exemple :http://scribe.monetab.fr) ou l'URI[70] (exemple :http://scribe.monetab.fr/webmail/) du serveur de destination hébergeant la ou les applications.
Il est possible de forcer l'utilisation du protocole HTTPS pour les requêtes utilisant le protocole HTTP de façon transparente. De cette manière, un utilisateur web se connectant à l'adresse http://monetab.fr sera automatiquement redirigé vers https://monetab.fr
Ainsi les communications sont automatiquement chiffrées protégeant la transmission de données sensibles (nom d'utilisateur, mot de passe, etc.).
Le proxy inverse peut être utilisé pour ne rediriger que le HTTPS en passant les valeurs Reverse proxy HTTP à non et Reverse proxy HTTPS à oui.
Il est possible d'ajouter plusieurs redirections en cliquant sur le bouton + Nom de domaine ou IP à rediriger.
Truc & astuce
Un répertoire déterminé peut également être redirigé vers un serveur différent. Par exemple le lien vers l'application Pronote[71], https://monetab.fr/pronote/ peut être redirigé vers http://pronote.monetab.fr/ (attention, le "/" final est important, puisqu'il faut rediriger à la racine du serveur de destination).
Réécriture d'URL
L'activation de la réécriture d'URL permet d'ajouter une expression rationnelle et une valeur de remplacement.
Il n'y a pas de lien automatique entre une "redirection" Nginx renseignée et une réécriture d'URL.
Pour que la réécriture d'URL s'applique à une règle il faut que le nom de domaine, le protocole et le répertoire de la réécriture correspondent aux paramètres saisis dans la règle de "redirection" renseignée.
Redirection de domaines
Le reverse proxy permet de rediriger automatiquement les utilisateurs voulant accéder à une page particulière vers une autre page.
L'exemple ci-dessus illustre le remplacement de SquirrelMail par Roundcube : si l'utilisateur cherche à accéder à l'adresse http://etb1.ac-test.fr/squirrelmail/, la page se recharge automatiquement avec l'URL de la nouvelle messagerie : http://etb1.ac-test.fr/roundcube/.
Onglet Proftpd : Configuration du serveur FTP
Le serveur FTP est activable/désactivable dans l'onglet Services par l'intermédiaire de l'option Activer l'accès FTP. Le serveur FTP est basé sur le logiciel libre ProFTPD.
L'onglet Proftpd n'apparaît en mode expert que si le service est activé.
Paramétrage du serveur ProFTPD
Nom du serveur FTP
Ce paramètre permet de personnaliser le nom du serveur FTP. Ce nom apparaît lorsqu'on se connecte en FTP sur le serveur avec un client ou en ligne de commande.
Activer le chiffrement TLS
Passer cette option à oui permet d'activer le chiffrement TLS mais son utilisation est déconseillée car les échanges réalisés avec du FTP sécurisé ne passent pas ou passent difficilement les pare-feux.
Activer l'accès anonyme
L'accès anonyme permet d'ouvrir l'accès en anonyme sur le répertoire de votre choix.
Si la variable est passée à oui une nouvelle variable Chemin du répertoire anonyme s'affiche, sa valeur est un chemin absolu. Ce répertoire doit être créé manuellement s'il n'existe pas. L'utilisateur anonymous peut télécharger depuis le répertoire spécifié, il n'a pas par défaut les droits d'écriture.
Le fichier de configuration contient la directive <Limit WRITE> :
<Limit WRITE>
DenyAll
</Limit>
Activer des accès FTP supplémentaires
L'accès FTP supplémentaire permet d'ouvrir l'accès à des comptes existants sur le répertoire de votre choix.
Si la variable est passée à oui une nouvelle variable Chemin du répertoire FTP supplémentaire s'affiche, sa valeur est un chemin absolu. Ce répertoire doit être créé manuellement s'il n'existe pas et les droits doivent être ajustés. Les utilisateurs du module peuvent lire et écrire dans le répertoire spécifié.
Autoriser CAS en accès FTP
Cette option doit être activée pour l'utilisation de l'application Pydio sur le serveur.
Nombre maximum d'utilisateurs simultanés
Par défaut à 50 cette variable permet d'ajuster le nombre d'utilisateurs simultanés autorisés à se connecter en FTP.
Nombre maximum de processus pour ProFTPD
Par défaut à 40 cette variable permet d'ajuster le nombre maximum de processus simultanés du logiciel ProFTPD.
Taille maximum du fichier récupéré (download) en Mb
Par défaut à 500 cette variable permet d'ajuster la taille maximum des fichiers pouvant être téléchargés.
Taille maximum du fichier déposé (upload) en Mb
Par défaut à 100 cette variable permet d'ajuster la taille maximum des fichiers pouvant être déposés.
Temps maximum d'inactivité avant déconnexion (en secondes)
Par défaut à 1200 secondes (20 minutes) cette variable permet d'ajuster le temps d'inactivité avant déconnexion.
Accès FTP
Une fois l'accès FTP activé, il est possible d'accéder au service avec un client FTP (Filezilla, gFTP), par un navigateur web ou avec une application web FTP ( Pydio, anciennement Ajaxplorer, sur le module Scribe).
Accès par un navigateur web
Pour accéder aux documents avec un navigateur web il faut préciser le protocole dans l'URL :
ftp://user@<adresse_serveur>/
ou
ftp://<adresse_serveur>/
Accès par une application web
Pour accéder aux fichiers par l'application web Pydio, il faut l'activer dans l'onglet Applications web. Pydio (anciennement Ajaxplorer) n'est pas pré-installé sur le module Horus (il s'installe avec la commande apt-eole, voir la documentation sur les applications web). Suite à une reconfiguration du serveur, l'application sera accessible à l'adresse http://<adresse_serveur>/pydio/ moyennant l'authentification (mire EoleSSO).
Attention
Avec un client FTP (en mode passif par défaut) le mode actif doit impérativement être configuré. Dans ce mode c'est le client FTP qui détermine le port de connexion à utiliser.
Interdire l'accès FTP à des comptes utilisateur
Le fichier /etc/ftpusers contient une liste des utilisateurs qui ne doivent pas se connecter via le service FTP. Ce fichier est utilisé non seulement pour l'administration système mais également pour augmenter la sécurité du réseau. Il contient typiquement la liste des utilisateurs qui, soit n'ont rien à faire avec le transfert FTP, soit ont trop de privilèges pour être autorisés à se connecter au serveur. De tels utilisateurs sont en général root, daemon, bin, uucp et news.
La liste du fichier /etc/ftpusers peut être complétée avec des utilisateurs systèmes ou LDAP dont il faut désactiver l'accès au service FTP.
Attention
Attention lors des accès FTP, le mot de passe transite en clair sur le réseau.
Anti-virus ClamAV
Si l'anti-virus ClamAV est activé, la recherche de virus en temps réel sur le FTP est activé par défaut. Il est possible de désactiver cette option dans l'onglet Clamav en passant Activer l'anti-virus temps réel sur FTP à non.
Accès au dossier personnel des élèves par FTP
Sur les modules Scribe et AmonEcole, les professeurs n'ont, par défaut, pas accès au dossier personnel de leurs élèves par l'intermédiaire du protocole FTP.
Cette restriction peut être levée en répondant oui à la question Activer l'accès aux dossiers personnels des élèves pour les professeurs. Cette option diminue légèrement la sécurité du serveur.
Onglet Freeradius : Configuration de l'authentification Radius
Proxy RADIUS
L'activation du proxy RADIUS permet de relayer les requêtes d'authentification vers un autre serveur RADIUS.
Le paramétrage fin du serveur proxy RADIUS n'est pas implémenté. La configuration est celle proposée par défaut dans le logiciel.
Requêtes d'authentification
Certains attributs externes comme le nom d'utilisateur doivent parfois être copiés dans la requête de d'authentification de tunnel ainsi que dans la réponse.
Les variables suivantes permettent d'activer ou non la copie des attributs externes dans la requête.
Modes de fonctionnement
Il est possible de choisir entre 2 modes d'utilisation de FreeRADIUS :
802.1x ;
accounting.
Le mode 802.1x
Numéro de l'interface sur laquelle FreeRADIUS écoutera : définition de l'interface d'écoute de FreeRADIUS.
Configuration des NAS
Adresse IP du serveur d'accès (NAS) : adresse IP du switch.
Nom court du serveur d'accès (NAS) : libellé du switch.
Secret partagé avec le serveur d'accès (NAS) : secret partagé entre FreeRADIUS et le switch.
Type du serveur d'accès (NAS) : type de switch.
Configuration LDAP
Authentifier les comptes utilisateurs sur un annuaire LDAP : L'authentification LDAP permet de s'assurer que l'utilisateur est autorisé à accéder aux réseaux. Mais si on gère une flotte de machine, l'authentification par clé TLS peut être jugée comme suffisante. Pour désactiver l'authentification LDAP, sélectionner non.
Adresse IP du serveur LDAP permettant de récupérer les comptes utilisateurs : adresse IP LDAP.
Suffixe racine de l'annuaire LDAP (base DN) : ou=education,o=gouv,c=fr par exemple.
Configuration des groupes et des VLAN
Groupe d'utilisateurs à récupérer dans l'annuaire LDAP : saisir ou choisir un groupe existant dans l'annuaire.
Numéro de VLAN à attribuer à ce groupe : les machines se connectant avec un utilisateur appartenant au groupe indiqué ci-dessus verra son port marqué avec ce numéro de VLAN.
Le mode accounting
Le mode accounting permet de créer un réseau Wi-Fi WPA enterprise sur une borne Wi-Fi (NAS) ayant pour identifiants autorisés les compte/motDePasse de l'annuaire LDAP déclaré.
Adresse IP sur laquelle FreeRADIUS écoutera : l'adresse IP d'une des interfaces du serveur.
Configuration des NAS
Adresse IP du serveur d'accès (NAS) : adresse IP de la borne Wi-Fi.
Masque de sous réseau (notation CIDR) du serveur d'accès (NAS) : 24 (en notation CIDR[74]) si le réseau est de classe C.
Nom court du serveur d'accès (NAS) : libellé de la borne Wi-Fi.
Secret partagé avec le serveur d'accès (NAS) : secret partagé entre FreeRADIUS et la borne Wi-Fi.
Type du serveur d'accès (NAS) : type de borne (other en général).
Configuration LDAP
Authentifier les comptes utilisateurs sur un annuaire LDAP : L'authentification LDAP permet de s'assurer que l'utilisateur est autorisé à accéder aux réseaux. Mais si on gère une flotte de machine, l'authentification par clé TLS peut être jugée comme suffisante. Pour désactiver l'authentification LDAP, sélectionner non.
Adresse IP du serveur LDAP permettant de récupérer les comptes utilisateurs : adresse IP ldap.
Suffixe racine de l'annuaire LDAP (base DN) : ou=education,o=gouv,c=fr par exemple.
Clé d'accès reader à la base ldap sur Scribe (/root/.reader) : à récupérer sur le serveur LDAP.
Truc & astuce
Pour tester la connexion à Freeradius en mode accounting il est possible d'utiliser la commande radtest :
root@amon:~# radtest -x admin <mdp admin> <Adresse IP sur laquelle FreeRADIUS écoute> <port d'écoute du NAS> <Secret partagé avec le serveur d'accès>
ou encore
root@amon:~# radtest -x admin <mdp admin> $(CreoleGet "freerad_listen_addr") <port d'écoute du NAS> $(CreoleGet "freerad_nas_passwd")
Les journaux systèmes sont disponibles dans /var/log/rsyslog/local/freeradius/ :
root@amon:/usr/share/eole/creole# tail -f /var/log/rsyslog/local/freeradius/freeradius.notice.log 2017-06-09T16:49:36.420151+02:00 amon.etb1.lan freeradius[32240]: Login OK: [admin] (from client other port 10)2017-06-09T16:49:57.807213+02:00 amon.etb1.lan freeradius[32240]: Login OK: [admin] (from client other port 10)
Choix du protocole d'authentification
FreeRADIUS supporte plusieurs versions du protocole EAP (Extensible Authentication Protocol) :
MD5
La version historique et la plus basique est la version MD5[75].
Le client est authentifié par le serveur qui utilise une authentification défi réponse. Une valeur aléatoire constituant le défi est envoyée au client, qui concatène à ce défi le mot de passe et en calcule, en utilisant l'algorithme MD5, le hash, une empreinte qu'il renvoie au serveur. Le serveur calcule sa propre empreinte connaissant le mot de passe, puis il compare les deux et valide ou non l'authentification.
La sécurité de cette version est faible. En cas d'écoute du trafic, il est possible de retrouver le mot de passe via force brute.
EAP-TLS
La version EAP-TLS[15] permet d'avoir un trafic chiffré entre le client et le serveur mais permet aussi, d'identifier le certificat présent sur le poste client.
Le serveur et le client possèdent chacun leur certificat qui va servir à les authentifier mutuellement, dans un fonctionnement similaire au protocole https.
Pour activer EAP-TLS, sélectionner tls dans la variable Type de protocole d'authentification.
RemarqueVersion TLS
La version TLS 1.1 est désactivée au profit de la version 1.2 !
AttentionMD5
Ce mode n'est plus considéré comme sécurisé et ne permet pas d'identifier le poste.
Onglet Synchronisation aaf
Permet de placer des quotas d'espace sur les comptes importé d'une base aaf.
Configuration des quotas sur les nouveaux compte importé
Écran
- 1
activation des options d'importation
La valeur est à non par défaut son passage à oui ouvre la partie inférieur pour le paramétrage des variables
- 2
Quotas "soft" des élèves
La variables
aaf_quotas_studentpermet d'indiquer la limite douce d'utilisation d'espace disque de l'utilisateur élèves, lorsque l'utilisateur atteindra cette valeur une alerte pourra être remonté pour avertir l'administrateur et l’utilisateur - 3
Quotas "hard" des élèves
La variables
aaf_quotas_hard_studentpermet d'indiquer la limite dur d'utilisation d'espace disque de l'utilisateur élèves, valeurs qu'il ne pourra pas dépasser. - 4
Quotas "soft" des enseignants
La variables
aaf_quotas_teacherpermet d'indiquer la limite douce d'utilisation d'espace disque de l'utilisateur enseignant, lorsque l'utilisateur atteindra cette valeur une alerte pourra être remonté pour avertir l'administrateur et l’utilisateur - 5
Quotas "hard" des enseignants
La variables
aaf_quotas_hard_teacherpermet d'indiquer la limite dur d'utilisation d'espace disque de l'utilisateur enseignant, valeurs qu'il ne pourra pas dépasser. - 6
Quotas "soft" des administratifs
La variables
aaf_quotas_administrativepermet d'indiquer la limite douce d'utilisation d'espace disque de l'utilisateur administratif, lorsque l'utilisateur atteindra cette valeur une alerte pourra être remonté pour avertir l'administrateur et l’utilisateur - 7
Quotas "hard" des administratifss
La variables
aaf_quotas_hard_administrativepermet d'indiquer la limite dur d'utilisation d'espace disque de l'utilisateur administratif, valeurs qu'il ne pourra pas dépasser.
Les différentes variables :
les variables concerne trois type d'utilisateurs :
etudiantenseignantadministratif
Pour chacun de ces utilisateur il y a deux quotas, un "doux" et un "bloquant".
Le quotas "doux" renvoi une alerte lorsqu'il est atteint, le quotas "bloquant" interdit à l'utilisateur de rajouter de la donnée sur son espace à la limite fixé. Si la limite "bloquante" est à 200Mo, l'utilisateur ne pourra jamais dépassé 200 Mo de donnée sur son espace.
Onglet Eoleflask
Dans cet onglet se trouvent les options concernant le service Eoleflask et les options des applications reposant sur ce service.
Passer la variable En écoute depuis l'extérieur à oui permet d'accéder à l'interface de configuration du module depuis un poste client.
Truc & astuce
Pour autoriser l'accès distant depuis une ou plusieurs adresses IP, il faut le déclarer explicitement dans l'onglet Interface-n de l'interface de configuration du module en passant la variable Autoriser les connexions SSH à oui.
Serveur d'applications
Remarque
L'installation d'une application utilisant Eoleflask (EOP par exemple) active automatiquement le service eoleapps.
Activer manuellement le service eoleapps permet de mettre à disposition vos propres applications le service Eoleflask.
Onglet Envole
L'onglet Envole est disponible par défaut sur les modules Scribe (>=2.8.1) et AmonEcole.
Écran
- 1 Activation de Posh Profil
Variable :
activer_poshprofilActiver ou non la synchronisation entre les service web Envole et eole-db.
- 2 Affecter par défaut les nouvelles applications au profil
Variable :
poshprofil_newitemAccorde un accès par défaut pour tout le monde à l'applicatif Envole eportail.
- 3 Type de synchronisation
Variable :
poshprofil_typesynchroIdentifie le type d'annuaire qui sera utilisé.
- 4 Ajouter un uid de type administrateur envole
Variable :
activer_addadminAjouter un second administrateur.
- 5 UID de votre second administrateur envole
Variable :
uid_addadminIdentifiant du second administrateur.
- 6 Alias apache pour posh-profil
Variable :
alias_poshprofilAlias à utiliser pour les connexions à Posh-Profil.
Affecter par défaut les nouvelles applications au profil
Cette option permet d'affecter les applications à de nouveaux profils.
Deux possibilités :
Tout le monde ;
Administrateur.
En choisissant Tout le monde, tous les utilisateurs auront accès aux applications par défaut. Par conséquent, une fois un nouvel utilisateur créé celui-ci aura accès aux applications sans nécessiter d'action supplémentaire.
En choisissant Administrateur, cette fonctionnalité est limitée aux seuls profils administrateur. Pour les autres utilisateurs il faudra effectuer des actions pour chaque application.
Type de synchronisation
Deux types de bases sont prévus par EOLE.
En choisissant la base ENT vous indiquez l’utilisation d'une base type Scribe. Base par défaut du module Scribe gérée via l'EAD.
En choisissant la base annuaire vous spécifiez l'utilisation d'une base différente de la base par défaut de Scribe, de type annuaire. (correspond à une base PIA par exemple)
Ajouter un uid de type administrateur envole
Il est possible de donner à une tierce personne un compte administrateur sur l'ensemble d'Envole.
Pour se faire il suffit de sélectionner oui, puis de saisir l'identifiant dans la nouvelle variable.
Exemplenouvelle variable : uid_addadmin
Alias apache pour posh-profil
Cette variable ne doit être modifiée que dans le cas où il y aurait au moins deux bases différentes utilisées par des applications situées au même endroit.
L'alias permet aux applicatifs et au proxy inverse de savoir à quelle base de données s'adresser.
Dans le cas où il n'y a qu'une seule base de données, il est préférable de ne pas modifier cette variable.
ExempleExemple de cas d'usage ou la variable externe est nécessaire.
Dans le cas où il y aurait plusieurs bases de données auxquelles se connecter, se situant toutes dans un même domaine (ou sous-domaine), derrière un HAProxy.
Attention
En cas de modification de la variable, bien reporter celle-ci dans les applications le nécessitant.
Onglet Posh-profile : configuration
Qu'est-ce que c'est ?
Posh-profile permet la synchronisation des comptes utilisateurs entre les différentes applications web Eole et la base utilisateur Eole-db. Exemple d'application web : eole-nextcloud
Valeur par défaut
Fonctionnement courant.
En laissant la valeurs sur default dans gen_config les informations de configuration de l'onglet eole-db seront automatiquement reprise. Il s'agit de la configuration la plus répandu correspondant à la majorité des cas.
Écran
- 1
Variable EOLE : <poshprofil_db_mode>
Emplacement de la base de donnée utilisé par Posh-profile.
Valeurs : <externe>
Écran
- 1
Variable EOLE : <poshprofil_db_mode>
Emplacement de la base de donnée utilisé par Posh-profile.
- 2
Variable EOLE : <poshprofil_dbserver>
Adresse du serveur de base de données.
- 3
Variable EOLE : <poshprofil_dbport>
Port d'accès à la base de donnée distante, par défaut 3306.
- 4
Variable EOLE : <poshprofil_allow_hosts>
Identification des hôtes autorisé à accéder à la base de donnée.
- 5
Variable EOLE : <poshprofil_db_mode>
Identifiant de l'utilisateur à utiliser sur la base de donnée.
- 6
Variable EOLE : <poshprofil_dbpass>
Emplacement du fichier de mot de passe de la base de donnée, exemple :
/root/.mysql
Plusieurs base de données.
Dans le cas ou il y aurait plusieurs bases de données auxquelles se connecter, il est nécessaire de sélectionner la variable "externe".
Indiquer l'emplacement de la base de donnée.
Renseigner l'adresse de la base de donnée. Attention dans le cas ou ces bases de données ce trouvent dans le même domaine, il sera nécessaire de leur donner différents Alias afin de les distinguer.
Remplir avec le port renseigné pour la base de donnée EoleDB distante. (par défaut
3306)Indiquer Tous les hôtes autoriser à ce connecter à la base de données distantes. Lors de la première connexion ils seront ajouté dans la base et autorisé à communiquer avec celle-ci.
Renseigner l'identifiant de l'utilisateur permettant l'accès à la base de données.
Emplacement du fichier de mot de passe de la base de donnée, couramment :
/root/.mysql
ExempleExemple de cas d'usage où la variable externe est nécessaire.
Dans ce cas il est nécessaire de changer la variable pour Appli_WEB4 qui utilise une autre base de données eole-db.
Base de type local
Écran
Truc & astuce
Dans le cas ou vous avez plusieurs applications web mais que certaines ne doivent pas avoir accès à la base EoleDB locale, vous avez la possibilité de les spécifier dans l'option Hôtes autorisés à utiliser la base de données.
Onglet Sonde statistique
L’onglet Sonde statistique permet d’activer et de configurer la récolte de renseignements sur l’utilisation des applications web du portail Envole.
Il est possible de récolter ces informations localement ou bien de configurer une remontée des informations sur des serveurs nationaux si un partenariat a été préalablement établi avec le Ministère.
Écran
- 1
Activer la connexion au serveur de statistiques local
Permet d’afficher les paramètres nécessaires à l’utilisation du serveur de statistiques local et active ce dernier.
- 2
Activer Sonde DNMA
Permet d’afficher les paramètres nécessaires à l’utilisation des sondes DNMA en partenariat avec le Ministère.
Ce mécanisme nécessite la mise en place du partenariat au préalable.
Serveur de statistiques local
Le passage de la variable Activer la connexion au serveur de statistiques local permet de renseigner les paramètres de connexion au serveur local.
Serveur de statistiques national
Il est possible, si un partenariat a été conclu avec le Ministère, de faire remonter les informations d’utilisation du portail sur un serveur national via le Dispositif National de Mesure d'Audience[130].
Écran
- 1
Ancien Code Projet DNMA
Code projet défini dans le cadre du partenariat avec le Ministère, n'est plus utile, ce code servait pour la version V1 de la sonde DNMA qui est à présent en V2.
- 2
Code Projet DNMA
Code projet défini dans le cadre du partenariat avec le Ministère.
- 3
Code Collectivité DNMA
Code collectivité défini dans le cadre du partenariat avec le Ministère.
- 4
Code Etab UIA DNMA
Code établissement défini dans le cadre du partenariat avec le Ministère.
Informations d’identifications associées aux remontées statistiques
Le passage de la variable Activer la connexion au serveur de statistiques local permet de renseigner les paramètres de connexion au serveur local.
Écran
- 1
Adresse postale
Adresse postale de l’établissement
- 2
Code postal
Code postal de l’établissement
- 3
Ville
Ville de l’établissement
- 4
Pays
Pays de l’établissement
- 5
Type de serveur
Type du serveur parmi les choix suivants :
- école
- collège
- lycée
- supérieur
- autre_etab
- rectorat
- dsden
- entreprise
- autre
- 6
Nature de serveur
Rôle du serveur dans l’infrastructure, parmi les choix suivants :
- production
- recette
- développement
- 7
Fonction du serveur
La finalité du portail, parmi les choix suivants :
- ENT
- PIA
Onglet Roundcube
Comme toutes les applications web utilisant le gestionnaire de bases de données EoleDB l'application web Roundcube a son propre onglet permettant de configurer l'un des 3 modes de gestion de la base de données :
mode default : l'application utilise la configuration globale d'EoleDB ;
mode local : l'application force l'utilisation d'un serveur de base de données local ;
mode externe : l'application force l'utilisation d'un serveur de base de données et définit complètement la configuration.
Mode default
Dans le mode default, mode par défaut sur le module, l'application ne prend aucune liberté et sa configuration repose exclusivement sur la configuration d'EoleDB indiquée dans l'onglet Eoledb de l'interface de configuration du module.
Mode local
Dans le mode local, la configuration de l'application force l'utilisation d'un serveur de base de données local. Le champ Hôtes autorisés à utiliser la base de données permet de renseigner des hôtes distants car localhost et 127.0.0.1 sont déjà autorisés.
Remarque
La configuration d'EoleDB saisie dans l'onglet Eoledb de l'interface de configuration du module est ignorée.
Mode externe
Dans le mode externe, l'application définit complètement le serveur externe de base de données à utiliser. Il faut préciser l'adresse et le port d'écoute du serveur de base de données distant.
Le champ Hôtes autorisés à utiliser la base de données permet de renseigner des hôtes distants supplémentaires (l'adresse IP de l'interface 0 du module est déjà autorisée).
Il faut préciser dans le champ Utilisateur du serveur de base de données le nom de l'utilisateur ayant des droits d'administrations sur le serveur de base de données utilisé par l'application Roundcube. Le mot de passe de cet utilisateur doit être renseigné dans le champ Fichier de mot de passe du serveur.
Remarque
La configuration d'EoleDB saisie dans l'onglet Eoledb de l'interface de configuration du module est ignorée.
Configuration DNS pour chaque interface
Configuration des alias sur l'interface
EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.
Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.
La variable Autoriser cet alias à utiliser les DNS de zones forward additionnelles permet d'autoriser le réseau de cet alias à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres adresses IP alias sur l'interface en cliquant sur le bouton + Adresse IP alias pour l'interface n.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser cet alias à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non cet alias à utiliser les DNS noms d'hôte de la zone AGRIATES.
Configuration des VLAN sur l'interface
Il est possible de configurer des VLAN[26] (réseau local virtuel) sur une interface déterminée du module.
Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :
le numéro du VLAN ;
l'adresse IP de l'interface dans ce VLAN ;
le masque de sous réseau de l'interface dans ce VLAN.
La variable Autoriser ce VLAN à utiliser les DNS des zones forward additionnelles permet d'autoriser le réseau de ce VLAN à résoudre les noms d'hôte des domaines déclarés dans la section Forward de zone DNS de l'onglet Zones-dns.
Truc & astuce
Il est possible d'ajouter d'autres VLAN sur l'interface en cliquant sur le bouton + Numéro d'identifiant du VLAN.
Remarque
Si le support du RVP est activé une option supplémentaire est disponible :
Autoriser ce VLAN à utiliser les DNS de Forward RVP/AGRIATES: Si le service RVP est activé (ongletServices) et que le serveur est membre du réseau AGRIATES (ongletRvp) la variable est disponible pour autoriser ou non ce VLAN à utiliser les DNS noms d'hôte de la zone AGRIATES.
Configuration DNS sur l'interface
Il est possible d'ajuster les paramètres du serveur DNS pour chaque interface réseau sauf pour l'interface 0.
Nom de la zone (pour résolution DNS): entrée DNS correspondant à l'adresse IP de l'interface. Le nom (par défaut admin pour l'interface 1) doit être différent pour chacune des interfaces.
Configurer la découverte automatique du proxy avec WPAD
Configuration côté client
Par défaut, les adresses pour lesquelles le proxy ne sera pas utilisé sont : 127.0.0.1 et le réseau local.
Configuration côté serveur
Pour fonctionner correctement, WPAD a besoin de trois éléments qui sont pris en charge par EOLE :
un serveur web qui diffuse le fichier, dans le cadre d'EOLE, c'est le service Nginx[23] qui se charge de distribuer les fichiers
wpad.datadaptés à chacun des sous-réseaux.
un nom de domaine
wpad.<nom_domain_local>qui pointe vers le serveur web ;
un serveur DHCP configuré pour envoyer le chemin du fichier.
Par défaut, la configuration est correctement définie sur un AmonEcole mais dans le cadre d'un environnement Amon / Scribe ou Amon / Horus il faut configurer correctement les deux modules.
Configuration sur le module Scribe
Le serveur DHCP doit être activé et correctement configuré sur le module Scribe (ou AmonEcole).
Dans l'interface de configuration du module en mode expert, dans l'onglet Dhcp, le champ Nom de domaine du serveur WPAD permet de configurer le nom de domaine du serveur WPAD.
Attention
Même s'il est possible d'utiliser n'importe quel domaine, il est conseillé d'utiliser la même valeur que celle utilisée pour le nom de domaine local.
Remarque
Pour les postes de travail Windows c'est la valeur du champ Nom de domaine du serveur WPAD qui sera utilisée pour accéder au fichier WPAD tandis que pour des postes de travail GNU/Linux c'est le nom de domaine local qui sera utilisé pour accéder au fichier WPAD.
Dans l'interface de configuration du module, en mode expert, il faut saisir dans le Nom de domaine du serveur WPAD de l'onglet Dhcp la même valeur que celle du champ Nom de domaine privé du réseau local de l'onglet Général.
Attention
Pour être pris en compte, les changements doivent être enregistrés et suivis de la commande reconfigure sur le module.
Configuration sur le module Amon
WPAD est mis à disposition sur les modules Amon et AmonEcole au travers du paquet eole-wpad.
Sur un module personnalisé, il n'est fonctionnel que si le paquet eole-proxy est installé.
Pour fonctionner correctement, il faut que l'URL wpad.<nom_domaine_local> correspondre à l'adresse IP du serveur web.
Le support de WPAD doit être activé et correctement configuré sur le module Amon.
Dans l'onglet Services de l'interface de configuration du module Activer le support de WPAD doit être placé à oui.
Cela rend disponible l'onglet Wpad au sein duquel le Nom de domaine du service WPAD doit être rempli avec la même valeur que le Nom de domaine privé du réseau local présent dans l'onglet Général.
Attention
Si vous souhaitez utiliser un autre nom de domaine qui ne correspondrait pas au Nom de domaine privé du réseau local de l'onglet Général, il faut le déclarer dans le champ Nom domaine local supplémentaire ou rien de l'onglet Zones-dns.
Attention
Pour être pris en compte, les changements doivent être enregistrés et suivis de la commande reconfigure sur le module.
Truc & astuce
WPAD supporte les VLAN et les alias, Nginx renvoie le bon fichier WPAD si des VLAN ou des alias sont déclarés.
En mode expert, Il est également possible de changer le port du proxy diffusé par défaut pour une interface, un VLAN ou un alias donné.
Ajouter des exclusions dans la configuration automatique du proxy
Dans l'onglet Exceptions proxy de l'interface de configuration du module il est possible d'ajouter des exclusions dans la configuration automatique du proxy.
Il est possible de déclarer différents types d'exceptions.
Exception de proxy pour des domaines de destination
Cette exception commune à ERA et à WPAD permet de déclarer un domaine de destination pour lequel on ne passe pas par le proxy.
Il est possible d'ajouter plusieurs exceptions sur une même interface.
Il est également possible de fournir une liste de noms de domaine ou d'IP à inclure dans les exceptions au proxy depuis une URL, en activant la variable Télécharger et appliquer des exceptions de domaine depuis une URL.
Attention
Si vous utilisez une copie des modèles ERA fournis, il faudra l'adapter pour obtenir les règles supplémentaires
Exception au niveau de l'authentification des domaines de destination
Cette exception permet de déclarer des sites pour lesquels le proxy ne demandera pas l'authentification à l'utilisateur qui souhaite y accéder.
Si cNTLM et WPAD sur activés sur l'interface réseau, les utilisateurs utiliseront directement Squid (sans passer par cNTLM) pour accéder à ces sites.
Remarque
Les domaines commençants par un . sont gérés, le domaine lui-même et les sous-domaines ne sont pas authentifiés.
Exemple
Si on spécifie la valeur .ac-dijon.fr alors ac-dijon.fr et www.ac-dijon.fr seront autorisés sans authentification.
Complément
Une liste de sites à ne pas authentifier par défaut est stockée dans la variable cachée proxy_noauth_auto.
Il est possible de l'afficher dans l'onglet Exceptions proxy de l'interface de configuration du module en activant le mode Debug.
Cette variable reprend la liste des sites qui étaient dans le template domaines_noauth des versions EOLE antérieures à 2.5.2.
Exceptions de proxy pour des IP et adresses réseaux de destination
Cette exception commune à ERA et à WPAD permet de déclarer une adresse IP ou une plage d'adresses IP de destination pour laquelle on ne passe pas par le proxy.
Le bouton Exceptions de type réseau pour l'interface n permet d'ajouter plusieurs exceptions sur une même interface.
Exceptions de proxy pour des IP et adresses réseaux source
Cette exception spécifique à ERA permet de déclarer une adresse IP ou une plage d'adresses IP source pour laquelle on ne passe pas par le proxy.
Le bouton + Exception source de type réseau pour l'interface n permet d'ajouter plusieurs exceptions sur une même interface.
Attention
Cette fonctionnalité permet à une machine de contourner le proxy ce qui constitue un non respect des règles légales de sécurité. Elle peut servir pour effectuer des tests de proxy et d'exceptions de filtrage.
Exception sur un nom d'hôte (spécifique à WPAD)
L'exception sur un nom d'hôte s'effectue sur le nom d'hôte et sur le nom d'hôte complet.
Il faut choisir une interface ou toutes les interfaces sur lesquelles l'exception sera appliquée. Le bouton + Ne pas passer par le proxy pour l'hôte ou le domaine permet d'ajouter plusieurs exceptions sur une même interface.
Ce type d'exception étant spécifique à WPAD, il n'est pas prise en compte par les autres services gérant des exceptions au niveau du proxy.
Exemple
Si le champ Ne pas passer par le proxy pour l'hôte ou le domaine a comme valeur www.ac-monacad.fr, le fichier WPAD.dat généré contiendra la ligne || localHostOrDomainIs(host, "www.ac-monacad.fr") qui permet d'exclure simplement des URLs.
Complément
Compléments sur Ne pas passer par le proxy pour le domaine (dnsDomainIs) :
http://findproxyforurl.com/netscape-documentation/#dnsDomainIs
Compléments sur Ne pas passer par le proxy pour l'hôte ou le domaine (localHostOrDomainIs) :
http://findproxyforurl.com/netscape-documentation/#localHostOrDomainIs
Authentification unique avec EoleSSO
Présentation du produit EoleSSO
Description du produit
EoleSSO est un serveur d'authentification développé pour répondre à la problématique du SSO[131] (authentification unique) dans différentes briques de l'architecture EOLE. Il est développé en langage Python à l'aide du framework Twisted[132].
Ce produit implémente en premier lieu un serveur d'authentification compatible avec le protocole CAS[117].
Une partie du protocole SAML[53] a été implémentée par la suite pour permettre de répondre à des problématiques de fédération avec d'autres produits (ou entre 2 serveurs EoleSSO).
Ce document décrit la configuration, l'administration et l'utilisation du serveur EoleSSO.
Principe de fonctionnement général
La gestion du Single Sign On[131] (SSO) dans EoleSSO est basée sur le protocole CAS[117].
Le principe est que l'utilisateur fournit ses identifiants sur la page d'authentification du service EoleSSO. Une fois les identifiants validés, le service pose un cookie de session SSO dans le navigateur. Ce dernier n'est valide que sur une durée définie.
Tant que le cookie est valide, le service reconnaît automatiquement l'utilisateur à chaque fois qu'une application demandera de vérifier son authentification. Ce système présente plusieurs intérêts : l'utilisateur ne saisit qu'une fois ses identifiants pour se connecter à un ensemble d'applications et celles-ci n'ont jamais accès à ses identifiants réels (La liste des informations envoyées aux applications par le service SSO est configurable par application grâce à un système de filtres).
Le serveur d'authentification possède plusieurs caches de sessions :
tickets utilisateurs (session SSO) : longue durée, réutilisable. Ces tickets sont la preuve d'authentification de l'utilisateur et sont stockés dans un cookie sécurisé dans le navigateur de l'utilisateur ;
tickets d'application : courte durée (5 minutes par défaut), utilisable une seule fois et pour une seule application.
Ces tickets sont également utilisés pour mémoriser une session de fédération avec un autre système (se reporter aux chapitres traitant de la fédération d'identité).
Les applications clientes n'ont pas accès à l'identifiant de la session utilisateur, il est échangé uniquement entre le serveur d'authentification et le navigateur.
Une fois qu'une application a obtenu un ticket, elle peut utiliser de façon classique une session interne pour ne pas surcharger le serveur par des appels trop nombreux.
Attention
La session SSO étant gérée par un cookie placé dans le navigateur du client, celui-ci doit être configuré pour accepter les cookies.
Déroulement de l'accès à une application via EoleSSO
L'utilisateur accède à une page d'une application (service) configurée pour utiliser le système SSO (application utilisant un client CAS).
L'application redirige l'utilisateur sur le serveur SSO en passant une URL de retour (paramètre
service). Le serveur SSO vérifie qu'un cookie de session est présent et qu'il correspond à une session valide.Si ce n'est pas le cas, il demande à l'utilisateur de saisir ses identifiant et mot de passe pour établir une nouvelle session SSO.
Une fois la session validée, le serveur SSO génère un ticket d'application valable pour une courte durée et réservé à l'URL du service. Il redirige alors l'utilisateur sur cette URL en passant le ticket en paramètre.
L'application récupère le ticket. Elle redirige l'utilisateur sur l'URL de validation du serveur SSO en passant en paramètre le ticket reçu et son URL de service.
Le service SSO vérifie que le ticket est encore valide et correspond à l'URL de service. puis redirige sur l'URL de service en incluant une réponse. Si cette réponse est positive (le ticket est valide), elle contient également des informations sur l'utilisateur (les informations renvoyées dépendent de l'application, se reporter au chapitre traitant des filtres).
L'application reçoit la réponse et crée éventuellement une session interne pour l'utilisateur.
La page de l'application est renvoyée à l'utilisateur
Complément
Le fonctionnement peut être plus complexe dans le cas de l'utilisation du mode proxy pour accéder à des services non web (par exemple, pour accéder à un service IMAP ou FTP).
Se reporter à la description du site officiel du protocole CAS pour plus de détail :
Onglet Eole sso : Configuration du service SSO pour l'authentification unique
Le serveur EoleSSO est prévu pour être déployé sur un module EOLE.
Il est cependant possible de l'utiliser dans un autre environnement en modifiant manuellement le fichier de configuration /usr/share/sso/config.py.
Cette section décrit la configuration du serveur depuis l'interface de configuration du module disponible sur tous les modules EOLE. Les valeurs définies par défaut simplifient la configuration dans le cadre d'une utilisation prévue sur les modules EOLE.
Serveur local ou distant
L'activation du serveur EoleSSO s'effectue dans l'onglet Services.
La variable Utiliser un serveur EoleSSO permet :
-
non: de ne pas utiliser de SSO sur le serveur ; -
local: d'utiliser et de configurer le serveur EoleSSO local ; -
distant: d'utiliser un serveur EoleSSO distant (configuration cliente).
Adresse et port d'écoute
L'onglet supplémentaire Eole-sso apparaît si l'on a choisi d'utiliser un serveur EoleSSO local ou distant.
Dans le cas de l'utilisation du serveur EoleSSO local, Nom de domaine du serveur d'authentification SSO doit être renseigné avec le nom DNS du serveur.
Durée de vie d'une session (en secondes): indique la durée de validité d'une session SSO sur le serveur. Cela n'influence pas la durée de la session sur les applications authentifiées, seulement la durée de la validité du cookie utilisé par le serveur SSO. Au delà de cette durée, l'utilisateur devra obligatoirement se ré-authentifier pour être reconnu par le serveur SSO. Par défaut, la durée de la session est de 3 heures (7200 secondes).CSS par défaut du service SSO (sans le .css): permet de spécifier une CSS différente pour le formulaire d'authentification affiché par le serveur EoleSSO. Le fichier CSS doit se trouver dans le répertoire/usr/share/sso/interface/theme/style/<nom_fichier>.css. Se reporter au chapitre personnalisation pour plus de possibilités à ce sujet.
AttentionPort 443
Si le port HTTPS (443) est déclaré pour ce service, alors celui-ci est uniquement accessible via l’URL https://<nom_du_serveur>/sso.
L’URL de la forme https://<nom_du_serveur>:<port>/ reste valable pour les autres valeurs de port que 443.
Dans le cas de l'utilisation d'un serveur EoleSSO distant, seuls les paramètres Nom de domaine du serveur d'authentification SSO et Port utilisé par le service EoleSSO sont requis et les autres options ne sont pas disponibles car elles concernent le paramétrage du serveur local.
Configuration LDAP
Le serveur EoleSSO se base sur des serveurs LDAP[11] pour authentifier les utilisateurs et récupérer leurs attributs.
Il est possible ici de modifier les paramètres d'accès à ceux-ci :
- l'adresse et le port d'écoute du serveur LDAP ;
- le chemin de recherche correspond à l'arborescence de base dans laquelle rechercher les utilisateurs (basedn) ;
- un libellé à afficher dans le cas où un utilisateur aurait à choisir entre plusieurs annuaires/établissements pour s'authentifier (voir le chapitre
Gestion des sources d'authentifications multiples) ; - un fichier d'informations à afficher dans le cadre qui est présenté en cas d'homonymes. Ces informations apparaîtront si l'utilisateur existe dans l'annuaire correspondant. Les fichiers doivent être placés dans le répertoire
/usr/share/sso/interface/info_homonymes; - DN[50] et mot de passe d'un utilisateur en lecture pour cet annuaire ;
- attribut de recherche des utilisateurs : indique l'attribut à utiliser pour rechercher l'entrée de l'utilisateur dans l'annuaire (par défaut, uid)
- choix de la disponibilité ou non de l'authentification par clé OTP[51] si disponible (voir plus loin).
Attention
Dans le cas où vous désirez fédérer EoleSSO avec d'autres fournisseurs de service ou d'identité (ou 2 serveurs EoleSSO entre eux), il est nécessaire de configurer un utilisateur ayant accès en lecture au serveur LDAP configuré.
Il sera utilisé pour récupérer les attributs des utilisateurs suite à réception d'une assertion d'un fournisseur d'identité (ou dans le cas d'une authentification par OTP).
Cet utilisateur est pré-configuré pour permettre un accès à l'annuaire local sur les serveurs EOLE.
Sur les modules EOLE, la configuration recommandée est la suivante :
- utilisateur :
cn=reader,o=gouv,c=fr - fichier de mot de passe :
/root/.reader
Si vous connectez EoleSSO à un annuaire externe, vous devez définir vous même cet utilisateur :
Utilisateur de lecture des comptes ldap: renseignez son dn complet dans l'annuairefichier de mot de passe de l'utilisateur de lecture: entrez le chemin d'un fichier ou vous stockerez son mot de passe (modifiez les droits de ce fichier pour qu'il soit seulement accessible par l'utilisateurroot)
Passer la variable Information LDAP supplémentaires (applications) à oui permet de configurer pour chaque annuaire LDAP déclaré des attributs supplémentaires qui seront utilisés par les applications web (DN racine de l'arbre utilisateurs, DN racine de l'arbre groupes, Champ 'nom d'affichage' de l'utilisateur, Champ 'mail' de l'utilisateur, Champ 'fonction' de l'utilisateur, Champ 'categorie' de l'utilisateur, Champ 'rne' de l'utilisateur, Champ 'fredurne' de l'utilisateur…).
Passer la variable Permettre le changement de mot de passe sur un serveur AD à oui permet à l'utilisateur de changer son mot de passe depuis la mire SSO si ce dernier à expiré.
Il est alors nécessaire de renseigner le nom du domaine AD et le nom du serveur AD sur lequel changer le mot de passe.
Serveur SSO parent
Un autre serveur EoleSSO peut être déclaré en tant que serveur parent dans la configuration (adresse et port). Se reporter au chapitre traitant de la fédération pour plus de détails sur cette notion.
Si un utilisateur n'est pas connu dans le référentiel du serveur EoleSSO, le serveur essayera de l'authentifier auprès de son serveur parent (dans ce cas, la liaison entre les 2 serveurs s'effectue par l'intermédiaire d'appels XML-RPC[52] en HTTPS, sur le port défini pour le serveur EoleSSO).
Si le serveur parent authentifie l'utilisateur, il va créer un cookie de session local et rediriger le navigateur client sur le serveur parent pour qu'une session y soit également créée (le cookie de session est accessible seulement par le serveur l'ayant créé).
Attention
Ce mode de fonctionnement n'est plus recommandé aujourd'hui. Il faut préférer à cette solution la mise en place d'une fédération par le protocole SAML.
Fédération d'identité
Le serveur EoleSSO permet de réaliser une fédération vers un autre serveur EoleSSO ou vers d'autre types de serveurs compatibles avec le protocole SAML[53] (version 2).
Nom d'entité SAML du serveur eole-sso (ou rien) : nom d'entité du serveur EoleSSO local à indiquer dans les messages SAML. Si le champ est laissé à vide, une valeur est calculée à partir du nom de l'académie et du nom de la machine.
Cacher le formulaire lors de l'envoi des informations de fédération : permet de ne pas afficher le formulaire de validation lors de l'envoi des informations de fédération à un autre système. Ce formulaire est affiché par défaut et indique la liste des attributs envoyés dans l'assertion SAML permettant la fédération.
Authentification OTP
Il est possible de configurer EoleSSO pour gérer l'authentification par clé OTP à travers le protocole securID[54] de la société EMC (précédemment RSA).
Pour cela il faut :
installer et configurer le client PAM/Linux proposé par EMC (voir annexes)
Répondre
ouià la questionGestion de l'authentification OTP (RSA SecurID)
Des champs supplémentaires apparaissent :
Pour chaque annuaire configuré, un champ permet de choisir la manière dont les identifiants à destination du serveur OTP sont gérés. '
inactifs' (par défaut) indique que l'authentification OTP n'est pas proposée à l'utilisateur. Avec'identiques', le login local (LDAP) de l'utilisateur sera également utilisé comme login OTP. La dernière option est 'configurables', et indique que les utilisateurs doivent renseigner eux même leur login OTP. Dans ce dernier cas, l'identifiant est conservé sur le serveur EoleSSO pour que l'utilisateur n'ait pas à le renseigner à chaque fois (fichier/usr/share/sso/securid_users/securid_users.ini).Le formulaire d'authentification détecte automatiquement si le mot de passe entré est un mot de passe OTP. Il est possible de modifier la reconnaissance si elle ne convient pas en réglant les tailles minimum et maximum du mot de passe et en donnant une expression régulière qui sera vérifiée si la taille correspond. Les options par défaut correspondent à un mot de passe de 10 à 12 caractères uniquement numériques.
Certificats
Les communications de et vers le serveur EoleSSO sont chiffrées.
Sur les modules EOLE, des certificats auto-signés sont générés à l'instanciation[55] du serveur et sont utilisés par défaut.
Il est possible de renseigner un chemin vers une autorité de certification et un certificat serveur dans le cas de l'utilisation d'autres certificats (par exemple, des certificat signés par une entité reconnue).
Les certificats doivent être au format PEM.
Configuration en mode expert
Autres options
En mode expert plusieurs nouvelles variables sont disponibles :
Alias d'accès au service SSO (paramètre : __CAS_FOLDER)permet de créer un alias spécifique en plus du domaine et du port pour certains serveurs SSO tels que lemonLDAP[115] ou keycloak[116].Cette variable est disponible uniquement à partir de la version 2.6.2 d'EOLE.
Nom du cookie EoleSSOetDomaine du cookie EoleSSOpermettent la gestion d'un cluster EoleSSO.
Générer des statistiques d'usage du serviceest ànonpar défaut.Si ce paramètre est à
oui, EoleSSO va générer des statistiques sur l'usage du service (consommation mémoire, nombre de session...). Ces statistiques sont générées par la librairie python prometheus-client. Elles peuvent être intégrées à un outil tel que Grafana, et sont disponibles sur l'URL suivante : https://<adresse_serveur>:8443/metric.
Activer la balise meta viewport (CSS responsive)permet d'inclure la balise HTML metaviewportdans les pages de l'application (avec content="width=device-width, initial-scale=1"). Elle est à activer en cas d'utilisation d'une feuille de style CSS responsive.
Ne pas répondre aux demandes CAS des applications inconnuesest ànonpar défautSi ce paramètre est à
oui, seules les applications renseignées dans les fichiers d'applications (/usr/share/sso/app_filters/*_apps.ini) sont autorisées à recevoir des réponses du serveur en mode CAS. Si il est à non, le filtre par défaut leur sera appliqué ;Nombre maximum de sessions en attente (backlog)permet de définir la taille de la file d'attente des sessions.Augmenter cette valeur est susceptible de résoudre des problèmes de lenteur voir de rejet des demandes d'authentification ;
Décalage de temps (en secondes) dans les messages de fédération SAMLest à-300secondes par défautCe décalage est appliqué aux dates dans les messages de fédération SAML. Cela permet d'éviter le rejet des messages lorsque le serveur partenaire n'est pas tout à fait synchrone (par défaut, on décale de 5 minutes dans le passé). Ce délai est aussi pris en compte pour la validation des messages reçus ;
Taille du pool de traitement (thread pool size)permet de configurer la valeur du paramètre THREAD_POOL_SIZE.Augmenter cette valeur est susceptible de résoudre les problèmes de charge rencontrés sur certaines infrastructures ;
Utiliser l'authentification SSO pour l'EADest àouipar défaut.Le passer à
nonpermet de ne plus utiliser le serveur SSO pour l'authentification de l'EAD.
Authentification OpenID Connect
Autoriser l'authentification OpenID Connectest ànonpar défautSi ce paramètre est à
oui, il devient possible de configurer un ou plusieurs fournisseurs d'identité OpenID Connect ;Référence du fournisseur d'identité OpenID: renseigner un libellé pour identifier le fournisseur. Ce libellé est interne à l'application EoleSSO. Il est utilisé pour définir le nom des fichiers contenant les logos/boutons du fournisseur :/usr/share/sso/interface/images/<libelle>.png: bouton de connexion présenté sur la page de login (par exemple : "se connecter avec France Connect") ;/usr/share/sso/interface/images/logo-<libelle>.png: logo du fournisseur qui sera affiché sur la page d'association de comptes.
Libellé du fournisseur d'identité OpenID: libellé à destination des utilisateurs pour décrire le fournisseur ("France Connect", "Google", ...) ;URL d'accès (issuer): URL décrivant le fournisseur d'identité (la plupart du temps, l'URL de base de son service d'authentification) ;URL de demande d'autorisation (authorization endpoint): URL permettant au client d'initier le processus d'authentification ;URL de récupération de jeton d'accès (token endpoint): URL permettant de récupérer un jeton (éventuellement l'identifiant de l'utilisateur) après authentification ;URL de déconnexion (logout endpoint): URL permettant de demander une déconnexion. Ce paramètre est ignoré pour les fournisseurs utilisant une cinématique de déconnexion spécifique comme Google, Facebook et Microsoft ;URL de lecture des informations (userinfo endpoint): URL permettant de récupérer les informations de l'utilisateur à l'aide du jeton fourni ;URL de description des certificats de signature (jwks URI): URL décrivant les certificats utilisés par le fournisseur (si disponible) ;
Définition de l'identifiant client (Client ID) et clé secrète (Client secret)
Attention
L'identifiant client (Client ID) et la clé privée secrète ( Client secret) renvoyés par le fournisseur d'identité utilisés pour valider les échanges doivent être, pour des raisons de sécurité, stockés dans un fichier à part avec des droits restreints.
Pour chaque fournisseur d'identité, ajouter une ligne dans le fichier /etc/eole/eolesso_openid.conf :
<nom_fournisseur> = "<client id> :<client secret>"
Le nom_fournisseur doit correspondre au paramètre Référence du fournisseur d'identité OpenID renseigné dans l'interface de configuration du module.
Si ces informations ne sont pas renseignées pour l'un des fournisseurs déclarés, un message l'indiquera au lancement de la commande diagnose.
Version du serveur SSO
Dans le cas où le serveur SSO est déclaré en SAML, de nouvelles variables permettent de déclarer les correspondances (mapping) permettant de récupérer les principaux attributs des utilisateurs parmi celle transmises par le serveur.
Protocoles supportés
Compatibilité CAS
Fonctions implémentées au niveau serveur
Le serveur EoleSSO implémente le protocole CAS[117].
Vous pouvez retrouver la description de ce protocole sur le site officiel du protocole :
http://www.apereo.org/cas/protocol
Les version 1 et 2 du protocole sont gérées.
En plus des fonctionnalités de base décrites dans le protocole, les fonctions suivantes ont été ajoutées pour permettre une meilleure compatibilité avec des versions plus récentes (CAS 3) :
échange de messages au format SAML 1.1 dans une enveloppe SOAP ;
implémentation d'une déconnexion centralisée pour les sessions établies via le protocole CAS. Cette fonctionnalité peut être activée ou désactivée au niveau du serveur (active par défaut) ;
envoi d'attributs utilisateur supplémentaires dans la réponse du serveur, avec un système de filtres suivant l'URL de destination.
Attention
Les protocoles 1 et 2 de CAS utilisent un format de messages différent. Le serveur peut être configuré pour répondre à l'un ou l'autre des formats, mais ne peut pas gérer les 2 en même temps. La version 1 du protocole est disponible pour permettre au serveur de répondre à des clients plus anciens, mais dans ce cas les fonctionnalités du serveur seront très limitées (en particulier, le mode proxy et l'envoi d'attributs ne sont pas gérés).
Compatibilité du client
Suivant le client utilisé, certaines fonctionnalités peuvent ne pas être disponibles.
- La prise en compte des requêtes de déconnexion envoyées par le serveurs nécessitent l'utilisation d'un client récent (phpCAS version 1.1.0 ou supérieur).
Une version modifiée du client phpCAS est disponible dans les dépôts de la distribution EOLE.
Compatibilité SAML2
Pour permettre de répondre à des problématiques de fédération de l'identité des utilisateurs dans des référentiels différents, le serveur EoleSSO est désormais capable d'échanger des messages au format SAML 2[53] . Cela permet, par exemple, que des utilisateurs authentifiés au niveau d'un établissement scolaire puissent accéder à des ressources gérées en académie sans s'authentifier à nouveau.
Les fonctionnalités implémentées correspondent à un certain nombre de scénarios envisagés. Les profils et bindings définis par le standard ne sont pas tous implémentés. En particulier, les binding HTTP Artifact et SOAP ne sont pas gérés, le serveur EoleSSO ne peut donc pas actuellement être considéré comme pleinement conforme au standard SAML 2.
Pour plus de détail, se reporter au document publié sur le site d'OASIS.
Les fonctionnalités absentes seront éventuellement implémentées dans des versions ultérieures selon les besoins.
Les mécanismes suivants sont implémentés :
WebSSO : AuthnRequest (POST/Redirect) / IDP Response (POST) ;
Single Logout : LogoutRequest (POST/Redirect) / LogoutResponse (POST/Redirect).
Le serveur EoleSSO met à disposition un fichier de méta-données pour faciliter la mise en relation avec une entité partenaire.
Il gère également un répertoire de fichiers de méta-données pour récupérer les informations sur ces entités. Se reporter au chapitre gestion des méta-données pour plus de détails.
Attention
Les requêtes et assertions échangées doivent être signées. La clé de signature de l'entité partenaire doit être inclue dans le fichier de méta-données.
Scenarii gérés :
En tant que fournisseur d'identité :
- émission d'une assertion d'authentification à destination d'un fournisseur de service (initié par le fournisseur d'identité ou suite à réception d'une requête authentification émise par un fournisseur de service valide) ;
- déclenchement du processus de déconnexion globale à l'initiative du fournisseur ou suite à la réception d'une requête de déconnexion valide.
En tant que fournisseur de service :
- création d'une session locale suite à la réception d'une assertion d'authentification d'un fournisseur d'identité (et redirection vers l'adresse spécifiée par le paramètre relayState si il est présent) ;
- émission d'une requête de déconnexion en direction du fournisseur d'identité en cas de demande de déconnexion depuis une application cliente.
Compatibilité RSA Securid
Principe de fonctionnement
Le service EoleSSO est capable de vérifier l'authentification d'un utilisateur auprès d'un serveur RSA utilisant le protocole SecurID[54] (authentification de type One Type Password).
L'authentification est effectuée par l'intermédiaire du module PAM[133] SecurID fourni par la société RSA.
Le principe est de vérifier l'authentification de l'utilisateur auprès du serveur RSA, et de conserver cette information dans la session SSO de l'utilisateur.
Lorsque l'utilisateur essaie ensuite de se connecter à un fournisseur de service, les messages SAML envoyés pour établir la fédération seront adaptés pour refléter le niveau d'authentification de l'utilisateur (mot de passe à utilisation unique).
Remarque
Utilisation
Lors de la première utilisation, l'utilisateur se connecte au serveur EoleSSO avec ses identifiants habituels (authentification LDAP). Avant de valider le formulaire d'authentification, il peut cocher la case Enregistrer mon identifiant OTP. Il peut alors renseigner l'utilisateur associé à sa clé OTP sur le serveur RSA, ainsi que son code PIN et le mot de passe actuel.
Attention
Le serveur SSO ne gère pas la saisie initiale du code PIN d'un utilisateur. Dans le cas d'un nouvel utilisateur, il faudra au préalable que celui-ci se connecte sur la mire RSA pour créer son code PIN.
Le serveur EoleSSO va vérifier l'authentification LDAP, puis va valider l'authentification auprès du serveur RSA. Si les deux authentifications réussissent, il va enregistrer l'identifiant de l'utilisateur sur le serveur RSA et va l'associer à l'utilisateur LDAP.
Par la suite, lorsque l'utilisateur revient sur la page d'authentification, le système détecte qu'il s'est déjà enregistré (après saisie de son identifiant habituel). L'utilisateur a alors la possibilité de cocher la case 'Connexion par clé OTP'. Dans ce cas, il lui suffit de saisir son code PIN et mot de passe OTP pour s'authentifier.
Compatibilité OpenID Connnect
Des modifications ont été apportées à EoleSSO pour permettre d'authentifier les utilisateurs auprès du fournisseur d'identité France Connect[134].
Il est également possible de configurer d'autres fournisseurs d'identité OpenID Connect[135] dans les limites des fonctionnalités implémentées. Seul France Connect et l'authentification OAuth[136] 2.0 de Google ont été testés à ce jour.
Le principe de fonctionnement est le suivant :
l'utilisateur se connecte à une application protégée par EoleSSO et est redirigé sur la mire d'authentification ;
la mire d'authentification EoleSSO présente un bouton pour chaque fournisseur d'identité OpenID configuré ;
lorsqu'un utilisateur clique sur un de ces boutons, il est redirigé vers le portail de connexion du fournisseur correspondant ;
après authentification, il est renvoyé sur le portail EoleSSO ;
lors de la première connexion de l'utilisateur avec ce fournisseur, EoleSSO demande de renseigner le couple identifiant/mot de passe habituel, et l'associe à l'identifiant retourné par le fournisseur ;
si l'association a déjà été réalisée, EoleSSO retrouve le compte associé, et créer directement la session de nécessaire à l'utilisateur ;
l'utilisateur est redirigé vers l'application à laquelle il souhaite accéder.
ComplémentDonnées échangées
Le protocole OpenID Connect prévoit que le fournisseur de service précise un ensemble de données auxquelles il veut accéder (scope dans le vocabulaire OpenID).
Cela peut permettre de récupérer diverses informations (sous réserve du consentement de l'utilisateur) , comme l'adresse de messagerie, le numéro de téléphone…
Pour l'implémentation de OpenID réalisé dans EoleSSO, le but est de récupérer un identifiant pérenne et que l'utilisateur l'associe à son compte local. Le scope minimal nommé openid est utilisé et seul l'attribut sub est récupéré par EoleSSO (identifiant nom nominatif de l'utilisateur et sans informations personnelles).
La correspondance entre l'identifiant local et l'identifiant OpenID est stockée dans un fichier /usr/share/sso/openid_users/<référence_fournisseur>_users.ini
Pré-requis à la mise en œuvre
OpenID Connect repose sur un principe de confiance entre un fournisseur de service (Relying Party, par exemple EoleSSO), et un fournisseur d'identité (OpenID Provider, par exemple France Connect).
Pour mettre en place cette relation de confiance, le fournisseur de service va effectuer une demande d'enregistrement auprès du fournisseur d'identité. Celui-ci lui renverra un identifiant et une clé secrète.
Le fournisseur d'identité met à disposition un certain nombre d'URLs nécessaires à la configuration du client.
Remarque
Un principe de configuration automatique est prévu par le protocole, mais il est rarement utilisé dans la pratique et n'a pas été implémenté dans EoleSSO.
Les modalités de cet échange d'informations sont spécifiques à chaque fournisseur.
Dans la plupart des cas, il sera demandé :
une adresse dite de callback : c'est l'adresse sur laquelle est renvoyé l'utilisateur après authentification.
Dans le cas d'EoleSSO cette adresse est :
https://<adresse_serveur_eolesso>:8443/oidcallback
une adresse électronique de contact ;
un logo représentant le fournisseur de service (logo EOLE, logo de l'académie…) qui apparaîtra sur la page d'authentification du fournisseur d'identité.
Gestion de la déconnexion
La cinématique de déconnexion (single logout) n'est pas implémentée par tous les fournisseurs.
Par ailleurs, certains acteurs utilisent une cinématique de déconnexion spécifique. Des adaptations ont ainsi été réalisées pour la déconnexion de Google (testée) ainsi que pour celles de Facebook et Microsoft (non testées).
Configuration du fournisseur d'identité France Connect
Pour mettre en place la relation de confiance entre EoleSSO et France Connect, il faut effectuer une demande d'enregistrement auprès de France Connect : https://franceconnect.gouv.fr/inscription
Le fournisseur d'identité France Connect renvoi un identifiant client (Client ID) et une clé privée secrète ( Client secret) utilisé pour valider les échanges. Il met à disposition un certain nombre d'URLs nécessaires à la configuration du client.
Pour l'inscription il est demandé les informations suivantes:
le nom du service ;
une adresse électronique de contact ;
un logo représentant le fournisseur de service (logo EOLE, logo de l'académie...) qui apparaîtra sur la page d'authentification de France Connect ;
une adresse dite de callback : adresse sur laquelle est renvoyé l'utilisateur après authentification.
Dans le cas d'EoleSSO cette adresse est :
https://<adresse_serveur_eolesso>:8443/oidcallback
Les logos et bouton de connexion France Connect sont déjà fournis avec EoleSSO.
Complément
Pour plus d'informations sur le fonctionnement et la configuration, se reporter à : https://franceconnect.gouv.fr/fournisseur-service
Les conditions d'utilisation de France Connect et le processus de raccordement sont décrites dans le document PDF suivant :
https://franceconnect.gouv.fr/files/CGU FS - Annexe Processus d'implementation de FC par FS V2.1.pdf
À noter que parmi les conditions, une déclaration CNIL simplifiée est disponible et une recette de la solution technique mise en œuvre doit être effectuée par le SGMAP[137].
Une configuration prédéfinie est fournie pour France Connect.
Pour l'activer, choisissez fconnect dans la liste déroulante de la variable Référence du fournisseur d'identité OpenID, ne pas oublier de valider le choix pour faire apparaître les différentes variables.
Attention
L'identifiant client (Client ID) et la clé privée secrète ( Client secret) renvoyés par le fournisseur d'identité utilisés pour valider les échanges doivent être, pour des raisons de sécurité, stockés dans un fichier à part avec des droits restreints.
Pour chaque fournisseur d'identité, ajouter une ligne dans le fichier /etc/eole/eolesso_openid.conf :
<nom_fournisseur> = "<client id> :<client secret>"
Le nom_fournisseur doit correspondre au paramètre Référence du fournisseur d'identité OpenID renseigné dans l'interface de configuration du module.
Si ces informations ne sont pas renseignées pour l'un des fournisseurs déclarés, un message l'indiquera au lancement de la commande diagnose.
Configuration du fournisseur d'identité Google (Google APIs).
Déclaration d'EoleSSO comme fournisseur de service
Pour récupérer votre Client ID / Client Secret, vous devez créer un compte développeur depuis cette adresse : https://developers.google.com/
Rendez-vous dans la console développeur de Google afin de déclarer votre service EoleSSO comme application : https://console.developers.google.com
Créez un nouveau projet (barre supérieure de la console ->
select a project->create a project) ;Une fois le projet créé, cliquez sur la barre de menu gauche (3 barres horizontales), puis sur
API Manager. Cliquez ensuite surCredentials(à gauche) ;Cliquer sur
Oauth Consent Screenet renseigner au minimum le champProduct name shown to users(par exemple 'établissement xxx') ;Sauvegarder et dans Credentias, cliquer sur
Create credentials, *Oauth Client ID" ;Choisir
Web applicationet renseigner les champs suivants :- Name : au choix
- Authorized JavaScript origins : https://[adresse_serveur_sso]:8443
- Authorized redirect URIs : https://[adresse_serveur_sso]:8443/oidcallback
Cliquer sur Create et recopier l'identifiant et la clé secrète fournis ;
Configuration du fournisseur d'identité (Google) dans l'interface de configuration du module
Une fois les identifiants récupérés, vous pouvez configurer les paramètres d'EoleSSO (gen_config, onglet Eole SSO en mode expert)
Passer à
ouila variableAutoriser l'authentification OpenID Connect;ajouter un forunisseur en cliquant sur
+Référence du fournisseur d'identité OpenID;Référence du fournisseur d'identité OpenID: google (des logos sont présents et utilisés automatiquement en choisissant ce libellé) ;Libellé du fournisseur d'identité OpenID: Google (ou autre description de votre choix) ;issuer: https://accounts.google.com ;authorization_endpoint: https://accounts.google.com/o/oauth2/v2/auth ;token_endpoint: https://www.googleapis.com/oauth2/v4/token ;userinfo_endpoint: https://www.googleapis.com/oauth2/v3/userinfo ;jwks_uri: https://www.googleapis.com/oauth2/v3/certs .
En cas de problème, les paramètres en cours de validité sont décrits ici : https://accounts.google.com/.well-known/openid-configuration
Pour plus d'informations sur le support d'OpenID de Google : https://developers.google.com/identity/protocols/OpenIDConnect
Attention
L'identifiant client (Client ID) et la clé privée secrète ( Client secret) renvoyés par le fournisseur d'identité utilisés pour valider les échanges doivent être, pour des raisons de sécurité, stockés dans un fichier à part avec des droits restreints.
Pour chaque fournisseur d'identité, ajouter une ligne dans le fichier /etc/eole/eolesso_openid.conf :
<nom_fournisseur> = "<client id> :<client secret>"
Le nom_fournisseur doit correspondre au paramètre Référence du fournisseur d'identité OpenID renseigné dans l'interface de configuration du module.
Si ces informations ne sont pas renseignées pour l'un des fournisseurs déclarés, un message l'indiquera au lancement de la commande diagnose.
Gestion des attributs des utilisateurs
Le gestionnaire de sessions permet de récupérer des informations de l'utilisateur connecté, par exemple :
- les données LDAP de l'utilisateur (récupérées lors de la phase d'authentification) ;
- le numéro et le libellé de l'établissement hébergeant le serveur d'authentification.
Le serveur EoleSSO permet également :
- d'étendre les données disponibles en définissant des attributs calculés ;
- de créer des filtres définissant quels attributs seront disponibles ;
- de décrire des URL afin de différencier les applications et leur appliquer un filtre.
Truc & astuce
En cas d'ajout de filtres, de définitions d'applications ou d'attributs calculés, il est possible de demander au serveur de les prendre en compte sans le redémarrer. Pour cela, il faut utiliser l'option reload du script de démarrage du service :
# CreoleService eole-sso reload
Ajout d'attributs calculés
EoleSSO permet de définir des attributs calculés en plus des données récupérées dans l'annuaire à la connexion de l'utilisateur. Ces attributs sont calculés par des fonctions écrites en langage Python et ayant accès aux attributs connus de l'utilisateur.
Pour ajouter un attribut calculé, créer un fichier <nom_attribut>.py dans le répertoire /usr/share/sso/user_infos/ :
# -*- coding: utf-8 -*-use_cache = True
... imports et fonctions utilitaires pour le calcul ...
def calc_info(user_info):
.....return valeur_attributs
use_cacheest une directive spécifiant si l'attribut doit être mis en cache (voir Optimisation des attributs calculés) ;user_infoest le dictionnaire des données existantes, il est passé automatiquement à la fonction par le serveur SSO ;
valeur_attributspeut êtreune liste Python contenant les valeurs à associer à l'attribut <nom_attribut> :
return [val1, val2, ...]un dictionnaire Python dont les clés sont le nom de champ et les valeurs la liste de valeurs associées (calcul d'attributs multiples) :
return {'attribut1' : [val1, val2, ...], 'attribut2' : [val1, val2, ...], ...}
Pour que ces données soient envoyées aux applications clientes du service EoleSSO, il faut les assigner dans un filtre de données (cf. paragraphes suivants)
Nom de l'attribut retourné
Dans le cas ou une simple liste de valeur est retournée, c'est le nom du fichier qui détermine le nom d'attribut auquel seront assignées les valeurs (nom du fichier sans l'extension .py).
Dans le cas du calcul d'attributs multiples, le nom de fichier n'est pas pris en compte , le nom de l'attribut est indiqué directement dans la structure retournée.
Données à disposition des fonctions de calcul
L'objet user_infos est un dictionnaire Python contenant les informations connues sur l'utilisateur (récupérées au moment de sa connexion). Il contient les informations suivantes :
- tous les champs de l'utilisateur dans l'annuaire LDAP qui sont accessibles par lui en lecture, à l'exception des mots de passe. Comme c'est le cas dans l'annuaire, les valeurs des attributs sont multivaluées. Par exemple, pour récupérer la première valeur du champ mail, utiliser
user_infos['mail'][0]; - une entrée
user_groupsqui contient la liste des groupes Samba auxquels l'utilisateur est inscrit (récupérée également dans l'annuaire) ; - une entrée
info_groupscontenant un dictionnaire dont les clés sont l'attributcndes groupes présents dansuser_groupset les valeurs sont les attributs du groupe correspondant dans l'annuaire LDAP. Seuls les attributs suivants sont conservés :sambaGroupType,displayName,cn,objectClass,gidNumber,mail,descriptionetniveau; - une entrée
dncontenant le DN complet de l'utilisateur (utilisé pour récupérer le RNE d'origine d'un utilisateur dans le cas d'un annuaire multi-établissements) ; - les entrées
rneetnom_etabqui correspondent aux informations présentes dans la configuration Creole du serveur (ou dans le fichier de configuration du serveur EoleSSO le cas échéant) ; - au fur et à mesure du calcul des attributs, ceux déjà traités sont rendus disponibles dans
user_infos.
Ordre de traitement et mise à disposition des attributs
2 règles s'appliquent pour déterminer dans quel ordre les attributs calculés sont évalués :
- Les fichiers sont traités par ordre de tri alphanumérique sur le noms des fichiers. Si un attribut dépend d'un autre, il est recommandé de préfixer le nom de fichier par un numéro (par exemple
00_attribut1.py,01_attribut2.pysi attribut2 doit récupérer la valeur d'attribut1) ; - Les fichiers renvoyant les valeurs d'un seul attribut (renvoi de liste) sont prioritaires sur celles renvoyant des attributs multiples (renvoi de dictionnaire, même si celui-ci contient un seul attribut). Cela permet par exemple de disposer d'un ensemble d'attributs renvoyés par une seule fonction, puis d'écraser au cas par cas certains attributs si des adaptations sont nécessaires d'un serveur à l'autre (ou de redéfinir un des attributs comme non mis en cache).
Truc & astuceOptimisation des attributs calculés
Toutes les fonctions présentes sont calculées lors de la création de la session d'un utilisateur et lorsqu'une application accède aux informations de l'utilisateur.
Pour éviter de surcharger le serveur EoleSSO lors de requêtes multiples, les attributs peuvent être mis en cache pour la durée de la session SSO de l'utilisateur. Pour qu'un attribut utilise ce cache, il faut ajouter la ligne suivante dans le fichier de calcul :
use_cache = True
Il est conseillé d'utiliser cette directive sur tous les attributs, sauf ceux dont la valeur doit être ré-évaluée durant la session de l'utilisateur.
Attention
Dans le cas d'une utilisation du produit EoleSSO hors du cadre de la distribution EOLE, certains attributs peuvent ne pas être disponibles (en fonction de l'organisation des données dans l'annuaire). Certaines informations comme le libellé de l'établissement ou son code RNE peuvent être renseignées dans le fichier de configuration principal du serveur : /usr/share/sso/config.py.
En plus des données ci-dessus, un certain nombre d'attributs calculés sont livrés par défaut par le serveur :
classes: la classe d'un élève ou les classes d'un professeur (livré pargroupes.py) ;disciplines: les matières enseignées pour un professeur (livré pargroupes.py) ;niveaux: le niveau (attributMefclf) d'un élève ou les niveaux dans lesquels un professeur enseigne (livré pargroupes.py) ;secureid: identifiant opaque calculé avec un MD5[75] de l'UID et du RNE de l'utilisateur ;ENTPersonProfils: renvoie le profil de l'utilisateur tel que défini dans le SDET (par ex. National_1 pour un élève) ;ENTPersonStructRattachRNE: le numéro d'établissement d'origine de l'utilisateur, calculé à partir de son DN dans l'annuaire (utile dans le cas d'un annuaire centralisé regroupant plusieurs établissements) ;ecs_profiletecs_rne: version spécifique des 2 attributs précédents (applications xDesktop et eConnect, voir le site http://envole.ac-dijon.fr) ;entlogin: renvoie l'attributENTPersonProfilde l'utilisateur. Si ce champ n'est pas renseigné, l'équivalent desecureidest renvoyé.
ExempleAttribut calculé secureid (identifiant unique et opaque à destination de services externes)
Contenu du fichier /usr/share/sso/user_infos/secureid.py :
# -*- coding: utf-8 -*-def calc_info(user_infos):
"""calcule secureid : identifiant crypté unique pour chaque utilisateur"""from md5 import md5
# calcul d'un identifiant crypté uniqueuser_hash = md5("%s@%s" % (user_infos['uid'][0], user_infos['rne'][0]))
return [user_hash.hexdigest()]
Filtrage des données par application
EoleSSO implémente un mécanisme permettant de renvoyer des informations différentes concernant l'utilisateur en fonction de l'application qui émet la requête.
Ce mécanisme nécessite la mise en place de deux fichiers de configuration :
- un fichier de description de l'application. Ces fichiers doivent être placés dans le répertoire
/usr/share/sso/app_filterset leur nom doit se terminer par_apps.ini. - un fichier de filtre (dans le même répertoire), devant se nommer
<nom_du_filtre>.ini.
La description d'une application se fait selon le modèle suivant (exemple avec une application fictive) :
[editeurs] # nom de l'application (indicatif)
port=80 # port de l'application (facultatif)
baseurl=/providers # url de l'application
scheme=both # type de protocole : http/https/both
addr=^appserv..*.fr$ # adresse des serveurs autorisés
typeaddr=regexp # type d'adresse
filter=mon_filtre # nom du filtre à appliquer
proxy=default # proxy http nécessaire pour accéder à l'application
Si port est spécifié, il devra apparaître dans l'URL du service désirant s'authentifier. Pour que la définition fonctionne quel que soit le port (ou si le port n'est pas dans l'URL), enlevez la ligne concernant le port, ou mettez port= sans valeur
Il y a 2 types de vérification de l'adresse (typeaddr) :
type ip : l'adresse donnée peut être une adresse IP ou un couple adresse/netmask.
Les formats d'écriture suivants sont possibles :
- 192.168.230.1
- 192.168.230.0/255.255.255.0
- 192.168.230.0/24
type regexp : l'adresse est donnée comme une expression régulière à comparer à l'adresse DNS du client.
Dans l'exemple : ^appserv..*.fr$ -> correspond à toutes les adresse du type par appserv.<qqe_chose>.fr
Ces données seront comparée avec l'URL associée à la session dans le serveur SSO (dans le cadre du protocole CAS, cette URL correspond au champ service donné lors de l'obtention d'un ticket d'application).
Truc & astuce
Pour vérifier le fonctionnement d'une regexp, lancer un shell python:
>>> import re
>>> regexp = '<votre regexp>'
>>> url = '<une url à comparer avec la regexp>
>>> print re.match(regexp, url) is not None
baseurl correspond au chemin de l'application.
Dans l'exemple ci dessus, une URL du type http://appserv_test.fr:80/providers sera reconnue (A noter que http://appserv_test.fr:80/providers/toto est aussi considéré comme valide).
La partie requête de l'URL n'est pas prise en compte (dans cet exemple, http://appserv_test.fr:80/providers?variable=1&variable2=test sera considérée valide).
Pour vérifier quelle URL est reçue, vous pouvez regarder dans /var/log/rsyslog/local/eolesso/eolesso.info.log. L'URL est affichée dans les lignes commençant par : adding session for service : ....
filter indique le nom du fichier de filtre à utiliser (sans l'extension.ini) pour les applications correspondant à cette description. Voir la section suivante pour plus de détail.
proxy indique que l'utilisation d'un proxy est nécessaire pour accéder à l'application depuis la machine hébergeant le serveur EoleSSO.
si la valeur est 'default', le proxy déclaré dans la configuration (dans l'onglet general de gen_config) est utilisé. Il est aussi possible de spécifier un proxy particulier avec une valeur du type 'nom_hote:port'. Le proxy déclaré sera utilisé dans les procédures suivantes :
envoi d'une requête de déconnexion CAS à une application
envoi d'un ticket PGT à un client CAS en mode proxy
Définition de filtres d'attributs
Toutes les données connues de l'utilisateur peuvent être propagées vers les applications lorsque celles-ci valident l'authentification de l'utilisateur auprès du serveur EoleSSO.
Pour décider quelles informations seront renvoyées aux différentes applications, un système d'application de filtres a été mis en place. Le principe est de définir dans un fichier un ensemble d'attributs à renvoyer à une(des) application(s), ainsi que le nom à leur donner dans le cadre de ce filtre.
Ces fichiers sont à placer dans le répertoire /usr/share/sso/app_filters et doivent avoir le format suivant :
[section1]
libelle=variable
libelle2=variable2
....
[section2]
....
- section sert à la mise en forme de la réponse (pour CAS, un nœud dans le XML retourné lors de la validation du ticket)
- variable correspond à l'identifiant LDAP de la donnée utilisateur à récupérer
- libelle est le nom qui sera utilisé pour présenter cette donnée dans la réponse du serveur
Le choix d'un filtre d'attribut est conditionné par l'adresse du service à atteindre (voir chapitre précédent). Il est également possible de créer dans le répertoire app_filters des fichiers de filtres globaux dont les attributs seront ajoutés à tous les filtres.
Le format est le même, mais ces fichiers doivent avoir l'extension .global.
Dans le cas ou un attribut défini dans un filtre global existe également dans le filtre d'une application, c'est la définition spécifique à l'application qui sera prise en compte lors de l'envoi des attributs à celle-ci.
Attention
Si vous souhaitez appeler la méthode statique getUser(…) dans votre application il est impératif d'utiliser au minimum la correspondance user=uid dans votre filtre. Sinon l'authentification ne peut pas aboutir : CAS Authentification failed !
Exemple
Exemple de fichier de profil stocké dans /usr/share/sso/app_filters/mon_filtre.ini (correspond à l'exemple du paragraphe précédent).
[utilisateur]
user=uid
codeUtil=uidNumber
nom=sn
prenom=givenName
niveau=niveau
mail=mail
[etablissement]
codeRNE=rne
nomEtab=nom_etab
Complément
Si vous utilisez EoleSSO dans le cadre d'une distribution EOLE, un certain nombre de filtres et de définitions d'applications sont disponibles.
Il faut installer le paquet envole-conf-sso avec la commande apt-get install envole-conf-sso pour les récupérer.
Les filtres sont installés dans /usr/share/sso/filters_available et /usr/share/sso/applications/available.
Pour les utiliser, recopiez les fichiers voulus dans /usr/share/sso/app_filters et rechargez la configuration du service avec la commande service eole-sso reload
Fédération avec une entité partenaire
Le serveur EoleSSO permet de réaliser une fédération vers un autre serveur EoleSSO, ou vers d'autre types de serveurs compatibles avec le protocole SAML (version 2). Les sections suivantes détaillent la mise en œuvre d'une telle solution suivant 2 méthodes différentes.
- Une première méthode de fédération simplifiée est gérée via la notion de serveur parent. Elle est utilisable uniquement entre deux serveurs EoleSSO et présente un certain nombre de limitations.
- La deuxième méthode, plus complète mais également plus complexe à mettre en œuvre, est gérée par l'implémentation d'un certain nombre d'éléments du protocole SAML[53] dans sa version 2. Ce type de fédération est compatible avec d'autres produit, et a principalement été testé pour une fédération avec la plateforme RSA/FIM. Des tests sont également en cours pour une fédération vers des ENT comme k-d'école de la société Kosmos.
Déclaration d'un serveur parent
Le fait de renseigner un serveur parent (serveur B) dans la configuration du serveur EoleSSO (serveur A) permet de fédérer ces deux serveurs. Cette solution correspond plus à une agrégation des référentiels des deux serveurs plutôt qu'à une fédération.
On considère par exemple que le serveur A est installé dans un établissement scolaire (annuaire local), et le serveur B est situé dans un rectorat (branché sur un annuaire académique).
Une fois l'adresse du serveur parent renseignée, le comportement sera le suivant :
Lorsqu'un utilisateur se connecte sur le serveur A, le serveur va d'abord vérifier le couple login/mot-de-passe auprès du serveur B (par un échange XMLRPC encapsulé dans le protocole HTTPS).
Si le serveur B indique une erreur d'authentification, l'authentification va alors être vérifiée localement (sur l'annuaire du serveur A).
En cas de réussite, une session SSO est établie pour le serveur A, et l'utilisateur sera authentifié auprès des services configurés pour utiliser A. Dans le cas contraire, on considère que l'authentification a échoué.
On retrouve donc ici le même schéma de fonctionnement que si le serveur A n'avait pas de serveur parent.
Si le couple login/mot-de-passe est accepté par le serveur B, une session locale 'déportée' est créée sur le serveur A. L'utilisateur est considéré comme authentifié, mais lors des échanges avec les applications, les validations seront faites auprès du serveur B.
Le serveur A va également rediriger le navigateur de l'utilisateur vers le serveur B afin qu'un cookie de session soit créé pour celui-ci (il redirige sur le serveur A une fois le cookie créé). A la fin de cette procédure, l'utilisateur est donc identifié en même temps sur les serveurs A et B. La durée de validité de la session est gérée par le serveur B qui refusera toute validation au serveur A une fois sa session expirée.
Attention
Limitations de ce système :
- Cette solution n'est pas à proprement parler un système de fédération des 2 serveurs. Il est recommandé de l'utiliser seulement dans des cas assez simples d'utilisation, par exemple pour permettre aux personnel des équipes académiques de se connecter avec leur identifiants dans un établissement (il faut ensuite prévoir de leur attribuer des droits dans les applications, ou un profil d'administrateur sur l'EAD, ...)
- Le système de serveur parent se base sur l'adresse IP du serveur parent. Pour des raisons de sécurité (attaques de types man in the middle[138]), il est conseillé d'utiliser cette solution dans le cadre d'un réseau sécurisé (par exemple, à travers un RVP). Le cas échéant, on préférera la solution proposée dans le paragraphe suivant.
Fédération SAML : Gestion des Associations
La solution retenue pour effectuer une fédération entre deux systèmes est l'utilisation de messages SAML[53] pour transmettre les informations d'authentification.
La mise en place de cette fédération s'effectue en deux étapes :
- définition des attributs permettant de retrouver les utilisateurs dans les référentiels des deux systèmes (clé de fédération) ;
- échange de fichiers de méta-données (métadata[139]) et de certificats entre les deux entités pour établir un lien de confiance.
Pour que la fédération soit possible, il faut pouvoir établir une correspondance entre les utilisateurs des deux entités partenaires.
Pour cela, il est nécessaire de définir les attributs qui seront utilisés de chaque côté pour faire la jointure entre les deux référentiels.
configuration en tant que fournisseur de service
Jeux d'attributs
Le fichier de méta-données du serveur EoleSSO indique quels attributs sont requis pour identifier les utilisateurs dans son référentiel (l'annuaire LDAP).
Cette partie des méta-données est calculée depuis les fichiers de jeux d'attributs présents dans le répertoire /usr/share/sso/attribute_sets(voir plus loin). Après création ou modification de ces fichier, le serveur doit être relancé (reload est suffisant) pour que les méta-données soient mises à jour.
Attention
Le fichier attributes.ini présent sur les anciennes versions n'est plus utilisé. Des jeux d'attributs différents pouvant être assignés à chaque fournisseur d'identité, il peut être gênant de forcer les attributs requis en mode fournisseur de service. (voir paragraphe suivant).
Un numéro d'index est attribué automatiquement à chaque jeu d'attribut au démarrage du serveur (ne le renseignez pas vous même). Dans le cas ou les fichiers de jeux d'attributs seraient perdus, il faudra envoyer à nouveau le fichier metadata du serveur aux entités partenaires afin que la nouvelle numérotation soit prise en compte.
Pour retrouver les utilisateurs après réception d'une assertion en provenance d'un fournisseur de service, le serveur EoleSSO va utiliser un jeu d'attributs. Ceux-ci sont renseignés dans des fichiers au format .ini situés dans /usr/share/sso/attribute_sets/.
Le format des fichiers est :
[user_attrs]
attribut_1=attribut_a
attribut_2=attribut_b
....
[optional]
attribut_3=attribut_c
....
[branch_attrs]
attribut_x=element_dn_y
....
Les attributs de gauche correspondent aux attributs reçus dans l'assertion du fournisseur d'identité, ceux de droite correspondent aux attributs auxquels il doivent correspondre localement.
La section branch_attrs permet d'utiliser certains attributs pour déterminer une branche de l'annuaire dans laquelle rechercher l'utilisateur.
Cela permet de limiter les problèmes dans le cas où des utilisateurs peuvent avoir le même identifiant dans l'annuaire (par exemple, dans le cas d'une fédération basée sur l'uid de l'utilisateur à destination d'un serveur Seshat répliquant l'annuaire de plusieurs Scribe).
Pour ces attributs, le fonctionnement est le suivant :
- lors de la recherche de l'utilisateur, le serveur va rechercher une correspondance sur 'element_dn_y=valeur_attribut_x' dans la liste des annuaires qui sont répliqués par le serveur LDAP local ;
- si plusieurs attributs de ce type sont renseignés, la branche de recherche devra correspondre à tout ces attributs.
Par exemple, si on renseigne rne=ou et que les attributs de l'utilisateur recherché contiennent rne=0000000A, le serveur EoleSSO va utiliser une branche d'annuaire dont la base de recherche contient ou=0000000A.
Les attributs de la section user_attrs (ou toute autre section différente de branch_attrs ou optional) seront utilisés pour retrouver l'utilisateur correpondant à la réponse du fournisseur d'identité dans le(s) serveur(s) LDAP utilisé(s) par EoleSSO.
Tous les attributs de droite doivent exister côté fournisseur de service.
Les attributs de la section optional seront envoyés ou non à l'initiative du fournisseur d'identité.
Si ils sont envoyés dans la réponse, ils seront intégrés aux attributs stockés dans la session SSO de l'utilisateur. Si un attribut local avec le même nom qu'un attribut optionnel existe, c'est l'attribut local qui sera conservé. Cela permet de rajouter des attributs provenant du fournisseur d'identité aux attributs connus dans le référentiel du fournisseur de service.
Par exemple, avec le fichier ci-dessus, le fournisseur de service peut récupérer l'attribut attribut_c dans la réponse du fournisseur d'identité et le stocker en tant qu'attribut_3 dans la session locale.
AttentionCadre d'utilisation
L'utilisation des attributs de type branch_attrs est pour l'instant limitée au cas suivant :
l'annuaire est sur le serveur hébergeant le service EoleSSO ;
l'annuaire est configuré pour répliquer l'annuaire d'autres serveurs (les branches de recherche correspondant aux différents serveurs répliqués sont récupérées dans /etc/ldap/replication.conf).
Dans l'état actuel, cela correspond typiquement à un service EoleSSO présent sur un serveur Seshat en académie (avec réplication de plusieurs serveurs Scribe).
Dans le cadre de l'utilisation de serveurs Scribe et Seshat, il est plutôt recommandé d'utiliser la configuration par défaut (fédération sur l'attribut FederationKey récupéré depuis l'annuaire fédérateur AAF).
Configuration de l'association avec un fournisseur d'identité
Le fichier /usr/share/sso/attribute_sets/associations.ini permet de définir les options de fédération pour chaque fournisseur de service partenaire. Sa syntaxe est la suivante
[nom_entité1]
option=valeur
[nom_entité2]
option=...
Le nom de l'entité doit être le nom de l'entité SAML apparaissant dans le fichier métadata du partenaire concerné (entityID).
Tout fichier de type .ini commençant par 'associations' pourra également être utilisé. Cela peut permettre, par exemple, de distribuer une association correspondant à un serveur Seshat fournisseur de services en académie sur l'ensemble des serveurs Scribe d'une académie. (en passant par une variante dans Zéphir).
Il est possible de spécifier les paramètres supplémentaires suivants pour chaque association avec un fournisseur d'identité (tous facultatifs) :
-
attribute_set: nom du jeu d'attributs à utiliser (correspond au nom du fichier de ce jeu, sans l'extension .ini) -
allow_idp('true' par défaut) : si spécifié à 'false', aucune assertion provenant du fournisseur d'identité ne seront prises en compte. -
allow_idp_initiated('true' par défaut) : si spécifié à 'false', les assertions envoyées par le fournisseur d'identité sans requête préalable ne seront pas traitées. -
force_auth('false' par défaut) : si spécifié à 'true', le fournisseur d'identité demandera ses identifiants à l'utilisateur, même si celui ci était déjà connecté. -
passive('false' par défaut) : si spécifié à 'true', le fournisseur d'identité ne demandera pas ses identifiants à l'utilisateur, même si il n'est pas reconnu. Dans ce cas, une réponse négative sera renvoyée par le fournisseur d'identité. -
default_service(aucun par défaut): si une url est renseignée ici, elle sera utilisée comme service de destination par défaut si aucun service n'est indiqué pendant le processus de fédération. -
default_logout_url: Adresse sur laquelle lorsqu'une déconnexion a été initiée par le fournisseur de service (utilisée seulement si la session a été établie depuis ce fournisseur d'identité). Cela permet par exemple de rediriger sur la mire du fournisseur d'identité. -
force_logout_url('false' par défaut) : Force la redirection sur l'url décrite ci dessus, même si une autre url à été spécifiée dans la demande de déconnexion (par défaut, c'est donc l'url passée en paramètre est prioritaire). -
req_context: niveau d'authentification requis pour accepter une assertion. Les valeurs reconnues par EoleSSO sont 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport' (par défaut, mot de passe saisi depuis une page sécurisée) et 'urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken' (connexion par clé OTP) -
comparison: opérateur de comparaison du niveau d'authentification indiqué par le fournisseur d'identité avec le niveau défini dans req_context. Par défaut cet opérateur estexact(valeur identique). Il est possible d'utiliserminimum(équivalent ou supérieur à),maximum(inférieur à) etbetter(strictement supérieur à).
Truc & astuce
Dans le cas d'une fédération entre des serveurs scribes et un serveur seshat avec réplication des annuaires scribe en central, il peut être utile de définir sur Seshat le paramètre default_logout_url pour chaque établissement fédéré.
Cela permet de revenir automatiquement sur le portail de l'établissement après une déconnexion depuis le portail ou un service de Seshat (l'utilisateur s'étant connecté à l'origine en établissement). Un script est fourni (/usr/share/sso/get_domains.py) pour essayer de déterminer automatiquement l'adresse du portail de chaque établissement en s'appuyant sur le serveur Zéphir.
Si le nom d'entité est default, les options définies seront utilisées par tous les fournisseurs d'identité n'ayant pas de valeur spécifique définie dans leur section. Dans le cas où aucune association avec default n'est présente, le fichier default.ini fourni avec le serveur sera utilisé comme association par défaut (et les options par défaut sont celles décrites ci-dessus).
Attention
Par défaut, aucun fichier d'association n'est fourni. Il faut ajouter manuellement la section correspondant à un fournisseur d'identité pour modifier les paramètres d'association avec les entités définies dans les métadonnées.
L'option allow_idp étant à 'true' par défaut, cela veut dire que tout fournisseur d'identité décrit dans les fichiers de métadonnées sera considéré comme valide (les assertions venant de lui seront traitées).
Pour avoir plus de contrôle sur les fournisseurs d'identité valides, Il est possible par exemple de redéfinir cette valeur à 'false' pour l'entité default, puis de la définir à 'true' au cas par cas pour chaque fournisseur d'identité que l'on veut autoriser.
Truc & astuce
Pour vérifier que les jeux d'attributs sont bien pris en compte :
- relancer le serveur ou recharger la configuration avec la commande CreoleService eole-sso restart (ou reload)
- consulter les logs du serveur (
/var/log/rsyslog/local/eolesso/eolesso.info.log). Si un jeu d'attribut est disponible pour une entité, une mention apparaîtra à côté de son nom. Par exemple :
2010/06/03 15:22 +0200 [-] - Fournisseur de services configuré : urn:fs:ac-dijon:etablissements:1.0
2010/06/03 15:22 +0200 [-] - Fournisseur de services configuré : urn:fi:ac-dijon:et-Collège du parc:1.0 (jeu d'attributs : parc)
Ici, le premier fournisseur utilisera le jeu d'attributs par défaut, alors que le deuxième utilisera un jeu spécifique.
Configuration en tant que fournisseur d'identité
Dans ce mode de fonctionnement, le serveur EoleSSO va envoyer des messages SAML à un partenaire fournisseur de service pour lui permettre de valider l'identité de l'utilisateur connecté. Les attributs envoyés dans ce message dépendent du filtre qui est appliqué lors de l'envoi du message (voir les paragraphes précédents sur la gestion des attributs).
Par défaut, le serveur EoleSSO va utiliser les attributs définis dans le filtre SAML (/usr/share/sso/app_filters/saml.ini). Il est également possible de spécifier un filtre d'attributs différent en fonction du fournisseur de service auquel la réponse est envoyée. Pour cela, il faut créer une description d'application correspondant à l'URL de réception des messages du fournisseur de services, et lui associer un filtre renvoyant les attributs voulus.
Truc & astuce
Dans le cas d'une fédération SAML, il est possible de renseigner directement le nom de l'entité partenaire au lieu de décrire l'URL de réception des messages. Par exemple, la section suivante est suffisante pour déclarer un filtre :
[mon_partenaire_saml] (indicatif, affiché dans les logs au démarrage du serveur)sp_ident=id_entité_fournisseur_service (entityID dans le fichier metadata)filter=nom_filtre (nom du fichier de filtre sans l'extension .ini)
Dans le cas où le filtre appliqué ne permettrait pas d'envoyer au fournisseur de service tous les attributs qu'il a indiqué comme requis (dans son fichier de méta-données), un message d'erreur apparaît à l'envoi des informations d'authentification.
Exemple
Dans le cadre d'une fédération d'un serveur Scribe en établissement avec un serveur EOLE (par exemple un module Seshat) situé dans les services académiques, nous utilisons l'adresse mail académique comme attribut de fédération (celle-ci est stockée sur Scribe dans l'attribut FederationKey lors de l'import de fichiers extraits de l'annuaire fédérateur).
Par défaut, le serveur est configuré pour utiliser cet attribut comme clé de jointure.
Le filtre utilisé par défaut lors de l'envoi d'assertion d'authentification (/usr/share/sso/app_filters/saml.ini) envoie l'attribut FederationKey dans le message envoyé au fournisseur de service.
Fédération SAML : Gestion des méta-données
Pour permettre d'établir un lien de confiance avec une entité partenaire, le serveur EoleSSO utilise des fichiers métadata[139] comme défini dans les standards SAML.
Envoi des informations du service EoleSSO à un partenaire :
- Le fichier métadata du service EoleSSO doit être mis en place sur le serveur partenaire. La procédure varie suivant le logiciel utilisé. Ce fichier est disponible sur le serveur à l'adresse
https://<adresse_serveur_eolesso>:8443/saml/metadata - Dans le cas où ils ne sont pas pris en compte depuis le fichier de métadata, les certificats du serveur doivent être envoyés séparément, et parfois convertis vers un autre format. Le certificat utilisé par défaut dans le cadre d'un serveur EOLE est /etc/ssl/certs/eole.crt, sauf si l'utilisation d'un autre fichier a été configurée (voir l'exemple de fédération avec un serveur RSA/FIM dans les annexes pour un exemple de conversion du certificat)
- Le fichier métadata du service EoleSSO doit être mis en place sur le serveur partenaire. La procédure varie suivant le logiciel utilisé. Ce fichier est disponible sur le serveur à l'adresse
Mise en place des information du partenaire sur le serveur EoleSSO :
- Le fichier métadata de l'entité partenaire doit être mis en place sur :
/usr/share/sso/metadata/<nom_fichier>.xml. Si possible utilisez un nom court, car le nom du fichier (sans le .xml) peut être utilisé dans des URLs pour faire référence à l'entité au lieu d'utiliser son identifiant SAML. - Une fois le fichier en place, il faut redémarrer le service EoleSSO pour qu'il soit pris en compte : CreoleService eole-sso restart (reload est suffisant dans ce cas)
- Le fichier métadata de l'entité partenaire doit être mis en place sur :
Attention
Si l'entité partenaire n'est pas un serveur EoleSSO, il faut vérifier que les informations suivantes sont disponibles dans le fichier métadata fourni :
- Certificat de signature des messages
- L'entité doit être capable de recevoir et envoyer des messages en utilisant les bindings
HTTP-Redirectou HTTP-POST. Actuellement, le serveur EoleSSO ne gère pas les bindingsHTTP-ArtifactetSOAP/PAOS. - En mode fournisseur de service, le serveur EoleSSO ne gère pas le service
Idp Discovery(détection automatique du fournisseur d'identité à l'aide d'un cookie sur un domaine commun). Il est possible cependant d'initier le processus d'authentification en tant que fournisseur de service en spécifiant le fournisseur d'identité à interroger.
Fédération SAML : Accès aux ressources
Activation des différents rôles dans un accord de fédération
Pour résumer, une fois les fichiers de métadata échangés entre EoleSSO et une entité partenaire (protocole SAML), les différents rôles disponibles sont conditionnés comme suit :
Si un fichier de description de l'entité partenaire (soit par l'URL de réception des assertions, soit par son nom d'entité) est présent dans
/usr/share/sso/app_filters, EoleSSO pourra envoyer des assertions à ce partenaire en tant que fournisseur d'identité.Si le nom d'entité du partenaire est présent dans un fichier d'association dans le répertoire
/usr/share/sso/attribute_sets, ce partenaire pourra jouer le rôle de fournisseur d'identité auprès d'EoleSSO. Si l'optionallow_idp_initiatedest àfalsepour ce partenaire, ses assertions ne seront prises en compte que si elles font suite à une requête d'authentification émise au préalable (via l'URLdiscoverydécrite ci-dessus).
Accéder à une ressource d'un fournisseur de service
Une fois la fédération mise en place entre EoleSSO et un fournisseur de service (FS), il est possible d'accéder aux services du FS à l'aide d'une URL au format suivant :
https://adresse_serveur_sso:8443/saml?sp_ident=id_fs&RelayState=service
id_fs est soit l'identifiant du fournisseur de service (entityID tel que défini dans son fichier de méta données), soit le nom de son fichier de méta données placé dans /usr/share/sso/metadata (sans l'extension .xml).
RelayState est une information indiquant au fournisseur de service ou rediriger l'utilisateur une fois son identité confirmée. Les données à envoyées peuvent être l'URL d'une application protégée par le fournisseur de service, l'identifiant de l'établissement depuis lequel l'utilisateur se connecte, ... (variable suivant le fournisseur de service).
L'accès à cette URL va déclencher la cinématique suivante :
vérification par le serveur EoleSSO de la session SSO de l'utilisateur (si il n'est pas connecté, une nouvelle session est établie après saisie des identifiants) ;
génération et envoi d'une réponse SAML au FS pour lui indiquer l'identité de l'utilisateur ;
Traitement de la réponse reçue par le fournisseur de service et recherche des informations sur l'utilisateur dans le référentiel du FS (profil associé, permissions, ...) ;
Redirection de l'utilisateur sur la ressource définie par RelayState (ou sur une ressource définie par défaut le cas échéant).
Accéder à une ressource en tant que fournisseur de service
Dans le cas où le serveur EoleSSO est utilisé comme fournisseur de service, l'accès à une ressource peut se faire de 2 façons :
en envoyant directement une réponse SAML d'authentification sur l'URL de traitement des assertions d'EoleSSO (FS) depuis le fournisseur d'identité (processus dit 'IDP initiated'). Une URL de service à atteindre peut être fournie par le paramètre RelayState.
en envoyant une requête SAML d'authentification depuis EoleSSO (FS) en spécifiant le fournisseur d'identité à interroger et le service à atteindre après authentification (méthode préférable).
Dans les 2 cas, une fois l'assertion reçue validée, une session est établie sur le serveur EoleSSO.
L'utilisateur est ensuite redirigé sur l'URL du service à atteindre (il est possible de définir un service par défaut pour chaque fournisseur d'identité, voir le chapitre précédent concernant la configuration des associations).
Exemple
Dans le cas d'un serveur Scribe servant de fournisseur de service, il est possible par exemple de spécifier dans RelayState l'accès à l'application Pydio (accès au FTP de Scribe). Si le fournisseur d'identité est également un serveur EoleSSO (adresse_FI), l'accès se fera à travers l'adresse suivante (cas 1) :
https://adresse_FI:8443/saml?sp_ident=id_scribe&RelayState=https://adresse_scribe/pydio
L'adresse à utiliser dans le cas 2 serait la suivante :
https://adresse_scibe:8443/discovery?idp_ident=id_fournisseur_identite&return_url=https://adresse_scribe/pydio
Gestion de la Déconnexion
Le serveur EoleSSO intègre la notion de déconnexion unique (single logout) dans le cadre de l'établissement d'un lien de fédération.
La procédure de déconnexion peut être initiée de deux façons.
Directement depuis le service EoleSSO, en accédant à l'URL : https://adresse_serveur_sso:8443/logout;
En utilisant le système de déconnexion de l'entité partenaire si celle-ci gère également la déconnexion unique.
Dans le deuxième cas, une demande de déconnexion au format SAML est envoyée au service EoleSSO, qui va enclencher la déconnexion et envoyer une confirmation une fois la procédure terminée (une adresse de redirection peut également être fournie avec la demande de déconnexion).
Une fois la procédure de déconnexion enclenchée, EoleSSO va envoyer une demande de déconnexion SAML à chaque entité partenaire sur laquelle l'utilisateur a établi une session par fédération.
Dans le cas où EoleSSO est également utilisé pour accéder à des applications locales, par exemple, pour le portail Envole du serveur Scribe, Il va également envoyer des requêtes de déconnexion aux applications ayant demandé un ticket au serveur SSO (ce comportement peut être désactivé dans la configuration du serveur).
Attention
Le mode de fonctionnement de la déconnexion unique est basé sur une suite d'aller-retours (par redirection) vers les différentes entités.
Dans le cas où une erreur se produit lors de la procédure de connexion sur une entité partenaire, il se peut que la procédure s'arrête dans un état de déconnexion partielle (la déconnexion n'est pas propagée à toutes les entités).
Dans ce cas, plusieurs solutions sont prévues pour limiter le problème :
- si l'URL de déconnexion du serveur EoleSSO est à nouveau sollicitée, le serveur va considérer que la dernière requête de déconnexion envoyée a échoué et va reprendre la procédure en passant au partenaire suivant.
- si une autre URL du serveur est sollicitée (création d'une nouvelle session, demande d'authentification par une application, ...), la session SSO précédente est dans tous les cas invalidée par le serveur (il devra donc se ré-authentifier).
Dans le dernier cas, il se peut que l'utilisateur possède toujours une session sur une entité partenaire.
La seule façon de résoudre le problème est de fermer le navigateur.
Gestion des sources d'authentification multiples
Il est possible de se retrouver confronté à des problèmes d'utilisateurs homonymes dans le cas où plusieurs annuaires sont utilisés comme source d'authentification ou dans le cadre d'un réplica d'annuaire distant comme c'est le cas avec le module Seshat.
EoleSSO a été amélioré pour prendre en compte ce problème.
Principe de fonctionnement
Si plusieurs annuaires sont configurés, EoleSSO va gérer une branche de recherche par annuaire. Lorsqu'un utilisateur va saisir son identifiant, une recherche va être effectuée dans chaque annuaire afin de vérifier si celui-ci est présent plusieurs fois. Si c'est le cas, une liste va être affichée pour permettre à l'utilisateur de choisir sa provenance.
La liste affichée est basée sur le libellé renseigné pour chaque annuaire dans l'interface de configuration du module. Il convient donc de bien renseigner ces informations pour que l'utilisateur soit capable de choisir.
Cas particulier : la réplication d'annuaire (Scribe/Seshat)
Gestion de la liste de choix de la source d'authentification
Dans le cadre de la réplication, l'unique annuaire à utiliser est celui du serveur hébergeant EoleSSO.
Des procédures ont été mises en place pour gérer automatiquement des branches de recherche sur chaque annuaire répliqué.
La procédure active_replication nécessite que les 2 serveurs (serveur répliqué/serveur de réplication) soient enregistrés sur le serveur Zéphir.
Lorsque le serveur Zéphir va envoyer au serveur répliquant les éléments nécessaires à la mise œuvre de la réplication, il va également lui envoyer un fichier décrivant l'établissement dans lequel la machine répliquée est installée (le libellé doit donc être renseigné correctement dans l'application Zéphir).
Sur le module Seshat, il est possible de demander manuellement une récupération de ce fichier auprès du serveur Zéphir en lançant le script :
/usr/share/sso/update_etabs.py
Les informations sont stockées dans le fichier /etc/ldap/replication/zephir/etabs.ini dont le format est le suivant :
[rne]
libelle_etab=....
type_etab=....
portail_etab=...
Ces informations sont détectées automatiquement par le serveur Zéphir lorsque c'est possible.
Le numéro RNE sert à faire la liaison avec les branches de recherche disponibles dans EoleSSO (en se basant sur le DN qui est du type ou=<rne>,ou=ac-<academie>,ou=education,o=gouv,c=fr).
Le type d'établissement permet de créer des sections dans la liste présentée à l'utilisateur afin d'en faciliter la lecture.
Truc & astuce
Dans le cas où toutes les informations ne sont pas détectées ou en cas de données mal renseignées dans l'application Zéphir, il est possible de modifier ou d'ajouter des informations en créant un(des) fichier(s) au même format.
Ils sont à placer dans le répertoire /etc/ldap/replication et doivent se nommer etabs_xxx.ini (la partie xxx n'est pas déterminante). Les données présentes dans ces fichiers seront prioritaires sur celles remontées par le serveur Zéphir.
Par exemple, le fichier suivant permet de corriger l'adresse du portail ENT de l'établissement 000000A1 (si celle-ci n'est pas correcte ou absente). Les autres informations remontées par le serveur Zéphir seront conservées (libellé et type d'établissement)
/etc/ldap/replication/etabs_perso.ini
[000000A1]
portail_etab=ent.mon_etab.ac-acd.fr
Dans l'affichage final (voir capture d'écran ci dessus), le libellé de l'établissement sera affiché en majuscules.
Si une description commence par le type d'établissement (ex : COLLEGE VICTOR HUGO), celui-ci sera supprimé pour simplifier l'affichage.
Au démarrage du service eole-sso, ces informations sont lues et rassemblées dans le fichier /usr/share/sso/interface/scripts/etabs.js qui est utilisé pour générer la liste des établissements dans lesquels un identifiant donné est présent.
Si l'application eole-dispatcher est installée sur la machine, un fichier d'informations est également généré pour celle-ci dans /var/www/html/dispatcher/utils/etabs.ini. Cette application permet de rediriger automatiquement les utilisateurs vers les portails ENT auxquels ils ont accès (pour plus d'informations, se reporter aux annexes).
Aide au choix de la source d'authentification
Lorsque des homonymes sont détectés, la mire d'authentification va générer la liste des choix disponibles.
Pour aider l'utilisateur dans sa décision, différentes informations sont affichées.
Si un fichier /usr/share/sso/interface/login_help.tmpl est présent, un lien apparaîtra sur la mire d'authentification (Quel est mon identifiant?). Un survol de ce lien avec la souris fait apparaître le contenu du fichier sous forme d'un cadre en surimpression (classes liées à a.aide dans la feuille de style).
Un exemple est fourni dans le fichier /usr/share/sso/interface/login_help_example.tmpl.
Le but de ce cadre est d'indiquer à l'utilisateur l'identifiant qu'il doit utiliser.
Un deuxième cadre d'information est affiché lorsque des homonymes ont été trouvés pour l'identifiant saisi par l'utilisateur (#homonyme et #homonymetext dans la feuille de style).
Le contenu de celui-ci est conditionné par les choix disponibles. Le but est d'aider à choisir parmi les sources proposées.
Le début du texte est générique et indique à l'utilisateur que plusieurs entrées sont disponibles pour l'identifiant renseigné.
Il est ensuite possible de spécifier un fichier d'information pour chaque annuaire LDAP, dont le contenu sera ajouté au cadre si l'identifiant entré y est présent (l'information doit donc être au format HTML).
Un exemple est fourni dans /usr/share/sso/interface/personnel_acad.html, et donne le résultat suivant :
Personnalisation de la mire SSO
Ce chapitre répertorie les différentes possibilités offertes pour personnaliser l'apparence de la page d'authentification du serveur EoleSSO (pour une meilleure intégration dans l'environnement existant, et en particulier dans le cadre d'un portail d'accès aux ressources d'un établissement).
Message d'avertissement (CNIL)
Il est prévu de pouvoir afficher un message relatif à la déclaration CNIL du site.
- mettre le texte du message d'avertissement (formaté en HTML) dans un fichier
avertissement.txtqui est à placer dans le répertoire/usr/share/sso/interface/theme; - relancer le service : CreoleService eole-sso restart
ExempleExemple de déclaration
Conformément à la loi, nous vous informons que ce site a fait l'objet d'une déclaration de traitement automatisé d'informations nominatives auprès de la CNIL Loi du 6 janvier 1978 relative à l' « Informatique et aux Libertés » :<br />
Conformément à la loi n° 78-17 du 6 janvier 1978, vous pouvez à tout moment accéder aux informations personnelles vous concernant et détenues par l'établissement, demander leur modification ou leur suppression. Ainsi, vous pouvez, à titre irrévocable, demander que soient rectifiées, complétées, clarifiées, mises à jour ou effacées les informations vous concernant qui sont inexactes, incomplètes, équivoques, périmées ou dont la collecte ou l'utilisation, la communication ou la conservation est interdite.<br/>
Pour toutes demandes, veuillez contacter l'administrateur à l'adresse : administrateur@etablissement.fr
CSS : Méthode 1
La feuille de style par défaut /usr/share/sso/interface/main.css importe les feuilles de style ./theme/style/theme.css et ./leaves.css :
[ …]
@import url(./leaves.css);
@import url(./theme/style/theme.css);
[…]
Comme le fichier ./theme/style/theme.css est appelé en deuxième dans la feuille il va permettre une surcharge de la première feuille de style ./leaves.css.
Éditer le fichier vide ./theme/style/theme.css appelé dont le chemin absolu est /usr/share/sso/interface/theme/style/theme.css.
S'inspirer des balises de style utilisées dans le fichier /usr/share/sso/interface/leaves.css pour les surcharger.
Utiliser le répertoire /usr/share/sso/interface/theme/images pour ajouter vos images.
Recharger votre page d'authentification sans même redémarrer le service eole-sso, la feuille de style est importée avec les modifications.
Attention
Cette méthode n'est pas compatible avec la personnalisation Envole Thèmes. Celui-ci écrase le contenu du fichier /usr/share/sso/interface/theme/style/theme.css à chaque reconfigure. Il est possible d'enlever Envole Thèmes avec la commande suivante : # apt-get remove eole-envole-themes
CSS : Méthode 2
Un certain nombre de thèmes sont fournis dans le répertoire /usr/share/sso/interface/themes/.
Il suffit de copier le thème voulu pour le rendre actif :
# /bin/cp -R /usr/share/sso/interface/themes/<nomDuTheme>/* /usr/share/sso/interface/theme
Recharger votre page d'authentification sans même redémarrer le service eole-sso, la feuille de style est importée avec les modifications.
Truc & astuce
N'hésitez pas à proposer votre thème, il sera ajouté au paquetage et reversé à la communauté d'utilisateurs.
CSS : Méthode 3
La feuille de style CSS par défaut utilisée lors de l'affichage de la page d'authentification au portail est :
/usr/share/sso/interface/leaves.css
Il est possible d'utiliser une feuille de style CSS personnalisée pour la mire SSO.
Les fichiers CSS à utiliser sont à placer dans :
/usr/share/sso/interface/
Dupliquer la feuille de style originale sous un autre nom.
Modifier à volonté votre_nouvelle_feuille.css
Renseigner le nom de votre feuille sans l'extension (.css) dans l'onglet Eole sso depuis l'interface de configuration du module.
Réaliser autant de feuilles de style que souhaités.
Remarque
Si vous faites appel à des images, placez-les dans :
/usr/share/sso/interface/images/
Il est possible de passer le nom de la CSS en paramètre dans URL :
http://<adresse_serveur>/css=<nom_de_la_feuille_CSS>
Si vous utilisez un client phpCAS, il faudra modifier le client pour utiliser cette méthode (les URLs sont calculées par le client).
Truc & astuceChoix de la CSS par le filtre SSO
Si un fichier CSS porte le même nom qu'un filtre d'application (par exemple, ead2.css), cette feuille de style CSS sera automatiquement utilisée lors des demandes à cette application (dans le cadre d'un portail web par exemple).
Configuration d'EoleSSO en mode cluster
Fonctionnement en mode cluster
Remarque
Cette documentation couvre seulement la configuration d'un (ou plusieurs) services EoleSSO et d'un service Redis pour permettre le stockage des sessions SSO dans une base de données partagée. La configuration de la répartition de charge ou du basculement (à travers ha-proxy ou autre système) n'est pas abordée ici.
La configuration peut se faire :
en mode serveur (partage d'une base Redis) ;
en mode client (accès à la base Redis par EoleSSO).
Installation et configuration en mode serveur
Sur un module Eole, il faut installer le paquet dédié à l'aide de la commande suivante :
# apt-eole install eole-sso-cluster-server
Celui-ci va installer un serveur Redis et configurer une instance spécifique sur le port 9380 (service redis-eolesso), ainsi qu'un service stunnel4 permettant de sécuriser l'accès à l'aide d'un tunnel SSL.
Dans l'interface de configuration du module apparaît le nouvel onglet Eole sso cluster.
Tous les paramètres sont renseignés pour une utilisation par défaut, mais il est possible d'effectuer les réglages suivants :
Port pour l'accès au service Redis à travers un tunnel SSL: Permet de modifier le port sur lequel les clients se connecteront pour accéder à la base de données.Nom d'hôte ou adresse pour l'accès au service Redis depuis l'extérieur (stunnel): Permet de définir l'adresse sur laquelle le tunnel sera disponible. Par défaut, l'adresse IP de l'interface 0 est utilisée.Chemin du certificat Serveur stunnel (Redis)etChemin de la clé du Serveur stunnel (Redis): Permettent de renseigner un certificat serveur spécifique pour le tunnel SSL. Par défaut, un certificat est généré automatiquement (/etc/ssl/certs/stunnel_client.crt).Nom d'hôte ou adresse IP du serveur RedisetPort du serveur Redis: Permettent de modifier le port sur lequel l'instance de Redis écoute, ou d'accéder à un autre serveur Redis. Si le nom d'hôte est différent de 127.0.0.1 ou localhost, le service local redis-eolesso est désactivé.
Remarque
eole-sso-cluster-server utilise partiellement le nouveau service eole-redis.
Afin d'éviter tout conflit, le port par défaut du service a été modifié de 6380 en 9380.
Attention
À partir d'EOLE 2.7.1, il n'est plus possible d'installer les paquets eole-sso-cluster-server et eole-sso-cluster-client sur la même machine.
Attention
En cas d'utilisation d'un serveur Redis non local, il faut être conscient que les échanges circuleront en clair, ce qui est déconseillé en dehors d'un réseau sécurisé.
Installation et configuration en mode client
Sur un module Eole dont le service EoleSSO doit être utilisé en mode cluster il faut installer le paquet adéquat à l'aide de la commande suivante :
# apt-eole install eole-sso-cluster-client
Celui-ci va installer les librairies nécessaires à l'accès Redis par EoleSSO, ainsi qu'un service stunnel4 configuré en mode client.
Dans l'interface de configuration du module apparaît le nouvel onglet Eole sso cluster.
Port pour l'accès au service Redis à travers un tunnel SSL: Permet de spécifier le port sur lequel le service stunnel4 va se connecter. Il doit correspondre à la valeur configurée sur la machine en mode serveur.Nom d'hôte ou adresse IP d'accès au service Redis distant (stunnel): Renseigner l'adresse choisie pour l'accès à Redis sur la machine en mode serveur.Les variables chemin du certificat et de la clé du client stunnel permettent d'utiliser un certificat spécifique pour le service stunnel local. Attention, ce certificat doit être un certificat client (nsCertType = client). par défaut, un certificat est généré automatiquement (
/etc/ssl/certs/stunnel_client.crt)
Attention
À partir d'EOLE 2.7.1, il n'est plus possible d'installer les paquets eole-sso-cluster-server et eole-sso-cluster-client sur la même machine.
Tunnel SSL
Échange des clés
Une fois la configuration renseignée, reconfigurer le serveur et générer les certificats à l'aide de la commande reconfigure sur chaque machine utilisée.
Il faut ensuite procéder à un échange des certificats entre le serveur et le client pour que la connexion par tunnel soit possible :
Exécuter reconfigure sur chaque machine après avoir copié les fichiers.
Sur la machine en mode serveur il faut recopier dans le répertoire /etc/stunnel/eole/ les fichiers /etc/ssl/certs/ca_local.crt et /etc/ssl/certs/stunnel_client.crt de chaque serveur en mode client. Il faut les renommer afin de ne pas les écraser au fur et à mesure de l'ajout de clients.
# scp root@<adresse_client> :/etc/ssl/certs/ca_local.crt /etc/stunnel/eole/ca_[adresse_client].crt
# scp root@<adresse_client> :/etc/ssl/certs/stunnel_client.crt /etc/stunnel/eole/stunnel_[nom_client].crt
Sur chaque machine en mode client il faut recopier dans le répertoire /etc/stunnel/eole/ les fichiers /etc/ssl/certs/ca_local.crt et /etc/ssl/certs/stunnel_server.crt de chaque serveur en mode serveur.
# scp root@<adresse_client> :/etc/ssl/certs/ca_local.crt /etc/stunnel/eole/
# scp root@<adresse_client> :/etc/ssl/certs/stunnel_server.crt /etc/stunnel/eole/
AttentionUtilisation de certificats spécifiques
En cas d'utilisation d'un autre certificat que celui généré par défaut, les fichiers à échanger sont :
le fichier du certificat utilisé pour le service stunnel ;
toute les autorités de certification permettant de valider celui-ci (autorité racine et éventuels certificats intermédiaires).
Truc & astuceVérifier le bon fonctionnement du tunnel
Une fois les machines configurées, il faut se connecter sur un des serveurs en mode client, se placer dans le répertoire /usr/share/sso/, exécuter l'interpréteur python et saisir le code suivant :
>>> import config, redis
>>> r = redis.Redis(host=config.REDIS_HOST, port=config.REDIS_PORT)
>>> r.ping()
La dernière commande doit retourner True.
Si la commande renvoie un message d'erreur se terminant par Error while reading from socket: (104, 'Connection reset by peer'), cela indique généralement un problème de validation des certificats (par le serveur ou le client), ou une interdiction d'accès au port du tunnel par le serveur (pare-feu, TCP Wrapper[141]...).
Répartition de charge EoleSSO en mode cluster
Cette documentation a pour but de décrire la mise en place d'une configuration HAProxy afin de pouvoir mettre plusieurs services EoleSSO en cluster et de gérer la répartition de charge.
Cette documentation décrit également la mise en place de 2 services pour suivre les métriques d'EoleSSO :
Prometheus : https://prometheus.io/
Grafana : https://grafana.net/
On suppose l’existence de 3 serveurs EoleSSO qui écoutent sur le port 443 dont les DNS sont les suivants :
sso-1.ac-academie.fr;sso-2.ac-academie.fr;sso-3.ac-academie.fr.
Un quatrième serveur doit héberger le service ha-proxy avec pour nom DNS sso-ha.ac-academie.fr.
Attention
Le serveur hébergeant le service ha-proxy du cluster doit avoir un nom de domaine différent de celui du cluster de serveur web même si les 2 noms de domaine pointent sur la même adresse IP.
Remarque
Pour maintenir et déployer la configuration (certificats pour stunnel, metadata, filtres, thèmes, CSS, attributs calculés) sur les différents serveurs EoleSSO il est possible d'utiliser Ansible.
Installation d'HAProxy
Sur le serveur sso-ha.ac-academie.fr :
# apt-eole install haproxy
Configuration d'HAProxy
Procéder à la configuration basique d'HAProxy (non détaillée ici).
Éditer le fichier de configuration /etc/haproxy/haproxy.cfg et ajouter les lignes suivantes :
global
...
# Les serveurs étant gérés par vous, la vérification ssl peut être désactivéessl-server-verify none
frontend https-in
bind <IP DU SERVEUR SSO-HA>:443 ssl crt <CHEMIN DU CERTIFICAT PEM>
option forwardfor
redirect scheme https if !{ ssl_fc }default_backend sso_servers
backend sso_servers
balance roundrobin
cookie SSONAME insert indirect nocache
server sso-1.ac-academie.fr sso-1.ac-academie.fr:443 ssl cookie sso1 check
server sso-2.ac-academie.fr sso-2.ac-academie.fr:443 ssl cookie sso2 check
server sso-3.ac-academie.fr sso-3.ac-academie.fr:443 ssl cookie sso3 check
Remarque
<IP DU SERVEUR SSO-HA> : est à remplacer par l'adresse IP de votre serveur HAProxy
<CHEMIN DU CERTIFICAT PEM> : chemin du certificat + key
Attention
Penser à redémarrer le service haproxy :
# service haproxy restart
Mise en place de Prometheus et de Grafana
Il faut mettre en place un serveur Prometheus qui sera chargé de collecter les données fournies par nos serveurs EoleSSO et mettre en place Grafana pour avoir un visuel des métriques.
Pour des raisons de simplicité, des micro-services docker sont utilisés pour fournir ces deux applications, aussi il faut installer les paquets docker et docker-compose.
Remarque
Il peut être intéressant de dissocier ces services du serveur HAPproxy, car il pourrait servir à d'autres serveurs, ce serveur de monitoring porte le nom DNS monitoring.ac-academie.fr.
ExempleExemple de configuration de Prometheus
Exemple de configuration, contenu dans le fichier /shared/prometheus/monitoring-compose.yml :
prometheus:
image: prom/prometheus
ports:
- 9090:9090
volumes:
- /shared/prometheus/etc/:/etc/prometheus/ - /shared/prometheus/data/:/prometheusgrafana:
image: grafana/grafana:4.1.1
ports:
- 3000:3000
volumes:
- /shared/prometheus/grafana/:/var/lib/grafana/env_file:
- /shared/prometheus/grafana.config.monitoringConfiguration de Prometheus
Le fichier de configuration de prometheus /shared/prometheus/etc/prometheus.yml contient :
global:
scrape_interval: 60s
scrape_configs:
- job_name: "eole_sso"
metrics_path: /metrics
scheme: https
tls_config:
insecure_skip_verify: truestatic_configs:
- targets: - sso-1.ac-academie.fr - sso-2.ac-academie.fr - sso-3.ac-academie.frConfiguration de Grafana
Configuration de Grafana dans le fichier /shared/prometheus/grafana.config.monitoring
GF_SECURITY_ADMIN_PASSWORD=VOTRE_MOT_DE_PASSE_ADMIN
GF_USERS_ALLOW_SIGN_UP=false
http_proxy=PROXY_HOST:PROXY_PORT
https_proxy=PROXY_HOST:PROXY_PORT
Remarque
Modifier les valeurs de :
VOTRE_MOT_DE_PASSE_ADMIN
PROXY_HOST
PROXY_PORT
Truc & astuce
La documentation de Grafana décrit les paramètres possibles :
ExempleJSON pour le tableau de bord Grafana
{ "annotations": {"list": []
},
"editable": true,
"gnetId": null,
"graphTooltip": 0,
"hideControls": false,
"id": 16,
"links": [],
"refresh": "1m",
"rows": [
{"collapse": false,
"height": 237,
"panels": [
{ "aliasColors": {"sso-3": "#82B5D8",
"sso-1": "#7EB26D",
"sso-2": "#EAB839"
},
"bars": false,
"datasource": null,
"editable": true,
"error": false,
"fill": 7,
"grid": {},"id": 9,
"legend": {"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": true,
"linewidth": 0,
"links": [],
"nullPointMode": "connected",
"percentage": false,
"pointradius": 5,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"span": 4,
"stack": true,
"steppedLine": false,
"targets": [
{"expr": "eolesso_login_gauge",
"intervalFactor": 2,
"legendFormat": "{{host}}","metric": "eolesso_login_gauge",
"refId": "A",
"step": 120
}
],
"thresholds": [],
"timeFrom": null,
"timeShift": null,
"title": "Nombre de tickets de login (TicketCache)",
"tooltip": {"msResolution": false,
"shared": true,
"sort": 0,
"value_type": "cumulative"
},
"type": "graph",
"xaxis": {"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
]
},
{"bars": true,
"datasource": null,
"editable": true,
"error": false,
"fill": 10,
"grid": {},"id": 4,
"legend": {"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": false,
"linewidth": 0,
"links": [],
"nullPointMode": "null as zero",
"percentage": false,
"pointradius": 5,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"span": 4,
"stack": true,
"steppedLine": true,
"targets": [
{"expr": "(rate(eolesso_sessions_new_counter[10m]))*60*2",
"intervalFactor": 2,
"legendFormat": "{{host}} [{{authclass}}]","metric": "eolesso_sessions_new_counter",
"refId": "A",
"step": 120
}
],
"thresholds": [],
"timeFrom": null,
"timeShift": null,
"title": "Nb connexions/s",
"tooltip": {"msResolution": false,
"shared": true,
"sort": 0,
"value_type": "individual"
},
"type": "graph",
"xaxis": {"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
]
},
{ "aliasColors": {"sso-3": "#82B5D8",
"sso-1": "#7EB26D",
"sso-2": "#EAB839"
},
"bars": false,
"datasource": null,
"editable": true,
"error": false,
"fill": 3,
"grid": {},"id": 2,
"legend": {"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": true,
"linewidth": 1,
"links": [],
"nullPointMode": "null",
"percentage": false,
"pointradius": 5,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"span": 4,
"stack": true,
"steppedLine": false,
"targets": [
{"expr": "eolesso_sessions_nb_gauge",
"intervalFactor": 1,
"legendFormat": "{{host}}","metric": "eolesso_sessions_gauge",
"refId": "A",
"step": 60
}
],
"thresholds": [],
"timeFrom": null,
"timeShift": null,
"title": "Nombre de tickets de sessions (auth)",
"tooltip": {"msResolution": false,
"shared": true,
"sort": 0,
"value_type": "cumulative"
},
"type": "graph",
"xaxis": {"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
]
}
],
"repeat": null,
"repeatIteration": null,
"repeatRowId": null,
"showTitle": false,
"title": "Row",
"titleSize": "h6"
},
{"collapse": false,
"height": "250px",
"panels": [
{ "aliasColors": {"sso-3": "#82B5D8",
"sso-1": "#7EB26D",
"sso-2": "#EAB839"
},
"bars": false,
"datasource": null,
"editable": true,
"error": false,
"fill": 7,
"grid": {},"id": 7,
"legend": {"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": true,
"linewidth": 1,
"links": [],
"nullPointMode": "connected",
"percentage": false,
"pointradius": 5,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"span": 6,
"stack": true,
"steppedLine": true,
"targets": [
{"expr": "eolesso_calcdata_gauge",
"intervalFactor": 2,
"legendFormat": "{{host}}","metric": "eolesso_calcdata_gauge",
"refId": "A",
"step": 60
}
],
"thresholds": [],
"timeFrom": null,
"timeShift": null,
"title": "taille du cache des attributs calculés",
"tooltip": {"msResolution": false,
"shared": true,
"sort": 0,
"value_type": "cumulative"
},
"type": "graph",
"xaxis": {"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{"format": "decbytes",
"label": "Octets",
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
]
},
{ "aliasColors": {"sso-3": "#82B5D8",
"sso-1": "#7EB26D",
"sso-2": "#EAB839"
},
"bars": false,
"datasource": null,
"editable": true,
"error": false,
"fill": 5,
"grid": {},"id": 8,
"legend": {"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": true,
"linewidth": 1,
"links": [],
"nullPointMode": "connected",
"percentage": false,
"pointradius": 5,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"span": 6,
"stack": true,
"steppedLine": false,
"targets": [
{"expr": "eolesso_userdata_gauge",
"intervalFactor": 2,
"legendFormat": "{{host}}","metric": "eolesso_userdata_gauge",
"refId": "A",
"step": 60
}
],
"thresholds": [],
"timeFrom": null,
"timeShift": null,
"title": "taille du cache des attributs ldap",
"tooltip": {"msResolution": false,
"shared": true,
"sort": 0,
"value_type": "cumulative"
},
"type": "graph",
"xaxis": {"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{"format": "decbytes",
"label": "Octets",
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
]
}
],
"repeat": null,
"repeatIteration": null,
"repeatRowId": null,
"showTitle": false,
"title": "New row",
"titleSize": "h6"
},
{"collapse": false,
"height": "250px",
"panels": [
{ "aliasColors": {"sso.ac-reunion.fr:4430": "#82B5D8",
"sso.ac-reunion.fr:4431": "#E5A8E2",
"sso.ac-reunion.fr:4432": "#AEA2E0"
},
"bars": false,
"datasource": null,
"editable": true,
"error": false,
"fill": 0,
"grid": {},"id": 3,
"legend": {"alignAsTable": true,
"avg": false,
"current": true,
"max": false,
"min": false,
"rightSide": true,
"show": true,
"total": false,
"values": true
},
"lines": true,
"linewidth": 1,
"links": [],
"nullPointMode": "null as zero",
"percentage": false,
"pointradius": 5,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"span": 6,
"stack": false,
"steppedLine": false,
"targets": [
{ "expr": "process_virtual_memory_bytes{job='eole_sso'}","intervalFactor": 2,
"legendFormat": "{{instance}}","refId": "A",
"step": 60
}
],
"thresholds": [
{"colorMode": "critical",
"fill": true,
"line": true,
"op": "gt",
"value": 1517522817
}
],
"timeFrom": null,
"timeShift": null,
"title": "Mémoire utilisée",
"tooltip": {"msResolution": false,
"shared": true,
"sort": 0,
"value_type": "individual"
},
"type": "graph",
"xaxis": {"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{"format": "bytes",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
]
},
{ "aliasColors": {"sso-3": "#82B5D8",
"sso-1": "#7EB26D",
"sso-2": "#EAB839"
},
"bars": false,
"datasource": null,
"editable": true,
"error": false,
"fill": 4,
"grid": {},"id": 1,
"legend": {"avg": false,
"current": false,
"max": false,
"min": false,
"show": true,
"total": false,
"values": false
},
"lines": true,
"linewidth": 1,
"links": [],
"nullPointMode": "connected",
"percentage": false,
"pointradius": 5,
"points": false,
"renderer": "flot",
"seriesOverrides": [],
"span": 6,
"stack": true,
"steppedLine": false,
"targets": [
{ "expr": "eolesso_appticket_gauge{job='eole_sso'}","intervalFactor": 2,
"legendFormat": "{{host}}","metric": "eolesso_appticket_gauge",
"refId": "A",
"step": 60
}
],
"thresholds": [],
"timeFrom": null,
"timeShift": null,
"title": "Nombre de Tickets applicatifs (AppTicket)",
"tooltip": {"msResolution": false,
"shared": true,
"sort": 0,
"value_type": "cumulative"
},
"type": "graph",
"xaxis": {"mode": "time",
"name": null,
"show": true,
"values": []
},
"yaxes": [
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
},
{"format": "short",
"label": null,
"logBase": 1,
"max": null,
"min": null,
"show": true
}
]
}
],
"repeat": null,
"repeatIteration": null,
"repeatRowId": null,
"showTitle": false,
"title": "New row",
"titleSize": "h6"
}
],
"schemaVersion": 14,
"style": "dark",
"tags": [],
"templating": {"list": []
},
"time": {"from": "now-12h",
"to": "now"
},
"timepicker": {"refresh_intervals": [
"5s",
"10s",
"30s",
"1m",
"5m",
"15m",
"30m",
"1h",
"2h",
"1d"
],
"time_options": [
"5m",
"15m",
"1h",
"6h",
"12h",
"24h",
"2d",
"7d",
"30d"
]
},
"timezone": "browser",
"title": "SSO Copy",
"version": 0
}
Monitoring
Lancer l'environnement de monitoring
# cd /shared/prometheus/
# docker-compose -f prometheus-compose.yml start
Par défaut Grafana écoute sur le port 3000 et Prometheus sur le port 9090
Compléments de configuration EoleSSO
Résumé des fichiers et liens
Fichiers de configuration
Fichiers de base
-
/usr/share/sso/config.py: fichier de configuration principal de l'application (sur un module Eole, la configuration est gérée via Creole) -
/usr/share/sso/app_filters/*_apps.ini: définition des applications et spécification du filtre à utiliser -
/usr/share/sso/app_filters/*.ini: fichiers de description des filtres d'attributs -
/usr/share/sso/user_infos/*.py: fonctions de calcul d'attributs supplémentaires -
/usr/share/sso/interface/theme: répertoire pour personnalisation de la CSS des pages d'authentification
Fichiers spécifiques au fonctionnement en mode SAML
-
/usr/share/sso/metadata/*.xml: fichiers metadata des entités partenaires (doit contenir le certificat utilisé pour la signature des requêtes) -
/usr/share/sso/metadata/attributes.ini: définition des attributs requis/optionnels en tant que fournisseur de service (obsolète) -
/usr/share/sso/attribute_sets/*.ini: description de jeux d'attributs pour la fédération via SAML -
/usr/share/sso/attribute_sets/associations*.ini: fichiers de configuration des associations avec des fournisseurs d'identité
URL principales
Toutes les URL du service EoleSSO décrites ci-dessous commencent par https://addresse_serveur:8443 (port par défaut, peut être différent suivant la configuration du service).
URL Générales
/ (sans paramètres): Page d'accueil, le formulaire d'authentification est présenté et une session SSO est créée après validation. Si l'utilisateur est déjà authentifié il est redirigé sur la page/loggedinou une liste des fédérations établies et des applications ayant un ticket est affichée/logout: adresse de déconnexion de la session actuelle (gestion du Single Logout pour les protocoles le supportant)
URL spécifiques à CAS
/?service=X: Adresse d'obtention d'un ticket CAS pour les applications clientes (à utiliser comme URI de base dans la configuration des clients CAS)serviceest l'URL de l'application désirant obtenir un ticket. Une fois la validité de la session SSO vérifiée, le service EoleSSO redirige l'utilisateur sur cette URL en passant le ticket en paramètre (nom du paramètre :ticket)
/validate?service=X&ticket=Y(ou/serviceValidate) : adresse de validation des tickets d'application CAS ;serviceest l'URL du service pour lequel le ticket a été délivré
ticketest le ticket a vérifier (de type ST)
/proxyValidate?service=X&ticket=Y&pgtUrl=Z: adresse de validation des tickets d'application CAS en mode proxyticketest le ticket à vérifier (de type ST ou PT) ;
/samlValidate: adresse de validation des tickets CAS au format SAML 1. Les paramètres doivent être passés par méthode POST (méthode supportée par les client CAS java 3.1.X, phpCAS 1.1.0 et .NET CAS Client). Pour plus de détail sur, se reporter à la page http://en.wikipedia.org/wiki/SAML_1.1TARGET: URL à laquelle la réponse doit être envoyée
Le corps de la requête doit contenir la requête SAML dans une enveloppe SOAP. Le ticket à valider est fourni comme valeur de l'élément AssertionArtifact
/proxy?pgt=X?targetService=Y: adresse d'obtention d'un ticket de type proxy
URL spécifiques à SAML 2 
/saml/metadata: adresse de récupération des méta-données SAML du serveur (fournisseur d'identité et fournisseur de services)/saml?sp_ident=X&RelayState=Y&index=Z: adresse à utiliser pour envoyer une assertion d'authentification SAML à un fournisseur de servicessp_identest l'identifiant de ce partenaire (ou le nom de son fichier metadata sans l'extension .xml)RelayStateest une information (URL ou autre) indiquant au partenaire où l'utilisateur doit être redirigé après la validation de l'assertion ;indexpermet de forcer l'utilisation d'un binding particulier (voir le fichier de méta données pour les valeurs possibles)
/saml/acs: adresse de traitement des assertions reçues en tant que fournisseur de services/discovery?idp_ident=X&return_url=Y: adresse permettant d'envoyer un demande d'authentification à un fournisseur d'identitéidp_identest l'identifiant de ce partenaire (ou le nom de son fichier metadata sans l'extension .xml)return_urlest le service de destination sur lequel rediriger après authentification
Astuces d'exploitation
Journalisation du service
Le fichier de journalisation du service EoleSSO est /var/log/rsyslog/local/eolesso/eolesso.info.log.
Il est possible d'activer un mode debug affichant beaucoup plus d'informations dans le fichier de log.
Pour l'activer, ouvrez le fichier /usr/share/sso/config.py et remplacer la ligne
DEBUG_LOG = False
par
DEBUG_LOG = True
Cette option de debug est à utiliser temporairement pour éviter de rendre les logs illisibles (et limiter l'espace disque utilisé). En cas de mise à jour du paquet eole-sso, elle sera réinitialisée à sa valeur par défaut.
Quand ce mode est activé, il est également possible d'afficher certaines requêtes SAML dans le navigateur en ajoutant un paramètre show=1 aux urls gérant leur envoi.
Cela est possible dans les cas suivants :
envoi d'une assertion d'authentification (ex :
/saml?sp_ident=X&show=1)envoi d'une requête d'authentification (ex :
/discovery?idp_ident=X&show=1)
Rechargement de la configuration du service
Il est possible de recharger le service EoleSSO (au lieu de le redémarrer) afin de prendre en compte de nouvelles données de configuration. Pour cela utilisez la commande suivante :
CreoleService eole-sso reload
L'avantage de cette méthode par rapport à CreoleService eole-sso restart est que les sessions des utilisateurs en cours sont conservées.
Les données suivantes sont prises en compte lors du rechargement :
filtres d'attributs et description d'applications (situés dans
/usr/share/sso/app_filters) ;jeu d'attributs et fichier de configuration d'associations (situés dans
/usr/share/sso/attribute_sets) ;fichiers metadata des entités partenaires (situés dans
/usr/share/sso/metadata) ;définitions d'attributs calculés (situés dans
/usr/share/sso/user_infos).
Exemple de Fédération avec RSA/FIM
Préparation de la configuration FIM
Les données suivantes sont nécessaires pour configurer l'association dans FIM :
- Les méta-données du serveur EoleSSO : wget https://<ip_serveur_sso>:8443/saml/metadata --no-check-certificate --outputfile=eolesso.xml
- le certificat du serveur EoleSSO :
/etc/ssl/certs/eole.crt(fichier par défaut, peut varier selon la configuration)
Si le certificat est au format PEM (c'est le cas du certificat par défaut sur un module EOLE), il faut le convertir au format DER : openssl x509 -inform PEM -outform DER -in eole.crt -out eole_der.crt
Une fois converti, utiliser la commande keytool pour intégrer le certificat à un truststore du serveur RSA/FIM (ou créer un truststore spécifique à cette occasion). Sur notre serveur de test, ils sont situés dans /appli/federation/rsa-fim-config/keystores
Par exemple : <chemin_vers_jdk>/bin/keytool -import -alias fs-ac-mon_acad-et-mon_etab-1.0 -keystore mon_truststore-trust.jks -file eole_der.crt
Configuration du fournisseur d'identité :
aller dans Quick Setup -> add New Partner ;
importer le fichier de méta-données
eolesso.xmlet donner un nom d'entité ;
sauver dans la page suivante (association), choisir le fournisseur de service (FIM) ;
cliquer sur l'onglet
general settingset choisir les réglages suivants :- Encrypting/Signature truststores : sélectionner le truststore créé ci dessus ;
- cocher la case
Transient Plug-in; - le greffon 'dictao cleartrust transient plugin' doit être sélectionné ;
- attribute plugin : ajouter DictaoDumbAttributePluginRP ;
- laisser les autres valeurs par défaut et sauver.
Configuration du serveur EoleSSO
La première étape est de récupérer le fichier de méta-données du fournisseur de service dans FIMConfig :
- Entities -> local entities -> manage existing ;
- cliquer sur le fournisseur, puis sur 'Export' dans le menu déroulant ;
- valider avec les valeurs par défaut, et copier le contenu affiché dans un fichier sur votre machine locale.
Placer ce fichier dans le répertoire /usr/share/sso/metadata (dans cet exemple, fim_sp.xml) du serveur EoleSSO et redémarrer le service.
Attention
Le fichier de méta-données doit être un fichier XML valide. Si l'entête suivant n'est pas présent, ajoutez le au début du fichier :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
Test du lien de fédération
Pour accéder à une ressource au moyen de la fédération, il faut utiliser une adresse de ce type :
https://<adresse_FI>:8443/saml?sp_ident=<id_FS>&RelayState=<adresse_service>
Fédération entre 2 serveurs EoleSSO
Synopsis
On considère la situation suivante :
Un serveur Scribe en établissement (adresse : Scribe_FI) propose l'accès à des ressources protégé par un serveur Seshat (adresse : Seshat_FS) à travers son portail local.
Une réplication d'annuaire est en place entre les 2 serveurs (le serveur Seshat répliquant les annuaires de plusieurs établissements).
On souhaite que l'utilisateur se connecte sur le portail établissement du serveur Scribe, et accès à un application web du serveur Seshat (en saisissant une seule fois ses identifiants lors de la connexion au portail).
Pour permettre de retrouver les utilisateurs sur le fournisseur de service, on décide d'utiliser comme clé de jointure le champ FederationKey de l'annuaire de Scribe. Ce champ étant unique au niveau national, il n'y aura pas de problème
Complément
Se reporter à la partie traitant de la gestion des identifiants ENT dans la documentation Scribe pour plus d'informations sur la mise en place de l'attribut FederationKey
Configuration du fournisseur d'identité (module Scribe)
La première étape est de définir un filtre pour définir les attributs à envoyer au fournisseur de service dans l'assertion SAML.
Par défaut, le serveur EoleSSO utilise le filtre défini dans le fichier /usr/share/sso/app_filters/saml.ini si aucun filtre n'est spécifié pour l'adresse du fournisseur de service (pour information, cette adresse est https://Seshat_FS:8443/saml/acs).
Il n'y a ici rien à modifier car ce filtre envoie l'attribut FederationKey.
Configuration du fournisseur de service (Seshat)
Sur le fournisseur de service, il faut indiquer le jeu d'attributs à utiliser pour établir la correspondance entre les attributs donnés dans l'assertion SAML et les attributs présents dans l'annuaire de Seshat.
Ici aussi, la configuration par défaut convient. Si aucun jeu d'attribut n'est défini pour l'identifiant du fournisseur d'identité, le jeu par défaut est FederationKey=FederationKey, ce qui correspond à notre cas d'utilisation.
Ce filtre est défini dans le fichier /usr/share/sso/attribute_sets/default.ini.
Mise en oeuvre du lien de fédération
Une fois les 2 serveurs configurés, on échange les fichiers de méta données pour établir le lien. Une méthode simple est de le faire par les commandes suivantes :
- sur le module Scribe : wget --no-check-certificate -O /usr/share/sso/metadata/seshat.xml https://seshat_FS:8443/saml/metadata
- sur le module Seshat : wget --no-check-certificate -O /usr/share/sso/metadata/scribe.xml https://scribe_FI:8443/saml/metadata
- redémarrer le service
eole-ssosur les 2 serveurs : CreoleService eole-sso restart
Pour tester le fonctionnement de la fédération, taper l'URL suivante dans un navigateur :
https://scribe_FI:8443/saml?sp_ident=seshat
Après validation du formulaire pour confirmer l'accès, le navigateur doit être redirigé sur l'URL https://seshat_FS:8443/loggedin. Des informations sur la session établie par le serveur Seshat sont affichées sur cette page
une fois le lien de fédération fonctionnel, ajouter un lien dans le portail du serveur Scribe pour accéder à l'application sur Seshat:
https://scribe_FI:8443/saml?sp_ident=seshat&RelayState=https://seshat_FS/mon_application
Mise en place de l'authentification OTP
Le service EoleSSO est capable de valider une authentification par clé OTP auprès d'un serveur RSA Authentication Manager (protocole SecurID).
Pour permettre ce fonctionnement, il est nécessaire d'installer sur le serveur un module PAM fourni par EMC.
Ce module est disponible à l'adresse suivante :
http://france.emc.com/security/rsa-securid/rsa-authentication-agents/pam-7-1.htm
La dernière version testée est la version 7.1.0.1. elle nécessite au minimum un serveur RSA Authentication Manager version 6.1 ou 7.1
Ce client n'est pas certifié pour fonctionner sur le système GNU/Linux Ubuntu, il peut être nécessaire de modifier le script d'installation présent dans l'archive pour qu'il s'exécute correctement sur un serveur EOLE (voir ci-dessous).
Complément
Adaptation du fichier install_pam.sh pour une installation sur un serveur EOLE :
- Remplacer les occurrences de chmod 755 par chmod 644 pour appliquer les permissions préconisées par la distribution.
- Rechercher la section concernant le paramétrage pour Linux (ligne 362 dans la version testée) :
Dans le bloc else (serveur 64 bits), remplacer MODULE_DIR_SECONDARY="/lib64/security/" par MODULE_DIR_SECONDARY="/lib/x86_64-linux-gnu/security/".
La même modification doit être effectuée sur le fichier uninstall_pam.sh si vous souhaitez désinstaller l'agent.
Cette modification concerne la dernière version testée du client (v7.1.0.1.16.05_06_13_02_04_01).
Un fichier de configuration est livré avec EoleSSO pour utiliser le module fourni (/etc/pam.d/rsa_securid)
Le module nécessite également les étapes suivantes :
- enregistrement du serveur hébergeant EoleSSO en tant qu'agent dans la configuration du serveur Authentication Manager ;
- copie du fichier
sdconf.recprésent sur le serveur RSA dans le répertoire/var/ace(serveur EoleSSO) ; - activer la gestion de l'authentification OTP dans EoleSSO (dans l'interface de configuration du module, onglet
Eole ssopuis redémarrer le service). Se reporter à la section Configuration pour le détail des options de configuration disponibles.
Truc & astuce
Deux utilitaires sont livrés avec le module PAM pour tester le fonctionnement :
/opt/pam/bin/32bit/acestatus: affiche les informations sur le serveur présentes danssdconf.rec/opt/pam/bin/32bit/acetest: permet de valider l'authentification d'un utilisateur
Sur un serveur 64 bits, les utilitaires livrés avec le module PAM se trouvent dans le répertoire /opt/pam/bin/64bit.
AttentionVersions 32 ou 64 bits
Les scripts d'installation fournis n'installent pas toujours correctement le module PAM. En cas de dysfonctionnement, vérifier que la version installée de la librairie correspond bien à l'architecture de la machine (voir complément ci dessus sur le script d'installation).
Vous pouvez comparer le fichier pam_securid.so installé avec les version 32 ou 64 bits qui peuvent être trouvées dans l'archive sd_pam_agent.tar du répertoire /lnx du répertoire d'installation de l'agent.
La librairie doit être installée dans le répertoire /lib64/security/ dans le cas d'une version d'EOLE inférieure à 2.5.0 ou dans le répertoire /lib/x86_64-linux-gnu/security/ dans le cas contraire.
Application de redirection : Eole-dispatcher
Dans le cadre de l'utilisation du module Seshat en tant que point d'entrée d'un ENT centralisé, l'application Eole-dispatcher permet de rediriger les utilisateurs vers leur établissement d'origine. Elle se base sur les informations remontées lors de la mise en place de la réplication des serveurs Scribe.
Elle est également prévue pour gérer le cas de l'affectation multiple pour les enseignants et les responsables :
un enseignant qui aurait des services sur plusieurs établissements se verrait proposer le choix de l'établissement sur lequel il souhaite se connecter ;
un parent d'élève qui aurait plusieurs enfants dans des établissements différents se verrait également proposer le choix de l'établissement. Il est à noter que la problématique de la l'affectation multiple pour un élève ne se pose pas, puisque ce dernier ne peut pas être scolarisé dans deux établissements.
Eole-dispatcher est capable (au travers de ses filtres d'attributs) de gérer les sources d'authentification suivantes :
LDAP Académique pour les agents de l'Éducation nationale ;
LDAP Téléservices pour les parents et élèves ;
LDAP local (réplicat des serveurs Scribe) pour l'authentification des élèves et parents (si les téléservices ne sont pas déployés).
Remarque
Le terme affectation est à prendre au sens large, il désigne l'appartenance d'une personne à un établissement.
Pré-requis
Cette application nécessite :
la mise en place de la réplication LDAP des serveurs Scribe sur le serveur Seshat ;
l'alimentation des annuaires des serveurs Scribe avec des extractions AAF EXCLUSIVEMENT ;
la bonne saisie des numéros et libellés établissement sur les serveurs Scribe et Zéphir ;
la configuration d'une fédération entre chaque serveur Scribe et le serveur Seshat (voir documentation EoleSSO au chapitre : Fédération entre 2 serveurs EoleSSO).
Installation
Le dispatcher est à installer sur le module Seshat, afin d'utiliser son portail EoleSSO comme portail unique d'authentification vers les ENT (Envole).
L'application n'est pas installée par défaut. Via l'interface de configuration du module, configurer le serveur pour recevoir les applications web :
en mode normal dans l'onglet
Services, passerActiver le serveur web Apacheàoui;
dans l'onglet
Applications web, saisissez le nom de domaine des applications web dansNom de domaine des applications web (sans http://);enregistrer la configuration et quitter l'interface de configuration du module.
Puis saisir les commandes suivantes sur le module Seshat pour installer le paquet eole-dispatcher :
# Query-Auto
# apt-eole install eole-dispatcher
Configuration
Une fois les paquets installés, il faut de nouveau se rendre dans l'onglet Application web de l'interface de configuration du module et passer Activation de la redirection vers les portails ENT à oui. Des paramètres supplémentaires s'affichent.
Rediriger en automatique si un seul ENT;Proposer le PIA aux professeurs: permet de proposer le portail académique aux enseignants ;RNE du Portail académique (PIA): permet de saisir l'UAI du portail académique ;Portail académique (PIA): portail sur lequel seront redirigés les personnels académiques ;Portail par défaut: adresse du site Internet dédié à l'ENT si aucun portail d'établissement n'est disponible pour l'utilisateur ;webService Arena: URL complète du webService ARENA pour la récupération des ressources ;Zone par défaut pour le webService Arena: zone par défaut du portail ARENA.
Il est possible de changer ou de désactiver le thème.
Une fois l'application paramétrée, il est nécessaire de reconfigurer le serveur à l'aide de la commande reconfigure.
Une fois le serveur reconfiguré, l'application est accessible à l'adresse : http://<adresse_serveur>/edispatcher/
Truc & astuce
Il est possible de rendre l'application directement accessible depuis l'adresse http://<adresse_serveur>/, en renseignant /edispatcher en tant qu'Application web par défaut (redirection) dans la famille Applications web
Fonctionnement
L'installation du dispatcher va mettre en place sur le serveur SSO les filtres d'attributs nécessaires afin de rediriger correctement la personne.
Extrait du fichier /usr/share/sso/app_filters/dispatcher.ini :
[user]
rne=ecs_rne
user=uid
uid=uid
source=SourceAuth
FederationKey=DispatcherKey
displayName=displayName
profils=DispatcherProfils
auth=auth
L'attribut calculé ecs_rne, va permettre de récupérer les codes RNE en fonction des établissements d'affectation de l'utilisateur.
Lors de la connexion d'une personne, Eole-dispatcher va prendre tous les RNE reçus de EoleSSO et présenter tous les liens de fédération pour l'accès aux portails Envole le concernant.
ExempleExemple d'URL de fédération
https://<domaineSeshatSSO>/saml?sp_ident=<id_fs>&RelayState=https://<URL_du_portail_Établissement>
Cette URL effectue une fédération vers le fournisseur de service <id_fs> et redirige vers l'<URL_du_portail_Établissement> du client en fournissant un identifiant de session.
Eole-dispatcher et EoleSSO
RNE : id_fs
id_fs est :
soit l'identifiant du fournisseur de service (entityID tel que défini dans son fichier de méta-données) ;
soit le nom de son fichier de méta-données placé dans
/usr/share/sso/metadata/(sans l'extension.xml).
Par simplicité il est possible de nommer le fichier metadata de nos entités partenaires (Serveur Scribe des établissements) par <RNE>.xml ; id_fs est alors le code RNE de l'établissement.
Libellé et adresse du portail des établissements : URL_du_portail_Établissement
EoleSSO va générer automatiquement, à chaque redémarrage du service eole-sso, un fichier dans /var/www/html/edispatcher/utils/etabs.ini qui va contenir les entrées nécessaires pour chaque établissement :
[9740091F]
libelle = COLLEGE LECONTE DE LISLE
portail = https://portail.college-lecontedelisle.re
...
Ces entrées sont récupérées depuis Zéphir, il est donc nécessaire que les serveurs Scribe soient enregistrés sur le serveur Zéphir. Dans le cas contraire, ou si des informations sont incorrectes ou manquantes, il faudra remplir ce fichier à la main (voir le chapitre
: Gestion des sources d'authentification multiples).
Vous pouvez vous baser sur le fichier d'exemple : /var/www/html/edispatcher/utils/etabs.ini.sample.
Truc & astuceMessage d'erreur : aucun portail trouvé
Il manque une section pour le code RNE dans le fichier /var/www/html/edispatcher/utils/etabs.ini.
Description de liens vers des applications web ou vers des portails.
Fichier /var/www/html/edispatcher/applications.ini :
Format des sections :
[<identifiant du lien>]
url="<adresse du lien>"
piwik=<identifiant piwik>
Paramétrage des URLs : il est possible d'insérer des étiquettes dynamiques dans les URLs
[SSO] : adresse du serveur SSO de Seshat
[PORTAILHOST] : portail dépendant de la zone d'accès du client (configuré dans portails.ini)
[TICKET] : identifiant de session
Configuration de l'accès à un portail en fonction de la plage IP du client
Eole-dispatcher est également utilisé dans certaines académies comme portail d'authentification unique pour l'accès aux portails ARENA[142].
Il peut exister plusieurs portails en fonction de l'endroit où se trouve l'utilisateur. Par exemple, dans l'académie de la Réunion il existe au moins trois portails d'accès aux application ARENA :
portail.ac-reunion.fr(accessible en externe) ;
scoens.ac-reunion.fr(depuis le réseau pédagogique des établissements) ;
scoweb.ac-reunion.fr(depuis le réseau administratif).
Chaque portail, en fonction de sa zone de confinement, ne présentera pas les mêmes ressources et l'utilisation d'une clé OTP[51] sera proposée ou non.
Il faut donc permettre à l'utilisateur d'obtenir le bon portail en fonction de la zone où il se trouve.
Complément
La fonction GetPortailHost du fichier /var/www/html/edispatcher/inc.php du dispatcher permet, en fonction de l'adresse IP du client, de rediriger l'utilisateur vers le bon portail. La récupération de l'adresse IP du client se base sur le champ HTTP_X_FORWARDED_FOR des headers HTTP.
Les différentes associations réseau / portail sont définies dans le fichier /var/www/html/edispatcher/utils/portails.ini.
Créer le fichier /var/www/html/edispatcher/utils/portails.ini et ajouter des sections décrivant une plage IP et l'adresse du portail correspondant :
[<adresse IP>]
mask=<masque IP>
portail="<adresse du portail pour cette plage IP>"
Un exemple de fichier est présent dans : /var/www/html/edispatcher/utils/portails.ini.sample.
Exemple
[172.16.0.0]
mask=13
portail="scoens.ac-reunion.fr"
arena="rev-proxy-peda"
[172.31.190.64]
mask=26
portail="portail.ac-reunion.fr"
arena="rev-proxy-id"
[172.31.16.0]
mask=16
portail="portail.ac-reunion.fr"
arena="rev-proxy-id"
[10.205.0.0]
mask=16
portail="scoweb.ac-reunion.fr"
arena="rev-proxy-agr"
Exemple
Dans cet exemple, tout utilisateur se présentant avec une adresse IP du réseau 10.205.0.0/16, se verra renvoyé vers l'URL du portail académique https://scoweb.ac-reunion.fr.
La variable arena, permet de spécifier la zone ClearTrust associée au portail. Elle est utilisée si vous souhaitez intégrer les ressources ARENA dans le bureau Envole.
Plus d'informations : https://envole.ac-dijon.fr/wordpress/2014/02/19/integration-de-arena-dans-le-bureau-envole.
Configuration du fournisseur d'identité France Connect
Pour mettre en place la relation de confiance entre EoleSSO et France Connect, il faut effectuer une demande d'enregistrement auprès de France Connect : https://franceconnect.gouv.fr/inscription
Le fournisseur d'identité France Connect renvoi un identifiant client (Client ID) et une clé privée secrète ( Client secret) utilisé pour valider les échanges. Il met à disposition un certain nombre d'URLs nécessaires à la configuration du client.
Pour l'inscription il est demandé les informations suivantes:
le nom du service ;
une adresse électronique de contact ;
un logo représentant le fournisseur de service (logo EOLE, logo de l'académie...) qui apparaîtra sur la page d'authentification de France Connect ;
une adresse dite de callback : adresse sur laquelle est renvoyé l'utilisateur après authentification.
Dans le cas d'EoleSSO cette adresse est :
https://<adresse_serveur_eolesso>:8443/oidcallback
Les logos et bouton de connexion France Connect sont déjà fournis avec EoleSSO.
Complément
Pour plus d'informations sur le fonctionnement et la configuration, se reporter à : https://franceconnect.gouv.fr/fournisseur-service
Les conditions d'utilisation de France Connect et le processus de raccordement sont décrites dans le document PDF suivant :
https://franceconnect.gouv.fr/files/CGU FS - Annexe Processus d'implementation de FC par FS V2.1.pdf
À noter que parmi les conditions, une déclaration CNIL simplifiée est disponible et une recette de la solution technique mise en œuvre doit être effectuée par le SGMAP[137].
Une configuration prédéfinie est fournie pour France Connect.
Pour l'activer, choisissez fconnect dans la liste déroulante de la variable Référence du fournisseur d'identité OpenID, ne pas oublier de valider le choix pour faire apparaître les différentes variables.
Attention
L'identifiant client (Client ID) et la clé privée secrète ( Client secret) renvoyés par le fournisseur d'identité utilisés pour valider les échanges doivent être, pour des raisons de sécurité, stockés dans un fichier à part avec des droits restreints.
Pour chaque fournisseur d'identité, ajouter une ligne dans le fichier /etc/eole/eolesso_openid.conf :
<nom_fournisseur> = "<client id> :<client secret>"
Le nom_fournisseur doit correspondre au paramètre Référence du fournisseur d'identité OpenID renseigné dans l'interface de configuration du module.
Si ces informations ne sont pas renseignées pour l'un des fournisseurs déclarés, un message l'indiquera au lancement de la commande diagnose.
Configuration du fournisseur d'identité Google (Google APIs).
Déclaration d'EoleSSO comme fournisseur de service
Pour récupérer votre Client ID / Client Secret, vous devez créer un compte développeur depuis cette adresse : https://developers.google.com/
Rendez-vous dans la console développeur de Google afin de déclarer votre service EoleSSO comme application : https://console.developers.google.com
Créez un nouveau projet (barre supérieure de la console ->
select a project->create a project) ;Une fois le projet créé, cliquez sur la barre de menu gauche (3 barres horizontales), puis sur
API Manager. Cliquez ensuite surCredentials(à gauche) ;Cliquer sur
Oauth Consent Screenet renseigner au minimum le champProduct name shown to users(par exemple 'établissement xxx') ;Sauvegarder et dans Credentias, cliquer sur
Create credentials, *Oauth Client ID" ;Choisir
Web applicationet renseigner les champs suivants :- Name : au choix
- Authorized JavaScript origins : https://[adresse_serveur_sso]:8443
- Authorized redirect URIs : https://[adresse_serveur_sso]:8443/oidcallback
Cliquer sur Create et recopier l'identifiant et la clé secrète fournis ;
Configuration du fournisseur d'identité (Google) dans l'interface de configuration du module
Une fois les identifiants récupérés, vous pouvez configurer les paramètres d'EoleSSO (gen_config, onglet Eole SSO en mode expert)
Passer à
ouila variableAutoriser l'authentification OpenID Connect;ajouter un forunisseur en cliquant sur
+Référence du fournisseur d'identité OpenID;Référence du fournisseur d'identité OpenID: google (des logos sont présents et utilisés automatiquement en choisissant ce libellé) ;Libellé du fournisseur d'identité OpenID: Google (ou autre description de votre choix) ;issuer: https://accounts.google.com ;authorization_endpoint: https://accounts.google.com/o/oauth2/v2/auth ;token_endpoint: https://www.googleapis.com/oauth2/v4/token ;userinfo_endpoint: https://www.googleapis.com/oauth2/v3/userinfo ;jwks_uri: https://www.googleapis.com/oauth2/v3/certs .
En cas de problème, les paramètres en cours de validité sont décrits ici : https://accounts.google.com/.well-known/openid-configuration
Pour plus d'informations sur le support d'OpenID de Google : https://developers.google.com/identity/protocols/OpenIDConnect
Attention
L'identifiant client (Client ID) et la clé privée secrète ( Client secret) renvoyés par le fournisseur d'identité utilisés pour valider les échanges doivent être, pour des raisons de sécurité, stockés dans un fichier à part avec des droits restreints.
Pour chaque fournisseur d'identité, ajouter une ligne dans le fichier /etc/eole/eolesso_openid.conf :
<nom_fournisseur> = "<client id> :<client secret>"
Le nom_fournisseur doit correspondre au paramètre Référence du fournisseur d'identité OpenID renseigné dans l'interface de configuration du module.
Si ces informations ne sont pas renseignées pour l'un des fournisseurs déclarés, un message l'indiquera au lancement de la commande diagnose.
Activation et configuration de Bareos
La sauvegarde du serveur et le support de stockage de la sauvegarde sont activés par défaut sur certains modules, il peuvent être activés/désactivés dans l'onglet Services de l'interface de configuration du module.
L'activation du directeur de sauvegarde permet d'activer la sauvegarde sur le serveur, celle-ci peut être locale si le support de stockage est activé ou déportée à condition d'avoir un serveur sur lequel est activé le support de stockage.
Cette fonctionnalité permet de mettre en place des sauvegardes croisées.
L'activation du support de stockage de la sauvegarde permet d'accueillir des sauvegardes locales ou distantes.
L'activation de la sauvegarde des fichiers locaux, en mode expert, permet de sauvegarder les fichiers du serveur lui-même.
Suite à l'activation du directeur de sauvegarde (
Activer le directeur de sauvegardeàoui) l'ongletDirecteur bareosapparaît dans l'interface de configuration du module. Il permet de configurer le nom du directeur et les périodes de rétention et de définir si le serveur de stockage est distant ou local.
Suite à l'activation du support de stockage (
Activer le stockage de sauvegardeàoui) l'ongletStockage bareosapparaît dans l'interface de configuration du module. Il permet de configurer le nom du serveur de stockage et permet également d'autoriser des directeurs à se connecter au présent stockage.Suite à l'activation de la sauvegarde des fichiers locaux (
Activer la sauvegarde des fichiers locauxàoui) l'ongletClients bareosapparaît dans l'interface de configuration du module. Il permet de configurer le nom du serveur de sauvegarde des fichiers locaux.
Onglet Directeur bareos
L'onglet Directeur bareos apparaît dans l'interface de configuration du module si le directeur de sauvegarde est activé dans l'onglet Services (Activer le directeur de sauvegarde à oui) .
L'onglet permet de configurer le nom du directeur et les périodes de rétention et de définir si le serveur de stockage est distant ou local.
Le nom du directeur est une information importante, il est utilisé en interne dans le logiciel mais, surtout, il est nécessaire pour configurer un client Bareos ou pour joindre le serveur de stockage depuis un autre module.
À l'enregistrement du fichier de configuration il ne sera plus possible de modifier le nom du directeur. En effet, cette variable est utilisée dans les noms des fichiers de sauvegarde.
AttentionMigration de version EOLE
À partir d'EOLE 2.8.1, Bareos fonctionne avec PostgreSQL[59] tandis que sur les versions précédentes, il était possible de choisir entre MySQL et SQLite.
Il n'existe pas de migration de données entre ces bases.
Dans le cas d'une montée de version vers 2.8.1, il vous faudra penser à effectuer une nouvelle sauvegarde dès que possible.
En mode expert, il est possible de modifier le répertoire utilisé par défaut pour l'extraction de la base de données du catalogue. Ce changement permet éventuellement de ne pas surcharger l'espace occupé dans /var.
Le champ Mot de passe du directeur contient le mot de passe à transmettre aux applications distantes pour leur permettre de s'authentifier auprès du directeur.
Configuration des durées de rétention
Les trois types de sauvegarde, complète, différentielle, incrémentale, disposent chacune d’un pool de volumes distinct. Cela permet de paramétrer des durées de rétention[60] et des tailles pour ces volumes différents pour chaque type de sauvegarde.
La sauvegarde du catalogue est également gérée avec un pool de volume distinct. Seule la taille des volumes est paramétrable cependant.
Écran
- 1
Configuration du pool du catalogue
Taille des volumes pour la sauvegarde du catalogue (taille illimitée si à 0)
- 2
Configuration du pool pour la sauvegarde complète
Durée de rétention et taille des volumes pour la sauvegarde complète
- 3
Configuration du pool pour la sauvegarde différentielle
Durée de rétention et taille des volumes pour la sauvegarde différentielle
- 4
Configuration du pool pour la sauvegarde incrémentale
Durée de rétention et taille des volumes pour la sauvegarde incrémentale
La durée de rétention des fichiers détermine le temps de conservation avant l'écrasement.
Plus les durées de rétention sont importantes, plus l'historique sera important et plus l'espace de stockage nécessaire sera important.
L’espace alloué à un volume n’est pas recyclé (réutilisé pour une autre sauvegarde) avant que le volume ne soit complet et que les durées de rétention ne soient atteintes.
Limiter la taille des volumes est utile dans deux cas :
le système de fichier hébergeant les volumes impose une contrainte sur la taille des fichiers (typiquement les systèmes FAT montés via le protocole SMB, à l’origine de la contrainte de 2 Go) ;
on souhaite pouvoir recycler plus rapidement les volumes (de petite taille, les volumes sont associés à moins de jobs ; il faut donc moins de temps pour purger l’ensemble des jobs associés et pouvoir recycler les volumes).
Sur les serveurs avec un historique de sauvegarde conséquent, il n’est pas rare que la limite par défaut de 2 Go pour le pool du Catalogue finisse par poser problème : ce pool n’autorise qu’un volume qui doit être d’une taille suffisante pour contenir la sauvegarde du catalogue.
Exemple
Il peut être intéressant de conserver un historique long mais avec peu d'états intermédiaires.
Pour cela, voici un exemple de configuration :
- 6 mois de sauvegardes totales ;
- 5 semaines de sauvegardes différentielles ;
- 10 jours de sauvegardes incrémentales.
Avec la politique de sauvegarde suivante :
- une sauvegarde totale par mois ;
- une sauvegarde différentielle par semaine ;
- une sauvegarde incrémentale du lundi au vendredi.
Dans l'historique, il y aura donc une sauvegarde par jour de conservée pendant 10 jours, une sauvegarde par semaine pendant 5 semaines et une sauvegarde mensuelle pendant 6 mois.
Attention
Une modification de la durée de rétention en cours de production n'aura aucun effet sur les sauvegardes déjà effectuées, elles seront conservées et recyclées mais sur la base de l'ancienne valeur, stockée dans la base de données.
Afin de prendre en compte la nouvelle valeur pour les sauvegardes suivantes, il faut utiliser les outils Bareos pour mettre à jour la base de données :
# bconsole
*update
*2
*<numéro du pool de volumes de sauvegarde>
Une autre solution consiste à vider le support de sauvegarde ou prendre un support de sauvegarde ne contenant aucun volume et à ré-initialiser la base de données Bareos avec la commande :
# bareosregen.sh
La regénération du catalogue de bareos va écraser l'ancienne base, confirmez-vous ? [oui/non]
[non] : oui
Paramètres supplémentaires
En mode expert d'autres paramètres sont disponibles.
La durée maximale pour l'exécution complète d'une sauvegarde permet d'annuler le job si il n’est pas terminé avant ce délai, exprimé en secondes, en comptant à partir de l’heure programmée. Par défaut le job est limité à 86 400 secondes soit 24 heures (la valeur 0 lève cette limite de temps).
Plus l'algorithme de compression est efficace, moins il nécessite d'espace mais plus il alourdit la charge système et allonge la durée du processus de sauvegarde. Deux algorithmes de compression sont proposés : GZIP et LZ4.
L'algorithme GZIP[120] permet plusieurs niveaux de compression de 1 à 9. Au delà de 6, le gain en place est faible par rapport aux niveaux immédiatement inférieurs, tandis que la durée de traitement s'allonge sensiblement.
L'algorithme LZ4[121] offre un taux de compression moindre que le niveau de compression 6 de GZIP mais est significativement plus rapide.
Remarque
L’utilisation de l’algorithme de compression LZ4 nécessite que Bareos ait été compilé avec le support de ce dernier. Dans le cas où Bareos n’aurait pas été compilé avec celui-ci, un message d’avertissement est émis au moment de la sauvegarde et aucune compression n’est effectuée. Les modules EOLE en version supérieure ou égale à 2.7.1 bénéficient d’une version de Bareos avec le support de LZ4 activé. Pour les autres clients, l’administrateur système doit s’assurer que ce support est également activé.
Le champ
Mot de passe du directeurcontient le mot de passe à transmettre aux applications distantes pour leur permettre de s'authentifier auprès du directeur.
Configuration du stockage
Le service de stockage gérant l'écriture des volumes de sauvegardes (bareos-sd ) peut être local ou distant, il est local par défaut. Dans ce cas aucun paramètre supplémentaire n'est à configurer dans cet onglet (Directeur Bareos).
Dans le cas d'un serveur de stockage distant (Le gestionnaire du stockage est local à non), il faut configurer le nom, l'adresse IP et le mot de passe du serveur de stockage distant.
Pour autoriser des directeurs à se connecter au présent stockage des paramètres se trouvent dans l'onglet Stockage bareos.
Attention
Certaines infrastructures nécessitent une dégradation des fonctionnalités des modules EOLE comme la désactivation des mises à jour automatiques pour que la sauvegarde distante fonctionne correctement.
Le déport du service bareos-sd sur un autre serveur que bareos-dir ne permet pas de gérer correctement les verrous des tâches d'administration sur ce serveur : bareos-dir ne permet pas de signaler efficacement à bareos-sd qu'une sauvegarde est lancée et qu'il doit poser un verrou empêchant les autres tâches d'administration.
Configuration de la sauvegarde de fichiers distants
Il est possible de déclarer plusieurs clients distants pour gérer la sauvegarde des fichiers d’autres serveurs.
Cette déclaration de clients distants peut être effectuée une fois la variable Activer la sauvegarde de fichiers distants passée à oui.
La déclaration d’un client distant nécessite de fournir plusieurs informations obligatoires.
Identifiant du client distant: identifiant interne unique utilisé pour distinguer la configuration du client, composé de lettres non accentuées et de chiffres ;Nom du client distant: le nom du service bareos-fd tel que renseigné sur le serveur distant l’hébergeant ;Adresse du client distant: l’adresse IP à laquelle ce client peut être joint ;Mot de passe du client distant: le mot de passe, identique à celui déclaré sur le client distant (cf. configuration d’un client indépendant).
Remarque
L’activation du service de lecture/écriture de fichiers (file server, bareos-fd) sur le serveur lui-même pour sauvegarder les fichiers locaux s’effectue dans l’onglet Services.
Onglet Stockage Bareos
L'onglet Stockage bareos apparaît dans l'interface de configuration du module si le support de stockage de sauvegarde est activé dans l'onglet Services (Activer le stockage de sauvegarde à oui).
L'onglet permet de configurer le nom du serveur de stockage et permet également d'autoriser des directeurs à se connecter au présent stockage.
Dans l'onglet Stockage bareos il est possible de choisir un nom de serveur de stockage et d'autoriser des directeurs distants à se connecter au présent serveur de stockage.
Autoriser un ou plusieurs directeurs distants à se connecter
Pour autoriser un ou plusieurs directeurs distants à se connecter il faut cliquer sur + Nom du directeur Bareos distant, le détail de l'autorisation s'affiche.
Pour ce faire il faut se munir des paramètres du directeur distant :
son nom ;
son adresse IP ;
son mot de passe.
Attention
Les sauvegardes sont des informations sensibles. Il ne faut pas utiliser de mot de passe facilement déductible.
Onglet Client bareos
L'onglet Clients bareos apparaît dans l'interface de configuration du module si la sauvegarde des fichiers locaux est activée (Activer la sauvegarde des fichiers locaux à oui).
L'onglet permet de configurer le nom du serveur de sauvegarde des fichiers locaux.
Le service de lecture/écriture de fichiers (file server, bareos-fd) de Bareos, autrement appelé client, ne nécessite pas de configuration dans le cas où le directeur (service director, bareos-dir) est également activé localement.
Dans le cas où on souhaite que la sauvegarde des fichiers du serveur soit gérée par un directeur distant, il est nécessaire de désactiver le service director local en passant la variable Activer le directeur de sauvegarde à non puis d’activer le service file local en passant la variable Activer la sauvegarde des fichiers locaux à oui, en mode expert, dans l’onglet Services.
À l’issue de cette manipulation, l’onglet Client Bareos est disponible.
Dans l’onglet Client Bareos, le service directeur distant est configuré au moyen de trois variables obligatoires :
l’adresse du directeur Bareos distant ;
le nom du directeur Bareos distant tel qu’il est défini dans la configuration du directeur dans l'onglet
Directeur bareos;le mot de passe distant, identique à celui déclaré dans la configuration du directeur dans l'onglet
Directeur bareos.
Attention
Les services Bareos partagent certaines variables de configuration et il faut veiller à la cohérence des valeurs entrées, notamment pour les noms des services et les mots de passe.
L'onglet Clients bareos apparaît dans l'interface de configuration du module si la sauvegarde des fichiers locaux est activée (Activer la sauvegarde des fichiers locaux à oui).
L'onglet permet de configurer le nom du serveur de sauvegarde des fichiers locaux.
Le service de lecture/écriture de fichiers (file server, bareos-fd) de Bareos, autrement appelé client, ne nécessite pas de configuration dans le cas où le directeur (service director, bareos-dir) est également activé localement.
Dans le cas où on souhaite que la sauvegarde des fichiers du serveur soit gérée par un directeur distant, il est nécessaire de désactiver le service director local en passant la variable Activer le directeur de sauvegarde à non puis d’activer le service file local en passant la variable Activer la sauvegarde des fichiers locaux à oui, en mode expert, dans l’onglet Services.
À l’issue de cette manipulation, l’onglet Client Bareos est disponible.
Dans l’onglet Client Bareos, le service directeur distant est configuré au moyen de trois variables obligatoires :
l’adresse du directeur Bareos distant ;
le nom du directeur Bareos distant tel qu’il est défini dans la configuration du directeur dans l'onglet
Directeur bareos;le mot de passe distant, identique à celui déclaré dans la configuration du directeur dans l'onglet
Directeur bareos.
Attention
Les services Bareos partagent certaines variables de configuration et il faut veiller à la cohérence des valeurs entrées, notamment pour les noms des services et les mots de passe.
Pour que les modifications soient prises en compte, une reconfiguration du module est nécessaire à l'aide de la commande reconfigure.
Gestion des bases de données avec EoleDB
EoleDB est disponible depuis la version 2.5.2 d'EOLE. C'est une re-implémentation de l'ancien gestionnaire des bases de données EOLE (eole-sql) dont les objectifs principaux sont :
n'utiliser qu'un seul fichier de configuration ;
supporter nativement plusieurs types de bases de données (MySQL, PostgreSQL, SQLite, ...) ;
supporter nativement l'externalisation des bases de données sur d'autres serveurs ;
ne plus avoir à fournir des scripts python dans les paquets d'application web du projet EOLE pour pouvoir générer ou mettre à jour des bases de données (cf eole-sql :
/usr/share/eole/applications/gen/,/usr/share/eole/applications/passwords/,/usr/share/eole/applications/updates/).
EoleDB rend possible l'externalisation des bases de données d'un module EOLE.
Remarque
Pour le moment, EoleDB gère uniquement les bases de données MySQL[97] et PostgreSQL[59].
Installation d'EoleDB
L'installation d'EoleDB se fait manuellement sur le serveur qui héberge l'application web avec la commande apt-eole :
# apt-eole install eole-db
Remarque
Le paquet eole-db est pré-installé sur le module Scribe depuis la version 2.6.0.
Configuration d'EoleDB
Par défaut le serveur de base de données est paramétré comme étant local. Dans le cas où le serveur est distant quelques variables sont à renseigner.
Adresse du serveur de base de données: adresse IP, nom de machine ou nom de domaine du serveur de base de données distant. Cette valeur est utilisée pour toutes les applications web qui ne définiront pas elles-mêmes un serveur de base de données.Port du serveur de base de données: port du serveur de base de données utilisé, par exemple3306pour le serveur MySQL fourni par EOLE.Nom d'utilisateur d'administration: identifiant du gestionnaire de la base de données distante.Fichier de mot de passe: chemin d'accès vers le fichier qui contient le mot de passe du gestionnaire, par exemple/root/bdpass.txt. Ce fichier doit être accessible par EoleDB, idéalement le fichier doit avoir les droits 600.Machines qui peuvent utiliser le serveur de BDD: permet d'autoriser des machines à accéder à l'administration des bases distantes #fixme, si rien n'est renseigné l'adresse IP du serveur utilisant EoleDB est ajoutée automatiquement dans le fichier de configuration.
Exemple
dbhost: 192.168.0.24
dbport: 3306
dbroot: root
client_hosts: ['192.168.0.26']
dbrootpwd: /root/bdpass.txt
Le fichier /root/bdpass.txt est un fichier à créer, il contient le mot de passe en clair du gestionnaire. Ce fichier doit être accessible par EoleDB, idéalement le fichier doit avoir les droits 600.
Configuration d'une application web
Les applications web disponibles sur les modules EOLE fournissent un fichier de configuration au format YAML[143] qui surcharge le fichier de configuration principal d'EoleDB.
Ces fichiers de configuration spécifiques aux applications redéfinissent le comportement par défaut d'EoleDB, ils sont stockés dans /etc/eole/eole-db.d/.
Pour des raisons pratiques, EoleDB réalise le changement de mots de passe dans les fichiers de configuration des applications.
Les mots de passe sont changés à chaque lancement des commandes eole_db_gen et reconfigure.
Pour utiliser EoleDB il faut mettre en place un fichier de configuration portant l'extension .yml dans le répertoire /etc/eole/eole-db.d/ en utilisant :
dbhost : définition de l'adresse du serveur de base de données utilisé par l'application (surcharge la valeur par défaut définie dans
/etc/eole/eole-db.conf) ;dbport : définition du port d'écoute du serveur de base de données utilisé par l'application (surcharge la valeur par défaut définie dans
/etc/eole/eole-db.conf) ;dbroot : définition du nom de l'utilisateur ayant des droits "Administrateur" sur le serveur de base de données utilisé par l'application (surcharge la valeur par défaut définie dans
/etc/eole/eole-db.conf) ;dbrootpwd : définition du mot de passe par défaut de l'utilisateur défini par l'option dbroot (surcharge la valeur par défaut définie dans
/etc/eole/eole-db.conf) ;dbtype : définition du type de base de données par défaut du serveur de base de données (mysql, pgsql, sqlite, ...) ;
dbname : nom de la base de données de l'application ;
dbuser : nom de l'utilisateur utilisé par l'application pour accéder à la base définie dans dbname ;
dbpass : mot de passe utilisé par l'application pour l'utilisateur défini dans dbuser ;
createscript : script SQL de création de la base de données définie dans dbname ;
sqlscripts : scripts SQL a lancer après le script de création défini dans createscript ;
updatescripts : scripts de mise à jour exécutés sur la base définie dans dbname (exécutés uniquement si la base existe déjà) ;
pwd_files : définition des fichiers à mettre à jour après le changement du mot de passe de l'utilisateur défini dans dbuser.
Exemple
dbtype: mysql
dbname: taskfreak
dbuser: taskfreak
dbpass: "53nrgk>as="
createscript: "/usr/share/eole/db/taskfreak/gen/taskfreak-create.sql"
pwd_files:
- {file: '/var/www/html/taskfreak/include/config.php',pattern: '$dbpass="',
owner: 'www-data:www-data',
mod: '600' }
Truc & astuce
L'option pwd_files accepte une liste de dictionnaires au format python.
Exemple
pwd_files:
- {file: '/var/www/html/posh/includes/config.inc.php',container: 'web',
pattern: 'define("__PASS","',end_pattern: ');',
owner: 'root:www-data',
mod: '660' }
- {file: '/usr/share/envole/eoledb/posh',pattern: 'dbpassPOSH="',
owner: 'root:root',
mod: '600' }
Liste des options possibles d'un dictionnaire pwd_files :
file : chemin complet du fichier à modifier (option obligatoire) ;
pattern : modèle de ligne qui contient le mot de passe entre " (option obligatoire) ;
end_pattern : permet de définir le ou les caractères à ajouter après le pattern ;
owner : propriétaire au format "user:group", à définir après la modification du mot de passe ;
mod : droits au format Unix (ex: 600) à définir après la modification du mot de passe ;
container : conteneur ou se trouve le fichier à modifier.
Attention
L'option pattern permet de définir le modèle de ligne qui contient le mot de passe, il est important de définir la totalité de ce qui précède le mot de passe dans la ligne.
Exemple
Ligne à changer dans le fichier de configuration /chemin/monFichier.conf :
password: "JeSuiSunMauvaisPassowrd"
La valeur de l'option pattern doit être password: "
Extrait du fichier YAML :
pwd_files:
- {file: "/chemin/monFichier.conf",
pattern: 'password: "'
EoleDB détermine automatiquement qu'il faut faire suivre, après remplacement, la valeur de pattern par le caractère ". Aussi si le caractère ouvrant est ' il faut préférer le format suivant :
pattern: "password: '"
EoleDB détermine automatiquement qu'il faut faire suivre la valeur de pattern par le caractère '.
EoleDB détecte également si le caractère ; est requis en fin de ligne et l'ajoute après le pattern.
Truc & astuce
L'option end_pattern permet de maîtriser des cas non gérés par EoleDB, exemple
define('DBPASS': 'JeSuisUnMauvaisPassword');
pattern : "define('DBPASS': '"
end_pattern: ");",
Pour une application 3 modes de gestion de la base de données sont possibles et sont fonctions de la configuration :
mode default : l'application utilise la configuration globale d'EoleDB ;
mode local : l'application force l'utilisation d'un serveur de base de données local ;
mode externe : l'application force l'utilisation d'un serveur de base de données et définit complètement la configuration.
Le mode default
Dans le mode default, l'application ne prend donc aucune liberté et sa configuration repose exclusivement sur la configuration d'EoleDB saisie dans l'onglet Eoledb de l'interface de configuration du module.
Exemple
dbtype: mysql
dbname: taskfreak
dbuser: taskfreak
dbpass: "53nrgk>as="
createscript: "/usr/share/eole/db/taskfreak/gen/taskfreak-create.sql"
pwd_files:
- {file: '/var/www/html/taskfreak/include/config.php',pattern: '$dbpass="',
owner: 'www-data:www-data',
mod: '600' }
Attention
Si le comportement d'EoleDB est changé, celui-ci impactera l'application.
Le mode local
Dans le mode local la configuration de l'application à utiliser un serveur de base de données local, il faut donc ajouter dans la configuration dbhost et client_hosts.
La configuration d'EoleDB saisie dans l'onglet Eoledb de l'interface de configuration du module est ignorée.
Exemple
---
dbhost: 127.0.0.1
dbtype: mysql
dbname: taskfreak
dbuser: taskfreak
dbpass: "task;Freak"
client_hosts: ["127.0.0.1", "localhost"]
createscript: "/usr/share/eole/mysql/taskfreak/gen/taskfreak-create.sql"
pwd_files:
- {file: '/var/www/html/taskfreak/include/config.php',pattern: '$dbpass="',
owner: 'www-data:www-data',
mod: '600' }
Le mode externe
Dans le mode externe l'application définie complètement le serveur externe de base de données à utiliser, il faut donc ajouter dans la configuration, en plus de dbhost et client_hosts ajouté dans le mode local, dbroot et dbrootpwd.
La configuration d'EoleDB saisie dans l'onglet Eoledb de l'interface de configuration du module est ignorée.
Exemple
---
dbhost: 192.168.45.34
dbport: 3309
dbroot: adminDB
dbrootpwd: /root/.secrets-mydb
dbtype: mysql
dbname: taskfreak
dbuser: taskfreak
dbpass: "task;Freak"
client_hosts: ["127.0.0.1", "localhost", "192.168.0.14" ]
createscript: "/usr/share/eole/mysql/taskfreak/gen/taskfreak-create.sql"
pwd_files:
- {file: '/var/www/html/taskfreak/include/config.php',pattern: '$dbpass="',
owner: 'www-data:www-data',
mod: '600' }
Mode conteneur
Pour fonctionner dans un conteneur EOLE, sur le module AmonEcole par exemple, l'application doit utiliser le mode local avec une configuration adaptée.
Configuration du serveur distant
Tester la connexion distante au serveur de base de données
# mysql -u admin -h <adresseDuServeur> -p<motDePasse>
Serveur Eolebase
Le serveur EOLE peut être l'un des modules ou un Eolebase.
Installer le paquet eole-adminer, le système de dépendance se charge d'installer les paquets nécessaires eole-web et eole-mysql :
root@eolebase:~# apt-eole install eole-adminer
Éditer le configuration du serveur à l'aide de la commande de l'interface de configuration du serveur :
root@eolebase:~# gen_config
Dans l'onglet t Applications web, la variable minimum à renseigner est Nom de domaine des applications web (sans http://), il est possible d'activer l'application Adminer et de la choisir comme application web par défaut.
Reconfigurer le serveur à l'aide de la commande reconfigure :
root@eolebase:~# reconfigure
Vérifier dans un navigateur web que le serveur répond.
Modifier le mot de passe par défaut du compte root mysql avec la commande mysql_pwd.py :
root@eolebase:~# mysql_pwd.py
## Réinitialisation des mots de passe Mysql ##
Nouveau mot de passe root mysql : eole21
Voulez-vous que les autres mots de passe soient modifiés ? [oui/non][non] : non
root@eolebase:~#
Se connecter à MySQL avec l'utilisateur root :
root@eolebase:~# mysql -u root -h localhost -peole21
Créer un utilisateur autre que root (le mot de passe du compte root est généré à chaque reconfigure) et lui donner les privilèges et l'autorisation de se connecter depuis le serveur hébergeant EoleDB :
mysql> grant all privileges on *.* to admin@<IPServeurEoleDB> identified by "eole21";
mysql> quit
Pour ouvrir le port il faut faire un dictionnaire personnalisé 00_mysql.xml à placer dans /usr/share/eole/creole/dicos/local/
<creole> <files><service_access service='mysql'>
<port>3306</port>
<tcpwrapper>mysqld</tcpwrapper>
</service_access> </files><variables />
<constraints />
<help />
</creole><!-- vim: ts=4 sw=4 expandtab-->Pour qu'il soit pris en compte il faut procéder à la reconfiguration du serveur :
root@eolebase:~# reconfigure
Vérifier la connexion entre le serveur hébergeant EoleDB et le serveur Eolebase :
root@scribe:~# mysql -u admin -h <IPServeurEoleDB> -peole21
mysql>
Remarque
À partir de la version 2.6.1 il n'est plus nécessaire de procéder à l'ouverture de port à l'aide d'un dictionnaire. En effet, depuis cette version, l'onglet expert Mysql permet de déclarer des adresses IP ou des réseaux autorisés à accéder à MySQL.
Serveur non EOLE
Exemple d'une distribution GNU/Linux supportant le système de paquet debian.
Installation du serveur de base de données :
# apt-get install mysql-server
Se connecter à MySQL avec l'utilisateur root :
# mysql -u root -h localhost -p<motDePasse>
Créer un utilisateur autre que root (le mot de passe du compte root est généré à chaque reconfigure) et lui donner les privilèges et l'autorisation de se connecter depuis le serveur hébergeant EoleDB :
mysql> grant all privileges on *.* to admin@<IPServeurEoleDB> identified by "<motDePasse>";
mysql> quit
Vérifier la connexion entre le serveur hébergeant EoleDB et le serveur hébergeant la base de données :
root@scribe:~# mysql -u admin -h <IPServeurEoleDB> -peole21
mysql>
Appliquer la configuration EoleDB
Pour que les changements soient pris en compte il faut exécuter la commande eole_db_gen.
L'appel de cette commande eole_db_gen doit au minimum préciser le répertoire utilisé pour sauvegarder les fichiers modifiés par EoleDB avec l'option -b.
Exemple
root@scribe:~# eole_db_gen -b /var/backup/eole-dbTASKFREAK :
>>> Passwords [OK]
>>> Create [OK]
>>> Update [OK]
root@scribe:~#La commande utilise les fichiers de configuration par défaut d'eoleDB, mais il est possible de préciser d'autres fichiers de configuration :
-c : permet de définir un fichier de configuration a utiliser à la place de
/etc/eole/eole-db.conf-d : permet de définir un répertoire différent de
/etc/eole/eole-db.d/et qui contient les fichiers de configuration des applications
Truc & astuce
Pour connaître les différents paramètres de la commande eole_db_gen :
# eole_db_gen --help