Comprendre WALLIX · WCP 12

WALLIX : applications RDS et AppDriver

Publier une application via RDP, distinguer le compte RDS du compte applicatif et comprendre le rôle de Session Probe et d’AppDriver.

Thomas SAUTIER · Publié le · Révisions de certification

Références et objectifs de certification (1)

Ce guide aborde le périmètre Bastion 12. Les menus, options et compatibilités peuvent évoluer avec les correctifs et la version d’Access Manager : vérifiez la documentation correspondant à votre environnement avant une configuration.

Comprendre le fonctionnement

Une application publiée permet d’ouvrir un programme plutôt qu’un bureau complet. Il faut distinguer trois accès : l’utilisateur au Bastion, le compte qui ouvre la session RDS et le compte éventuellement utilisé dans l’application. Un échec de login applicatif ne signifie donc pas que RDP a échoué.

Ce guide distingue des applications sans compte, avec compte secondaire et avec mapping. AppDriver aide à injecter les identifiants dans des applications web au travers d’un navigateur Chromium hébergé sur RDS. Cette publication repose sur RDP, pas sur une session SSH.

Repère visuelWALLIX : applications RDS et AppDriver
WALLIX : applications RDS et AppDriver Bastion ouvre une session sur RDS. La sonde ou AppDriver participe au lancement et au pilotage du programme, qui peut nécessiter un compte applicatif distinct. 01 Bastion Application publiée 02 RDS Session Windows 03 Application Login applicatif 04 Sonde / Driver Lancement et pilotage
Bastion ouvre une session sur RDS. La sonde ou AppDriver participe au lancement et au pilotage du programme, qui peut nécessiter un compte applicatif distinct.

Construire et vérifier la configuration

  1. Préparer le serveur RDS, sa collection et les droits de connexion du compte qui hébergera le programme.
  2. Choisir le mode de lancement selon Session Probe. La configuration distingue la publication de cmd.exe avec les paramètres attendus lorsque la sonde lance le programme, et la publication directe de l’application sinon.
  3. Déclarer l’application, son chemin et ses arguments. Pour une application avec compte, employer les variables prises en charge plutôt qu’un secret fixé dans la configuration.
  4. Ajouter le compte applicatif dans son domaine si nécessaire, puis publier la méthode d’accès dans le groupe cible.
  5. Tester le lancement, l’authentification applicative et la fermeture. Pour AppDriver, vérifier le navigateur, les paramètres et les éléments d’interface ciblés.

Les choix à retenir

Reliez chaque réglage à son effet sur l’accès et à la vérification associée.

WALLIX : applications RDS et AppDriver : points de décision
ÉlémentRôle ou effetVérification
Compte RDSOuvre la session WindowsDroits sur la collection
Compte applicatifAuthentifie dans le programmeDomaine, login et secret corrects
Session ProbeLance et observe le programmeSonde démarrée sur la cible
AppDriverPilote le navigateur webParamètres adaptés à l’application

Diagnostiquer sans masquer le problème

Une variable de secret ne garantit pas qu’il sera invisible dans une ligne de commande ou un journal. Pour les automatisations sensibles, étudier le mécanisme de canal virtuel présenté dans le parcours WCE.

Une mise à jour de l’application ou de la page de login peut casser son pilotage. Valider le lancement et le login séparément ; conserver un compte de lab sans droits de production.

Exercice de compréhension

Windows s’ouvre correctement mais le programme refuse le login. Quel compte faut-il examiner en premier ?

Voir le corrigé

Le compte applicatif et la manière dont ses identifiants sont transmis. Le compte RDS a déjà permis l’ouverture de Windows ; cela ne valide pas l’identité utilisée dans le programme.

Pour approfondir

Continuer le parcours WCP 12

Retrouver les 20 guides du parcours WCP 12

Un autre angle sur ces sujets

Découvrir l’accompagnement WALLIX de Samhan

Échange

Un projet d’accès privilégiés ?

Échangeons sur vos identités, vos flux d’administration et vos contraintes d’exploitation.