Contrôleur de domaine Windows
Vous pouvez installer un agent de serveur Okta Privileged Access sur les contrôleurs de domaine Windows. Le serveur peut ensuite se connecter à votre environnement Active Directory (AD) pour découvrir des comptes privilégiés et permet aux administrateurs de gérer accès à ces comptes à l'aide de stratégies Okta Privileged Access.
Intégration d'Okta Privileged Accessavec AD
La gestion des comptes AD et l'accès aux contrôleurs de domaine requièrent une configuration spécifique au sein des règles de compte AD de Okta Privileged Access. Pour activer l'accès RDP aux contrôleurs de domaine via Okta Privileged Access, les configurations suivantes sont requises au sein des règles de compte AD de Okta Privileged Access :
-
Les comptes AD doivent être gérés par Okta Privileged Access.
-
Les comptes AD requis et les serveurs du contrôleur de domaine cibles doivent tous deux être configurés de manière explicite dans le cadre de la règle.
Pour une connexion via le protocole RDP, les comptes AD doivent disposer de permissions RDP par le biais d'une politique de groupe ou d'un autre mécanisme.
Permission de l'agent du serveur Okta Privileged Access dans AD.
Afin de limiter les risques de perturbation de votre environnement AD, Okta empêche la modification des contrôleurs de domaine et des groupes AD, tels que les administrateurs, par l'agent de serveur.
-
L'accès des contrôleurs de domaine est géré exclusivement par le biais des comptes et autorisations existants du domaine. Les comptes utilisateur Okta individuels ne sont ni créés ni supprimés sur le serveur. Par exemple, votre org peut avoir une stratégie qui accorde un accès temporaire au serveur pour les utilisateurs à des fins de dépannage. Cependant, cette stratégie ne peut pas être appliquée à un contrôleur de domaine, car l'agent de serveur ne crée pas de comptes utilisateur Okta individuels dans ce cas.
-
L'agent du serveur Okta Privileged Access n'analyse pas le contrôleur de domaine pour identifier ou gérer les mots de passe des comptes du domaine.
-
Les administrateurs des groupes locaux de domaine et les utilisateurs du bureau à distance ne peuvent pas être modifiés, et aucun autre groupe n'est affecté.
Lorsque Okta Privileged Access approvisionne un compte persistant sur un serveur Windows, il vérifie s'il existe un utilisateur Active Directory (AD) dans l'OU de l'utilisateur avec un nom d'utilisateur Windows correspondant. S'il y a une correspondance, Okta Privileged Access prend immédiatement le contrôle de l'objet AD, change son mot de passe et bloque les tentatives de connexion directe depuis AD. À partir de ce moment, l'utilisateur doit accéder à l'environnement via Okta Privileged Access. Il peut effectuer une connexion en tant qu'utilisateur AD sur un contrôleur de domaine et en tant qu'utilisateur local sur les serveurs membres.
Ce comportement modifié empêche l'agent serveur Okta Privileged Access de modifier les contrôleurs de domaine et les groupes AD, tels que le groupe d'administrateur local. Cependant, vous pouvez remplacer ces paramètres par défaut en utilisant un fichier de configuration sftd.yaml. Voir Configurer l'agent du serveur Okta Privileged Access.