@adolfotrinca - log4j cannot do that and AuditEvents are not log4j logs, rather they are hibernate objects persisted to spt_audit_event. log4j only captures log statements issued via a logger. There is no OOTB appender that captures the persistence of audit records, thus there will not be a combination of log4j2.properties statements that will allow you to get all audit events.
You can enable debug/trace on sailpoint.api.Auditor, sailpoint.server.AuditService, or sailpoint.server.Authenticator or sailpoint.web.LoginBean and get some output, but that’s internal debug statements, not audit records.
What actually solves it without a Rule or SQL procedure → SailPoint SIEM Plugin SailPoint Certified solution, designed to do exactly this. Exposes REST API endpoints to read AuditEvents, Syslog Events, and Task Results from IdentityIQ.
Repo: GitHub - sailpoint-oss/colab-siem-plugin: Creates API endpoints to fetch AuditEvent, Syslog Event, and Task Results from IdentityIQ. · GitHub
This gives you a structured audit data, no BeanShell rule, no stored procedure, and a supported artifact you could hand to Support if needed.
Second option, if you can’t install plugins
Point a JDBC based log collector at spt_audit_event directly with a read-only DB account. Most SIEMs (QRadar, Splunk DB Connect, etc.) have generic JDBC collectors, and there are prebuilt IdentityIQ DB event collectors. It is technically a SQL read, but it is configured on the SIEM side, not developed in IIQ, so it satisfies “no rule, no procedure” in the sense you probably mean.