6:27 a.m.
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?
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
6:41 a.m.
--On Friday, June 21, 2019 4:27 PM +0200 Mark Coetser <mark(a)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>
11:03 p.m.
On 2019/06/21 15:41, Quanah Gibson-Mount wrote:
--On Friday, June 21, 2019 4:27 PM +0200 Mark Coetser
<mark(a)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
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
8:57 a.m.
--On Monday, June 24, 2019 9:03 AM +0200 Mark Coetser <mark(a)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(a)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>
10:08 a.m.
--On Tuesday, June 25, 2019 9:57 AM -0700 Quanah Gibson-Mount
<quanah(a)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>
10:33 a.m.
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.
10:35 a.m.
--On Tuesday, June 25, 2019 8:33 PM +0200 Michael Ströder
<michael(a)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>
12:04 p.m.
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,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
663
days inactive
667
days old
openldap-technical@openldap.org
7 comments
4 participants
participants (4)
-
Mark Coetser -
Michael Ströder -
Ondřej Kuzník -
Quanah Gibson-Mount