Hi
changing my loglevel to trace or stats, shows me search queries but I need a way to debug a remote client doing a php ldap modify that is failing?
--On Friday, June 21, 2019 4:27 PM +0200 Mark Coetser mark@pkfnet.co.za wrote:
Hi
changing my loglevel to trace or stats, shows me search queries but I need a way to debug a remote client doing a php ldap modify that is failing?
STATS level debugging shows information about all operations, including MOD. What error code is the server returning to the client?
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 2019/06/21 15:41, Quanah Gibson-Mount wrote:
--On Friday, June 21, 2019 4:27 PM +0200 Mark Coetser mark@pkfnet.co.za wrote:
Hi
changing my loglevel to trace or stats, shows me search queries but I need a way to debug a remote client doing a php ldap modify that is failing?
STATS level debugging shows information about all operations, including MOD. What error code is the server returning to the client?
Hi Quanah
This is all I am seeing with loglevel stats for the modify operation, I can see which attr are being modified but I am not seeing what the values are..
Jun 24 08:01:02 admin01.domain.co.za slapd[751]: conn=3318 op=5 MOD dn="uid=mark.coetser,ou=People,dc=domain,dc=co,dc=za,dc=root" Jun 24 08:01:02 admin01.domain.co.za slapd[751]: conn=3318 op=5 MOD attr=vacationActive vacationInfo vacationKeep vacationForward Jun 24 08:01:02 admin01.domain.co.za slapd[751]: conn=3318 op=5 RESULT tag=103 err=21 text=vacationKeep: value #0 invalid per syntax Jun 24 08:01:02 admin01.domain.co.za slapd[751]: conn=3318 op=6 UNBIND Jun 24 08:01:02 admin01.domain.co.za slapd[751]: conn=3318 fd=27 closed
--On Monday, June 24, 2019 9:03 AM +0200 Mark Coetser mark@pkfnet.co.za wrote:
On 2019/06/21 15:41, Quanah Gibson-Mount wrote:
--On Friday, June 21, 2019 4:27 PM +0200 Mark Coetser mark@pkfnet.co.za wrote:
Hi
changing my loglevel to trace or stats, shows me search queries but I need a way to debug a remote client doing a php ldap modify that is failing?
STATS level debugging shows information about all operations, including MOD. What error code is the server returning to the client?
Hi Quanah
This is all I am seeing with loglevel stats for the modify operation, I can see which attr are being modified but I am not seeing what the values are..
Hi Mark,
I see, you don't have control over the PHP client side then I'm guessing (which is generally where I would expect one to debug). To get this information, you will need to start slapd in debug mode (-d packets). I.e., it's not currently information that can be made available via a loglevel setting (I'm going to file an issue on that).
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, June 25, 2019 9:57 AM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
I see, you don't have control over the PHP client side then I'm guessing (which is generally where I would expect one to debug). To get this information, you will need to start slapd in debug mode (-d packets). I.e., it's not currently information that can be made available via a loglevel setting (I'm going to file an issue on that).
Hi Mark,
Another way to do this would be to set up an accesslog database backend and the slapo-accesslog overlay on your primary DB, and log all operations (not just success). This would also allow you to inspect what values the client is providing.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 6/25/19 7:08 PM, Quanah Gibson-Mount wrote:
Another way to do this would be to set up an accesslog database backend and the slapo-accesslog overlay on your primary DB, and log all operations (not just success). This would also allow you to inspect what values the client is providing.
AFAIK this only helps if the modify request reaches the backend.
If the slapd frontend already rejects a request (e.g. invalid DN or schema violation) there is no auditModify entry to look at.
Ciao, Michael.
--On Tuesday, June 25, 2019 8:33 PM +0200 Michael Ströder michael@stroeder.com wrote:
On 6/25/19 7:08 PM, Quanah Gibson-Mount wrote:
Another way to do this would be to set up an accesslog database backend and the slapo-accesslog overlay on your primary DB, and log all operations (not just success). This would also allow you to inspect what values the client is providing.
AFAIK this only helps if the modify request reaches the backend.
If the slapd frontend already rejects a request (e.g. invalid DN or schema violation) there is no auditModify entry to look at.
In this case, it's that the value provided violates the SYNTAX rule, it should be logged.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On Tue, Jun 25, 2019 at 07:33:59PM +0200, Michael Ströder wrote:
On 6/25/19 7:08 PM, Quanah Gibson-Mount wrote:
Another way to do this would be to set up an accesslog database backend and the slapo-accesslog overlay on your primary DB, and log all operations (not just success). This would also allow you to inspect what values the client is providing.
AFAIK this only helps if the modify request reaches the backend.
Sure, but most reasons it doesn't reach the overlay should be logger already.
If the slapd frontend already rejects a request (e.g. invalid DN or schema violation) there is no auditModify entry to look at.
For an otherwise LDAP conformant modify PDU with no controls attached, only an invalid DN/invalid attribute name would make that happen and I'd hope both generate useful messages in the response (preferably) or at least in the relevant logs.
Regards,
openldap-technical@openldap.org
-
Mark Coetser -
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount