dimanche 11 décembre 2016

OKTA - Rôle et installation de l'agent AD

# Rôle de l'agent AD

Le rôle de l'agent AD Okta -"Okta AD agent"- en anglais et d'intégrer un environnement sur site Active Directory (AD) afin de synchroniser les identités issues de ce domaine Windows dans le cloud Okta. Ces identités, dès lors qu’elles sont présentes dans Okta peuvent être "transformées", pour ensuite être consommées par les applications raccordées à Okta.

L'agent AD Okta supporte les fonctionnalitées suivante:
  • Importation des utilisateurs et des groupes de sécurité AD
  • Gestion du cycle de provisionnement et de-provisionnement des utilisateurs
  • Support de l'Authentification déléguée permettant aux utilisateurs d'utiliser leur compte AD pour s'authentifier

# Prérequis à l'installation de l'agent AD

Le lien officiel proposé par Okta est plutôt complet (ici), je vais donc aller à l'essentiel, pour installer un agent AD Okta en environnement sur site Windows, les prérequis sont les suivants:
  • Un serveur Windows 2003 ou version ultérieure intégré à un domaine windows ayant accès à Internet et pouvant communiquer avec le cloud Okta.
  • Un compte utilisateur Windows pour réaliser l'installation ayant des privilèges "Administrateur local" si vous décider d'utiliser un compte de service dédié pour l'agent Okta ou "Administrateur du domaine" si vous laissez l'installeur créer le compte de service Okta nommé "oktaService" 
  • Un compte de service Windows dédié à l'agent Okta ayant des privilèges "Utilisateur" si vous ne laissez pas l'installeur créer le compte de service Okta 
  • Un compte de service OKTA dédié (Issu de votre tenant) ayant des privilèges "Super Admin" utilisé pour établir la "liaison de sécurité" entre l'agent AD Okta et votre tenant Okta

Quelques éléments clès sur le fonctionnement de l'agent AD
➤ Communication entre l'agent Okta et le cloud Okta
La communication entre l'agent AD Okta et votre tenant Okta est opérée par une unique connexion HTTPs sortante initiée par l'agent AD d'une durée de 60 secondes. L'agent AD okta récupère ainsi toutes les opérations en attente depuis le cloud. A l'issue des 60 secondes, la connexion est fermée et une nouvelle et ouverte.


➤ Usage du compte de service Okta
L'utilisation d'un compte de service OKTA dédié à l'établissement de la "liaison de sécurité" entre l'agent AD et votre tenant Okta est "obligatoire". Il ne faut pas utiliser un compte lié à un utilisateur. Pourquoi ? Lors de l'installation de l'agent, votre tenant Okta génère un jeton de sécurité (Token API) devant être validé par un compte "Super Admin" Okta pour ensuite être transmit à l'agent. Hors ce jeton est lié au compte l'ayant généré, donc si on désactive ce compte, le token API est désactivé et l'agent AD Okta ne peut plus communiquer avec le service Cloud Okta. Un compte utilisateur/Administrateur est généralement désactivé lors du départ de son utilisateur.

Prise en compte de la Haute disponibilité
Okta recommande d'installer à minima 2 agents AD pour assurer la redondance du service. Les agents installés seront dans ce cas installés sur des VM séparées et tous de la même version car l'exécution de versions différentes "peut" entraîner le fonctionnement de tous les agents au niveau du plus ancien.

A savoir : La haute disponibilité des agents Okta est automatiquement pilotée par le service Cloud Okta en mode Actif / Actif. Il n'existe aucun moyen pour modifier ce comportement que vous déployez 2, 4... 10 agents. Un agent sera considéré comme défaillant si celui ne communique plus avec le service Cloud Okta au dela de 120 secondes. L'agent défaillant est alors "flaggué" comme tel dans le portail Okta et écarté de la liste des agents pouvant traiter les commandes en attentes d'exécutions.

Prise en compte de la performance
Un agent AD okta installé sur une VM dotée de 2 VCPU + 8 GO RAM supporte sans broncher plusieurs dizaines de milliers d'utilisateurs.

 Prise en compte des trusts Windows
L'agent AD Okta supporte les topologies Windows complexe de type forêts de "Ressources / Comptes" et permet donc au travers des "trusts" Windows la synchronisation de domaines Windows différents par un même agent.

Important: cette configuration présente un inconvénient, lors du redémarrage de l'agent AD Okta si l'un des domaines est inaccessible, l'agent refusera de redémarrer... En contournement il faut modifier la configuration de l'agent pour supprimer le domaine fautif. C'est du "by design" Okta, un case est ouvert et une demande d'évolution en cours dans le forum community pour changer ce comportement => L'agent DOIT démarrer même si l'un des domaines est inaccessible. 


# Installation pas à pas de l'agent AD

⇨ Se connecter à votre tenant Okta
⇨ Pour récupérer les binaires d'installation, sélectionner Directory puis Directory Integrations
⇨ Cliquer Add Directory puis sélectionner Add Active Directory
⇨ Cliquer Set Up Active Directory puis Download Agent
⇨ Sur votre serveur Windows Click-droit sur les sources d’installation,
⇨ Sélectionner Run as Administrator.
⇨ Click sur Yes au message Do you want to allow the following program to make changes to this computer? »

⇨ Cliquer sur Next.

⇨ Spécifier le répertoire d'installation, puis Install.

⇨ Renseigner le domaine Active directory géré par l'agent, puis Next

⇨ Spécifier le compte de service, ici OktaService est créé par l'installeur, puis Next

⇨ Indiquer un mot de passe pour le compte service OktaService, puis Next

⇨ Configuration optionnelle si l'accès internet passe par un proxy, puis Next

⇨ Enregister l'agent AD, sélectionner Preview et indiquer votre espace de nom, puis Next

⇨ Renseigner un compte de service Okta ayant des privilèges "Super Admin", puis Se connecter. Rappel: Ne pas utiliser un compte utilisateur ayant des droits administrateur. Celui-ci pouvant être désactivé entrainant la désactivation du Token API et donc la désactivation de l'agent.

⇨ Cliquer sur Allow Access

⇨ Installation terminée, cliquer sur Finish

⇨ Depuis le portail Okta, l'agent est détecté, cliquer sur Next

⇨ Toute la configuration inhérente à la synchro des utilisateurs, des groupes de sécurité, l'enrichissement du schéma OKTA et le mapping peut-être réalisée ultérieurement, cliquer sur Next

⇨ Ecran de validation de la configuration de l'agent, cliquer sur Done

⇨ Ecran de configuration du schéma Okta, cliquer sur Next

⇨ Vérifier que Schedule Import est sur Never (Par defaut) et cocher Do not import Users. Ces paramètres seront à modifier quand la configuration de schéma et du mapping auront été réalisé. 

⇨ Depuis le portail sélectionner Directory > Directory Integrations puis Settings,  et vérifier que l'agent Okta installé est opérationnel.  (La couleur de la puce est verte et le message de statut indique "This agent is active and healthy")


⇨ L'installation d'un deuxième agent suit les mêmes étapes. Résultat final :

 ⇨ Les Tokens générés pour les agents AD sont localisés dans l'onglet Security/API/Tokens + filtre sur Okta AD agents. Les tokens héritent des droits associés aux comptes les ayants générés. La désactivation des comptes entraine la désactivation des agents AD.


Si l'installation de l'agent AD ne fonctionne pas, les causes les plus probables sont les suivantes:
  • Droits Windows insuffisants
  • Accès internet bloqué (Règles firewall, proxy, etc.)
Dans tous les cas il faut parcourir les logs systèmes dans le portail OKTA depuis l'onglet Reports/System log  et les logs serveurs C:\Program Files (x86)\Okta\Okta AD Agent\logs\InstallUtil.txt

Liens OKTA:
Okta Active Directory Agent
Active Directory Agent Version History
Administrators

Aucun commentaire:

Enregistrer un commentaire