Dépannage de l'intégration LDAP

Afin de résoudre les problèmes de LDAP, utilisez un navigateur LDAP tel qu'Apache DIrectory Studio.

Les modèles de schémas constituent des suggestions qui s'appuient sur les valeurs les plus fréquentes. Chaque environnement LDAP est unique et peut nécessiter un remplacement des valeurs par défaut avec des paramètres spécifiques à votre environnement. Vous pouvez utiliser Apache Directory Studio pour examiner les attributs pour les groupes et utilisateurs existants, aux fins de vérification des valeurs des modèles, ou bien sélectionner les paramètres adéquats.

La modification des modèles change l'ensemble des valeurs par défaut des modèles. Les paramètres que vous aurez remplacés ne seront pas modifiés.

Erreur à l'installation de l'agent

Durant l'installation de l'agent, une fois que vous avez cliqué sur Autoriser l'accès, le message d'erreur suivant s'affiche :

Échec de l'analyse de la réponse d'Okta et de l'inscription de l'agent. Code d'erreur 12.

Dans le journal, repérez l'entrée suivante :

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No valid public key found in certificate chain.

Si le journal contient cette entrée, vous tentez probablement d'installer l'agent Java LDAP version 5.3.1 ou ultérieure. Dans votre environnement, la prise en charge par l'agent de l'épinglage de certificats SSL empêche la communication avec le serveur Okta. Cela a le plus de chances de se produire dans les environnements utilisant des proxies SSL. Pour autoriser l'installation à réussir dans ce cas, Okta vous recommande d'ignorer le traitement des proxies SSL en ajoutant le domaine okta.com dans une liste d'autorisation.

Sinon, vous pouvez décider de désactiver l'épinglage SSL, comme décrit dans les procédures suivantes, mais cela désactiverait l'amélioration de sécurité fournie par l'agent.

Afin de désactiver la prise en charge de l'épinglage de certificats SSL, appliquez la procédure ci-dessous adaptée à votre système d'exploitation :

Windows

Installez l'agent LDAP d'Okta à partir d'une ligne de commande.

  1. Sur le serveur hôte, connectez-vous à Okta à l'aide d'un compte d'administrateur Okta avec les permissions super admin afin d'accéder à Admin Console.
  2. Téléchargez l'agent LDAP d'Okta :
    1. Dans Admin Console, accédez à RépertoireIntégrations de répertoires.
    2. Cliquez sur Ajouter un répertoireAjouter le répertoire LDAP.
    3. Vérifiez les exigences d'installation, puis cliquez sur Configurer LDAP.
    4. Cliquez sur Télécharger l'agent et sélectionnez Télécharger le programme d'installation EXE pour le téléchargez sur votre serveur Windows.
  3. Ouvrez une ligne de commande et exécutez la commande suivante : OktaADAgentSetup.exe OktaDisableSslPinning=1
  4. Finalisez l'installation :
    1. Si le message Autoriser ce programme à apporter des modifications à cet ordinateur ? s'affiche, cliquez sur Oui.
    2. Cliquez sur Suivant.
    3. Acceptez le contrat de licence et cliquez sur Suivant.
    4. Acceptez l'emplacement par défaut du dossier d'installation, ou cliquez sur Parcourir pour en sélectionner un autre, puis cliquez sur Installer.
    5. Facultatif. Si vous souhaitez activer LDAP sur SSL (LDAPS), sélectionnez Enable LDAP over SSL (Activer LDAP avec SSL), puis poursuivez la procédure indiquée.
    6. Dans l'écran de configuration LDAP, saisissez les informations suivantes :
      • LDAP Server : saisissez l'hôte et le port LDAP au format hôte:port. Par exemple : ldap.monentreprise.com:389.
      • Nom unique racine : nom unique racine du DIT servant de base de recherche pour les utilisateurs et les groupes.
      • Nom unique de liaison : nom unique de liaison de l'utilisateur LDAP utilisé pour la connexion au répertoire LDAP initiée par l'agent.
      • Mot de passe de liaison : mot de passe du nom unique de liaison utilisé pour la connexion au répertoire LDAP initiée par l'agent.
      • Facultatif. Utiliser la connexion SSL : sélectionnez si vous avez activé LDAP sur SSL (LDAPS). (Remarque : si vous n'effectuez pas les étapes décrites dans Activer LDAP sur SSL, l'erreur Échec de la connexion au serveur LDAP spécifié s'affiche.)
  5. Cliquez sur Suivant.
  6. Facultatif. Saisissez un serveur proxy pour l'agent LDAP d'Okta sur la page de configuration de proxy de l'agent LDAP d'Okta, puis cliquez sur Next (Suivant).

    Si le serveur proxy LDAP renvoie son propre schéma, des problèmes d'importation de données utilisateur peuvent survenir lorsque le schéma du serveur proxy et les schémas des serveurs LDAP diffèrent. Afin d'éviter tout problème d'importation de données, assurez-vous que les schémas du serveur proxy LDAP et du serveur LDAP sont identiques.

  7. Pour inscrire l'agent LDAP d'Okta au sein du service Okta, saisissez votre sous-domaine Okta, puis cliquez sur Suivant.
  8. Sur la page de connexion d'Okta, saisissez le nom d'utilisateur et le mot de passe de votre compte administrateur Okta, puis cliquez sur Connexion.
  9. Cliquez sur Autoriser l'accès afin d'accéder à l'API Okta. Remarque : si un message d'erreur s'affiche, consultez la section Localiser le journal de l'agent LDAP d'Okta.
  10. Cliquez sur Terminer.
  11. Configurez les paramètres d'intégration LDAP.

Si vous souhaitez réactiver la prise en charge de l'épinglage de certificats SSL :

  1. Localisez et ouvrez le fichier de configuration de Active Directory Agent :C:\Program Files (x86)\Okta\Okta AD Agent\OktaAgentSetup.exe.config
  2. Définissez le paramètre d'activation de l'épinglage SSL sur True : "SslPinningEnabled" value="True"
  3. Enregistrez le fichier de configuration et redémarrez l'agent.

Linux

  1. Depuis une ligne de commande, définissez le paramètre d'épinglage SSL sur False : $ sudo /opt/Okta/OktaLDAPAgent/scripts/configure_agent.sh -sslPinningEnabled false
  2. Enregistrez le fichier de configuration et redémarrez l'agent.

Si vous souhaitez réactiver la prise en charge de l'épinglage de certificats SSL une fois l'installation terminée, ouvrez OktaLDAPAgent.conf et définissez le paramètre d'épinglage SSL sur True.

Pour plus d'informations sur l'épinglage de certificats SSL, consultez l'article publié par Open Web Application Security Project.

Problèmes d'importations d'objets de rôle LDAP

Cas d'utilisation

Vous avez créé un rôle dans votre répertoire LDAP, mais ce rôle n'est pas importé dans Okta lorsque les utilisateurs affectés à ce rôle se connectent à Okta, même si JIT est activé.

Quand les rôles LDAP sont-ils intégrés dans Okta, par Okta ?

Okta intègre des rôles LDAP dans Okta uniquement durant les importations, non durant le JIT. Une fois intégrés dans Okta, les rôles LDAP sont présentés comme des groupes.

Quand les groupes LDAP sont-ils intégrés dans Okta, par Okta ?

Okta intègre les groupes LDAP dans Okta durant les importations et le JIT.

Solutions de contournement

Si vous ne souhaitez pas importer l'ensemble des comptes utilisateur dans Okta, pensez à l'une des solutions de contournement suivantes au sein de votre Preview Org. Si vous obtenez les résultats attendus, vous pouvez mettre en œuvre une solution de contournement dans votre Production Org.

Importer dans Okta un groupe avec une appartenance identique à celle d'un rôle LDAP spécifique

  1. Créez un groupe sur LDAP avec la même appartenance que le rôle LDAP que vous souhaitez importer.

  2. En utilisant l'approvisionnement JIT ou une importation LDAP, intégrez ce groupe et son appartenance dans Okta, puis affectez-le à l'application ou à l'intégration de votre choix.

Effectuer une importation LDAP dans Okta, sans confirmer les objets indésirables

  1. Dans Okta, accédez à RépertoireIntégrations de répertoiresLDAPParamètresParamètres d'importation.

  2. Dans la section Importer les règles de correspondance, faites défiler jusqu'à l'option Aucune correspondance identifiée, puis sélectionnez Confirmation manuelle des nouveaux utilisateurs. Cela permet de s'assurer qu'aucun nouveau compte utilisateur ne sera automatiquement créé dans Okta lors d'une importation.

  3. Effectuez une importation liée à votre répertoire LDAP afin d'importer le groupe créé à l'étape 1. Les membres du groupe sont ensuite ajoutés au groupe lors d'une connexion JIT à Okta.

Séparer les comptes LDAP inactifs de façon temporaire

Si vous ne souhaitez pas effectuer d'importation, car votre répertoire LDAP contient des comptes utilisateur inactifs, vous pouvez opter pour la solution de contournement suivante afin d'identifier les comptes probablement inactifs et les ignorer lors de l'importation :

  1. Exécutez une requête liée à votre répertoire LDAP pour l'attribut lastlogon (ou tout autre attribut qui filtre les comptes inactifs).

  2. Déplacez les objets utilisateur inactifs en dehors de leur conteneur de synchronisation afin de vous assurer qu'ils ne seront pas intégrés à Okta durant l'importation. Vous pourrez replacer ces objets une fois l'importation terminée.

Échec de l'installation de l'agent LDAP en raison de la configuration du mode FIPS

Les scénarios suivants décrivent les étapes de dépannage des problèmes d'échec d'installation de l'agent LDAP liés à la configuration du mode FIPS.

  • Si l'installation de l'agent échoue pendant le flux interactif, relancez le flux et sélectionnez N lorsque le système vous demande d'activer le mode FIPS.

  • Si une erreur se produit au cours du processus de mise à niveau de agent, désactivez le mode FIPS en ajoutant fipsMode=false au fichier de configuration, puis relancez la commande d'installation.

Erreur lors de la vérification du nom d'utilisateur

Lors de la vérification de votre nom d'utilisateur, vous voyez l'erreur suivante s'afficher : Nom d'utilisateur : Ne correspond pas au motif obligatoire.

Le nom d'utilisateur doit être au format e-mail. Vérifiez que les paramètres d'importation sont correctement définis. Consultez la section Installer et configurer l'agent Okta LDAP.

Erreur suite à la sélection de la case à cocher SSL

Vous avez coché la case à cocher Utiliser la connexion SSL et voyez apparaître l'erreur suivante : Échec de connexion au serveur LDAP spécifié.

Assurez-vous que LDAPS (LDAP avec SSL) est activé. Voir la section Activer l'utilisation de LDAP sur SSL.