November 2021 - openldap-technical

Failed LDAP Synchronization (openldap-servers-2.4.44)

by nabeel.tariq＠rapidcompute.com

Hi, I have configured LDAP successfully on Centos 7. I have integrated it with my Axigen email server. I can authenticate successfully with LDAP. I can search all the records using ldapsearch command. ldapsearch -H ldaps://cyberldap.cyber.net.pk:636 -b "o=intranet,dc=cyber,dc=net,dc=pk" -D "cn=manager,dc=cyber,dc=net,dc=pk" -W -x However, while synchronizing LDAP with my Axigen, I have faced below mentioned error. 2021-11-24 11:17:50 +0500 02 test USERDB:00000001: Failed OpenLdap search basedn(o=intranet,dc=cyber,dc=net,dc=pk), filter((&(objectClass=inetOrgPerson))), error(Other (e.g., implementation specific) error) on domain cyber.net.pk

1 year, 10 months

1
0
0 / 0

Synchronisation ODSEE --> Openldap 2.5

by laurent.revillion＠ambre-systems.com

Hello, I want to synchronize the data in my ODSEE directory with the new Openldap directory. I have ODSEE [slapd 64-bit] Oracle Corporation. Sun-Directory-Server/11.1.1.7.3 B2015.0429.2115 64-bit ns-slapd : 11.1.1.7.3 B2015.0429.2115 ZIP Slapd Library : 11.1.1.7.3 B2015.0429.2115 Front-End Library : 11.1.1.7.3 B2015.0429.2115 end Openldap 2.5.X I did exactly what is indicated in the tests: openldap / tests / scripts / test072-dsee-sync openldap / tests / scripts / test075-dsee-persist The ODSEE directory starts correctly. When I start the Openldap instance with the indicated replication data / slapd-dsee-consumer1.conf data / slapd-dsee-consumer2.conf IN Openldap start i have (with -d -1 option) 61926439.1a909db2 0x7f7e26799880 slapd starting 61926439.1b711895 0x7f7e1e406700 daemon: added 4r listener=(nil) 61926439.1b718582 0x7f7e1e406700 daemon: added 7r listener=0x563d9bd87c10 61926439.1b71aee4 0x7f7e1e406700 daemon: added 8r listener=0x563d9bd87d00 61926439.1b728f00 0x7f7e1e406700 daemon: epoll: listen=7 active_threads=0 tvp=zero 61926439.1b729cbf 0x7f7e1e406700 daemon: epoll: listen=8 active_threads=0 tvp=zero 61926439.1b72aaf3 0x7f7e1e406700 daemon: activity on 1 descriptor 61926439.1b72b304 0x7f7e1e406700 daemon: activity on:61926439.1b72bbba 0x7f7e1e406700 61926439.1b72cd95 0x7f7e1e406700 daemon: epoll: listen=7 active_threads=0 tvp=zero 61926439.1b72d667 0x7f7e1e406700 daemon: epoll: listen=8 active_threads=0 tvp=zero 61926439.1c6896b8 0x7f7e1dc05700 >>> dnNormalize: <cn=Consumer 002> 61926439.1c691535 0x7f7e1dc05700 <<< dnNormalize: <cn=consumer 002> 61926439.1c69b3df 0x7f7e1dc05700 =>do_syncrepl rid=002 61926439.1c69eaae 0x7f7e1dc05700 ldap_create 61926439.1c6a1e25 0x7f7e1dc05700 ldap_url_parse_ext(ldap://127.0.0.1:3389) 61926439.1c6a3c1d 0x7f7e1dc05700 ldap_sasl_bind_s 61926439.1c6a4b7a 0x7f7e1dc05700 ldap_sasl_bind 61926439.1c6a8303 0x7f7e1dc05700 ldap_send_initial_request 61926439.1c6a9831 0x7f7e1dc05700 ldap_new_connection 1 1 0 61926439.1c6aa2a5 0x7f7e1dc05700 ldap_int_open_connection 61926439.1c6ab2ef 0x7f7e1dc05700 ldap_connect_to_host: TCP 127.0.0.1:3389 61926439.1c6aea76 0x7f7e1dc05700 ldap_new_socket: 12 61926439.1c6afeb6 0x7f7e1dc05700 ldap_prepare_socket: 12 61926439.1c6b1f47 0x7f7e1dc05700 ldap_connect_to_host: Trying 127.0.0.1:3389 61926439.1c6b2888 0x7f7e1dc05700 ldap_pvt_connect: fd: 12 tm: -1 async: 0 61926439.1c6b2fd3 0x7f7e1dc05700 attempting to connect: 61926439.1c6dd2fe 0x7f7e1dc05700 connect success 61926439.1c6e01eb 0x7f7e1dc05700 ldap_open_defconn: successful 61926439.1c6e0de0 0x7f7e1dc05700 ldap_send_server_request 61926439.1c6e1c57 0x7f7e1dc05700 ber_scanf fmt ({it) ber: 61926439.1c6e2774 0x7f7e1dc05700 ber_dump: buf=0x7f7e10001bb0 ptr=0x7f7e10001bb0 end=0x7f7e10001bda len=42 61926439.1c6e3112 0x7f7e1dc05700 0000: 30 28 02 01 01 60 23 02 01 03 04 14 63 6e 3d 64 0(...`#.....cn=d 61926439.1c6e3916 0x7f7e1dc05700 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 61926439.1c6e40a5 0x7f7e1dc05700 0020: 80 08 70 61 73 73 77 6f 72 64 ..password 61926439.1c6e4fb6 0x7f7e1dc05700 ber_scanf fmt ({i) ber: 61926439.1c6e5814 0x7f7e1dc05700 ber_dump: buf=0x7f7e10001bb0 ptr=0x7f7e10001bb5 end=0x7f7e10001bda len=37 61926439.1c6e5fe9 0x7f7e1dc05700 0000: 60 23 02 01 03 04 14 63 6e 3d 64 69 72 65 63 74 `#.....cn=direct 61926439.1c6e6776 0x7f7e1dc05700 0010: 6f 72 79 20 6d 61 6e 61 67 65 72 80 08 70 61 73 ory manager..pas 61926439.1c6e6f8f 0x7f7e1dc05700 0020: 73 77 6f 72 64 sword 61926439.1c6e8145 0x7f7e1dc05700 ber_flush2: 42 bytes to sd 12 61926439.1c6e8afb 0x7f7e1dc05700 0000: 30 28 02 01 01 60 23 02 01 03 04 14 63 6e 3d 64 0(...`#.....cn=d 61926439.1c6e9274 0x7f7e1dc05700 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 61926439.1c6e99ea 0x7f7e1dc05700 0020: 80 08 70 61 73 73 77 6f 72 64 ..password 61926439.1c6eec1c 0x7f7e1dc05700 ldap_write: want=42, written=42 61926439.1c6ef60f 0x7f7e1dc05700 0000: 30 28 02 01 01 60 23 02 01 03 04 14 63 6e 3d 64 0(...`#.....cn=d 61926439.1c6efd8d 0x7f7e1dc05700 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 61926439.1c6f05c4 0x7f7e1dc05700 0020: 80 08 70 61 73 73 77 6f 72 64 ..password 61926439.1c6f2277 0x7f7e1dc05700 ldap_result ld 0x7f7e10000920 msgid 1 61926439.1c6f2c34 0x7f7e1dc05700 wait4msg ld 0x7f7e10000920 msgid 1 (infinite timeout) 61926439.1c6f34b0 0x7f7e1dc05700 wait4msg continue ld 0x7f7e10000920 msgid 1 all 1 61926439.1c6f3e6c 0x7f7e1dc05700 ** ld 0x7f7e10000920 Connections: 61926439.1c6f52a0 0x7f7e1dc05700 * host: 127.0.0.1 port: 3389 (default) 61926439.1c6f6877 0x7f7e1dc05700 * from: IP=127.0.0.1:56180 61926439.1c6f70a2 0x7f7e1dc05700 refcnt: 2 status: Connected 61926439.1c6f8693 0x7f7e1dc05700 last used: Mon Nov 15 14:44:25 2021 61926439.1c6f8f52 0x7f7e1dc05700 61926439.1c6f98a4 0x7f7e1dc05700 ** ld 0x7f7e10000920 Outstanding Requests: 61926439.1c6fa2a6 0x7f7e1dc05700 * msgid 1, origid 1, status InProgress 61926439.1c6fab71 0x7f7e1dc05700 outstanding referrals 0, parent count 0 61926439.1c6fb4ca 0x7f7e1dc05700 ld 0x7f7e10000920 request count 1 (abandoned 0) 61926439.1c6fbc72 0x7f7e1dc05700 ** ld 0x7f7e10000920 Response Queue: 61926439.1c6fc3fa 0x7f7e1dc05700 Empty 61926439.1c6fcb6c 0x7f7e1dc05700 ld 0x7f7e10000920 response count 0 61926439.1c6fd389 0x7f7e1dc05700 ldap_chkResponseList ld 0x7f7e10000920 msgid 1 all 1 61926439.1c6fdb88 0x7f7e1dc05700 ldap_chkResponseList returns ld 0x7f7e10000920 NULL 61926439.1c6fe4a8 0x7f7e1dc05700 ldap_int_select 61926439.1c728a2b 0x7f7e1dc05700 read1msg: ld 0x7f7e10000920 msgid 1 all 1 61926439.1c72a729 0x7f7e1dc05700 ber_get_next 61926439.1c72bcf8 0x7f7e1dc05700 ldap_read: want=8, got=8 61926439.1c72c592 0x7f7e1dc05700 0000: 30 0c 02 01 01 61 07 0a 0....a.. 61926439.1c72ddfd 0x7f7e1dc05700 ldap_read: want=6, got=6 61926439.1c72e594 0x7f7e1dc05700 0000: 01 00 04 00 04 00 ...... 61926439.1c72ef09 0x7f7e1dc05700 ber_get_next: tag 0x30 len 12 contents: 61926439.1c72f810 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011c0 end=0x7f7e100011cc len=12 61926439.1c73000c 0x7f7e1dc05700 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ 61926439.1c73242e 0x7f7e1dc05700 ldap_find_request_by_msgid: msgid 1, lr 0x7f7e100010a0 lr->lr_refcnt = 1 61926439.1c7331b9 0x7f7e1dc05700 read1msg: ld 0x7f7e10000920 msgid 1 message type bind 61926439.1c733b07 0x7f7e1dc05700 ber_scanf fmt ({eAA) ber: 61926439.1c73431c 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011c3 end=0x7f7e100011cc len=9 61926439.1c734ad7 0x7f7e1dc05700 0000: 61 07 0a 01 00 04 00 04 00 a........ 61926439.1c7357b8 0x7f7e1dc05700 read1msg: ld 0x7f7e10000920 0 new referrals 61926439.1c736002 0x7f7e1dc05700 read1msg: mark request completed, ld 0x7f7e10000920 msgid 1 61926439.1c736829 0x7f7e1dc05700 request done: ld 0x7f7e10000920 msgid 1 61926439.1c73709e 0x7f7e1dc05700 res_errno: 0, res_error: <>, res_matched: <> 61926439.1c737a4d 0x7f7e1dc05700 ldap_return_request: lrx 0x7f7e100010a0, lr 0x7f7e100010a0 61926439.1c738307 0x7f7e1dc05700 ldap_return_request: lrx->lr_msgid 1, lrx->lr_refcnt is now 0, lr is still present 61926439.1c738cab 0x7f7e1dc05700 ldap_free_request (origid 1, msgid 1) 61926439.1c739a8c 0x7f7e1dc05700 ldap_free_request_int: lr 0x7f7e100010a0 msgid 1 removed 61926439.1c73a4cd 0x7f7e1dc05700 ldap_do_free_request: asked to free lr 0x7f7e100010a0 msgid 1 refcnt 0 61926439.1c73bb4b 0x7f7e1dc05700 ldap_parse_result 61926439.1c73c76f 0x7f7e1dc05700 ber_scanf fmt ({iAA) ber: 61926439.1c73cf85 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011c3 end=0x7f7e100011cc len=9 61926439.1c73d701 0x7f7e1dc05700 0000: 61 07 0a 01 00 04 00 04 00 a........ 61926439.1c73e2d4 0x7f7e1dc05700 ber_scanf fmt (}) ber: 61926439.1c73eac1 0x7f7e1dc05700 ber_dump: buf=0x7f7e100011c0 ptr=0x7f7e100011cc end=0x7f7e100011cc len=0 61926439.1c73f201 0x7f7e1dc05700 61926439.1c73fad8 0x7f7e1dc05700 ldap_msgfree 61926439.1c746e58 0x7f7e1dc05700 => mdb_entry_get: ndn: "dc=ici,dc=fr" 61926439.1c74789d 0x7f7e1dc05700 => mdb_entry_get: oc: "(null)", at: "lastChangeNumber" 61926439.1c74ce52 0x7f7e1dc05700 mdb_dn2entry("dc=ici,dc=fr") 61926439.1c76894c 0x7f7e1dc05700 => mdb_dn2id("dc=ici,dc=fr") 61926439.1c76a201 0x7f7e1dc05700 <= mdb_dn2id: got id=0x1 61926439.1c76c985 0x7f7e1dc05700 => mdb_entry_decode: 61926439.1c76e088 0x7f7e1dc05700 <= mdb_entry_decode 61926439.1c76ec57 0x7f7e1dc05700 => mdb_entry_get: found entry: "dc=ici,dc=fr" 61926439.1c76f8d5 0x7f7e1dc05700 <= mdb_entry_get: failed to find attribute lastChangeNumber 61926439.1c770d36 0x7f7e1dc05700 mdb_entry_get: rc=16 61926439.1c7717f9 0x7f7e1dc05700 do_syncrep1: rid=002 starting refresh (sending cookie=(null)) slapd: memory.c:705: ber_bvreplace_x: Assertion `!((src)->bv_val == ((void *)0))' failed. ./start-consumer1.sh : ligne 4 : 15293 Abandon /opt/symas/lib/slapd -d -1 -u ldap -g ldap -h "ldap://:5389/" -f /opt/symas/config/static-test/slapd-dsee-consumer1.conf IN access log ODSEE i have : [15/Nov/2021:14:44:25 +0100] conn=18 op=0 msgId=1 - BIND dn="cn=directory manager" method=128 version=3 [15/Nov/2021:14:44:25 +0100] conn=18 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [15/Nov/2021:14:44:25 +0100] conn=18 op=1 msgId=0 - RESULT err=80 tag=120 nentries=0 etime=0 [15/Nov/2021:14:44:25 +0100] conn=18 op=-1 msgId=-1 - closing from 127.0.0.1:56180 - A1 - Client aborted connection - [15/Nov/2021:14:44:25 +0100] conn=18 op=-1 msgId=-1 - closed. I do not understand why ODSEE systematically gives an error 80 following the BIND of the consumer Openldap. Can you help me ? Thanks

1 year, 10 months

2
2
0 / 0

OpenLDAP 2.6 installation on RHEL 7.9

by sumanbadra＠gmail.com

Hi, I have been trying to install OpenLDAP 2.6 in RHEL 7.9. At my first attempt it was failed as it requires openssl version 1.1.1 or greater. I had installed 1.1.1l as earlier version was openssl 1.0.2k. (installed with "./config --prefix=/usr --openssldir=/etc/ssl --libdir=lib shared" from the directory /usr/local/src/openssl-1.1.1l as root account and export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64 echo "export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64" >> ~/.bashrc) Verified openssl vesrion # openssl version OpenSSL 1.1.1l 24 Aug 2021 # which openssl /bin/openssl # openssl version -d OPENSSLDIR: "/usr/local/ssl" Now when I tried openldap 2.6 again I am getting below error ------ checking for sys/un.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_export_keying_material_early in -lssl... no configure: error: Could not locate TLS/SSL package ------ I am trying to run below config vi /root/.ldap-env -------- export PATH=/opt/orsus/openldap-2.6/bin:/opt/orsus/openldap-2.6/sbin:/opt/orsus/openldap-2.6/libexec:$PATH export OWNER=ldap:ldap export CONFIG=/opt/orsus/openldap-2.6/etc/openldap/slapd.d -------- source /root/.ldap-env ./configure --with-cyrus-sasl --with-argon2 --with-systemd --with-tls=openssl --enable-overlays=mod --enable-backends=mod --disable-perl --disable-ndb --enable-crypt --enable-modules --enable-dynamic --enable-syslog --enable-debug --enable-local --enable-spasswd --disable-sql --disable-hdb --disable-bdb --prefix=/opt/orsus/openldap-2.6.0 I have tried below but still no luck. LDFLAGS="-L/usr/lib64/openssl -Wl,-rpath,/usr/include/openssl" CPPFLAGS="-I/usr/include/openssl" export CPPFLAGS export LDFLAGS Kindly help me. Thank you!!

1 year, 10 months

1
0
0 / 0

contextCSN value

by bourguijl＠gmail.com

Dears, In context of a 4 MMR mirrored, if I do a ldapsearch for contextCSN of cn=config, I get following output : contextCSN: 20210720121843.555301Z#000000#000#000000 contextCSN: 20211001095511.729248Z#000000#001#000000 contextCSN: 20211021090559.554997Z#000000#002#000000 contextCSN: 20211025120556.001311Z#000000#003#000000 contextCSN: 20211021090202.909879Z#000000#004#000000 which is correct as I've 4 servers, but if I do same request for my own dn DB o=xxxx.be, I get following output : contextCSN: 20211116155042.534901Z#000000#001#000000 contextCSN: 20211116153150.449895Z#000000#002#000000 for me I should receive 003 & 004 ones too as they are in mirrored mode, no ? Can you advice ? Thx, Jean-Luc.

1 year, 10 months

3
2
0 / 0

global vs. frontend config in slapd.conf

by Michael Ströder

HI! Since the fix for ITS#9575 there is this misleading message even when invoking slapcat: /opt/openldap-ms/etc/openldap/slapd.conf: line 126: setting password scheme in the global entry is deprecated. The server may refuse to start if it is provided by a loadable module, please move it to the frontend database instead As you can see I'm using static config (aka slapd.conf). Can I avoid this warning by rearraging something in slapd.conf? Ciao, Michael.

1 year, 10 months

2
2
0 / 0

Re: Referrals on glued databases

by Nick Folino

nvm. I found the updatedn option. On Tue, Nov 16, 2021 at 9:24 AM Nick Folino <nick(a)folino.us> wrote: > > > ---------- Forwarded message --------- > From: Nick Folino <nick(a)folino.us> > Date: Tue, Nov 16, 2021 at 9:12 AM > Subject: Referrals on glued databases > To: OpenLDAP Technical Discussion List <openldap-technical(a)openldap.org> > > > Can anyone provide guidance on using referrals on consumers with glued > directories? > > For example if I have a root of dc=bar, with a separate database glued as > o=foo,dc=bar. Replication works fine in o=foo by configuring it on dc=bar. > > Configuring an updateref on dc=bar also works for updates to dc=bar, but > does not work for updates to o=foo. > > I can't add an updateref to o=foo as there is no replication defined on > that database. > > How can I configure this to provide referrals from all glued directories? > > Nick >

1 year, 10 months

1
0
0 / 0

Referrals on glued databases

by Nick Folino

Can anyone provide guidance on using referrals on consumers with glued directories? For example if I have a root of dc=bar, with a separate database glued as o=foo,dc=bar. Replication works fine in o=foo by configuring it on dc=bar. Configuring an updateref on dc=bar also works for updates to dc=bar, but does not work for updates to o=foo. I can't add an updateref to o=foo as there is no replication defined on that database. How can I configure this to provide referrals from all glued directories? Nick

1 year, 10 months

1
0
0 / 0

RE: [EXT]:Re: OpenLDAP SSLV3 disable

by Quanah Gibson-Mount

--On Sunday, November 14, 2021 9:36 PM +0000 "Ballem, Narayanan" <Narayanan.Ballem(a)Staples.com> wrote: > I modified the file as per the base but no luck with that. > When I look TLS library which slapd program it's looks like it's using > gnutls . Do I need to configure in different way for GNUTLS for TLS > version in slapd. Yes. You will need to consult the GnuTLS documentation. The slapd man page clearly states that the TLSProtocolMin option is ignored when linked to GnuTLS. I generally advise linking to OpenSSL for a number of different reasons. I believe with GnuTLS you do this via the TLSCipherSuite option to slapd. See also <https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/...>. One example from Exim sets the cipher suites to: NORMAL:!VERS-SSL3.0 so that may be of help. See also the slapd.conf(5) man page section on TLSCipherSuite for the GnuTLS command line to print out relevant information. This ticket may also be helpful: <https://mod.gnutls.org/ticket/29> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 year, 10 months

2
1
0 / 0

OpenLDAP client build/compilation steps on Windows platform

by c.venugopal521＠gmail.com

Hi Team, I am planning to migrate the NSLDAP C SDK to OpenLDAP (2.5/2.6) client SDK of the latest version. For this, I need to build OpenLDAP libraries/dlls to use them for our source code compilation and to run our application. Can someone please provide detailed steps to compile OpenLDAP on Windows platform with Microsoft Visual Studio 2019 as C compiler. - How to prepare a build environment (like any Cygwin installation required?) - What are the prerequisites for building OpenLDAP on Windows? - How to pass prerequisites while building OpenLDAP - What are the ENV variables that need to be set before building OpenLDAP code? - What are the options that we should pass to ./configure to generate .libs and .dlls (shared libs and static) along with TLS (say: OpenSSL as SSL provider) - What are the changes required in OpenLDAP source code to compile successfully on Windows with MSVC compiler if any? I am expecting .libs and .dll files (ex: libldap.lib, libldap.dll, liblber.lib, liblber.dll etc) from the compilation of OpenLDAP along with client utilities (.exe s) Once I successfully build, I will try to build OpenLDAP on the RHEL platform with gcc C compiler as my next step. Please help me here to build OpenLDAP successfully.

1 year, 10 months

2
3
0 / 0

compare operation behaves differently under 2.5

by Paul B. Henson

I've run into another quirk during my 2.5 upgrade process. We use the Apache ldap authnz module with a configuration such as: AuthLDAPURL ldaps://ldap.cpp.edu:636/DC=cpp,DC=edu?uid Require ldap-group uid=unxadmin,ou=group,dc=cpp,dc=edu This stopped working when accessing a server updated to 2.5. On the 2.4 server, the Apache logs look like: [Wed Nov 10 15:07:52.056237 2021] [authnz_ldap:debug] [pid 29887] mod_authnz_ldap.c(926): [client 10.104.223.117:51050] AH01714: auth_ldap authorize: require group: testing for member: uid=henson,ou=user,dc=cpp,dc=edu (uid=unxadmin,ou=group,dc=cpp,dc=edu) [Wed Nov 10 15:07:52.056264 2021] [authnz_ldap:debug] [pid 29887] mod_authnz_ldap.c(935): [client 10.104.223.117:51050] AH01715: auth_ldap authorize: require group: authorization successful (attribute member) [Comparison true (cached)][6 - Compare True] and the slapd logs look like: Nov 10 15:07:52 ldap-01 slapd[1233]: conn=224154 op=4 CMP dn="uid=unxadmin,ou=group,dc=cpp,dc=edu" attr="member" Nov 10 15:07:52 ldap-01 slapd[1233]: conn=224154 op=4 RESULT tag=111 err=6 text= Nov 10 15:08:42 ldap-01 slapd[1233]: conn=224154 fd=138 closed (connection lost) whereas on the 2.5 server, the Apache logs look like: [Wed Nov 10 15:03:52.375004 2021] [authnz_ldap:debug] [pid 29088] mod_authnz_ldap.c(926): [client 10.104.223.117:51022] AH01714: auth_ldap authorize: require group: testing for member: uid=henson,ou=user,dc=cpp,dc=edu (uid=unxadmin,ou=group,dc=cpp,dc=edu) [Wed Nov 10 15:03:52.375887 2021] [authnz_ldap:debug] [pid 29088] mod_authnz_ldap.c(945): [client 10.104.223.117:51022] AH01719: auth_ldap authorize: require group "uid=unxadmin,ou=group,dc=cpp,dc=edu": didn't match with attr member [Comparison false (adding to cache)][5 - Compare False] and the slapd logs look like: Nov 10 15:03:52 ldap-03 slapd[1197]: conn=208924 op=4 CMP dn="uid=unxadmin,ou=group,dc=cpp,dc=edu" attr="member" Nov 10 15:03:52 ldap-03 slapd[1197]: conn=208924 op=4 RESULT tag=111 err=5 qtime=0.000011 etime=0.000139 text= If I understand correctly, Apache is making a compare call to check to see if my DN (uid=henson,ou=user,dc=cpp,dc=edu) exists as a value of the member attribute in the group uid=unxadmin,ou=group,dc=cpp,dc=edu. It certainly does, on both the server running 2.4 and 2.5: dn: uid=unxadmin,ou=group,dc=cpp,dc=edu objectClass: groupOfNames objectClass: cppGroup objectClass: posixGroup uid: unxadmin cn: Unix Administrators gidNumber: 17730 member: member: uid=gkuri,ou=user,dc=cpp,dc=edu member: uid=henson,ou=user,dc=cpp,dc=edu memberUid: gkuri memberUid: henson Any thoughts on why this is behaving differently? The configuration should be pretty much identical, modulo required path changes and updating the memberOf handling. I was able to work around it by sitting a couple of additional parameters: AuthLDAPGroupAttribute memberUid AuthLDAPGroupAttributeIsDN off This now compares just my uid (henson) to the group memberUid attribute: Nov 10 15:24:54 ldap-03 slapd[1197]: conn=210708 op=4 CMP dn="uid=unxadmin,ou=group,dc=cpp,dc=edu" attr="memberUid" Nov 10 15:24:54 ldap-03 slapd[1197]: conn=210708 op=4 RESULT tag=111 err=6 qtime=0.000016 etime=0.000108 text= Apparently "err=6" is good and "err=5" is not :)? I was able to replicate this difference in behavior using the CLI tools: # ldapcompare -x -H ldaps://ldap-01.ldap.cpp.edu/ uid=unxadmin,ou=group,dc=cpp,dc=edu member:uid=henson,ou=user,dc=cpp,dc=edu TRUE # ldapcompare -x -H ldaps://ldap-03.ldap.cpp.edu/ uid=unxadmin,ou=group,dc=cpp,dc=edu member:uid=henson,ou=user,dc=cpp,dc=edu FALSE ldapsearch confirms that attribute exists for that group in both locations: ldapsearch -x -H ldaps://ldap-01.ldap.cpp.edu/ member=uid=henson,ou=user,dc=cpp,dc=edu dn | grep unxadmin # unxadmin, group, cpp.edu dn: uid=unxadmin,ou=group,dc=cpp,dc=edu # ldapsearch -x -H ldaps://ldap-03.ldap.cpp.edu/ member=uid=henson,ou=user,dc=cpp,dc=edu dn | grep unxadmin # unxadmin, group, cpp.edu dn: uid=unxadmin,ou=group,dc=cpp,dc=edu Help :)? Thanks much…

1 year, 10 months

2
4
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2021