Conditions préalables pour l'intégration Active Directory
Dans cette section, vous seront présentées les conditions nécessaires pour les intégrations Active Directory (AD).
L'Active Directory Agent Okta est compatible avec IPv4 et IPv6.
Matériel
Un serveur Windows au moins est requis pour installer l'AD Agent Okta. Ces serveurs sont appelés serveurs hôtes. Ces serveurs hôtes doivent toujours être actifs et disposer d'une connexion permanente à Internet pour pouvoir communiquer avec Okta.
- Le serveur hôte peut être un serveur physique ou virtuel.
- Le serveur doit disposer d'au moins deux UC et d'une RAM de 8 Go minimum.
Système d'exploitation et logiciels
Téléchargez et installez la dernière version de l'AD Agent Okta sur vos serveurs hôtes. Cela garantit que vous disposez des fonctionnalités les plus récentes et bénéficiez de performances optimales. Si vous exécutez plusieurs agents AD Okta, assurez-vous que ceux-ci ont une version identique. L'exécution de plusieurs versions pour un même domaine peut induire un fonctionnement basé sur l'agent le plus ancien pour tous les agents. Les autres domaines ne sont pas affectés.
- Serveur hôte exécutant Windows Server 2016, Windows Server 2019, Windows Server 2022 ou Windows Server 2025 : vous aurez besoin d'accéder à un serveur Windows afin d'installer l'AD Agent Okta. Vous n'avez pas besoin d'installer l'agent sur le contrôleur de domaine. Votre système doit disposer d'au moins 20 Mo de mémoire pour le compte de service AD créé durant l'installation de l'agent.
-
.NET 4.6.2 ou version ultérieure. Si vous disposez d'une version antérieure de .NET, effectuez une mise à niveau vers la version 4.6.2 ou une version ultérieure.
- Afin d'optimiser la sécurité des intégrations AD, le protocole de sécurité par défaut est TLS 1.2 pour les organisations utilisant .NET Framework 4.5 ou version ultérieure.
- Niveau fonctionnel de la forêt/du domaine AD : Okta prend en charge un niveau fonctionnel de forêt/domaine AD de 2003 et ultérieur. Consultez la section Niveaux fonctionnels de la forêt et du domaine.
- Si vous utilisez le niveau fonctionnel de domaine AD de 2003, les noms d'utilisateur AD devront présenter le même format que le nom de domaine. En d'autres termes, les utilisateurs doivent avoir un UPN présentant le format @domaine.nom.
- Serveur membre : le serveur hôte peut être un serveur membre de votre domaine AD ou un contrôleur de domaine. Okta recommande d'utiliser un serveur membre.
-
Exécuter l'assistant de configuration depuis le serveur hôte : exécutez l'assistant de configuration de l'agent dans un navigateur web sur le serveur hôte sur lequel vous souhaitez installer l'agent. Si vous ne suivez pas cette recommandation, il vous faudra transférer le programme d'installation de l'agent sur le serveur hôte, puis l'exécuter.
- Doit être un serveur membre dans votre forêt Active Directory : le serveur hôte peut se trouver dans un domaine autre que celui de vos utilisateurs, mais il doit être dans la même forêt AD. Placer l'agent sur un autre domaine peut entraîner des problèmes de performance.
- Politique en matière d'historique des mots de passe AD : pour mettre en œuvre cette politique, vous devez utiliser l'AD Agent Okta version 3.4.1 ou ultérieure, avec un niveau fonctionnel de domaine AD Windows Server 2016 ou ultérieur.
- Haute disponibilité : pour garantir une haute disponibilité ainsi qu'une redondance, installez l'agent sur deux ordinateurs au minimum.
- Nombre d'agents : si le nombre d'utilisateurs est supérieur à 30 000, déployez au moins trois agents AD.
Vous devez également déterminer les éléments suivants :
- Le format de nom d'utilisateur à utiliser lors de l'importation d'utilisateurs AD dans Okta (adresse e-mail, samAccountName, UPN ou personnalisé)
- Les OU depuis lesquelles les utilisateurs et groupes sont importés
- Les attributs AD à importer dans le profil utilisateur Okta
Comptes obligatoires
- Compte Okta avec les permissions requises: connectez-vous à Okta avec un compte qui dispose des permissions requises pour installer l'AD Agent et l'autoriser à se connecter à Okta. Ce compte doit être issu d'Okta, non d'AD.
- Compte administrateur AD pour exécuter le programme d'installation de l'AD Agent Okta: obligatoire pour exécuter le programme d'installation de l'AD Agent Okta. Ce compte doit disposer pour tous les domaines de la forêt de permissions d'accès en lecture seule aux données utilisateur dans les domaines auxquels l'agent se connecte.
- Compte utilisateur de domaine AD pour exécuter le service de l'AD Agent Okta : il s'agit d'un compte utilisateur ou d'un service de domaine AD. Durant l'installation, vous pouvez choisir de demander au programme d'installation de créer ce compte (appelé OktaService par défaut) ou sélectionner un compte existant. Le compte de service Okta doit disposer pour tous les domaines de la forêt de permissions d'accès en lecture seule aux données utilisateur dans les domaines auxquels l'agent se connecte. Il est conseillé d'utiliser le même compte de service AD pour installer l'ensemble des agents AD Okta.
Compte Okta avec les permissions requises
Pour installer l'agent, vous devez utiliser un compte qui dispose de permissions de gestion des annuaires, de gestion des agents et d'enregistrement des agents. Il est préférable de créer un rôle administrateur personnalisé qui dispose de ces permissions. Affectez ce rôle à un compte Okta pour connecter l'agent à Okta. Consultez Créer un rôle et Permissions d'agent.
Des permissions d'annuaire sont requises lors de la création d'une instance d'application avec l'AD Agent. Consultez la section Permissions de rôle.
Pour plus de sécurité, pensez à demander à vos administrateurs d'utiliser la MFA pour accès à la Admin Console. Consultez la section Appliquer la MFA pour accéder à l'Admin Console.
À partir de la version 3.18.0, l'AD Agent fonctionne indépendamment de tout compte Okta . Cela permet de garantir que l'intégration AD Okta continuera à fonctionner comme prévu, quel que soit le statut du compte utilisé pour enregistrer l'agent. Par exemple, dans les versions 3.17.0 et antérieures, un compte dédié était souvent utilisé pour enregistrer l'agent. Si les privilèges de ce compte étaient modifiés (par exemple, réduits ou révoqués), ou si le compte était désactivé, l'AD Agent cessait de fonctionner.
Compte administrateur AD à utiliser pour exécuter le programme d'installation de l'AD Agent Okta
Lors de l'installation de l'agent, vous serez invité à choisir si le programme d'installation devra créer un compte de service Okta ou non. Il vous faudra l'un des éléments suivants, selon le choix que vous effectuerez :
- Un compte administrateur de domaine AD, si vous souhaitez autoriser le programme d'installation à créer le compte de service Okta.
- Un compte utilisateur AD disposant de privilèges d'administrateur locaux sur le serveur hôte, si vous souhaitez utiliser un compte utilisateur de domaine existant comme compte de service Okta.
- Si vous avez choisi l'option Utiliser un autre compte spécifié par mes soins durant l'installation, le compte utilisateur AD doit disposer de droits d'accès en lecture seule à l'OU. Cette exigence s'applique également au compte OktaService.
Compte utilisateur de domaine AD à utiliser pour exécuter le service de l'AD Agent Okta
Durant l'installation, vous pourrez choisir de demander au programme d'installation de créer le compte de service Okta. Son nom par défaut est OktaService. Si vous choisissez d'utiliser un compte utilisateur de domaine existant, assurez-vous de ne pas définir de date d'expiration pour le mot de passe du compte. L'AD Agent Okta prend en charge les comptes de service gérés dans la version 3.6.0 et les versions ultérieures.
Pour que le programme d'installation crée le compte de service Okta pendant l'installation, vous devez remplir les conditions suivantes :
- Être un membre du group des administrateurs de domaine. Cela est nécessaire, car vous devez pouvoir créer un utilisateur AD qui fera office de compte de service de l'AD Agent.
- Avoir des privilèges d'administrateur local. Si vous installez l'AD Agent, mais utilisez un compte utilisateur existant comme compte de service, vous avez uniquement besoin de privilèges d'administrateur local.
Avec l'une ou l'autre de ces options, le programme d'installation attribuera la fonction de connexion en tant que service à l'utilisateur de domaine que vous avez sélectionné.
Si vous choisissez un compte utilisateur de domaine existant pour exécuter le service agent AD d'Okta, il doit prendre en charge le chiffrement AES Kerberos 128 bits et 256 bits. Vous pouvez activer ces options depuis l'onglet Compte des propriétés du compte.
Permissions du compte de service Okta
L'AD Agent est exécuté via le compte Okta que vous avez indiqué (soit le compte OktaService que le programme d'installation a créé, soit l'utilisateur de domaine sélectionné durant l'installation de l'agent).
Si vous choisissez d'utiliser un utilisateur de domaine comme compte de service, vous devrez vous assurer que l'utilisateur dispose des permissions énumérées dans les permissions du compte de service Okta.
Suivant la configuration de votre intégration, l'agent effectuera les actions suivantes :
- Lecture des utilisateurs, des OU et des groupes : nécessite un accès en lecture des objets concernés. Par défaut, un utilisateur de domaine dispose de permissions suffisantes pour ce faire. Si nous recommandons un accès en lecture seule sur l'ensemble du domaine, cela n'est toutefois pas requis.
- Authentifier les utilisateurs : aucune autorisations spéciale n'est requise.
- Modifier des mots de passe utilisateur (via la fourniture du mot de passe actuel) : aucune permissions spéciale n'est obligatoire.
- Définition des mots de passe utilisateur (sans le mot de passe actuel, via des droits administrateur) : nécessite des permissions de définition de mots de passe pour les utilisateurs.
- Créer et mettre à jour des utilisateurs, des attributs et l'appartenance dans AD, avec des valeurs renvoyées par Okta : nécessite des permissions de lecture et d'écriture pour les attributs que vous mettez à jour.
Configurer une délégation pour le compte de service Okta
Sur votre serveur Windows, vous devez configurer une délégation vers le compte de service Okta dans votre domaine AD, suivant vos besoins.
- Sur votre contrôleur de domaine AD, ouvrez le composant logiciel enfichable Ordinateurs et utilisateurs Active Directory.
- Effectuez un clic-droit sur l'OU ou le nom de domaine, puis sélectionnez Déléguer le contrôle.
- Dans l'assistant de délégation de contrôle, ajoutez le compte de service Okta et sélectionnez les tâches à déléguer :
Créer, supprimer et gérer les comptes utilisateur : pour la création et la mise à jour de flux utilisateur.
Réinitialiser les mots de passe utilisateur et forcer le changement de mot de passe à la prochaine connexion : pour la synchronisation de mots de passe.
Lire l'ensemble des informations utilisateur : pour l'importation et la création de flux utilisateur.
Modifier l'appartenance à un groupe : pour l'envoi de groupes en mode push.
