Problèmes connus de l'authentification unique de bureau sans agent Active Directory
Voici les problèmes connus liés à l'implémentation d'une nouvelle configuration de l'authentification unique de bureau sans agent (DSSO) ou à la migration d'une configuration DSSO existante :
- Une Agentless Desktop SSO ne fonctionne pas si un seul utilisateur est membre de plus de 600 groupes de sécurité ou si le jeton Kerberos est trop important pour qu'Okta puisse le consommer. Si un utilisateur avec un paquet Kerberos volumineux implémente ou migre une Agentless Desktop SSO, une réponse 400 s'affiche et il se voit redirigé vers la page de connexion habituelle.
- Le niveau fonctionnel de Windows 2008 ou les versions antérieures utilisent un chiffrement RC4 moins sécurisé. Okta recommande la mise à jour vers le niveau fonctionnel de Windows 2008 ou version ultérieure afin de vous assurer que vous utilisez l'algorithme de chiffrement le plus sécurisé.
- Lorsque l'Agentless Desktop SSO est réactivée, les règles de routage du fournisseur d'identité (IDP) doivent être manuellement réactivées.
- La Agentless Desktop SSO ne fonctionne pas lorsque l'authentification déléguée est désactivée et que l'option Ne pas créer de mot de passe Okta est sélectionnée. Pour en savoir plus à propos de l'authentification déléguée, Consultez authentification déléguée.
- La page de connexion par défaut utilisée pour le basculement automatique de la DSSO ne prend pas en charge la personnalisation HTML.
- Une boucle infinie de redirection peut se produire lorsque les URL de la page d'erreur du client du fournisseur d'identité (IdP) et de l'entreprise sont identiques.
- Lorsque le nom d'utilisateur du compte de service et le nom du compte utilisateur Active Directory ne correspondent pas, l'Agentless Desktop SSO peut échouer. Lorsque cela se produit, vous êtes redirigé vers la page de connexion par défaut et une erreur GSS_ERR apparaît dans le Journal système. Le nom d'utilisateur du compte de service et le compte utilisateur Active Directory sont sensibles à la casse et doivent correspondre.
- Le chiffrement RC4_HMAC_MD5 n'est pas pris en charge avec l'ADSSO et l'activation silencieuse d'Office 365. Okta recommande d'utiliser le chiffrement AES 128-bit (AES-128) ou AES 256-bit (AES-256) lorsque vous utilisez l'ADSSO ou l'activation silencieuse d'Office 365. Si l'erreur KDC_ERR_ETYPE_NOTSUPP apparaît dans l'Observateur d'événements Windows lors de l'implémentation du chiffrement AES, Consultez Erreur etype non prise en charge par Kerberos.
- La version héritée de Microsoft Edge n'est pas prise en charge. La nouvelle version d'Edge qui utilise Chromium est prise en charge.
- La version 4.0.8.0 et les versions ultérieures de Microsoft Teams sont prises en charge.
