Hi!
I had also thought about that, but I think recording IP addresses that access a server may be a job for a frontend tool. Imagining a distributed attack guessing passwords is done from some thousand hosts in parallel. It might blow up your accesslog without being helpful actually.
I wrote a tool that examines failed authentication attempts and sends a message to the affected user (plus maybe admins), so they get notified in time.
Similar to this: --- Dear user XXX!
Your account YYY (XXX) in the ZZZ LDAP-Server has 1 of 4 allowed authentication failures. If more than the allowed number of failed authentication attempts are detected, then the account may be locked temporarily. This message tried to warn you ahead of time.
The first failure was 2024-10-18T11:07:09.193314Z, and last change was 2024-10-21T07:03:53Z.
Failed attempts will be cleared after 2 weeks, or upon a successful authentication. ... --- (I decided NOT to tell the user how long the account will be locked, but I could)
Regards, Ulrich
-----Original Message----- From: Benjamin Renard brenard@easter-eggs.com Sent: Wednesday, November 13, 2024 10:08 AM To: openldap-technical@openldap.org Subject: [EXT] Re: Client IP address in accesslog ?
Hi,
Le 12/11/2024 à 22:43, Quanah Gibson-Mount a écrit :
I use the auditlog overlay for this.
I fear I may have been misunderstood. My goal was to retrieve (ideally from the events logged by the accesslog overlay) the IP address of the client who performed actions on a database.
My ultimate goal might be clearer: in the context of an LDAP directory with ppolicy enabled and a policy that blocks accounts after too many failed login attempts, I would like to allow administrators of this directory to see, from their administration interface, the failed login attempts of a given user and display where these connections came from (=client's IP address). Ideally, I would like to do this without having to parse log files for performance reasons.
I looked into the auditlog overlay, but it does not seem to log client information either. The patch provided by David seems to exactly match what I am looking for, but patching my production installation is not feasible. Is there any chance this patch will be accepted someday?
Regards
-- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com