Scénario #29460
Activer la demande de consentement Veyon
100%
Description
Retour de formation Cadoles :
Afin de rester dans les clous au niveau juridique, le plus simple est que l'utilisateur observé (y compris un élève) ait une fenêtre d'acceptation.
Solutions à mettre en œuvre¶
- À faire pour EOLE >= 2.7.1
- Déterminer et mettre en place l'option dans la configuration de Veyon
- Mettre à jour le test squash
- Mettre à jour la doc
Critères d'acceptation¶
- Test squash modifié passant
- Comportement indiqué dans la doc
Sous-tâches
Demandes liées
Historique
#1 Mis à jour par Joël Cuissinat il y a plus de 4 ans
- Description mis à jour (diff)
#2 Mis à jour par Gilles Grandgérard il y a environ 4 ans
- Version cible changé de sprint 2020 04-06 Equipe MENSR à Prestation Cadoles MEN 07-09
#3 Mis à jour par Benjamin Bohard il y a environ 4 ans
- Assigné à mis à Benjamin Bohard
#4 Mis à jour par Benjamin Bohard il y a environ 4 ans
Dans le système de contrôle d’accès, il y a un mécanisme d’action à exécuter à la connexion. L’une des actions est la demande d’autorisation à l’utilisateur connecté au poste.
https://docs.veyon.io/en/latest/admin/access-control-rules.html
#5 Mis à jour par Benjamin Bohard il y a environ 4 ans
Actuellement, le contrôle d’accès aux fonctionnalités de visionnage et de prise de contrôle est implémenté avec une liste blanche d’utilisateurs appartenant à des groupes passés en paramètre.
Pour activer la demande de permission, il faut abandonner le système de liste blanche pour celui des règles.
Une régle se compose d’une série de conditions et d’une action à effectuer si les conditions sont réunies.
La demande de permission est l’une des actions disponibles.
Parmi les conditions, la première permet d’effectuer un test sur l’appartenance de l’utilisateur se connectant à un groupe déterminé. Pour obtenir l’équivalent de la liste blanche, il faut donc deux règles (une pour chaque groupe de la liste blanche remplacée). Voir si certaines autres conditions seraient pertinentes (comme celle sur l’appartenance des deux postes au même emplacement).
Ne pas oublier une dernière règle pour interdire tout ce qui n’a pas été explicitement autorisé.
#6 Mis à jour par Benjamin Bohard il y a environ 4 ans
Le poste ouvrant la connexion n’est pas bien identifié. Par exemple, un etb1.pcprofs avec un nom du genre PC-322688.dompedago.etb1.lan semble se présenter comme pc-linux.dominexistant.lan.domsupp1.lan.
C’est visible lorsqu’on active la demande d’autorisation.
L’autre conséquence de ce comportement est qu’on ne peut pas activer la contrainte SameLocation pour n’autoriser que la connexion entre deux postes "au même endroit".
#7 Mis à jour par Joël Cuissinat il y a environ 4 ans
- Lié à Tâche #29572: Validation du scénario : Activer la demande de consentement Veyon ajouté
#8 Mis à jour par Benjamin Bohard il y a environ 4 ans
Ce qui se rapproche le plus du nom farfelu pc-linux.dominexistant.lan.domsupp1.lan se trouve dans les hôtes déclarés dans l’application de configuration du serveur Amon pour l’adresse 10.1.2.51.
Il semblerait que l’étape de récupération du FQDN pour le pc essayant de se connecter récupère une réponse envoyée par l’Amon plutôt que le serveur DNS associé à Samba.
#9 Mis à jour par Benjamin Bohard il y a environ 4 ans
- Lié à Scénario #17656: Seth : Envisager l'ajouter les zones de recherche inverse dans le DNS (PTR). ajouté
#10 Mis à jour par Benjamin Bohard il y a environ 4 ans
La résolution inverse n’est pas disponible. J’ai retrouvé une demande dans le bac à idée à ce propos.
#11 Mis à jour par Joël Cuissinat il y a environ 4 ans
- Statut changé de Nouveau à Terminé (Sprint)
#12 Mis à jour par Joël Cuissinat il y a environ 4 ans
- Lié à Scénario #29706: Faire le point sur les évolutions Veyon ajouté