openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure
by Siddharth Jain 06 Oct '20

06 Oct '20

(I mistakenly posted this at openldap-its earlier. apologies if anyone saw it there) Hello, We have a LDAP server running with TLS enabled and verified we can connect to it from openssl s_client. This works: $ openssl s_client -connect ldap.foo.com:636 -cert client_tls_cert.pem -key client_tls_key.pem -state -nbio -CAfile ca_chain.pem -showcerts But ldapsearch throws an error: $ ldapsearch -d 1 -x -H ldaps://ldap.foo.com:636 ... -ZZ TLS: during handshake: peer cert is valid, or was ignored if verification disabled (-9841) TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure We followed the instructions given at https://www.openldap.org/doc/admin24/tls.html#Client%20Configuration. We edited /etc/openldap/ldap.conf like so: TLS_REQCERT demand TLS_CACERT ca_chain.pem TLS_CACERTDIR /path/to/ca/cert TLS_CERT client_tls_cert.pem TLS_KEY client_tls_key.pem The ca_chain.pem file is placed under /path/to/ca/cert. We are running ldapsearch on a Mac. Can anyone help us? Sid PS: we do see following on server: TLS trace: SSL_accept:before SSL initialization TLS trace: SSL_accept:before SSL initialization TLS trace: SSL_accept:SSLv3/TLS read client hello TLS trace: SSL_accept:SSLv3/TLS write server hello TLS trace: SSL_accept:SSLv3/TLS write certificate TLS trace: SSL_accept:SSLv3/TLS write key exchange TLS trace: SSL_accept:SSLv3/TLS write certificate request TLS trace: SSL_accept:SSLv3/TLS write server done

5 9

ACL not behaving as I would expect
by Scott Classen 02 Oct '20

02 Oct '20

Hello, I’m having trouble understanding why I can’t get a service account to reset a userPassword attribute. ACLs are: {0}to attrs=userPassword by self write by anonymous auth by * none {1}to * by self write by users read by dn.base="uid=pwreset,dc=example,dc=com" write by * none But when the password reset utility attempts to modify the password I see the following 50 error, indicating that the ACL is somehow preventing the pwreset account from modifying userPassword Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 ACCEPT from IP=192.168.1.104:52888 (IP=0.0.0.0:389) Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 STARTTLS Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 RESULT oid= err=0 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 TLS established tls_ssf=256 ssf=256 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" method=128 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" mech=SIMPLE ssf=0 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 RESULT tag=97 err=0 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=username))" Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD dn="uid=username,ou=People,dc=example,dc=com" Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD attr=userPassword Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 RESULT tag=103 err=50 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=4 UNBIND Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 closed I’ve also tried with this ACL combination: {0}to attrs=userPassword by self write by anonymous auth by dn.base="uid=pwreset,dc=example,dc=com" write by * none {1}to * by self write by users read by * none Any advice would be greatly appreciated. Scott

3 7

Re: RE24 testing call #1 (OpenLDAP 2.4.54)
by Nick Folino 02 Oct '20

02 Oct '20

No problems noted on Fedora 32. On Thu, Oct 1, 2020 at 12:19 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the first testing call for OpenLDAP 2.4.54. Depending on the > results, this may be the only testing call. > > Generally, get the code for RE24: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.4.54 Engineering > Fixed slapd delta-syncrepl to ignore delete ops on deleted entry > (ITS#9342) > Fixed slapd delta-syncrepl to be fully serialized (ITS#9330) > Fixed slapd delta-syncrepl MOD on zero-length context entry (ITS#9352) > Fixed slapd sessionlog to use a TAVL tree (ITS#8486) > Fixed slapd syncrepl to be fully serialized (ITS#8102) > Fixed slapd syncrepl to call check_syncprov on fresh consumer > (ITS#9345) > Fixed slapd syncrepl to propagate errors from overlay_entry_get_ov > (ITS#9355) > Fixed slapd syncrepl to not create empty ADD ops (ITS#9359) > Fixed slapd syncrepl replace usage on single valued attrs (ITS#9295) > Fixed slapd-monitor fix monitor_back_register_database for empty > suffix > DB (ITS#9353) > Fixed slapo-accesslog normalizer for reqStart (ITS#9358) > Fixed slapo-syncprov contextCSN generation with empty suffix (ITS#9015) > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: RE24 testing call #1 (OpenLDAP 2.4.54)
by Nick Folino 01 Oct '20

01 Oct '20

oops. Yes I did. Sorry. Nick On Thu, Oct 1, 2020 at 1:27 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, October 1, 2020 2:21 PM -0400 Nick Folino <nick(a)folino.us> > wrote: > > > > > --enable-monitor is missing from configure > > > > > > configure: WARNING: unrecognized options: --enable-monitor > > It appears you grabbed openldap trunk and not the RE24 branch. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: RE24 testing call #1 (OpenLDAP 2.4.54)
by Nick Folino 01 Oct '20

01 Oct '20

--enable-monitor is missing from configure configure: WARNING: unrecognized options: --enable-monitor Nick On Thu, Oct 1, 2020 at 12:19 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the first testing call for OpenLDAP 2.4.54. Depending on the > results, this may be the only testing call. > > Generally, get the code for RE24: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.4.54 Engineering > Fixed slapd delta-syncrepl to ignore delete ops on deleted entry > (ITS#9342) > Fixed slapd delta-syncrepl to be fully serialized (ITS#9330) > Fixed slapd delta-syncrepl MOD on zero-length context entry (ITS#9352) > Fixed slapd sessionlog to use a TAVL tree (ITS#8486) > Fixed slapd syncrepl to be fully serialized (ITS#8102) > Fixed slapd syncrepl to call check_syncprov on fresh consumer > (ITS#9345) > Fixed slapd syncrepl to propagate errors from overlay_entry_get_ov > (ITS#9355) > Fixed slapd syncrepl to not create empty ADD ops (ITS#9359) > Fixed slapd syncrepl replace usage on single valued attrs (ITS#9295) > Fixed slapd-monitor fix monitor_back_register_database for empty > suffix > DB (ITS#9353) > Fixed slapo-accesslog normalizer for reqStart (ITS#9358) > Fixed slapo-syncprov contextCSN generation with empty suffix (ITS#9015) > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

ldap_start_tls: Connect error - self signed certificate in certificate chain
by paul.jc＠yahoo.com 01 Oct '20

01 Oct '20

Hello, I have recently upgraded from openldap 2.4.45 to 2.5.53. I are running into one issue when running ldapsearch wth StartTLS locally on the openldap servers. I get the following error whereas I did not prior to upgrade. Any input/suggestions welcome. $ ldapsearch -ZZ -LLL -H ldap://<uri> -x -D "cn=admin, dc=<test.dc,dc=com" -b "dc=test,dc=com" -w ${pw} ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) Here is the debug: -------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 3, err: 19, subject: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority, issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). ldap_err2string ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) -------------- This does not happen with the same ldapsearch done remotely - TLS works just fine with remote ldapsearch queries. Running ldapsearch without StartTLS locally on the server works just fine as well. Prior to this upgrade, we had built openldap with MozNSS (--with-tls=moznss) but now are using the recommended openssl. With our earlier version, running ldapsearch with StartTLS locally on the openldap servers worked without issue. Our certs are not self signed but it appears tls with ldapsearch is seeing the CA cert from our CA as self signed when running locally on the server. Is this even a problem since remote connectivity with TLS works fine? Since we were running moznss prior, I am not sure what the expected behavior is now but it seems that it should work the same as before. A few more details: ------------------ -Servers are CentOS Linux release 7.5 -We are running Openldap version: OpenSSL 1.0.2k-fips 26 Jan 2017 -We are using the same certs (no changes to the certs as part of the upgrade) -Here is partial output from openssl s_client -connect <hostname-here>:636 (same result with openssl s_client -connect <hostname-here>:389 -starttls ldap): This shows return code of 0 (ok): -------------- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Verify return code: 0 (ok) -------------- -Ran openssl s_client -verify 3 -connect localhost:636 (and with hostname as well) and openssl s_client -showcerts -connect localhost:636. Both return code 0 (ok): Verify return code: 0 (ok) -Checked the certs: openssl verify -verbose -x509_strict -CAfile ca.crt slapd.crt slapd.crt: OK -Here is our cert config: olcTLSCACertificateFile: /etc/openldap/certs/ca.crt olcTLSCertificateFile: /etc/openldap/certs/slapd.crt olcTLSCertificateKeyFile: /etc/openldap/certs/slapd.key For reference, here is the debug output when running the same ldapsearch command locally on the server on our previous version (2.4.45 with moznss) and the same cert is validated. -------------- TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: certificate [CN=*<test-domain-here>,OU=Domain Control Validated] is valid TLS certificate verification: subject: CN=*<test-domain-here>,OU=Domain Control Validated, issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US, cipher: AES-256-GCM, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_sasl_bind -------------- Any suggestions are appreciated. Thanks. Paul

2 3

When will OpenLDAP 2.5 be released officially?
by junc76＠gmail.com 30 Sep '20

30 Sep '20

Out product is planned to support the ldap channel binding required by MS (ADV190023). It seems that the feature has been implemented. https://bugs.openldap.org/show_bug.cgi?id=9189. From the isse description above, the target milestone is 2.5.0. My question is when will the version 2.5.0 be released? Thank you very much.

2 1

What does "slapcat: error writing output" means?
by Dario García Díaz-Miguel 30 Sep '20

30 Sep '20

Hello everyone, I couldn't find an answer or explanation about this error, so I hope somebody could help me over here. I use slapcat with head, grep and awk to retrieve some information and store it into a variable for a shell/bash script. Whenever I use slapcat, the output prompts the following error: - slapcat: error writing output. However, the information looked for is correctly retrieved. What's the reason behind this message? Is there a way to address it or at least, ignore it and hiding it? I can't just redirect that output to /dev/null. Version: Openldap2-2.4.41-18.43.1 Suse 12 SP3 Thank you so much. Kind Regards. Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com P Please consider the environment before printing this e-mail.

2 1

Issues with resetting user password
by CLARKE, ED C 29 Sep '20

29 Sep '20

Hello, I am new to this arena, I have a Open LDAP installed on my Linux server RHEL 7.8. I am not able to reset user passwords, I have checked the systemctl status slapd.service And it is active & running. Below is an example of the resetpw.ldif: $ cat ResetPW.ldif # dn: uid=foxdiv,ou=People,dc=att,dc=com changetype: modify replace: pwdReset pwdReset: TRUE - replace: userPassword userPassword: xxxxxxxxxxxx Any help would be appreciated, also any help on client side commands to test communications. Thanks, Ed Ed Clarke Senior Software Engineer Operations Transformation, Real-time Automation & Predictive Insights<http://mysolutions.dev.att.com/GNFO_Solutions/index.jsp> "RAPID" Certified Quality Eng. - ISO 9000/1 Six Sigma - Yellow Belt AT&T Veterans AT&T "ATO" 1010 Pine ST. Shared, St. Louis, MO. 63101 m 636.639.0713 | o 314.335.3158 | ec4397(a)att.com<mailto:ec4397@att.com>

4 19

delta-syncrepl "got search entry without Sync State control"
by Stefan Kania 29 Sep '20

29 Sep '20

I try to set up a delta-syncrepl configured via slapd.d. Building the configuration with Ansilbe. I got the following errormessages on my two consumers: ---------------- Sep 08 19:45:49 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:49 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) Sep 08 19:45:54 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:54 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (3 retries left) Sep 08 19:45:59 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:45:59 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (2 retries left) Sep 08 19:46:04 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:04 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying (1 retries left) Sep 08 19:46:09 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:09 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying Sep 08 19:46:14 ldapslave-01 slapd[3198]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20200908174203.000008Z,cn=accesslog) Sep 08 19:46:14 ldapslave-01 slapd[3198]: do_syncrepl: rid=001 rc -1 retrying ---------------- Here is my configuration of the provider: ------------- # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapmaster-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapmaster-key.pem olcToolThreads: 1 # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}syncprov.la olcModuleLoad: {2}accesslog.la . . . # {0}mdb, config dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb # {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500 # {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb # {1}mdb, config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1} to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2} to attrs=shadowLastChange by self write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824 # {0}syncprov, {1}mdb, config dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 300 # {2}mdb, config dn: olcDatabase={2}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcAccess: {0} to dn.sub=cn=accesslog by dn.exact=cn=repl-user,ou=users,dc=exa mple,dc=net read by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net read olcDbIndex: reqStart,reqEnd,reqMod,reqResult eq # {0}accesslog, {2}mdb, config dn: olcOverlay={0}accesslog,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 01+00:00 00+04:00 olcAccessLogSuccess: TRUE ------------- As you can see, the syncrepl and accesslog overlays are configured. The database files are pressend and filepermission is ok. Here now the configuration of the consumer ------------- # config dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certificates/cacert.pem olcTLSCertificateFile: /etc/ssl/certificates/ldapslave-01-cert.pem olcTLSCertificateKeyFile: /etc/ssl/certificates/ldapslave-01-key.pem olcToolThreads: 1 # module{0}, config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_md . . . # {0}mdb, config dn: olcBackend={0}mdb,cn=config objectClass: olcBackendConfig olcBackend: {0}mdb # {-1}frontend, config dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcSizeLimit: 500 # {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=exte rnal,cn=auth manage by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}VKs74I0HQj84sDa2f8Ie3fwYdEL/BVtb # {1}mdb, config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=net olcAccess: {0} to * by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=e xternal,cn=auth write by dn.exact=cn=ldap-admin,ou=users,dc=example,dc=net wr ite by dn.exact=cn=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1} to attrs=userPassword by anonymous auth by self write by * none olcAccess: {2} to attrs=shadowLastChange by self write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {SSHA}psW8QuHfZE1qFpyXTE8r4RGdzzonln6a olcSyncrepl: {0}rid=1 provider=ldaps://ldapmaster.example.net type=refreshAndP ersist retry="5 5 300 +" filter="(ObjectClass=*)" scope=sub bindmethod=simple searchbase="dc=example,dc=net" binddn="cn=repl-user,ou=users,dc=example,dc=n et" credentials=geheim syncdata=accesslog logbase="cn=accesslog" logfilter="( &(objectClass=auditWriteObject)(reqResult=0)) olcUpdateRef: ldaps://ldapmaster.example.net olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: entryCSN,entryUUID eq olcDbMaxSize: 1073741824 ------------- I can access the accesslog-DB with ldapsearch as repl-user: ----------------- root@ldapslave-01:~# ldapsearch -x -D cn=repl-user,ou=users,dc=example,dc=net -w geheim -b cn=accesslog -H ldaps://ldapmaster.example.net -LLL dn: cn=accesslog objectClass: auditContainer cn: accesslog dn: reqStart=20200908174203.000008Z,cn=accesslog objectClass: auditAdd reqStart: 20200908174203.000008Z reqEnd: 20200908174203.000011Z reqType: add reqSession: 18446744073709551615 reqAuthzID: cn=accesslog reqDN: cn=accesslog reqResult: 0 reqMod: objectClass:+ auditContainer reqMod: cn:+ accesslog reqMod: structuralObjectClass:+ auditContainer ----------------- On the provider I see the following messages when accessing the accesslog: ----------------- Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 ACCEPT from IP=192.168.56.16:52338 (IP=0.0.0.0:636) Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 TLS established tls_ssf=256 ssf=256 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" method=128 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 BIND dn="cn=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE ssf=0 Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=0 RESULT tag=97 err=0 text= Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 op=2 UNBIND Sep 08 19:45:54 ldapmaster slapd[2211]: conn=1058 fd=14 closed ----------------- I see these messages even when I restart the consumer. So I think there is no problem with the access-permissions. any help is welcome :-) Stefan

4 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical