Skip navigation
Une nouvelle fonctionnalité de Duo permet aux utilisateurs d’éviter les problèmes de RPV

Une nouvelle fonctionnalité de Duo permet aux utilisateurs d’éviter les problèmes de RPV

C’est la fin d’une histoire bien connue de frustration pour les utilisateurs qui essaient d’accéder aux ressources internes de l’entreprise. 

La fonctionnalité de protocole de bureau à distance (RDP) de la passerelle Duo Network Gateway demande aux utilisateurs de s’authentifier uniquement lorsque cela est nécessaire, au lieu de devoir d’abord essayer et échouer, ce qui les force à réessayer après s’être connectés au réseau privé virtuel (RPV) de l’entreprise.

Maintenant que cette fonctionnalité qui réduit la friction est en aperçu public, nous voulions partager une perspective interne sur son fonctionnement et sur ce qui a éclairé notre conception.

Une histoire bien connue

Nous connaissons tous très bien l’état actuel de l’accès à distance à l’aide d’un RPV :

  • Vous essayez d’accéder au site Web interne de l’entreprise.

  • Vous n’êtes pas capable d’accéder au site Web interne de l’entreprise.

  • Vous vous demandez brièvement pourquoi ça ne fonctionne pas.

  • Vous vous connectez au RPV.

  • Vous essayez d’accéder de nouveau au site Web interne de l’entreprise et espérez réussir.

La passerelle Duo Network Gateway (DNG), une passerelle proxy d’accès à distance sans RPV, résout élégamment ce problème pour les sites Web, en simplifiant l’expérience de l’utilisateur final :

  • Vous essayez d’accéder au site Web interne de l’entreprise.

  • On vous demande de vous authentifier auprès de votre fournisseur d’identité (FID).

  • On vous demande d’effectuer une authentification multifactorielle avec Duo.

Vous accédez au site Web interne de l’entreprise.

Les utilisateurs finaux ne se font demander de s’authentifier que si leur session expire ou si elle est résiliée par un administrateur.

Un processus centré sur l’utilisateur

Nous aimons ce processus : vous faites ce que vous voulez faire et vous pourriez avoir à vous authentifier au besoin. Nous n’aimons pas ce processus : vous faites ce que vous voulez faire, mais si ça échoue, vous devez penser à ce que vous devez faire ensuite. 

 

Pour les connexions par SSH, la DNG et DuoConnect (notre client léger pour l’accès à distance) peuvent tirer parti de la capacité « ProxyCommand » du client SSH, qui permet aux administrateurs de modifier les configurations SSH et de spécifier que certaines connexions doivent utiliser DuoConnect avec des arguments spécifiques.

 

Avec la DNG, se connecter à un serveur SSH est aussi simple et facile que d’accéder à un serveur Web : lancez la connexion par SSH et vous serez invité à vous authentifier au moyen d’une page Web, au besoin. Sinon, la DNG n’intervient pas.

 

Malheureusement, d’autres protocoles, en particulier le RDP, n’ont pas d’option « proxy » comparable pour spécifier un relais et un hôte (comme SSH) et ils ne contiennent pas suffisamment d’information pour permettre à DuoConnect et à la DNG de déduire la destination et l’état d’authentification d’une demande entrante (comme HTTP[s]/Web).

 

Nous avons travaillé fort pour reproduire cette expérience fluide pour les connexions par RDP. Avec la nouvelle architecture, si un utilisateur (par exemple, Suzanne) souhaite se connecter à son bureau (à l’adresse ordinateur-suzanne.exemple.local par exemple) qui se trouve à l’intérieur du réseau de l’entreprise, elle n’a qu’à accéder à son client RDP et à se connecter à ordinateur-suzanne.rdp.exemple.com. Se elle doit s’authentifier, un navigateur s’affichera et lui demandera de le faire. Sinon, la connexion est transparente. Vous remarquerez que les noms d’hôte utilisés pour se connecter ici sont différents, ce qui sera expliqué dans les prochains paragraphes.

Modalités

La DNG utilise deux composantes pour que cela fonctionne : les relais et les sous-domaines.

 

Comme les relais SSH, les relais RDP servent de point de relais du trafic au réseau interne et de point d’authentification. Vous pouvez protéger plusieurs serveurs RDP avec un relais RDP et le relais aurait son propre nom d’hôte (par exemple, relais-rdp.exemple.com).

 

En l’absence d’une configuration « proxy », nous comptons sur la délégation d’un sous-domaine à la DNG. Vous configurez la DNG avec une paire externe/interne de sous-domaines, où le sous-domaine externe est délégué par votre domaine principal à la DNG, et le sous-domaine interne en est un qui peut être résolu au sein du réseau d’entreprise.

 

Par exemple, si le nom de l’entreprise est « Exemple, inc. » et qu’il possède exemple.com, l’administrateur de domaine peut déléguer rdp.exemple.com à la DNG (par l’entremise d’un DNS public) et régler la configuration des sous-domaines de la DNG pour que rdp.exemple.com corresponde à exemple.local. 

 

Lorsque Suzanne tente de se connecter à ordinateur-suzanne.rdp.exemple.com, la DNG reçoit la demande, la met en relation avec la configuration de relais existante et la configuration de sous-domaines, attribue une adresse IP temporaire aléatoire au nom ordinateur-suzanne.rdp.exemple.com et la renvoie au client RDP.

Comme les relais SSH, les relais RDP servent de point de relais du trafic au réseau interne et de point d’authentification.
Illustration de l’appareil de l’utilisateur amorçant une connexion au serveur RDP. Le chemin de requête réel peut différer.

Lorsque l’attribution temporaire d’une adresse IP est reçue, la connexion est acheminée en interne vers l’application DuoConnect installée. À la réception de la connexion, DuoConnect contacte la DNG configurée pour démarrer le processus d’authentification (si nécessaire) et la connexion tunnel par le relais RDP à relais-rdp.exemple.com. 

 

Si vous avez acheté Duo Beyond, vous pouvez participer à l’aperçu public du soutien du protocole RDP pour la passerelle Duo Network Gateway. 

 

Nous espérons que vous aimerez utiliser cette nouvelle fonctionnalité de la passerelle Duo Network Gateway. Nous sommes très enthousiastes de celle-ci!