Résolution de nom de serveur

Okta Privileged Access met en œuvre un système de résolution de noms personnalisé, utilisé pour résoudre les noms fournis par les utilisateurs vers un serveur enregistré auprès d'Okta Privileged Access.

Par exemple, si vous exécutez sft ssh web0, le nom web0 sera résolu dans Okta Privileged Access. De la même manière, si l'agent sur web0 dispose d'un fichier de configuration qui spécifie Bastion: bastion.example.com, alors bastion.example.com est résolu afin d'établir un tunnel vers web0.

Si Okta Privileged Access ne parvient pas à résoudre un nom vers un serveur inscrit, il utilisera une résolution de nom et des méthodes d'authentification en local pour accéder au serveur. Par exemple, si vous exécutez sft ssh web0.example.com et que Okta Privileged Access ne parvient pas à résoudre web0.example.com vers un serveur inscrit dans Okta Privileged Access, alors le client se comportera comme si vous aviez exécuté ssh web0.example.com sans utiliser Okta Privileged Access.

Serveurs actifs

Okta Privileged Access n'établit une correspondance qu'entre des noms et des serveurs actifs. Un serveur est considéré comme actif si les conditions suivantes sont remplies :

  1. Le serveur a été enrôlé dans Okta Privileged Access
  2. Le serveur n'a pas été supprimé ultérieurement d'Okta Privileged Access
  3. L'agent Okta Privileged Access était récemment exécuté sur le serveur et en mesure d'établir une liaison avec la plateforme Okta Privileged Access. Actuellement, le seuil est de 96 heures (4 jours), mais des modifications peuvent survenir.

Dans un cas particulier, si un serveur non géré est créé dans Okta Privileged Access, il est considéré comme actif jusqu'à ce qu'il soit supprimé.

Correspondance

Lors de la résolution d'un nom, Okta Privileged Access cherchera tout serveur correspondant à l'une des valeurs suivantes.

ID serveur

Le id du serveur, un UUID aléatoire automatiquement affecté par la plateforme Okta Privileged Access durant l'enrôlement.

Nom d'hôte

Le hostname du serveur, tel qu'indiqué par le système d'exploitation sur le serveur. Si le nom d'hôte du système d'exploitation se termine par local, cette partie est ignorée par la plateforme. Par exemple, si le nom d'hôte du système d'exploitation est web0.local, vous pouvez accéder au serveur en tant que web0, mais pas en tant que web0.local.

Si une valeur CanonicalName est spécifiée dans la configuration de l'agent Okta Privileged Access, alors cette valeur sera utilisée à la place du nom d'hôte du système d'exploitation.

AltNames

Toute valeur AltNames spécifiée dans le fichier de configuration de l'agent Okta Privileged Access sur le serveur. AltNames peut être utilisée pour ajouter d'autres alias sur des serveurs.

Adresse IP par défaut

L'adresse IP par défaut du serveur, comme déterminé par Okta Privileged Access.

ID de l'instance

Si le serveur est une instance cloud AWS ou GCE, alors il s'agit de l'ID de l'instance assigné par le fournisseur.

Noms ambigus

Si un nom fourni au client d'Okta Privileged Access se résout vers plusieurs serveurs, le client renverra une erreur afin d'éviter toute connexion involontaire à un serveur erroné.

L'un des effets collatéraux de cela est que, si un serveur est remplacé par un nouveau serveur portant le même nom d'hôte, ou si l'agent est contraint à une réinscription, un administrateur devra supprimer manuellement l'enregistrement du serveur initial avant que le nom partagé puisse s'adresser au nouveau serveur. Il est également possible de spécifier un nom sans ambiguïté, tel que l'ID serveur, ou d'attendre que l'enregistrement du serveur initial devienne inactif.

Si le nom d'un Bastion fourni dans une configuration de l'agent Okta Privileged Access est ambigu, la plateforme Okta Privileged Access essaiera de choisir l'option la plus adéquate en classant les correspondances par ordre de préférence décroissant et en associant les éléments suivants :

  1. id ou CanonicalName
  2. ID de l'instance cloud
  3. Nom d'hôte
  4. AltNames
  5. Adresse IP par défaut

Les liens sont rompus de façon arbitraire.

Adresses IP

Une fois un serveur résolu, Okta Privileged Access essaie de déterminer quelle adresse IP doit être utilisée pour établir une liaison avec le serveur.

Si l'on peut accéder au serveur directement via le client Okta Privileged Access, ce dernier tentera d'utiliser l'adresse IP par défaut du serveur comme décrit dans la section ci-après.

Si l'on accède au serveur via un ou plusieurs bastions, et que le bastion précédent se situe dans le même réseau GCE, VPC ou AWS que le serveur, lOkta Privileged Access privilégiera l'adresse IP privée correspondante du serveur. Dans le cas contraire, Okta Privileged Access utilisera l'adresse IP par défaut.

Adresse IP par défaut

Chaque serveur enrôlé dans Okta Privileged Access se voit assigner une adresse IP par défaut, correspondant à la première valeur disponible dans :

  1. une valeur AccessAddress spécifiée dans le fichier de configuration de l'agent Okta Privileged Access ;
  2. l'adresse public_ip_v4 d'une instance AWS, basée sur les métadonnées de l'instance ;
  3. l'adresse IP interne ou externe d'une instance GCE ou Azure, basée sur les métadonnées de l'instance ;
  4. l'adresse IPv4 à la valeur numérique la plus basse dans une plage d'adresses publiques ;
  5. l'adresse IPv4 à la valeur numérique la plus basse dans une plage d'adresses privées.

Rubriques connexes

Configurer l'agent serveur Okta Privileged Access