Questo contenuto non è disponibile nella lingua selezionata.
Chapter 5. Auditing IdM API operations
Identity Management (IdM) servers use the systemd journal to create audit records of all IdM API operations. Querying these logs helps you track who performed actions, troubleshoot issues, and meet compliance requirements.
5.1. Overview of IdM API auditing Copia collegamentoCollegamento copiato negli appunti!
An IdM server records any use of the Identity Management (IdM) API in the systemd journal. This unified logging method helps you audit API operations and identify security events across your IdM deployment.
The systemd journal allows for centralized collection of logs from individual systems, which can then be queried and filtered.
Each log entry is tagged with an IPA.API marker and contains the following details in a structured format:
-
The authenticated Kerberos principal that performed the action, or
` if the operation was performed by the `rootuser directly on the server through LDAPI. - The name of the API command that was executed.
-
The result of the execution, which is either
SUCCESSor an exception name. - An LDAP backend instance identifier, which is the same for all operations performed as part of the same request.
- A list of arguments and options passed to the command, in JSON format.
You can query these entries with the journalctl utility. Using journalctl with the -x option provides a more detailed, human-readable explanation of the log entry, including links to the relevant documentation.
All IdM API audit entries have a MESSAGE_ID property set to the application UID 6d70f1b493df36478bc3499257cd3b17.
5.2. Viewing the IdM API audit logs Copia collegamentoCollegamento copiato negli appunti!
You can view the IdM API audit logs by querying the systemd journal. Filtering and inspecting these logs helps you investigate specific operations and understand the details of API calls.
Prerequisites
- You have root access to the IdM server.
Procedure
To see a list of all IdM API operations recorded in the journal, filter the journal for the
IPA.APImarker:# journalctl -g IPA.API May 23 10:30:15 idmserver.idm.example.com /usr/bin/ipa[247422]: [IPA.API] [autobind]: user_del: SUCCESS [ldap2_140328582446688] {"uid": ["example_user"], "continue": false, "version": "2.253"} May 23 10:32:01 idmserver.idm.example.com /usr/bin/ipa[247555]: [IPA.API] admin@IDM.EXAMPLE.COM: user_add: SUCCESS [ldap2_140328582446999] {"uid": ["new_user"], "givenname": "New", "sn": "User", "cn": "New User"} May 23 10:33:10 idmserver.idm.example.com /mod_wsgi[247035]: [IPA.API] admin@IDM.EXAMPLE.COM: ping: SUCCESS [ldap2_139910420944784] {"version": "2.253"} May 23 10:34:05 idmserver.idm.example.com /usr/bin/ipa[247888]: [IPA.API] [autobind]: group_add_member: SUCCESS [ldap2_140328582447111] {"cn": "admins", "user": "new_user"}The output shows a summary of each API call, including the user, the command, the result, the unique connection ID, and the parameters used.
-
Identify the unique identifier for the specific entry you want to inspect. For example, the
user_delcall has the LDAP backend instance identifierldap2_140328582446688. Use
journalctlwith the-xoption and the unique identifier value to get a detailed explanation of the user deletion log entry:# journalctl -x -g ldap2_140328582446688 May 23 10:30:15 idmserver.idm.example.com /usr/bin/ipa[255232]: [IPA.API] [autobind]: user_del: SUCCESS [ldap2_140328582446688] {"uid": ["example_user"], "continue": false, "version": "2.253"} -- Subject: IdM API command was executed and result of its execution was audited -- Defined-by: FreeIPA -- Support: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/ -- Documentation: man:ipa(1) -- Documentation: https://freeipa.readthedocs.io/en/latest/api/index.html -- Documentation: https://freeipa.readthedocs.io/en/latest/api/user_del.html -- Identity Management provides an extensive API that allows to manage all aspects of IdM deployments. -- The following information about the API command executed is available: -- [IPA.API] [autobind]: user_del: SUCCESS [ldap2_140328582446688] {"uid": ["example_user"], "continue": false, "version": "2.253"} -- The command was executed by '/usr/bin/ipa' utility. If the utility name -- is '/mod_wsgi`, then this API command came from a remote source through the IdM -- API end-point. -- The message includes following fields: -- - executable name and PID ('/mod_wsgi' for HTTP end-point; in this case it -- was '/usr/bin/ipa' command) -- - '[IPA.API]' marker to allow searches with 'journalctl -g IPA.API' -- - authenticated Kerberos principal or '[autobind]' marker for LDAPI-based -- access as root. In this case it was '[autobind]' -- - name of the command executed, in this case 'user_del' -- - result of execution: SUCCESS or an exception name. In this case it was -- 'SUCCESS' -- - LDAP backend instance identifier. The identifier will be the same for all -- operations performed under the same request. This allows to identify operations -- which were executed as a part of the same API request instance. For API -- operations that didn't result in LDAP access, there will be -- '[no_connection_id]' marker. -- - finally, a list of arguments and options passed to the command is provided -- in JSON format. -- --------- -- The following list of arguments and options were passed to the command -- 'user_del' by the '[autobind]' actor: -- -- {"uid": ["example_user"], "continue": false, "version": "2.253"} -- --------- -- A detailed information about Identity Management API can be found at upstream documentation API reference: -- https://freeipa.readthedocs.io/en/latest/api/index.html -- For details on the IdM API command 'user_del' see -- https://freeipa.readthedocs.io/en/latest/api/user_del.html