Ce playbook décrit les étapes pour résoudre les problèmes lorsque le provisionnement SCIM planifié échoue.
Vue d'ensemble
Les synchronisations SCIM sont essentielles pour le provisionnement des utilisateurs vers CMA, garantissant un onboarding fluide et un accès cohérent aux ressources. La fréquence de synchronisation dépend du fournisseur d'identité (IdP) utilisé, comme décrit dans Provisionnement d'utilisateur SCIM.
Lorsque le provisionnement SCIM échoue, les utilisateurs nouvellement créés peuvent être incapables de se connecter ou d'accéder aux services requis, et les politiques de sécurité peuvent ne pas être appliquées correctement. Pour aider à garantir une détection et une résolution rapides, une histoire XOps est automatiquement générée chaque fois qu'un échec de provisionnement se produit entre l'IdP et CMA.
Lors de la réponse aux histoires XOps Réseau, il est essentiel d'aborder le problème de manière systématique. Tout d'abord, vérifiez que le problème est en cours, puis dépannez-le et enfin confirmez que le problème est résolu.
Étape 1 - Vérification de l'échec de la synchronisation SCIM
Voici les différentes manières dont un administrateur de l'application de gestion Cato peut vérifier qu'une synchronisation SCIM a échoué.
- Une histoire XOps sera générée lorsque la synchronisation SCIM échoue.
- Allez à la page Atelier des Histoires et utilisez le préréglage Opérations Réseau, y compris le filtre 'Indication Contient SCIM'. Ajustez la période si nécessaire.
- Vérifiez si une histoire est générée comme indiqué ci-dessous.
- Cliquez sur l'histoire pour examiner les détails. Elle fournit des informations sur le statut de l'histoire, une chronologie de l'incident et, plus important encore, le statut de la synchronisation SCIM.
- En parcourant plus loin l'analyse détaillée de l'histoire, vous trouverez la chronologie de l'incident. Cette chronologie met en évidence les modifications du statut des synchronisations SCIM. Dans le volet de droite, vous verrez le flux de travail du playbook qui décrit les étapes pour dépanner le problème.
Utilisation de l'événement
- Les échecs de synchronisation SCIM peuvent également être vérifiés en examinant les entrées d'événements pertinentes.
- Pour voir cet événement, filtrez le Tableau de bord des événements en définissant Sous-Type sur Provisionnement SCIM et Action sur Échoué. Ajustez la période au besoin pour correspondre au moment où le problème est survenu.
- Si un échec de synchronisation SCIM est détecté, vous verrez des événements similaires à l'exemple illustré ci-dessous. Le message d'événement indiquera la raison de l'échec de la synchronisation. Dans l'exemple illustré ci-dessous, cela est dû à une "Erreur interne du serveur".
Cette section décrit les outils disponibles dans Cato pour une approche structurée du dépannage des incidents de ce type. Bien que les étapes soient généralement destinées à être suivies dans l'ordre, les résultats de chaque vérification peuvent influencer l'étape suivante du processus.
- Pour déterminer si le problème était un événement unique, effectuez un provisionnement à la demande depuis la plateforme IdP. Pour Azure, accédez à Applications d'entreprise > Provisionnement Cato Networks > Provisionnement et cliquez sur "Provisionner à la demande."
- Sélectionnez un utilisateur ou un groupe assigné à l'application et cliquez sur le bouton "Provisionner".
- Si la synchronisation SCIM est terminée avec succès, cela peut indiquer que l'échec de la synchronisation SCIM était un incident isolé. L'administrateur doit vérifier si des interruptions de fournisseur ou des activités de maintenance de Cato ont coïncidé avec le temps de synchronisation SCIM.
- Si la synchronisation SCIM échoue également, cela indique que le problème persiste et que la synchronisation avec l'IdP ne s'achève pas correctement. Dans ce cas, examinez les modifications récentes de la configuration qui pourraient avoir conduit au problème.
Examen des modifications dans la piste d'audit
- Examinez les modifications sur la page de la piste d'audit pour déterminer si une modification de configuration est la cause de ce problème. Cette étape est particulièrement importante si la synchronisation planifiée fonctionnait normalement mais a cessé de fonctionner de manière inattendue.
- Pour voir les modifications apportées à la configuration du domaine, filtrez le Tableau de bord d'audit en définissant Type de modèle sur Domaine. Ajustez la période au besoin pour correspondre au moment où le problème est survenu.
- Par exemple, la capture d'écran ci-dessous montre que l'administrateur a apporté des modifications de configuration au provisionnement SCIM d'Okta. Si le timing de cette activité coïncide avec l'échec de la synchronisation SCIM, l'administrateur peut revenir en arrière sur les modifications pour déterminer si elles en sont la cause.
- Un autre facteur pouvant affecter la connectivité SCIM est les modifications apportées à l'application côté IdP. Pour Azure, accédez à Applications d'entreprise > Provisionnement Cato Networks et vérifiez les journaux d'audit et les journaux de provisionnement afin de déterminer si une modification de configuration a déclenché l'échec SCIM.
Mettre à jour les informations d'identification de l'administrateur
Pour vérifier un échec d'authentification avec l'IdP, générez un nouveau token depuis CMA sous Services d'annuaire > SCIM. Cliquez sur "générer un token" et copiez le nouveau token.
Pour Azure, accédez à Applications d'entreprise > Provisionnement Cato Networks > Provisionnement et développez Provisionnement > Informations d'identification de l'administrateur. Entrez le token généré depuis CMA et cliquez sur "Tester la connexion".
-
Si l'authentification réussit, le problème peut être lié à une discordance de token entre l'IdP et CMA.
Après avoir identifié et résolu le problème qui a causé l'échec de la synchronisation SCIM, vérifiez que la synchronisation est maintenant affichée comme résolue dans l'histoire.
NOTE : Une fois le problème résolu, le statut de l'histoire passera de "Ouvert" à "Surveillance". Il restera dans cet état pour l'heure suivante, à condition qu'il n'y ait pas d'autres incidents. Pour plus d'informations, consultez Compréhension des Colonnes d'Histoires.
Élever des cas au support Cato
Si suivre ce playbook n'a pas résolu un problème, soumettez un ticket de support. Pour obtenir la réponse la plus utile à une demande, un administrateur doit fournir les résultats des étapes de dépannage effectuées.
0 commentaire
Vous devez vous connecter pour laisser un commentaire.