openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

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

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

29 Sep '20

About my last e-mail... I noticed that problem occurs when there is a head piped with the slapcat. I replaced: slapcat -d0 -c | head -n1 | awk -F "dn: " '{print $2}' With: slapcat -d0 -a "objectClass=dcObject" | grep ^dn | awk '{print $2}' And error disappeared. Thank you. 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 -----Mensaje original----- De: Dario García Díaz-Miguel Enviado el: martes, 29 de septiembre de 2020 7:45 Para: 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org> Asunto: What does "slapcat: error writing output" means? 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.

1 0

openssl output
by Shaheena Kazi 24 Sep '20

24 Sep '20

Hello, I am using openssl - 1.1.1d Slapd Version - 2.4.47 I have complied slapd against the openssl to use the support ofTLSv1.3 The path is /opt/openssl/bin/openssl Now, I have a doubt, when I run the below command I get the expected output. /opt/openssl/bin/openssl s_client -connect localhost:636 But when I run /opt/openssl/bin/openssl s_client -connect localhost:389, I get the output as below: root@xxxxxxxxx# /opt/openssl/bin/openssl s_client -connect localhost:389 CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 293 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- +++++++++++++++++++++++++++++++++++++++++++++++++++++ Is this correct? I mean I dont face any issues but the output does not show the Protocol used. ++++++ As for the present openssl I get the below output where it shows the protocol used. root@cxxxxxxxxxxxx# openssl s_client -connect localhost:389 CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1600959876 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- So I am wondering, If I am missing on anything or is it fine ?

2 2

Problems with syncrepl state
by Berthold Cogel 24 Sep '20

24 Sep '20

Hello, we have a cluster of LDAP servers consisting of one provider and 4 consumer. We're upgrading the os of the systems by proving an replacement system for each of the five systems. Then we stop the slapd on the system that should be replaced, dump the database with slapcat, copy it to new system, switch hostname and ip of both systems. We shut down the old and reboot the new system. Then we slapadd the database on the new system. So far so good... We started with the provider. After importing the database and starting the slapd on the new provider, we get errors for the syncrepl state on all consumer systems: "Can't get Context CSN with SID <x> from ldap+tls://localhost. Please set SID with -I option." We're using check_ldap_syncrepl_status from ltb-project with icinga2 to monitor the replication. I don't know how to fix this. When I modify an entry in the provider, it is synced to the consumer. But the status error stays. On all four consumers. I've then 'upgraded' a consumer by starting the slapd on the replacment system without any database. The system started the sync and after completion the error was gone. But syncing takes more time than importing a dump from a local file. And in a case where we have to rebuild the provider from scratch after a crash, it might be not an option to resync one consumer after the other to rebuild the complete cluster. Is there a method to fix the problem? Syncrepl configuration on the provider overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Syncrepl configuration on the consumer syncrepl rid=<x> provider=ldap://yxz:389 binddn="cn=xxxxxxx" credentials="xxxxxxx" tls_cacertdir=/etc/pki/tls/certs tls_reqcert=demand bindmethod=simple starttls=critical searchbase="xxxxxx" type=refreshAndPersist retry="10 10 300 +" filter="(objectClass=*)" scope=sub attrs="*,+" sizelimit=unlimited timelimit=unlimited schemachecking=off Regards Berthold Cogel

3 8

How to delete root DIT
by mi.aleksio＠gmail.com 23 Sep '20

23 Sep '20

Hello all! I have test database: dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcSuffix: dc=aleksio,dc=com olcRootDN: cn=Manager,dc=aleksio,dc=com # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd-config(5) for details. # Use of strong authentication encouraged. olcRootPW: 1 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. olcDbDirectory: /usr/local/var/openldap-data # Indices to maintain olcDbIndex: objectClass eq I created top record: dn: dc=aleksio,dc=com objectClass: dcObject objectClass: organization dc: aleksio o: myorg Record successfully created, I can search this record: ~# ldapsearch -x -w 1 o # extended LDIF # # LDAPv3 # base <dc=aleksio,dc=com> (default) with scope subtree # filter: (objectclass=*) # requesting: o # # aleksio.com dn: dc=aleksio,dc=com o: myorg # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Then I try to delete this record: ~# ldapdelete -x -w 1 'dc=aleksio,dc=com' ldap_delete: No such object (32) If I create child record in DN dc=aleksio,dc=com I can successfully delete this child record. How can I delete root record?

2 1

Why does OpenLDAP think my code didn't bind to the server?
by suryakalpo.sarker＠gmail.com 22 Sep '20

22 Sep '20

I'm trying to use the OpenLDAP C APIs to execute a search query against an AD. #include <ldap.h> #include <iostream> int main(void) { LDAP *ldp; auto ldap_version = LDAP_VERSION3; auto tls_cert_strat = LDAP_OPT_X_TLS_NEVER; //Never require identity cert from peer int err = ldap_initialize(&ldp,"ldap://1.1.1.1"); if (err != LDAP_SUCCESS) { std::cerr << "unable to connect" << std::endl; return -1; } std::cout << "connected, err == " << ldap_err2string(err) << "\n"; ldap_set_option(ldp, LDAP_OPT_PROTOCOL_VERSION, &ldap_version); //Set version to LDAPv3 ldap_set_option(ldp, LDAP_OPT_X_TLS_REQUIRE_CERT, &tls_cert_strat); err = ldap_start_tls_s(ldp, nullptr, nullptr); if (err != LDAP_SUCCESS) { char* msg; ldap_get_option(ldp, LDAP_OPT_DIAGNOSTIC_MESSAGE, &msg); std::cerr << "unable to upgrade to TLS! err: " << ldap_err2string(err) << std::endl; std::cerr << "diagnostic msg: " << msg << "\n"; ldap_memfree(msg); return -1; } std::cout << "start_tls request sent successfully, err == " << ldap_err2string(err) << "\n"; err = ldap_tls_inplace(ldp); if (err != 1) { char* msg; ldap_get_option(ldp, LDAP_OPT_DIAGNOSTIC_MESSAGE, &msg); std::cerr << "TLS handlers not installed! err: " << ldap_err2string(err) << std::endl; std::cerr << "diagnostic msg: " << msg << "\n"; ldap_memfree(msg); return -1; } std::cout << "TLS handlers have been installed sucessfully" << "\n"; //err = ldap_bind_s(ldp, "user(a)domain.com", "foo", LDAP_AUTH_SIMPLE); err = ldap_simple_bind_s(ldp, "user(a)domain.com", "foo"); if (err != LDAP_SUCCESS) { char* msg; ldap_get_option(ldp, LDAP_OPT_DIAGNOSTIC_MESSAGE, &msg); std::cerr << "Unable to bind to domain! err: " << ldap_err2string(err) << std::endl; std::cerr << "diagnostic msg: " << msg << "\n"; ldap_memfree(msg); return -1; } std::cout << "Successfully bound to DC\n"; char* base_dn = const_cast<char*>("dc=domain,dc=com"); char* filters = const_cast<char*>("userPrincipalName=user"); char* attr[4]; attr[0] = const_cast<char*>("samaccountname"); attr[1] = const_cast<char*>("cn"); attr[2] = const_cast<char*>("mail"); attr[3] = nullptr; LDAPMessage* ldp_msg; std::cout << "Executing LDAP search query\n"; err = ldap_search_ext_s(ldp, base_dn, LDAP_SCOPE_SUBTREE, filters, attr, 0, nullptr, nullptr, nullptr, 0, &ldp_msg); if (err != LDAP_SUCCESS) { char* msg; ldap_get_option(ldp, LDAP_OPT_DIAGNOSTIC_MESSAGE, &msg); std::cerr << "Unable to search domain! err: " << ldap_err2string(err) << std::endl; std::cerr << "diagnostic msg: " << msg << "\n"; ldap_memfree(msg); return -1; } std::cout << "Search executed successfully\n"; return 0; } I build the code as follows: g++8 -D LDAP_DEPRECATED -g -std=c++17 my_ldap.cpp -o my_ldap -l ldap But when I execute it, I get the following error: connected, err == Success start_tls request sent successfully, err == Success TLS handlers have been installed sucessfully Successfully bound to DC Executing LDAP search query Unable to search domain! err: Operations error diagnostic msg: 000004DC: LdapErr: DSID-0C0907E1, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580 This is where I'm confused: The diagnostic message says that I didn't bind, but given that ldap_simple_search_s returned LDAP_SUCCESS, that would mean that I did have a successful bind. I would understand if the search fails with a message citing lack of authorization, filter not matching, etc. The only other thing that I could think of is that I may have bound to one DN and executed a search against a different DN, but I checked for any typos several times, and nothing popped up. Just FYI, ldap_bind_s(ldp, "user(a)domain.com", "foo", LDAP_AUTH_SIMPLE) has the same behavior. Now, if the DC didn't like my bind/authentication method, I would imagine that would've caused an error during the bind call, but nothing of the sort happened. I thought about using the built-in debugging of the library as documented in the man pages for ldap_set_option, i.e. the LDAP_OPT_DEBUG_LEVEL option, but the code doesn't compile when I try to use one of the options as shown in the man page (incidentally none of those options are defined in ldap.h) I've tried a few other random (I'm saying random coz I doubt this is the cause) things too: a) Tried binding to the secure port directly instead of upgrading to TLS. b) Tried disabling LDAP_OPT_REFERRALS One strange thing that I observed though was that if the changed the syntax of the bind dn to "uid=user,dc=domain,dc=com" that would result in an "Invalid credentials" error from ldap_bind_s, but the "user(a)domain.com" format is accepted without any errors. I'm unable to check the contents of LDAP* in gdb because I cannot build the openldap port in freeBSD with non-stripped symbols (even though I built the port with debug support). What other angle should I be looking at to understand/resolve this problem?

2 1

error 53 text=consumer state is newer than provider!
by Stefan Kania 22 Sep '20

22 Sep '20

hi, replication is now running, but when I setup all three servers (one provider and two consumers) I get the following errormessage on the provider -------------------- SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! -------------------- And on the consumers: -------------------- syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid 1dc6e700 Sep 21 19:42:03 ldapslave-01 slapd[2360]: syncrepl_entry: rid=001 inserted UUID 61db79ba-907d-103a-80a6-2965db2a1bbb Sep 21 19:42:03 ldapslave-01 slapd[2360]: syncrepl_entry: rid=001 be_search (0) Sep 21 19:42:03 ldapslave-01 slapd[2360]: syncrepl_entry: rid=001 cn=ldap-admin,ou=users,dc=example,dc=net Sep 21 19:42:03 ldapslave-01 slapd[2360]: syncrepl_entry: rid=001 be_add cn=ldap-admin,ou=users,dc=example,dc=net (0) Sep 21 19:42:03 ldapslave-01 slapd[2360]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT Sep 21 19:42:03 ldapslave-01 slapd[2360]: do_syncrep2: rid=001 cookie=rid=001,csn=20200921174113.067710Z#000000#000#000000 Sep 21 19:42:03 ldapslave-01 slapd[2360]: slap_queue_csn: queueing 0x7f6714106290 20200921174113.067710Z#000000#000#000000 Sep 21 19:42:03 ldapslave-01 slapd[2360]: slap_graduate_commit_csn: removing 0x7f6714106290 20200921174113.067710Z#000000#000#000000 Sep 21 19:42:03 ldapslave-01 slapd[2360]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT Sep 21 19:42:03 ldapslave-01 slapd[2360]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Sep 21 19:42:03 ldapslave-01 slapd[2360]: do_syncrep2: rid=001 (53) Server is unwilling to perform -------------------- As soon as I do a modification with "ldapmodify" on the provider and then restart slad on the consumer everything is working fine. Is this normal? Or do I still have configured something wrong? Stefan

2 2

adding sortvals later
by Michael Ströder 17 Sep '20

17 Sep '20

HI! I vaguely remember having asked this before but I forgot the answer: Do I have to re-import or re-index the database when adding directive sortvals to a database containing affected entries? Ciao, Michael.

2 1

"rootDN must be defined before syncrepl may be used" and rootDN, rootpw in general
by Christopher Paul 17 Sep '20

17 Sep '20

Salutations OpenLDAP-Technical, I am thinking of rootDN and how I'm not a big fan of it. You don't need rootDN to configure OpenLDAP (assuming you first load OLC with slapadd). You don't need it to configure OLC if you've set up access to it for admin accounts. It ends up being one shared password that rules everything. Would it not be best to always give elevated access to specific accounts? Yes I understand without privileged admin access in the first place it's a chicken or egg situation to give access to admins but that can be solved with slapadd or slaptest to generate the initial configuration from a text file. And in some extreme cases, it's best to not evaluate access at all. This is the only reason I can think of for rootDN. It seems that syncrepl depends on it though, because when I try to configure a server without rootdn, rootpw and set up syncrepl, I get Other (e.g., implementation specific) error (80) additional info: rootDN must be defined before syncrepl may be used. What do people think about the need, utility, implications of having a password based root account? And why would rootDN need to be defined for syncrepl to work? Many thanks, -- Chris Paul Rex Consulting, Inc https://www.rexconsulting.net

2 3

@Quanah About your blog
by Stefan Kania 15 Sep '20

15 Sep '20

Hi Quanah, I got a question about your blog about MMR. You wrote: Add the syncprov and accesslog overlays to the existing primary database. Note that it will be renumber from dn: olcDatabase={2}mdb,cn=config to dn: olcDatabase={3}mdb,cn=config But you did not explain why you renumber the entry. Could you do tell me the reason ehy you did this? Thank you Stefan

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical