Zugreifen auf und Konfigurieren von AEM-Benutzerüberwachungsprotokollen
Die Benutzerüberwachungsaktivität in AEM kann schwierig zu verfolgen sein, wenn Prüfereignisse an unerwartete Orte geschrieben werden oder wenn Repository-Abfragen unvollständige Ergebnisse zurückgeben. In AEM 6.5-Bereitstellungen können Benutzerverwaltungs-Audit-Ereignisse im Standardprotokoll verbleiben, bis ein dedizierter Logger konfiguriert ist, während AEM as a Cloud Service engere Audit-Abfragen erfordern kann, um Durchlauffehler zu vermeiden. Die Lösung besteht darin, den Bereitstellungstyp zu überprüfen, die entsprechende Logger-Konfiguration zu bestätigen oder zu erstellen und Auditdaten zu validieren, indem Protokolle oder Auditknoten überprüft werden. Wenn die erwarteten Audit-Ereignisse nach der Validierung immer noch nicht angezeigt werden, reichen Sie ein Support-Ticket zur weiteren Untersuchung ein.
Beschreibung description
Umgebung
- Adobe Experience Manager as a Cloud Service
- Adobe Experience Manager Managed Services
- Adobe Experience Manager On-Premise
Problem/Symptome
- Auditprotokolle wie
useraudit.logoderaudit.logbleiben nach Konfigurationsänderungen leer. - Ereignisse zum Erstellen, Ändern oder Löschen von Benutzern werden nur in
error.logangezeigt. - Abfragen unter
/var/auditgeben unvollständige Ergebnisse zurück oder schlagen fehl, wenn der Suchbereich zu breit ist. - Audit-Ereignisse sind in einer Umgebung verfügbar, aber nicht in einer anderen.
- Um das Problem zu bestätigen, stellen Sie fest, ob es sich bei der Umgebung um AEM as a Cloud Service, Managed Services oder On-Premise handelt.
- Überprüfen Sie die vorhandene Sling Logger-Konfiguration, um festzustellen, ob Benutzerüberwachungsereignisse an eine dedizierte Datei weitergeleitet werden.
- Überprüfen Sie, ob Audit-Ereignisse in
error.logangezeigt werden, wenn sie nicht in einem dedizierten Audit-Protokoll aufgeführt werden. - Testen Sie für AEM as a Cloud Service, ob die Abfrage eines spezifischeren Pfads unter
/var/auditErgebnisse zurückgibt.
Ursache
Das Verhalten der Auditprotokollierung unterscheidet sich je nach Bereitstellungstyp. In AEM 6.5-Umgebungen können Benutzerverwaltungs-Audit-Ereignisse im Standardprotokoll verbleiben, es sei denn, sie werden an einen dedizierten Apache Sling-Logger umgeleitet. In AEM as a Cloud Service werden Auditdaten als Repository-Knoten unter /var/audit gespeichert und allgemeine Abfragen müssen möglicherweise eingegrenzt werden, um verwendbare Ergebnisse zurückzugeben.
Lösung resolution
Führen Sie die folgenden Schritte aus, um das Problem zu lösen:
- Überprüfen Sie, welcher AEM-Bereitstellungstyp verwendet wird, damit Sie Audit-Daten am richtigen Speicherort überprüfen können.
- Öffnen Sie die Sling-Protokollkonfiguration und überprüfen Sie, ob bereits Logger für
com.adobe.granite.security.user.internal.auditundcom.adobe.granite.security.user.internal.servlets.AuthorizableServletvorhanden sind. - Wenn diese Logger-Zuordnungen in AEM 6.5-Umgebungen fehlen, erstellen Sie eine
Apache Sling Logging Logger Configurationund leiten Sie die Protokollausgabe anlogs/useraudit.logweiter. - Trigger : Eine Benutzerverwaltungsaktion, z. B. das Aktualisieren eines Benutzers oder das Ändern der Gruppenmitgliedschaft, und eine Bestätigung, dass das Ereignis in das dedizierte Administratorprotokoll geschrieben wurde.
- Rufen Sie in AEM as a Cloud Service Auditdaten aus
/var/auditab und bestätigen Sie, dass Auditknoten zurückgegeben werden. - Wenn die Audit-Abfrage zu breit angelegt ist, grenzen Sie sie auf einen spezifischeren Unterpfad unter
/var/auditein und führen Sie dann erneut einen Test durch. - Wenn ACS Commons verfügbar ist, verwenden Sie seine Auditprotokoll-Suchschnittstelle, um Seiten-, Veröffentlichungs- oder benutzerbezogene Überwachungsaktivitäten zu validieren.
Wenn die oben beschriebenen Symptome weiterhin auftreten, nachdem alle Schritte zur Fehlerbehebung abgeschlossen wurden, oder wenn die Ergebnisse dieser Schritte zeigen, dass das Problem nicht durch einen Benutzerfehler, fehlende Berechtigungen oder eine nicht unterstützte Konfiguration verursacht wird, sollten Support-berechtigte Benutzende ein Ticket einreichen über das Support-Portal für Experience League an den Adobe-Support senden. Wenn die betroffene Person keinen Fall erstellen kann, weil die Option „Offener Fall“ oder „Fall erstellen“ nicht verfügbar ist, die richtige Organisation fehlt oder eine Meldung zur Support-Berechtigung angezeigt wird, wenden Sie sich an den Systemadministrator oder Support-Administrator Ihrer Organisation, um den Support-Zugriff zu überprüfen, bevor Sie es erneut versuchen.