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
Subtasks
Related issues
History
#1 Updated by Joël Cuissinat about 3 years ago
- Description updated (diff)
#2 Updated by Gilles Grandgérard about 3 years ago
- Target version changed from sprint 2020 04-06 Equipe MENSR to Prestation Cadoles MEN 07-09
#3 Updated by Benjamin Bohard about 3 years ago
- Assigned To set to Benjamin Bohard
#4 Updated by Benjamin Bohard about 3 years ago
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 Updated by Benjamin Bohard about 3 years ago
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 Updated by Benjamin Bohard about 3 years ago
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 Updated by Joël Cuissinat about 3 years ago
- Related to Tâche #29572: Validation du scénario : Activer la demande de consentement Veyon added
#8 Updated by Benjamin Bohard about 3 years ago
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 Updated by Benjamin Bohard about 3 years ago
- Related to Scénario #17656: Seth : Envisager l'ajouter les zones de recherche inverse dans le DNS (PTR). added
#10 Updated by Benjamin Bohard about 3 years ago
La résolution inverse n’est pas disponible. J’ai retrouvé une demande dans le bac à idée à ce propos.
#11 Updated by Joël Cuissinat about 3 years ago
- Status changed from Nouveau to Terminé (Sprint)
#12 Updated by Joël Cuissinat about 3 years ago
- Related to Scénario #29706: Faire le point sur les évolutions Veyon added