dynlist vs memberof performance issues
by Mark Cairney
Hi,
I've been out the LDAP loop for a bit but the recent discussion of the
memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box,
removed the memberof elements from the database and replaced the
memberof overlay with dynlist the queries appear to work as expected but
are both a) slow and b) heavily CPU-intensive on the LDAP server.
2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738
(IP=129.215.17.9:636)
2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256
tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0
filter="(objectClass=*)"
2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms
2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014
etime=0.000214 nentries=1 text=
2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 BIND dn="" method=163
2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030
etime=0.009084 text=SASL(0): successful result:
2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 BIND dn="" method=163
2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031
etime=0.000181 text=SASL(0): successful result:
2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND dn="" method=163
2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK"
authzid="mcairney(a)EASE.ED.AC.UK"
2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 BIND
dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk"
mech=GSSAPI bind_ssf=256 ssf=256
2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024
etime=0.000409 text=
2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH
base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0
filter="(uid=mcairney)"
2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SRCH attr=* +
2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=5 UNBIND
2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031
etime=13.233679 nentries=1 text=
2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk
slapd[30075]: conn=1019 fd=12 closed
I'm guessing that as the values are computed that this will be heavier
on the CPU but it seems a bit excessive? Has anyone else noticed any
similar performance issues?
This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I
guess this could be a factor but there's no io waiting on the server and
no swapping?
The database is on a par in size with our Production service ( about
400K user objects with 1 group object per user and then about 80K actual
groups of users)
The config for the primary DB (ACLs and rootPW redacted) is:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /opt/openldap/var/openldap-data/authorise
olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 2
olcReadOnly: FALSE
olcSecurity: ssf=1
olcSecurity: update_ssf=112
olcSecurity: simple_bind=64
olcSizeLimit: unlimited
olcSyncUseSubentry: FALSE
olcTimeLimit: unlimited
olcMonitoring: TRUE
olcDbEnvFlags: writemap
olcDbEnvFlags: nometasync
olcDbNoSync: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: eduniType eq
olcDbIndex: gecos pres,eq,sub
olcDbIndex: eduniCategory eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: eduniSchoolCode eq
olcDbIndex: eduniIDStatus eq
olcDbIndex: eduniCollegeCode eq
olcDbIndex: eduniOrgCode eq
olcDbIndex: memberOf pres,eq
olcDbIndex: eduniLibraryBarcode pres,eq
olcDbIndex: eduniOrganisation pres,eq,sub
olcDbIndex: eduniServiceCode pres,eq
olcDbIndex: krbName pres,eq
olcDbIndex: eduPersonAffiliation pres,eq
olcDbIndex: eduPersonEntitlement pres,eq
olcDbIndex: sn pres,eq,sub
olcDbIndex: eduniIdmsId pres,eq
olcDbIndex: member pres,eq
olcDbIndex: memberUid pres,eq
olcDbIndex: eduniRefNo pres,eq
olcDbIndex: eduniTitle pres,eq
olcDbIndex: title pres,eq,sub
olcDbIndex: eduniCardNumber pres,eq
olcDbIndex: eduniYearOfStudy eq
olcDbIndex: description pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: aliasedObjectName eq
olcDbIndex: yubiKeyId pres,eq
olcDbIndex: isMemberOf pres,eq
olcDbIndex: hasMember pres,eq
olcDbIndex: proxyAddresses pres,eq,sub
olcDbMaxReaders: 96
olcDbMaxSize: 32212254720
olcDbMode: 0600
olcDbSearchStack: 16
structuralObjectClass: olcMdbConfig
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
structuralObjectClass: olcSyncProvConfig
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 02+00:00 00+04:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcDynListConfig
olcOverlay: {2}dynlist
olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames
structuralObjectClass: olcDynListConfig
--
/****************************
Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh
Tel: 0131 650 6565
Email: Mark.Cairney(a)ed.ac.uk
*******************************/
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
2 months, 1 week
Empty error when configuring OpenLDAP
by Cezary Drożak
Hello,
I am trying to set up OpenLDAP on Arch Linux on my server, following
instruction on Arch Wiki[1]. I prepared the config.ldif file, replacing
every $BASEDN and $PASSWD in the example configuration:
# The root config entry
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /run/openldap/slapd.args
olcPidFile: /run/openldap/slapd.pid
# Schemas
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# TODO: Include further schemas as necessary
include: file:///etc/openldap/schema/core.ldif
# The config database
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootDN: cn=Manager,dc=example,dc=com
# The database for our entries
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: dc=example,dc=com
olcRootDN: cn=Manager,dc=example,dc=com
olcRootPW: {SSHA}xZqSQN4wG4+C5I57dB/Qm02vJ+kQcwd7
olcDbDirectory: /var/lib/openldap/openldap-data
# TODO: Create further indexes
olcDbIndex: objectClass eq
Then I executed the following command:
sudo -u ldap slapadd -n 0 -F /etc/openldap/slapd.d/ -l ./config.ldif
This gave me the following error:
invalid config directory /etc/openldap/slapd.d/, error 2
slapadd: bad configuration directory!
I checked that the directory did not exist, so I created it and changed
owner to `ldap`. The wiki page did not mention that the directory should
be created earlier, so maybe it should have been created by a post
installation script. If that's the case, I will report it to package
maintainers.
After I created the directory, I ran the command again, this time having
a different error message:
slapadd: could not add entry dn="cn=config" (line=1):
Closing DB...
I have no idea what is wrong now and I cannot find anything useful on
the internet. Does anyone have an idea what I may be doing wrong here?
[1]: https://wiki.archlinux.org/title/OpenLDAP
7 months
Re: Pass-through
by Stéphane Veyret
Could it be that the SASL global configuration (also given in first
message) is wrong? I only set those 2 options:
olcSaslHost: localhost
olcSaslSecProps: none
7 months, 1 week
OpenLDAP on Debian 11: missing TLS ciphers?
by Jochen Keutel
Hello,
we installed the standard OpenLDAP package on Debian 11. Checking the
TLS ciphers offered by the server we could see that all six Camellia
ciphers are gone (128 and 256, for TLS 1.0, 1.1, 1.2) compared with the
standard OpenLDAP package on Debian 9.
Is this special to the Debian package? Or: Has Gnutls changed something?
We did run into this issue because some special devices (e.G. Cisco
Prime Collaboration Assurance) cannot connect to the new OpenLDAP
server. The server logfile states: TLS handshake: negotiation failure.
It's not yet clear whether they really can "speak" only Camellia ...
Regards
Jochen.
7 months, 3 weeks
OpenLDAP 2.6 is holding connections open
by Bradley T Gill
All,
I have been struggling with upgrading OpenLDAP from 2.4 to 2.5/2.6 for some time. We have finally found that we needed to rebuild the schema from scratch and re-add our customizations. The database is now running much better with one lingering problem. Our Established connections just continues to grow until we run out of resources. Below is our cn=config (minus some unrelated info). This is on the same server as where the previous version was running, so changes are openldap and openssl versions. Any insights as to what might be causing the ESTABLISHED connections to continually grow would be very appreciated.
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 422b88f4
dn: cn=config
objectClass: olcGlobal
cn: config
olcAttributeOptions: lang-
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexHash64: FALSE
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
olcLogLevel: 256
olcLogFileOnly: FALSE
olcMaxFilterDepth: 1000
olcReadOnly: FALSE
olcSaslAuxpropsDontUseCopyIgnore: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 262143
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcThreadQueues: 1
olcTLSCRLCheck: none
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
olcToolThreads: 1
structuralObjectClass: olcGlobal
creatorsName: cn=config
createTimestamp: 20220726200129Z
olcAuthzPolicy: any
olcWriteTimeout: 30
olcSizeLimit: size.soft=unlimited size.hard=unlimited size.unchecked=unlimited
size.pr=1000 size.prtotal=unlimited
7 months, 3 weeks
SASL GSSAPI Channel Binding testing
by Andreas Hasenack
Hello,
openldap 2.5.12
cyrus-sasl 2.1.28 + sasl channel binding patch[1] + gss-spnego maxssf=0 patch[2]
openldap linked with gnutls
libsasl2-modules-gssapi-mit
I'm currently testing the patches[1][2] for sasl channel binding over
GSSAPI + ssl/tls connection, and was wondering if I could get openldap
to reject ldaps connections without sasl channel binding. Currently it
seems to always accept it, but I can't be sure CB was even checked by
the server by looking at logs (even with -d -1). I got windows 2016 AD
to reject ldaps connections without CB over gssapi and gss-spnego, so
the client part of openldap (ldapwhoami specifically) seems ok.
I looked at test 077[3] and it runs the server with this configuration:
dn: cn=config
changetype: modify
replace: olcSaslCBinding
olcSaslCBinding: ${acb}
Where `${acb}` loops over the 3 valid values of "none" "tls-unique"
"tls-endpoint".
Then a simple connection with ldapwhoami is attempted, also looping -o
SASL_CBINDING=$icb over those values.
I have seen the comment in that test script that it looks like
tls-unique is broken when used with gnutls[4], and also a comment
about MIT failing in another case[5].
When trying it manually, though, I could never get the client
connection to be refused by the server. Before digging in deeper, let
me just ask if my understanding is correct:
- server configured with:
dn: cn=config
changetype: modify
replace: olcSaslCBinding
olcSaslCBinding: tls-endpoint
- client connecting to that server over ldaps://, with GSSAPI, and
with -o SASL_CBINDING=none
Should that client be rejected?
Sample run:
$ sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config
'(olcSaslCBinding=*)' olcSaslCBinding
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
olcSaslCBinding: tls-endpoint
$ ldapwhoami -Y GSSAPI -H ldaps://k-slapd.lxd -o SASL_CBINDING=none
SASL/GSSAPI authentication started
SASL username: ubuntu@VMS
SASL SSF: 256
SASL data security layer installed.
dn:uid=ubuntu,cn=gssapi,cn=auth
And the server logs (olcLogLevel: stats):
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 ACCEPT from
IP=10.0.100.36:33800 (IP=0.0.0.0:636)
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 TLS established
tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 BIND dn="" method=163
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=0 RESULT tag=97
err=14 qtime=0.000011 etime=0.002447 text=SASL(0): successful result:
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 BIND dn="" method=163
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=1 RESULT tag=97
err=14 qtime=0.000012 etime=0.000069 text=SASL(0): successful result:
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND dn="" method=163
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND
authcid="ubuntu" authzid="ubuntu"
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 BIND
dn="uid=ubuntu,cn=gssapi,cn=auth" mech=GSSAPI bind_ssf=256 ssf=256
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=2 RESULT tag=97 err=0
qtime=0.000012 etime=0.000109 text=
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 EXT
oid=1.3.6.1.4.1.4203.1.11.3
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 WHOAMI
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=3 RESULT oid= err=0
qtime=0.000016 etime=0.000087 text=
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 op=4 UNBIND
Jul 25 14:38:36 k-slapd slapd[261]: conn=1002 fd=14 closed
1. https://github.com/cyrusimap/cyrus-sasl/commit/975edbb69070eba6b035f08776...
2. https://github.com/cyrusimap/cyrus-sasl/pull/603/commits
3. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/te...
4. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/te...
5. https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/te...
8 months
Re: Pass-through
by Stéphane Veyret
> Ok, you may need to run slapd under debug mode (-1) and then try binding as
> one of the users with userPassword set to the {SASL}username@realm value
> to see what it's doing.
Is this what I did in my first post
(https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.or...,
the log is at the end of the message) or is there some missing
information ?
By the way, I don’t know why GMail is starting a new thread each time
I answer to you… :-/
8 months, 2 weeks
Re: Pass-through
by Stéphane Veyret
Le lun. 11 juil. 2022 à 17:22, Quanah Gibson-Mount
<quanah(a)fast-mail.org> a écrit :
> Do the logs from saslauthd show that LDAP is actually forwarding the
> requests to it?
No, I have nothing at saslauthd side, except the starting logs :
# saslauthd -d -a kerberos5
saslauthd[31345] :num_procs : 5
saslauthd[31345] :mech_option: NULL
saslauthd[31345] :run_path : /run/saslauthd
saslauthd[31345] :auth_mech : kerberos5
saslauthd[31345] :using accept lock file: /run/saslauthd/mux.accept
saslauthd[31345] :master pid is: 0
saslauthd[31345] :listening on socket: /run/saslauthd/mux
saslauthd[31345] :using process model
saslauthd[31345] :forked child: 31346
saslauthd[31346] :acquired accept lock
saslauthd[31345] :forked child: 31347
saslauthd[31345] :forked child: 31348
saslauthd[31345] :forked child: 31349
--
Bien cordialement, / Plej kore,
Stéphane Veyret
8 months, 2 weeks
pcacheOffline cache is expired and stale instead of indefinitely cached
by Tri Tu
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
8 months, 2 weeks
