Re: ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene
Dear Quanah,
Herewith the ldapwhoami without and with -H ldap:/// to compare.
Regards,
Thierry
server# ldapwhoami -x -D "cn=Manager,dc=be" -w password -d -1
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x55c5863df610 ptr=0x55c5863df610 end=0x55c5863df636 len=38
0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d
0$...`......cn=M
0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61
anager,dc=be..pa
0020: 73 73 77 6f 72 64 ssword
ber_scanf fmt ({i) ber:
ber_dump: buf=0x55c5863df610 ptr=0x55c5863df615 end=0x55c5863df636 len=33
0000: 60 1f 02 01 03 04 10 63 6e 3d 4d 61 6e 61 67 65
`......cn=Manage
0010: 72 2c 64 63 3d 62 65 80 08 70 61 73 73 77 6f 72
r,dc=be..passwor
0020: 64 d
ber_flush2: 38 bytes to sd 3
0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d
0$...`......cn=M
0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61
anager,dc=be..pa
0020: 73 73 77 6f 72 64 ssword
ldap_write: want=38, written=38
0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d
0$...`......cn=M
0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61
anager,dc=be..pa
0020: 73 73 77 6f 72 64 ssword
ldap_result ld 0x55c5863d6050 msgid 1
wait4msg ld 0x55c5863d6050 msgid 1 (infinite timeout)
wait4msg continue ld 0x55c5863d6050 msgid 1 all 1
** ld 0x55c5863d6050 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Thu Mar 12 08:33:07 2020
** ld 0x55c5863d6050 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x55c5863d6050 request count 1 (abandoned 0)
** ld 0x55c5863d6050 Response Queue:
Empty
ld 0x55c5863d6050 response count 0
ldap_chkResponseList ld 0x55c5863d6050 msgid 1 all 1
ldap_chkResponseList returns ld 0x55c5863d6050 NULL
ldap_int_select
read1msg: ld 0x55c5863d6050 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
0000: 30 0c 02 01 01 61 07 0a 0....a..
ldap_read: want=6, got=6
0000: 01 00 04 00 04 00 ......
ber_get_next: tag 0x30 len 12 contents:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a80 end=0x55c5863e0a8c len=12
0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........
read1msg: ld 0x55c5863d6050 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0a8c len=9
0000: 61 07 0a 01 00 04 00 04 00 a........
read1msg: ld 0x55c5863d6050 0 new referrals
read1msg: mark request completed, ld 0x55c5863d6050 msgid 1
request done: ld 0x55c5863d6050 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0a8c len=9
0000: 61 07 0a 01 00 04 00 04 00 a........
ber_scanf fmt (}) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a8c end=0x55c5863e0a8c len=0
ldap_msgfree
ldap_extended_operation
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x55c5863df610 ptr=0x55c5863df610 end=0x55c5863df630 len=32
0000: 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
0....w...1.3.6.1
0010: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
.4.1.4203.1.11.3
ber_scanf fmt ({) ber:
ber_dump: buf=0x55c5863df610 ptr=0x55c5863df615 end=0x55c5863df630 len=27
0000: 77 19 80 17 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e
w...1.3.6.1.4.1.
0010: 34 32 30 33 2e 31 2e 31 31 2e 33 4203.1.11.3
ber_flush2: 32 bytes to sd 3
0000: 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
0....w...1.3.6.1
0010: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
.4.1.4203.1.11.3
ldap_write: want=32, written=32
0000: 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
0....w...1.3.6.1
0010: 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
.4.1.4203.1.11.3
ldap_result ld 0x55c5863d6050 msgid -1
wait4msg ld 0x55c5863d6050 msgid -1 (timeout 100000 usec)
wait4msg continue ld 0x55c5863d6050 msgid -1 all 1
** ld 0x55c5863d6050 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Thu Mar 12 08:33:07 2020
** ld 0x55c5863d6050 Outstanding Requests:
* msgid 2, origid 2, status InProgress
outstanding referrals 0, parent count 0
ld 0x55c5863d6050 request count 1 (abandoned 0)
** ld 0x55c5863d6050 Response Queue:
Empty
ld 0x55c5863d6050 response count 0
ldap_chkResponseList ld 0x55c5863d6050 msgid -1 all 1
ldap_chkResponseList returns ld 0x55c5863d6050 NULL
ldap_int_select
read1msg: ld 0x55c5863d6050 msgid -1 all 1
ber_get_next
ldap_read: want=8, got=8
0000: 30 21 02 01 02 78 1c 0a 0!...x..
ldap_read: want=27, got=27
0000: 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e 3d 4d 61
........dn:cn=Ma
0010: 6e 61 67 65 72 2c 64 63 3d 62 65 nager,dc=be
ber_get_next: tag 0x30 len 33 contents:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a80 end=0x55c5863e0aa1 len=33
0000: 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e
...x..........dn
0010: 3a 63 6e 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62
:cn=Manager,dc=b
0020: 65 e
read1msg: ld 0x55c5863d6050 msgid 2 message type extended-result
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0aa1 len=30
0000: 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e
x..........dn:cn
0010: 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62 65 =Manager,dc=be
read1msg: ld 0x55c5863d6050 0 new referrals
read1msg: mark request completed, ld 0x55c5863d6050 msgid 2
request done: ld 0x55c5863d6050 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0aa1 len=30
0000: 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e
x..........dn:cn
0010: 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62 65 =Manager,dc=be
ber_scanf fmt (x) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a8c end=0x55c5863e0aa1 len=21
0000: 8b 13 64 6e 3a 63 6e 3d 4d 61 6e 61 67 65 72 2c
..dn:cn=Manager,
0010: 64 63 3d 62 65 dc=be
ber_scanf fmt (}) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0aa1 end=0x55c5863e0aa1 len=0
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a83 end=0x55c5863e0aa1 len=30
0000: 78 1c 0a 01 00 04 00 04 00 8b 13 64 6e 3a 63 6e
x..........dn:cn
0010: 3d 4d 61 6e 61 67 65 72 2c 64 63 3d 62 65 =Manager,dc=be
ber_scanf fmt (O) ber:
ber_dump: buf=0x55c5863e0a80 ptr=0x55c5863e0a8c end=0x55c5863e0aa1 len=21
0000: 8b 13 64 6e 3a 63 6e 3d 4d 61 6e 61 67 65 72 2c
..dn:cn=Manager,
0010: 64 63 3d 62 65 dc=be
dn:cn=Manager,dc=be
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
0000: 30 05 02 01 03 42 00 0....B.
ldap_write: want=7, written=7
0000: 30 05 02 01 03 42 00 0....B.
ldap_free_connection: actually freed
server# ldapwhoami -x -H ldap://192.168.100.11/ -D "cn=Manager,dc=be" -w
password -d -1
ldap_url_parse_ext(ldap://192.168.100.11/)
ldap_create
ldap_url_parse_ext(ldap://192.168.100.11:389/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 192.168.100.11:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.100.11:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x559745d846c0 ptr=0x559745d846c0 end=0x559745d846e6 len=38
0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d
0$...`......cn=M
0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61
anager,dc=be..pa
0020: 73 73 77 6f 72 64 ssword
ber_scanf fmt ({i) ber:
ber_dump: buf=0x559745d846c0 ptr=0x559745d846c5 end=0x559745d846e6 len=33
0000: 60 1f 02 01 03 04 10 63 6e 3d 4d 61 6e 61 67 65
`......cn=Manage
0010: 72 2c 64 63 3d 62 65 80 08 70 61 73 73 77 6f 72
r,dc=be..passwor
0020: 64 d
ber_flush2: 38 bytes to sd 3
0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d
0$...`......cn=M
0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61
anager,dc=be..pa
0020: 73 73 77 6f 72 64 ssword
ldap_write: want=38, written=38
0000: 30 24 02 01 01 60 1f 02 01 03 04 10 63 6e 3d 4d
0$...`......cn=M
0010: 61 6e 61 67 65 72 2c 64 63 3d 62 65 80 08 70 61
anager,dc=be..pa
0020: 73 73 77 6f 72 64 ssword
ldap_result ld 0x559745d7b070 msgid 1
wait4msg ld 0x559745d7b070 msgid 1 (infinite timeout)
wait4msg continue ld 0x559745d7b070 msgid 1 all 1
** ld 0x559745d7b070 Connections:
* host: 192.168.100.11 port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 11 20:54:07 2020
** ld 0x559745d7b070 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x559745d7b070 request count 1 (abandoned 0)
** ld 0x559745d7b070 Response Queue:
Empty
ld 0x559745d7b070 response count 0
ldap_chkResponseList ld 0x559745d7b070 msgid 1 all 1
ldap_chkResponseList returns ld 0x559745d7b070 NULL
ldap_int_select
read1msg: ld 0x559745d7b070 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=0
ber_get_next failed.
ldap_err2string
ldap_result: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed
Op do 12 mrt. 2020 om 00:04 schreef Quanah Gibson-Mount <quanah(a)symas.com>:
>
>
> --On Wednesday, March 11, 2020 9:59 PM +0100 Thierry Debaene
> <thierry.debaene(a)gmail.com> wrote:
>
> >
> > ldap_chkResponseList returns ld 0x55bbbd3ec070 NULL
> > ldap_int_select
> > read1msg: ld 0x55bbbd3ec070 msgid 1 all 1
> > ber_get_next
> > ldap_read: want=8, got=0
>
> It successfully connected to port 389 on that IP address, but got no
> response back from whatever is listening to that port on that IP address.
> I'd suggest comparing the output to the same command with no -H option
> specified.
>
> --Quanah
>
>
3 years, 6 months
Re: ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene
Dear Quanah,
Herewith the requested info.
Thanks a lot for you help and time !
Kind Regards,
Thierry
client# ldapwhoami -x -H ldap://192.168.100.11/ -D "cn=Manager,dc=be" -w
password -d 1
ldap_url_parse_ext(ldap://192.168.100.11/)
ldap_create
ldap_url_parse_ext(ldap://192.168.100.11:389/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 192.168.100.11:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.100.11:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 38 bytes to sd 3
ldap_result ld 0x55d49a4a3070 msgid 1
wait4msg ld 0x55d49a4a3070 msgid 1 (infinite timeout)
wait4msg continue ld 0x55d49a4a3070 msgid 1 all 1
** ld 0x55d49a4a3070 Connections:
* host: 192.168.100.11 port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 11 20:32:08 2020
** ld 0x55d49a4a3070 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x55d49a4a3070 request count 1 (abandoned 0)
** ld 0x55d49a4a3070 Response Queue:
Empty
ld 0x55d49a4a3070 response count 0
ldap_chkResponseList ld 0x55d49a4a3070 msgid 1 all 1
ldap_chkResponseList returns ld 0x55d49a4a3070 NULL
ldap_int_select
read1msg: ld 0x55d49a4a3070 msgid 1 all 1
ber_get_next
ldap_err2string
ldap_result: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed
server# ldapwhoami -x -D "uid=thierry,ou=People,ou=linux,dc=be" -w password
-d 1
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 58 bytes to sd 3
ldap_result ld 0x563d667e3060 msgid 1
wait4msg ld 0x563d667e3060 msgid 1 (infinite timeout)
wait4msg continue ld 0x563d667e3060 msgid 1 all 1
** ld 0x563d667e3060 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 11 20:30:44 2020
** ld 0x563d667e3060 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x563d667e3060 request count 1 (abandoned 0)
** ld 0x563d667e3060 Response Queue:
Empty
ld 0x563d667e3060 response count 0
ldap_chkResponseList ld 0x563d667e3060 msgid 1 all 1
ldap_chkResponseList returns ld 0x563d667e3060 NULL
ldap_int_select
read1msg: ld 0x563d667e3060 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x563d667e3060 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x563d667e3060 0 new referrals
read1msg: mark request completed, ld 0x563d667e3060 msgid 1
request done: ld 0x563d667e3060 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_extended_operation
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 32 bytes to sd 3
ldap_result ld 0x563d667e3060 msgid -1
wait4msg ld 0x563d667e3060 msgid -1 (timeout 100000 usec)
wait4msg continue ld 0x563d667e3060 msgid -1 all 1
** ld 0x563d667e3060 Connections:
* host: localhost port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 11 20:30:44 2020
** ld 0x563d667e3060 Outstanding Requests:
* msgid 2, origid 2, status InProgress
outstanding referrals 0, parent count 0
ld 0x563d667e3060 request count 1 (abandoned 0)
** ld 0x563d667e3060 Response Queue:
Empty
ld 0x563d667e3060 response count 0
ldap_chkResponseList ld 0x563d667e3060 msgid -1 all 1
ldap_chkResponseList returns ld 0x563d667e3060 NULL
ldap_int_select
read1msg: ld 0x563d667e3060 msgid -1 all 1
ber_get_next
ber_get_next: tag 0x30 len 53 contents:
read1msg: ld 0x563d667e3060 msgid 2 message type extended-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x563d667e3060 0 new referrals
read1msg: mark request completed, ld 0x563d667e3060 msgid 2
request done: ld 0x563d667e3060 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (x) ber:
ber_scanf fmt (}) ber:
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ber_scanf fmt (O) ber:
dn:uid=thierry,ou=People,ou=linux,dc=be
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed
Op wo 11 mrt. 2020 om 18:15 schreef Quanah Gibson-Mount <quanah(a)symas.com>:
>
>
> --On Wednesday, March 11, 2020 10:08 AM +0100 Thierry Debaene
> <thierry.debaene(a)gmail.com> wrote:
>
> >
> >
> > Dear Quanah, OpenLDAPs,
> >
> >
> > Herewith the proof that slapd is listening on port 389.
> > I also included the slapd.conf, /etc/sysconfig/slapd and ldap.conf files.
>
> I would:
>
> a) Start with ldapwhoami (rather than ldapsearch), just for simplicity
> b) add a -d -1 for full client side debugging to see where it's getting
> hung up
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 6 months
Information about source code of mobiuniquemember
by HANCHATE Ravikiran (u5574292)
Dear,
we need information about source code of mobiuniquemember.
How can we find source code of mobiuniquemember for our Opneldap infra ?
Kindly assist here .
Regards,
Ravikiran.
*********DISCLAIMER*********
This electronic transmission (and any attached document) is intended
exclusively for the person or entity to whom it is addressed and may
contain confidential and/or privileged material.
Any disclosure, copying, distribution or other action based upon
the information by persons or entities other than the intended recipient
is prohibited. If you receive this message in error, please contact the
sender and delete the material from any and all computers.
Orange Belgium does not warrant a proper and complete transmission of this
information, nor does it accept liability for any delays.
Unless clearly and unambiguously stated otherwise, the content of this
e-mail and its attachment is provided to you for information purposes
only, and nothing herein shall be binding upon, or shall constitute or
be construed as a binding offer of Orange Belgium.
*****END OF DISCLAIMER*****
3 years, 6 months
Re: ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene
Dear Quanah, OpenLDAPs,
Herewith the proof that slapd is listening on port 389.
I also included the slapd.conf, /etc/sysconfig/slapd and ldap.conf files.
Regards,
Thierry
# netstat -ltn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:389 0.0.0.0:*
LISTEN
tcp 0 0 127.0.0.1:8080 0.0.0.0:*
LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:*
LISTEN
tcp6 0 0 :::389 :::*
LISTEN
tcp6 0 0 :::3306 :::*
LISTEN
tcp6 0 0 :::22 :::*
LISTEN
# nc -zv 192.168.100.11 389
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.100.11:389.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
# cat /etc/openldap/slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/ppolicy.schema
allow bind_v2
idletimeout 10
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/lib64/openldap
moduleload ppolicy.la
moduleload syncprov
password-hash {CRYPT}
password-crypt-salt-format "$6$%.86s"
access to * by * read
database bdb
suffix "dc=be"
rootdn "cn=Manager,dc=be"
rootpw {CRYPT}$6$DAn/HuEvv8oxXzht$4...k4ZUiJG4qUKzqUTCQVtuUY1
directory /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=be"
ppolicy_use_lockout
# cat /etc/sysconfig/slapd
SLAPD_URLS="ldapi:/// ldap:///"
# cat /etc/openldap/ldap.conf
#TLS_CACERTDIR /etc/openldap/certs
#TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT never
SASL_NOCANON on
Op di 10 mrt. 2020 om 19:42 schreef Quanah Gibson-Mount <quanah(a)symas.com>:
> --On Tuesday, March 10, 2020 12:03 PM +0100 Thierry Debaene
> <thierry.debaene(a)gmail.com> wrote:
>
> ># ldapsearch -x -H ldap://192.168.100.11 -D
> ># "uid=thierry,ou=People,ou=linux,dc=be" -w password -b ou=linux,dc=be
> ># -LLL memberUid -v
> > ldap_initialize( ldap://192.168.100.11:389/??base )
> > ldap_result: Can't contact LDAP server (-1)
>
> Please provide evidence that slapd is listening to 192.168.100.11 on port
> 389 and that it can be accessed (i.e., no firewall etc blocking access).
>
> For example on my local system:
>
> nc -zv 10.2.0.74 389
> Connection to 10.2.0.74 389 port [tcp/ldap] succeeded!
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 6 months
ldapsearch not working with '-H ldap://<IP_LDAP_server>/' option
by Thierry Debaene
Hello OpenLDAPs,
Any LDAP search request with '-H ldap://<IP_LDAP_server>/' option returns
'Can't contact LDAP server (-1)' (see below).
When the '-H ...' option is left out or when '-H ldap:///' is used, the
expected result is returned (see below).
The 'ldapsearch -x -H ldap://<IP_LDAP_server>/ ...' behaves the same from
the server as from a client on the same LAN.
Thanks for helping me to get rid of this problem.
Thierry
# ldapsearch -x -H ldap://192.168.100.11 -D
"uid=thierry,ou=People,ou=linux,dc=be" -w password -b ou=linux,dc=be -LLL
memberUid -v
ldap_initialize( ldap://192.168.100.11:389/??base )
ldap_result: Can't contact LDAP server (-1)
# ldapsearch -x -D "uid=thierry,ou=People,ou=linux,dc=be" -w password -b
ou=linux,dc=be -LLL memberUid -v
ldap_initialize( <DEFAULT> )
filter: (objectclass=*)
requesting: memberUid
dn: cn=thierry,ou=Group,ou=linux,dc=be
memberUid: thierry
# ldapsearch -x -H ldap:/// -D "uid=thierry,ou=People,ou=linux,dc=be" -w
password -b ou=linux,dc=be -LLL memberUid -v
ldap_initialize( ldap://:389/??base )
filter: (objectclass=*)
requesting: memberUid
memberUid: thierry
3 years, 6 months
Re: back-ldap SASL proxy authorization
by Dieter Bocklandt
Hi Quanah,
Of course! Submitted this as ITS#9179.
Regards,
//Dieter
On Fri, 6 Mar 2020 at 17:52, Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Thursday, March 5, 2020 8:04 PM +0000 Howard Chu <hyc(a)symas.com>
> wrote:
>
> >> Actually, I spent some more time on this today and I /think/ I might
> >> know what's happening here:
> >
> > Your analysis makes sense. Would have to ask Pierangelo why he wrote it
> > the way he did but it seems that it should use op->o_ndn.
>
> Hi Dieter,
>
> Can you file an ITS on this issue at http://www.openldap.org/its
> including
> your analysis?
>
> Thanks!
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 6 months
Memory mapping questions
by Sam Dave
Hi,
1. Is it possible to disable memory mapping in LMDB?
2. If I create a brand-new database and write data into it (but haven't read it yet) can I be assured it won't be memory-mapped yet?
The purpose of these question is to get more consistent/reproducible time benchmarks for some stuff I'm doing. (As you know the drive vs. memory-mapped performance varies heavily.)
Thanks,
Sam
3 years, 6 months
Re: back-ldap SASL proxy authorization
by Dieter Bocklandt
Hey Quanah,
Thanks for getting back to me!
So as I understood it, I expected the proxied identity to be the identity
that the client successfully authorized as instead of the identity it
initially started with. The session tracking request is just there to
confirm that piece of information is actually present but not used. That
initial identity is also used for ACL evaluation on the producer side,
leading to insufficient access (as expected).
To give a maybe more clear example, assume the following users (stripped
down to just the relevant attributes in play):
*dn: cn=proxy,ou=System,dc=example,dc=netauthzTo: dn:**
*dn: cn=service,ou=System,dc=example,dc=net *
*authzTo: dn:uid=user,ou=People,dc=example,dc=net *
*dn: uid=dieter,ou=People,dc=example,dc=net *
*and the following idassert config:*
*olcDbIDAssertBind: mode=self flags=override,prescriptive tls_reqcert=never
bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX *
When I perform an operation like this:
ldapmodify -H ldaps://ldapserver -Y PLAIN -U service -X
dn:uid=dieter,ou=People,dc=example,dc=net -w servicepassword -f
modifications.ldif
I would assume the following takes place:
- The service user binds to the consumer and assumes dieter's identity,
which should be the same net effect as binding with dieter's user in the
first place.
- The proxy user binds to the provider and assumes dieter's identity
- The provider tries to perform the write, using dieter's identity for ACL
evaluation
What actually happens:
- The service user binds to the consumer and assumes dieter's identity
- The proxy user binds to the provider and assumes the service user's
identity
- The provider tries to perform the write, using the service user's
identity for ACL evaluation
Actually, I spent some more time on this today and I *think* I might know
what's happening here:
(from servers/slapd/back-ldap/bind.c in master):
line 2222 - 2227:
*if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; }
else { ndn = op->o_ndn; }*
line 2549 - 2557:
*if ( op->o_tag == LDAP_REQ_BIND ) { ndn = op->o_req_ndn; } else if (
!BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else {
ndn = op->o_ndn; }*
It seems it tries to use op->o_conn->c_ndn if it's not null, which is
(correct me if I'm wrong) the original authcID. That value however doesn't
change when performing a proxy authorization, while op->o_ndn does properly
reflect that. Shouldn't OpenLDAP always use op->o_ndn?
Again, let me know if I can provide more information or tell me if I'm
grossly misunderstanding how this is all supposed to work in the first
place :)
Thanks!
// Dieter
On Wed, 4 Mar 2020 at 23:12, Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt
> <dieterbocklandt(a)gmail.com> wrote:
>
> > However, we also have a service using SASL proxy authorization, in which
> > case the authcid is used in the ProxyAuthz instead of the authorized
> > authzid.
> >
> > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ
> > dn="cn=service,ou=system,dc=internal,dc=machines"
> > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2
> > [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD
> > dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines"
> >
> > Am I misunderstanding how this is supposed to work, am I hitting a
> > certain limitation or maybe a bug? Let me know if you need any more
> > details!
>
> This looks to me like it:
>
> a) Logs what the proxied identity is (PROXYAUTHZ
> dn="cn=service,ou=system,dc=internal,dc=machine")
>
> b) Logs what the actual identity making the changes is
> (USERNAME=cn=enduser,ou=People,dc=example,dc=net) and what IP address it
> came from (IP=10.243.72.199) so that if questions arise about who made a
> change, those questions can be answered from the logs.
>
> I.e., I see both bits of information provided in the connection operation.
>
> What makes you think you are hitting a limitation or a bug?
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
3 years, 6 months
Re: openldap-technical Digest, Vol 148, Issue 6
by Dieter Bocklandt
Hey Michael,
I would assume that for the proxy it shouldn't matter how the client got
authenticated to the consumer. Mode=self should just try and assert the
resulting authzID to the target. The identity of the proxy is only there so
we have something to bind with to the producer. With mode=none, that
identity would also be used for the actual ACL evaluation, but that would
just lead to all writes being done by seemingly 1 user, making auditing
impossible ...
Cheers,
//Dieter
On Fri, 6 Mar 2020 at 13:00, <openldap-technical-request(a)openldap.org>
wrote:
>
> ---------- Forwarded message ----------
> From: "Michael Ströder" <michael(a)stroeder.com>
> To: openldap-technical(a)openldap.org
> Cc:
> Bcc:
> Date: Thu, 5 Mar 2020 21:46:12 +0100
> Subject: Re: back-ldap SASL proxy authorization
> On 3/5/20 9:04 PM, Howard Chu wrote:
> > Dieter Bocklandt wrote:
> >> I would assume the following takes place:
> >> - The service user binds to the consumer and assumes dieter's identity,
> which should be the same net effect as binding with dieter's user in the
> first place.
> >> - The proxy user binds to the provider and assumes dieter's identity
> >> - The provider tries to perform the write, using dieter's identity for
> ACL evaluation
> >>
> >> What actually happens:
> >> - The service user binds to the consumer and assumes dieter's identity
> >> - The proxy user binds to the provider and assumes the service user's
> identity
> >> - The provider tries to perform the write, using the service user's
> identity for ACL evaluation
> >>
> >> Actually, I spent some more time on this today and I /think/ I might
> know what's happening here:
> >
> > Your analysis makes sense. Would have to ask Pierangelo why he wrote it
> the way he
> > did but it seems that it should use op->o_ndn.
>
> Hmm, is the semantics of proxying the SASL proxy authorization clearly
> defined? The consumer proxy itself also has an identity.
>
> Just asking...
>
> Ciao, Michael.
>
>
> _______________________________________________
> openldap-technical mailing list
> openldap-technical(a)openldap.org
> http://www.openldap.org/lists/mm/listinfo/openldap-technical
>
3 years, 6 months
