Projet

Général

Profil

Scénario #29460

Activer la demande de consentement Veyon

Ajouté par Joël Cuissinat il y a environ 4 ans. Mis à jour il y a environ 4 ans.

Statut:
Terminé (Sprint)
Priorité:
Normal
Assigné à:
Début:
14/01/2020
Echéance:
28/02/2020
% réalisé:

100%

Points de scénarios:
2.0
Restant à faire (heures):
0.00 heure
Estimation basée sur la vélocité:
Release:
Liens avec la release:
Auto

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

Tâche #29577: Déterminer et mettre en place l’optionFermé

Tâche #29585: Mettre à jour les cas de testFerméBenjamin Bohard

Tâche #29613: Documenter la fonctionnalité de demande de consentementFerméBenjamin Bohard

Tâche #29627: Lorsque l'on exécute Veyon Master, une boîte de dialogue nous demande d'autoriser l'accès à notre propre machineFerméBenjamin Bohard


Demandes liées

Lié à Distribution EOLE - Tâche #29572: Validation du scénario : Activer la demande de consentement Veyon Fermé 05/02/2020
Lié à EOLE AD DC - Scénario #17656: Seth : Envisager l'ajouter les zones de recherche inverse dans le DNS (PTR). Terminé (Sprint) 17/10/2016 30/04/2020
Lié à eole-workstation - Scénario #29706: Faire le point sur les évolutions Veyon Terminé (Sprint) 24/04/2020 30/04/2020

Historique

#1 Mis à jour par Joël Cuissinat il y a environ 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

Formats disponibles : Atom PDF