openldap-technical

openldap-technical@openldap.org

21 participants
9787 discussions

pcacheOffline cache is expired and stale instead of indefinitely cached
by Tri Tu 14 Jul '22

14 Jul '22

Hello, I understand that with the pcacheOffline TRUE and the cache contents can be use indefinitely but its cache data never get refresh with remote DSA. It's not really useful once user is login 1st time and their user attributes would not get refresh with DSA after that. But the default configuration option of pcacheOffline FALSE, pcache would use the local cached data, refresh with remote DSA and continues to response with its cached data when the DSA is cut off/unreachable. However if remote DSA is offline and the existing cached is expired, the client would get the respond with error "Proxy operation retry failed" as "cache is stale", pcache is checking with remote DSA for refresh but remote DSA is unreacheable offline. Can we continue to use the existing expired cached data (the cache contents to be used indefinitely) with pcacheOffline FALSE until remote DSA is back online (days/weeks later)? Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 do_bind Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: >>> dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com> Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <<< dnPrettyNormal: <uid=userX,ou=employees,o=mycompany.com>, <uid=userX,ou=employees,o=mycompany.com> Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 BIND dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: do_bind: version=3 dn="uid=userX,ou=employees,o=mycompany.com" method=128 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => bdb_entry_get: ndn: "uid=userX,ou=employees,o=mycompany.com" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => bdb_entry_get: oc: "(null)", at: "(null)" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => bdb_entry_get: found entry: "uid=userX,ou=employees,o=mycompany.com" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: bdb_entry_get: rc=0 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: str2filter "(uid=userX)" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: begin get_filter Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: EQUALITY Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: end get_filter 0 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: Lock QC index = 0x562be57eb700 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: QUERY ANSWERABLE (answered 115 times) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => hdb_search Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: bdb_dn2entry("uid=userX,ou=employees,o=mycompany.com") Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access to "uid=userX,ou=employees,o=mycompany.com" "entry" requested Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <= root access granted Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access granted by manage(=mwrscxd) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: base_candidates: base: "uid=userX,ou=employees,o=mycompany.com" (0x00000003) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => test_filter Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: EQUALITY Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access to "uid=userX,ou=employees,o=mycompany.com" "uid" requested Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <= root access granted Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: => access_allowed: search access granted by manage(=mwrscxd) Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: <= test_filter 6 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: pc_bind_search: cache is stale, reftime: 1655318380, current time: 1655318385 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: send_ldap_result: conn=1115 op=0 p=3 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: send_ldap_result: err=0 matched="" text="" Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: =>ldap_back_getconn: conn=1115 op=0: lc=0x7f2644105d10 inserted refcnt=1 rc=0 Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: activity on 1 descriptor Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: activity on: Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=7 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=9 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=10 active_threads=0 tvp=zero Jun 15 18:39:45 prd-ldap1-euc1 slapd[12041]: daemon: epoll: listen=11 active_threads=0 tvp=zero Jun 15 18:39:55 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 ldap_back_retry: retrying URI="ldaps://dsa.mycompany.com" DN="" Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: send_ldap_result: conn=1115 op=0 p=3 Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: send_ldap_result: err=52 matched="" text="Proxy operation retry failed" Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: send_ldap_response: msgid=1 tag=97 err=52 Jun 15 18:40:05 prd-ldap1-euc1 slapd[12041]: conn=1115 op=0 RESULT tag=97 err=52 text=Proxy operation retry failed Jun 15 18:40:06 prd-ldap1-euc1 slapd[12041]: daemon: activity on 1 descriptor Jun 15 18:40:06 prd-ldap1-euc1 slapd[12041]: daemon: activity on: Thanks

3 4

mdb_dbi_open
by Sam Dave 14 Jul '22

14 Jul '22

Hello, The docs for mdb_dbi_open mention: "This function must not be called from multiple concurrent transactions in the same process. A transaction that uses this function must finish (either commit or abort) before any other transaction in the process may use this function." Is this talking about a given environment, or does this text also hold across multiple environments? Thanks, S. Dave

2 1

TLS negotiation failure
by aRaviNd 14 Jul '22

14 Jul '22

Hi All, I am trying to debug an issue related to Chef-manage WebUI trying to authenticate users using LDAP. Authentication was working fine but after upgrading the LDAP server to the latest version of the OS we are getting authentication failures below are the errors showing in the log Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14) Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14): got connid=1003 Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): checking for input on id=1003 Jul 13 20:26:52 ldap.local slapd[18572]: op tag 0x77, time 1657744012 Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 do_extended Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 13 20:26:52 ldap.local slapd[18572]: do_extended: oid=1.3.6.1.4.1.1466.20037 Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 STARTTLS Jul 13 20:26:52 ldap.local slapd[18572]: send_ldap_extended: err=0 oid= len=0 Jul 13 20:26:52 ldap.local slapd[18572]: send_ldap_response: msgid=0 tag=120 err=0 Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 RESULT oid= err=0 text= Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on: Jul 13 20:26:52 ldap.local slapd[18572]: Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on: Jul 13 20:26:52 ldap.local slapd[18572]: 14r Jul 13 20:26:52 ldap.local slapd[18572]: Jul 13 20:26:52 ldap.local slapd[18572]: daemon: read active on 14 Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=11 active_threads=0 tvp=NULL Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14) Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14): got connid=1003 Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): checking for input on id=1003 Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): TLS accept failure error=-1 id=1003, closing Jul 13 20:26:52 ldap.local slapd[18572]: connection_closing: readying conn=1003 sd=14 for close Jul 13 20:26:52 ldap.local slapd[18572]: connection_close: conn=1003 sd=14 Jul 13 20:26:52 ldap.local slapd[18572]: =>ldap_back_conn_destroy: fetching conn 1003 Jul 13 20:26:52 ldap.local slapd[18572]: daemon: removing 14 Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 fd=14 closed (TLS negotiation failure) Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on:: We are not seeing the error while connecting to OpenLDAP servers using OpenSSL or LDAP client tools. How can we debug further to see why the server was not able to complete TLS negotiation? Package versions are openldap-2.4.44-25.el7_9.x86_64 openssl-1.0.2k-25.el7_9.x86_64 kernel-3.10.0-1160.66.1.el7.x86_64 Regards, Aravind M D

2 1

When pwdReset is set to TRUE
by Francesco Malvezzi 13 Jul '22

13 Jul '22

hi all, the pwdReset attribute is set to TRUE on password reset unless entry's pwdPolicySubentry's pwdMustChange is FALSE or missing? Does the default policy's pwdMustChange play a role (even on entries with valid pwdPolicySubentry)? thank you, Francesco

1 0

How to relay read and write requests to different ldap servers
by nagamani.chinnapaiyan＠viasat.com 13 Jul '22

13 Jul '22

Hi, I am new to ldap. We have 4 ldap servers, 2 of them are in mirror-mode providers, 2 of them are just consumers/replicas. I am working on loadbalancer for these 4 ldap servers using ldap/meta backend. I want to the ldap proxy/loadbalancer to, redirect write requests to one of the 2 mirror-mode providers. redirect read requests to any of the 2 replicas/consumers. I know ldap backend has uri list which can be used to redirect to mirror-mode providers. But I want to redirect only the write requests. Regards, Nagamani Chinnapaiyan

5 8

pwdChangedTime range query
by Francesco Malvezzi 13 Jul '22

13 Jul '22

hi all, I am using some pwdChangedTime range queries to warn users about password expiration. An example filter might be: (&(pwdChangedTime<=20211019000000Z)(pwdChangedTime>=20211018000001Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu)) since in-place upgrade to OpenLDAP-2.6.2 these queries return no entries. If I remove either comparison condition: (&(pwdChangedTime>=20211018000001Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu)) (&(pwdChangedTime<=20211019000000Z)(pwdPolicySubentry=cn=default270g,ou=policies,ou=people,dc=example,dc=edu)) they both work. Did I forget some re-index? thank you in advance for your time, Francesco

4 6

RE26 testing call #2 (OpenLDAP 2.6.3)
by Quanah Gibson-Mount 11 Jul '22

11 Jul '22

This is the second testing call for OpenLDAP 2.6.3. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/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.6.3 Engineering Fixed librewrite declaration of calloc (ITS#9841) Fixed libldap to check for NULL ld (ITS#9157) Fixed libldap memory leaks (ITS#9876) Fixed lloadd to correctly tag Notice of Disconnection (ITS#9856) Fixed slapd kqueue support (ITS#9847) Fixed slapd delta-sync DN leak on ADD ops (ITS#9866) Fixed slapd replication with back-glue (ITS#9868) Fixed slapd lastbind replication with chaining (ITS#9863) Fixed slapd-ldap to correctly set authzid (ITS#9863) Fixed slapd-mdb to check for stale readers on MDB_READERS_FULL (ITS#7165) Fixed slapd-mdb indexer task with replicated config (ITS#9858) Fixed slapo-accesslog onetime memory leak (ITS#9864) Fixed slapo-ppolicy interaction with slapo-rwm (ITS#9871) Fixed slapo-rwm to handle escaping special characters (ITS#9817) Fixed slapo-syncprov memory leaks (ITS#9867) Fixed slapo-syncprov fallback in delta-sync mode (ITS#9823) Fixed slapo-unique to not release NULL entry (ITS#8245) Build Environment Added slapd-watcher -c contextDN option (ITS#9865) Fixed parallel builds (ITS#9840) Fixed test020 to skip back-wt (ITS#9859) Fixed slapd-watcher SID handling with single URI (ITS#9850) Fixed test043 with workaround for ITS#9878 Contrib Added slapo-emptyds contrib module (ITS#8882) Added slapo-ciboolean contrib module (ITS#9855) Fixed slapo-autogroup backwards compat (ITS#9020) Update ppm module to the 2.2 release (ITS#9846) Documentation Fixed ldap_get_option(3) to clarify ldap_get/set_option restrictions (ITS#9824) Fixed slapd-ldap(5),slapd-meta(5) missing bold tag on authz parameter (ITS#9872) Regards, Quanah

2 1

RE25 testing call #2 (OpenLDAP 2.5.13)
by Quanah Gibson-Mount 11 Jul '22

11 Jul '22

This is the second testing call for OpenLDAP 2.5.13. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/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.5.13 Engineering Fixed librewrite declaration of calloc (ITS#9841) Fixed libldap memory leaks (ITS#9876) Fixed slapd kqueue support (ITS#9847) Fixed slapd delta-sync DN leak on ADD ops (ITS#9866) Fixed slapd replication with back-glue (ITS#9868) Fixed slapd-mdb to check for stale readers on MDB_READERS_FULL (ITS#7165) Fixed slapo-accesslog onetime memory leak (ITS#9864) Fixed slapo-ppolicy interaction with slapo-rwm (ITS#9871) Fixed slapo-syncprov memory leaks (ITS#9867) Fixed slapo-syncprov fallback in delta-sync mode (ITS#9823) Fixed slapo-unique to not release NULL entry (ITS#8245) Build Environment Added slapd-watcher -c contextDN option (ITS#9865) Fixed parallel builds (ITS#9840) Fixed test020 to skip back-wt (ITS#9859) Fixed slapd-watcher SID handling with single URI (ITS#9850) Fixed test043 with workaround for ITS#9878 Contrib Added slapo-emptyds contrib module (ITS#8882) Fixed slapo-autogroup backwards compat (ITS#9020) Documentation Fixed ldap_get_option(3) to clarify ldap_get/set_option restrictions (ITS#9824) Fixed slapd-ldap(5),slapd-meta(5) missing bold tag on authz parameter (ITS#9872) Thanks! Regards, Quanah

2 1

Re: Pass-through
by Stéphane Veyret 11 Jul '22

11 Jul '22

Hello Quanah, Thank you for your answer (and sorry for double-reply, I forgot to answer to all at first time). > The way that SASL passthrough works is that you put the value {SASL} for > the userPassword. This tells slapd to pass the user authentication to SASL > to handle. You don't set an actual password value in the userPassword > attribute. Actually, I did not set a real password, only, as I saw in examples : userPassword: {SASL}user@realm (you don’t directly see it in the extracts I provided because the password there is base64 encoded). I tried setting only, as you suggested : userPassword: {SASL} but I don’t have any better result. Regards, Stéphane

2 1

dirSync syncrepl_dirsync_message: unknown attributeType member;range=1-1
by Christopher Paul 09 Jul '22

09 Jul '22

Hello OpenLDAP-Technical, I am testing the dirSync replication. I am trying to replicate Active Directory (Windows Server 2019) -> OpenLDAP 2.5.12 from symas-openldap-servers-2.5.12-1.el8.x86_64 RPM on RedHat 8.6. Group members are not replicating, and I am seeing this error: syncrepl_dirsync_message: rid=999 unknown attributeType member;range=1-1 In this case, "member" is a recognized attribute per "core.schema" and is not a problem unless sent with the range indicator, which seems not to be part of the protocol but rather be an AD "embellishment". Those responsible for AD call this "Searching Using Range Retrieval" if you care to look it up. I guess has this default now of 1500 max values for an LDAP response, and it will indicate that the attribute has greater than this number of values by sending "member;range=0-1499" instead of "member" as the attribute type in the result data if there are more than 1500 values, and subsequently, if the amount is greater than 3000, "member;range=1500-2999", etc. I also observed (using packet capture) that when using the dirSync control, all groups are sent with this range notation, even if below the limit, even if just one member, Windows Server 2019 AD DS sends a PartialAttributeList of type "member;range=1-1". Although using ldapsearch without the control only will send the range notation if the number of member values is greater than the 1500 limit. So I am wondering if anyone else has seen this? Am I doing something wrong or is this a bug? What version of Windows was the dirSync syncrepl functionality developed to work with and/or tested with? I can provide more info as needed as this issue is just testing right now in my local lab. Thanks, Chris Paul | Rex Consulting | https://www.rexconsulting.net

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical