DocumentationExperience Cloud KCS

Accéder aux journaux d’audit des utilisateurs AEM et les configurer

Dernière mise à jour : 20 juin 2026

Il peut s’avérer difficile de suivre l’activité d’audit des utilisateurs dans AEM lorsque des événements d’audit sont écrits à des emplacements inattendus ou lorsque des requêtes de référentiel renvoient des résultats incomplets. Dans les déploiements d’AEM 6.5, les événements d’audit de gestion des utilisateurs peuvent rester dans le journal par défaut jusqu’à ce qu’un enregistreur dédié soit configuré, tandis qu’AEM as a Cloud Service peut nécessiter des requêtes d’audit plus étroites pour éviter les échecs liés aux traversées. La résolution consiste à vérifier le type de déploiement, à confirmer ou à créer la configuration d’enregistreur appropriée et à valider les données d’audit en vérifiant les journaux ou les nœuds d’audit. Si les événements d’audit attendus n’apparaissent toujours pas après la validation, envoyez un ticket d’assistance pour plus d’informations.

Description description

Environnement

  • Adobe Experience Manager as a Cloud Service
  • Adobe Experience Manager Managed Services
  • Adobe Experience Manager On-Premise

Problème/Symptômes

  • Les journaux d’audit tels que useraudit.log ou audit.log restent vides après les modifications de la configuration.
  • Les événements de création, de modification ou de suppression d’utilisateur apparaissent uniquement dans error.log.
  • Les requêtes sous /var/audit renvoient des résultats incomplets ou échouent lorsque la portée de la recherche est trop large.
  • Les événements d’audit sont disponibles dans un environnement, mais pas dans un autre.
  • Pour confirmer le problème, identifiez si l’environnement est AEM as a Cloud Service, Managed Services ou On-Premise.
  • Passez en revue la configuration existante de l’enregistreur Sling pour déterminer si les événements de contrôle de l’utilisateur sont acheminés vers un fichier dédié.
  • Vérifiez si les événements d’audit apparaissent dans error.log lorsqu’ils n’apparaissent pas dans un journal d’audit dédié.
  • Pour AEM as a Cloud Service, vérifiez si l’interrogation d’un chemin d’accès plus spécifique sous /var/audit renvoie des résultats.

Cause principale

Le comportement de la journalisation d’audit diffère selon le type de déploiement. Dans les environnements AEM 6.5, les événements d’audit de gestion des utilisateurs peuvent rester dans le journal par défaut, sauf s’ils sont redirigés vers un enregistreur Apache Sling dédié. Dans AEM as a Cloud Service, les données d’audit sont stockées en tant que nœuds de référentiel sous /var/audit et il peut être nécessaire de réduire les requêtes larges pour renvoyer des résultats utilisables.

Résolution resolution

Essayez les étapes suivantes pour résoudre le problème :

  1. Vérifiez quel type de déploiement AEM est utilisé afin de pouvoir valider les données d’audit à l’emplacement approprié.
  2. Ouvrez la configuration du journal Sling et vérifiez si les enregistreurs pour com.adobe.granite.security.user.internal.audit et com.adobe.granite.security.user.internal.servlets.AuthorizableServlet existent déjà.
  3. Si ces mappages d’enregistreur sont manquants dans les environnements AEM 6.5, créez un Apache Sling Logging Logger Configuration et acheminez la sortie du journal vers logs/useraudit.log.
  4. Déclenchez une action de gestion des utilisateurs, telle que la mise à jour d’un utilisateur ou la modification de l’appartenance à un groupe, et confirmez que l’événement est écrit dans le journal d’audit dédié.
  5. Dans AEM as a Cloud Service, récupérez les données d’audit de /var/audit et vérifiez que les nœuds d’audit sont renvoyés.
  6. Si la requête d’audit est trop large, limitez-la à un sous-chemin plus spécifique sous /var/audit et testez-la à nouveau.
  7. Si ACS Commons est disponible, utilisez son interface de recherche du journal d’audit pour valider la page, la publication ou l’activité d’audit liée à l’utilisateur.

Si les symptômes décrits ci-dessus se produisent toujours une fois toutes les étapes de dépannage terminées, ou si les résultats de ces étapes montrent que le problème n’est pas causé par une erreur utilisateur, des autorisations manquantes ou une configuration non prise en charge, les utilisateurs bénéficiant de l’assistance doivent envoyer un ticket à l’assistance Adobe via le portail d’assistance Experience League. Si la personne affectée ne parvient pas à créer un dossier parce que l’option de création de dossier n’est pas disponible, que la bonne organisation est manquante ou qu’un message de droit à l’assistance s’affiche, contactez l’administrateur système ou l’administrateur de l’assistance de votre organisation pour vérifier l’accès à l’assistance avant de réessayer.

Lecture connexe

recommendation-more-help
experience-cloud-kcs-help-kbarticles