Get more details in ldap access logs

[Theodor Vallier]

Hello all,

I'm trying to log more details when there are operations on users, such as modifications (MOD). The goal is to detect legitimate user modifications like login or password changes, and differentiate them from non-legitimate ones such as default shell modifications.

I attempted to change the access log level without success; the activation of the audit plugin shows me the changes, but it is not usable (it's not syslog compliant and can't be correlated to MOD requests).

Is anyone able to log which fields a MOD request changes?

Thank you.

Best regards, Whidix

[Florence Blanc-Renaud]

Hi,

On Wed, Apr 2, 2025 at 10:04 AM Theodor Vallier via FreeIPA-users <
[e-mail]> wrote:
> Hello all,
>
> I'm trying to log more details when there are operations on users, such as
> modifications (MOD). The goal is to detect legitimate user modifications
> like login or password changes, and differentiate them from non-legitimate
> ones such as default shell modifications.
>
> I attempted to change the access log level without success; the activation
> of the audit plugin shows me the changes, but it is not usable (it's not
> syslog compliant and can't be correlated to MOD requests).
>
> Is anyone able to log which fields a MOD request changes?

This level of details can be seen in the audit log if you enable it.
# cat /tmp/dse.ldif
dn: cn=config
changetype: modify
replace: nsslapd-auditlog-logging-enabled
nsslapd-auditlog-logging-enabled: on
-
replace: nsslapd-auditfaillog-logging-enabled
nsslapd-auditfaillog-logging-enabled: on

# ldapmodify -D "cn=directory manager" -W -f /tmp/dse.ldif

The audit log is located in /var/log/dirsrv/slapd-XXX/audit. The audit fail
log records operations that failed.

Refer to
https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/co...
for more information.

flo
> Thank you.
> Best regards, Whidix
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Theodor Vallier]

Hello Florence,

Thank you for your quick response. As I mentioned, the audit plugin is not usable because it outputs changes on multiple lines (not RFC syslog friendly without some work) and cannot be linked to a MOD event due to the lack of connection and operation IDs, which is my biggest issue.

For this reason, I have discarded this solution.

Thank you.

Best regards, Whidix

[Rob Crittenden]

Theodor Vallier via FreeIPA-users wrote:
> Hello all,
>
> I'm trying to log more details when there are operations on users, such as modifications (MOD). The goal is to detect legitimate user modifications like login or password changes, and differentiate them from non-legitimate ones such as default shell modifications.
>
> I attempted to change the access log level without success; the activation of the audit plugin shows me the changes, but it is not usable (it's not syslog compliant and can't be correlated to MOD requests).
>
> Is anyone able to log which fields a MOD request changes?

What sort of thing are you looking for specifically? The audit log is
pretty much the gold standard even if the formatting is strange.

If you enable debug on the IPA server you can get more robust logging at
the cost of log spamming. To enable that create /etc/ipa/server.conf
with contents:

[global]
debug = True

And restart httpd.

rob

[Theodor Vallier]

Hello Rob,

The audit log can't be linked to the LDAP MOD log from the access file, as the only correlating factors are the timestamp, the DN, and the change type, which is not efficient for correlating logs because we can't be sure if we are looking at the corresponding MOD operation.

I would like to have something similar to what OpenLDAP offers (https://www.openldap.org/lists/openldap-software/200904/msg00049.html), with logs using the same connection and operation IDs as the MOD and RESULT.

As you mentioned, the debug mode is too verbose and will consume too much disk space.

Thank you.

Best regards, Whidix

[Rob Crittenden]

Theodor Vallier via FreeIPA-users wrote:
> Hello Rob,
>
> The audit log can't be linked to the LDAP MOD log from the access file, as the only correlating factors are the timestamp, the DN, and the change type, which is not efficient for correlating logs because we can't be sure if we are looking at the corresponding MOD operation.
>
> I would like to have something similar to what OpenLDAP offers (https://www.openldap.org/lists/openldap-software/200904/msg00049.html), with logs using the same connection and operation IDs as the MOD and RESULT.

I'd suggest you file an issue with the 389-ds project for something like
that.
> As you mentioned, the debug mode is too verbose and will consume too much disk space.

rob

[Alexander Bokovoy]

On Срд, 02 кра 2025, Theodor Vallier via FreeIPA-users wrote:
> Hello Rob,
>
> The audit log can't be linked to the LDAP MOD log from the access file,
> as the only correlating factors are the timestamp, the DN, and the
> change type, which is not efficient for correlating logs because we
> can't be sure if we are looking at the corresponding MOD operation.

There are two formats of auditlog: using LDIF and JSON. JSON format
includes connection and operation IDs as well as time and a lot of other
details.

Set 'nsslapd-auditlog-log-format: json' in cn=config to get JSON output.
If you'd set it to anything other than 'default' or 'json', it will be
'json-pretty'.

[Theodor Vallier]

Thank you,

It should work with some rsyslog configuration.

Have a nice day.
Whidix

[Mark Reynolds]

On 4/2/25 4:03 AM, Theodor Vallier via FreeIPA-users wrote:
> Hello all,
>
> I'm trying to log more details when there are operations on users, such as modifications (MOD). The goal is to detect legitimate user modifications like login or password changes, and differentiate them from non-legitimate ones such as default shell modifications.
>
> I attempted to change the access log level without success; the activation of the audit plugin shows me the changes, but it is not usable (it's not syslog compliant and can't be correlated to MOD requests).
>
> Is anyone able to log which fields a MOD request changes?

I'm not sure if it's going to help you, but in newer versions of 
389-ds-base (389-ds-base-2.5.x and up) there is an option for the audit 
log to be in JSON which includes more information:

https://www.port389.org/docs/389ds/design/audit-json-logging-design.html

The access log has also updated to include a JSON format with more info:

https://www.port389.org/docs/389ds/design/accesslog-json-design.html

However, as of right now the access log JSON formatting will only be 
available in 389-ds-base-3.x

HTH,

Mark
> Thank you.
>
> Best regards, Whidix