Dépannage de l'authentification unique de bureau sans agent

Une fois l'Agentless Desktop SSO activé, vous parcourerez vers votre locataire Okta et affichez la page de connexion habituelle.

Vous n'avez pas été routé(e) vers le point de terminaison Agentless Desktop SSO. Confirmez que votre adresse IP est ajoutée à la zone adéquate et que celle-ci est adaptée pour l'Agentless Desktop SSO.

Je travaille à distance et l'Agentless Desktop SSO ne fonctionne pas.

Pour que l'Agentless Desktop SSO fonctionne, votre navigateur doit pouvoir se connecter au centre de distribution de clés (KDC) sur votre domaine. Cela est essentiel pour la validation Kerberos. Si vous n'êtes pas en mesure de vous connecter au KDC, vous n'obtiendrez pas de ticket Kerberos ni ne pourrez vous authentifier. Si un VPN (Virtual Private Network) est disponible, utilisez-le pour rejoindre votre réseau. Si le KDC est disponible via le VPN, l'Agentless Desktop SSO fonctionnera.

J'utilise la zone adéquate et je suis en local, et l'Agentless Desktop SSO échoue toujours.

Confirmez l'exactitude du nom d'utilisateur et du mot de passe du compte SPN, tels qu'utilisés sur AD et stockés dans la configuration Okta. Si le compte a expiré ou a été modifié, le flux sera interrompu.

J'ai vérifié que j'utilisais la zone adéquate et le compte approprié pour le SPN, je suis en local et l'Agentless Desktop SSO échoue toujours.

Cela pourrait indiquer un type d'échec Kerberos. Avec des outils tels que Wireshark, capturez le trafic de votre réseau durant vos tentatives d'activation de l'Agentless Desktop SSO. Une fois le trafic capturé, appliquez un filtre pour obtenir les données Kerberos. Comparez ce trafic avec les journaux de l'Observateur d'événements sur votre KDC. Avec ces deux outils (ou des outils similaires) vous devriez pouvoir identifier les échecs Kerberos.

Validateur Kerberos et échec de connexion

Si la variation d'horloge entre votre réseau d'entreprise et le SSO Okta sans agent devient trop importante, la connexion et la validation Kerberos échoueront. Ce problème ne surviendra pas si l'horloge du contrôleur de votre domaine est synchronisée avec un serveur de temps externe.

Expérience d'authentification lente ou qui échoue

Durant la connexion Agentless Desktop SSO, Okta effectue une recherche SID. Durant le délai d'exécution de l'accès anticipé, cela est effectué via un appel à l'agent AD. Si vous rencontrez un problème de ralentissement ou d'échecs de connexion, pensez à augmenter le nombre de threads d'interrogation pour vos agents AD, ou à ajouter de nouveaux agents AD pour vos domaines. Pour les détails sur la façon de procéder, consultez les sections Installer plusieurs agents Okta Active Directory et Modifier le nombre de threads pour l'Active Directory Agent Okta.

Si cela se produit, vous constaterez que les journaux de l'agent AD contiennent un très grand nombre d'appels LDAP lus, sans qu'aucune ligne Next action = NONE (Action suivant = aucune) n'apparaisse. Par exemple :

2018/06/11 23:14:34.441 Debug -- N079-H076(57) -- Sending result for READ_LDAP action (id=ADS2n15k1yGW23cn10g7) finished, (executionTime=00:00:00.2196026)

La SSO de bureau/IWA ne fonctionne pas

• Veillez à ce que le nom d'hôte du serveur puisse être résolu depuis le réseau client.
• IWA doit être activé à la fois dans la configuration de l'authentification IIS et dans le client.

Le service IWA Okta est installé dans le menu des pools d'applications. Sous Paramètres avancés, vous pouvez modifier le mot de passe de service d'Okta, afin qu'il corresponde au nouveau mot de passe. En raison de la mise en cache, le service IWA peut ne pas s'interrompre immédiatement. Lorsque le cache est réinitialisé, si le mot de passe OktaService n'a pas été mis à jour de façon à correspondre au mot de passe réinitialisé dans l'outil Utilisateurs et ordinateurs Active Directory et la console Services dans la console Services sur le serveur sur lequel l'agent est installé, alors IWA arrête de fonctionner.

IWA ne fonctionne pas après un redémarrage du serveur ou des modifications de la politique de groupe

Le compte de service IWA Okta nécessite les autorisations Logon as a Batch Job (Se connecter en tant que tâche par lot) et Log on as a Service (Se connecter en tant que service). Assurez-vous que le compte de service dispose de ces autorisations.

Que faire si je reçois le message d'erreur : The request was aborted: Could not create SSL/TLS secure channel?

Votre agent IWA Web Okta peut passer hors ligne et le message d'erreur The request was aborted: Could not create SSL/TLS secure channel (La requête a été abandonnée : échec de création d'un canal sécurisé SSL/TLS) peut s'afficher si votre agent IWA Web Okta remplit les conditions suivantes :

• Être installé sur un serveur exécutant Windows Server 2008 R2 SP1
• Être configuré pour l'utilisation de HTTPS
• Être configuré pour le basculement automatique

Si votre agent Web IWAOkta est installé sur un serveur exécutant Windows Server 2008 R2 SP1 et que vous souhaitez utiliser l'IWA d'authentification unique (SSO) sur des connexions sécurisées (HTTPS), vous devez d'abord activer le protocole TLS 1.2 pour les connexions entrantes (par exemple IIS). Ceci est nécessaire car l'agent Okta Active Directory (AD), qui essaie d'utiliser TLS 1.2 chaque fois que possible, peut perdre la connectivité avec l'agent Web IWA Okta installé sur des serveurs Windows Server 2008 R2 SP1 qui ne sont pas activés pour les connexions entrantes TLS 1.2. Windows Server 2008 R2 SP1 prend en charge les connexions sortantes du protocole TLS 1.2 par défaut. Toutefois, la prise en charge des connexions entrantes est désactivée par défaut. Okta recommande vivement d'activer ce paramètre.

1. Sur le même serveur Windows 2008 R2 que celui qui héberge votre agent IWA Web, ajoutez les valeurs suivantes au registre :
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\DisabledByDefault : 0 (DWORD)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\Enabled : 1 (DWORD)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\DisabledByDefault : 0 (DWORD)HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server\Enabled : 1 (DWORD)
2. Redémarrez le serveur.

Échec de stockage de la configuration IWA lors de l'installation de l'agent

Pendant l'installation de l'agent, si le message d'erreur s'affiche, vous tentez probablement d'installer une version de l'agent Web IWAOkta dans laquelle l'épinglage SSL est activé par défaut et la prise en charge par l'agent de l'épinglage de certificats SSL empêche, du fait de votre environnement, la communication avec le serveur Okta. Cela a le plus de chances de se produire dans les environnements utilisant des proxies SSL. Pour permettre la finalisation de l'installation, dans cette situation, Okta recommande de contourner le traitement par proxy SSL en ajoutant le domaine okta.com à une liste d'autorisation.

Si l'épinglage du certificat SSL est activé, utilisez cette procédure pour le désactiver :

1. Effectuez les étapes 1 et 2 de la procédure Installer l'agent IWA Web Okta.
2. Ouvrez une invite de commande et saisissez la commande suivante : OktaSsoIwa.exe OktaDisableSslPinning=1
3. Appuyez sur Entrée.
4. Finalisez l'installation. Consultez Installer l'agent IWA Web Okta.