Hi,
I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented.
Thanks!
Am 12.11.24 um 17:38 schrieb Benjamin Renard:
Hi,
I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented.
if you enable loglevel "LDAP_DEBUG_STATS", then any connection to a slapd is logged: https://github.com/openldap/openldap/blob/master/servers/slapd/connection.c#...
LDAP_DEBUG_STATS = defines as 0x100 here: https://github.com/openldap/openldap/blob/master/include/ldap_log.h#L115
slapd.conf: loglevel 256
should help...
Andeas
--On Tuesday, November 12, 2024 5:38 PM +0100 Benjamin Renard brenard@easter-eggs.com wrote:
Hi,
I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented.
I use the auditlog overlay for this.
--Quanah
--On Tuesday, November 12, 2024 1:43 PM -0800 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Tuesday, November 12, 2024 5:38 PM +0100 Benjamin Renard brenard@easter-eggs.com wrote:
Hi,
I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented.
I use the auditlog overlay for this.
although that only helps with writes. Other than that, what Andreas noted, you can log it with stats logging and parse those logs however you please from there.
--Quanah
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
On 13Nov24 10:08+0100, Benjamin Renard wrote:
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.
I wanted to have this as well. After discovering accesslog is not adding a source attribute, I solved that by switching over to increase the loglevel to 'stats' and run a log analyser on it (promtail+loki+grafana). Which is still not simple to process because the data is spread over multiple lines. But I'm getting there.
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
Hi Ulrich,
Do you have something to share with us about this tool you wrote ? A priori, I will have to proceed with parsing the logs to move forward with my need, so if I can avoid starting from scratch, I would be interested :)
Thanks !
Le 14/11/2024 à 10:17, Windl, Ulrich a écrit :
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
Hi!
Thank you for your feedback. From what I understand, your tool does not seem to be able to provide the IP address from which the connection failure occurred today. Moreover, I already receive alerts by email on my end, so that's not necessarily what I'm looking for. But thank you for taking the time to respond to me.
I have worked in the past on a log parser for OpenLDAP that I hadn't finished. I think I will have to get back to it to retrieve the information directly from the logs and store it somewhere to make it available for consultation from my web administration interface.
That said, if you know of a 'lightweight' solution for this (I wouldn't want to have to deploy an ELK stack for it), I'm interested.
Regards,
Le 14/11/2024 à 10:17, Windl, Ulrich a écrit :
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
I would like to know if there is a way to get the client's IP address in the events recorded by accesslog (at least during BINDs). I found traces of requests for this dating back to 2010, but I haven't been able to determine if it was ever implemented.
I was disappointed to see the following marked as WONTFIX:
https://bugs.openldap.org/show_bug.cgi?id=7345
I use a variation of that patch to this day. It isn't easily replaced by slapd logging or auditlog, in my opinion. I'd love to see that patch reconsidered.
openldap-technical@openldap.org