iNetOrgPerson doesn't exist?
by Luca Stancapiano
Hi all, I'm triing to create a user with openldap 2.4
dn: uid=rrrrrr,ou=users,dc=my-domain,dc=com
objectClass: iNetOrgPerson
uid: iiiiii
but it doesn't seem recognize the objectClass producing this error:
adding new entry "uid=rrrrrr,ou=users,dc=my-domain,dc=com"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax
Using other object classes is ok. What's the problem?
3 weeks
Re: OpenSSL1.1.1 support after its EOL
by Anil 1. Tadikamalla (EXT-NSB)
Hi Team,
Can you please help to address below queries ASAP from OpenLDAP point of view:
1. Please do let us know if OpenLDAP can provide extended support of OpenSSL1.1.1 beyond the EOL(End of life cycle) i.e after september 2023?
2. Does OpenLDAP depend on RHEL for OpenSSL support or Does it package OpenSSL on its own? If it depends on RHEL and RHEL introduces OpenSSL3.0 support, how would this be handled by OpenLDAP?
Regards,
Anil Kumar
________________________________
From: Anil 1. Tadikamalla (EXT-NSB)
Sent: Friday, December 9, 2022 9:54:28 AM
To: openldap-technical(a)openldap.org
Cc: Seenivasan 1. Alagarsamy (EXT-NSB)
Subject: Re: OpenSSL1.1.1 support after its EOL
Hi Team,
GENTLE REMINDER....
Can you please help to address below query to from OpenLDAP Point of View ASAP.
Does OpenLDAP depend on RHEL for OpenSSL support or Does it package OpenSSL on its own? If it depends on RHEL and RHEL introduces OpenSSL3.0 support, how would this be handled by OpenLDAP?
Regards,
Anil Kumar
________________________________
From: Anil 1. Tadikamalla (EXT-NSB)
Sent: Friday, December 9, 2022 12:53 AM
To: openldap-technical(a)openldap.org
Cc: Seenivasan 1. Alagarsamy (EXT-NSB)
Subject: OpenSSL1.1.1 support after its EOL
Hi Team,
Please do let us know if OpenLDAP can provide extended support of OpenSSL1.1.1 beyond the EOL(End of life cycle) i.e after september 2023?
Regards,
Anil Kumar
3 months, 2 weeks
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.
4 months, 3 weeks
Help for filter in openldap server
by baalchina
Hi, all
I had a old openldap server from my colleague, and I am studying the
server.
I found a strange problem, when I using client(ldapadmin in Windows), I can
filter by uid, objectClass,sn or anything else, but except inetUserStatus.
For example, when I searching by 'sn=*', or 'sn=Jim', which jim is the
exact name of my user, I will got the correct result.
But when I searching by 'inetUserStatus=Inactive' or
'inetUserStatus=Active', nothing happens.
I also tried 'inetUserStatus=*', and got the whole ldap users.
The same happens in the memberOf attribute, which 'memberOf=*' got the
whole users, and 'memberOf=cn=ABC*' got nothing. (My ldap users all have a
attribute of 'memberOf: cn=ABC,ou=Groups,dc=abc,dc=cn'.
So, what should I do if I want to using this two attribute memberOf and
inetUserStatus?
Thanks a lot.
--
from:baalchina
4 months, 4 weeks
Slow Mod operations on LDAP
by Bhanush Mehta
Hi All,
We are seeing very slow MOD operations on our ldap (250 MB data dump),
while using mdb (data.mdb is 6.4 Gb). The average MOD operation is going to
8-9 seconds.
We are seeing 1k disk ops and 6-7MB/s writes. The disk is 4096 IOPS Sata
SSD, we have seen write speed to be 126 MB/s generally.
The slapd version is slapd (May 14 2022 18:35:44).
We the following olcDbIndex for eq: objectClass, entryCSN , entryUUID eq,
uid , uidNumber , uniqueMember ,gidNumber , memberUid ,displayName ,cn ,sn
, member, source , supervisor ,accountExpiryDate
And, sortVals for memberUid and member.
Regards
Bhanush
--
*-----------------------------------------------------------------------------------------*
*This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error, please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee,
you should not disseminate, distribute or copy this email. Please notify
the sender immediately by email if you have received this email by mistake
and delete this email from your system. If you are not the intended
recipient, you are notified that disclosing, copying, distributing or
taking any action in reliance on the contents of this information is
strictly prohibited.*****
****
*Any views or opinions presented in this
email are solely those of the author and do not necessarily represent those
of the organization. Any information on shares, debentures or similar
instruments, recommended product pricing, valuations and the like are for
information purposes only. It is not meant to be an instruction or
recommendation, as the case may be, to buy or to sell securities, products,
services nor an offer to buy or sell securities, products or services
unless specifically stated to be so on behalf of the Flipkart group.
Employees of the Flipkart group of companies are expressly required not to
make defamatory statements and not to infringe or authorise any
infringement of copyright or any other legal right by email communications.
Any such communication is contrary to organizational policy and outside the
scope of the employment of the individual concerned. The organization will
not accept any liability in respect of such communication, and the employee
responsible will be personally liable for any damages or other liability
arising.*****
****
*Our organization accepts no liability for the
content of this email, or for the consequences of any actions taken on the
basis of the information *provided,* unless that information is
subsequently confirmed in writing. If you are not the intended recipient,
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.*
_-----------------------------------------------------------------------------------------_
4 months, 4 weeks
OpenLDAP stats logging performance degradation
by Christopher Paul
Hello OpenLDAP-Technical,
Using the oldie but goodie LDAP performance testing tool, SLAMD, I've been doing performance tests. What I found was that stats logging (olcLogLevel: 256) degrades performance significantly. A pity, because it is recommended in the manual. Also, it considered very useful by those of us who've been running OpenLDAP for a while.
The test was performed on Dell Workstation Intel Xeon E-2630 v3 @ 2.40Ghz Xen 4.6.5 hypervisor running Linux 4.4.0 Ubuntu 16.04, 4 vcpus pinned to the hypervisor and the other 12 pinned to the OpenLDAP VM. The OpenLDAP VM was allocated 8GB RAM and runs OpenLDAP 2.5.13 (Symas RPM build) on RedHat 8.7. Ten thousand fake users were created in an OU=FakePeople for testing.
I am aware that contention with disk I/O can cause problems, so I tried eliminating systemd-journald and rsyslogd in order to test "pure OpenLDAP" response times but was not perfectly successful. I ran slapd in the foreground using "slapd -d 256 ... 2>/dev/null". But then I noticed that systemd-journald still was logging to "session-4.scope". I tried "systemctl stop systemd-journald" and "systemctl stop systemd-journald.socket" and "systemctl stop systemd-journald-dev-log.socket" but was not able to stop systemd-journald from showing up using CPU in "htop". I tried limiting it also by setting RateLimitIntervalSec=1s and RateLimitBurst=1 in /etc/system/journald.conf. This reduced the logging but I still saw "/usr/lib/system/systemd-journald" taking 100% of one vcpu during the performance tests whenever olcLogLevel was set to 256.
The test results I will include with this post are from the Asynchronous Search Rate SLAMD job class using LDAPSearch filters of valid random values for indexed attributeTypes "uid" and "mail" matching exact filters (equality match).
Using LogLevel 256, the Asynchronous Search Rate test with 3 clients, 2 connection threads each (from laptop i7-1280P vPro Processor), OpenLDAP returned an average 10,932 results completed per second with err=0 and average 21ms response time.
Then I ran ldapmodify to changetype: replace olcLogLevel to 0, reran the same test, and saw OpenLDAP perform much better. The same test with olcLogLevel=0 returned 84,286 results per second with err=0 (671% increase) and average response time of 2.6 ms (88% decrease). Watching "htop" during this test showed all vcpus firing a lot more evenly and hotter than the test with olcLogLevel=256; it was very clear how efficient slapd can be without having to do any logging.
I ran several samples of each test and picked the best for each of olcLogLevels I tested. I ran other tests like 3 and 4 clients times 50 connections each, also ran Basic Bind Rate and saw similar patterns there. I don't mind sharing my configs or the test data if anyone is interested.
And so naturally, I am wondering if this is a known limitation and also whether it is something that can be addressed or is a hard constraint. I guess I had expected some impact as a result of logging (nothing comes for free...) but not this much.
Thanks,
Chris Paul | Rex Consulting | https://www.rexconsulting.net
5 months
slappasswd generating a supposedly incorrect password hash (only when using {SHA256})
by Ralf Hildebrandt
Using slapd 2.5.13+dfsg-1ubuntu1 on ubuntu 22.10:
=================================================
The password hashes are differing between what "slappasswd" and
"openssl dgst" emit:
$ slappasswd -s secret -h '{SHA256}' -o module-path=/usr/lib/ldap -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
With SHA512 on the other hand, the hash generated by different programs is identical:
$ slappasswd -s secret -h '{SHA512}' -o module-path=/usr/lib/ldap -o module-load=pw-sha2
{SHA512}vSsar3708Jvp9Szi2NWZZ02Bqp1qRCFpbcTZPdBhnWgs5WtNZKnvCXdhztmeD2cmW192CF5bDufKRpayrW/isg==
$ echo -n "secret" | openssl dgst -sha512 -binary | openssl enc -base64
vSsar3708Jvp9Szi2NWZZ02Bqp1qRCFpbcTZPdBhnWgs5WtNZKnvCXdhztmeD2cm
W192CF5bDufKRpayrW/isg==
On an older box (ubuntu 20.04) with slapd 2.4.49+dfsg-2ubuntu1.9 we're seeing:
==============================================================================
$ slappasswd -s secret -h '{SHA256}' -o module-path=/usr/lib/ldap -o module-load=pw-sha2
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
$ echo -n "secret" | openssl dgst -sha256 -binary | openssl enc -base64
K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
So why is the SHA256 password hash generated by the 2.5.13 slappasswd
command different from the hashes generated by the other programs/versions?
--
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netzwerk
Campus Benjamin Franklin (CBF)
Haus I | 1. OG | Raum 105
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49 30 450 570 155
ralf.hildebrandt(a)charite.de
https://www.charite.de
5 months, 1 week
Question about Persistent Search
by pham lan
Hello,
I am new to OpenLDAP. May I ask if Persistent Search is supported in any
version of OpenLdap Server? I installed version 2.4.46 from Rocky repo and
it does not seem to support persistent search.
5 months, 2 weeks
lloadd Proxied Authorization Denied (123)
by Stefan Kania
I now took the example configuration and changed it to my settings:
---------------------
TLSCertificateFile /opt/symas/etc/openldap/example-net-cert.pem
TLSCertificateKeyFile /opt/symas/etc/openldap/example-net-key.pem
TLSCACertificateFile /opt/symas/etc/openldap/cacert.pem
pidfile /var/symas/run/slapd.pid
argsfile /var/symas/run/slapd.args
loglevel 256
modulepath /opt/symas/lib/openldap
moduleload lloadd.la
backend lload
listen "ldap://:1389 ldaps://:1636"
feature proxyauthz
TLSShareSlapdCTX true
bindconf bindmethod=simple
network-timeout=5
tls_cacert="/opt/symas/etc/openldap/cacert.pem"
tls_cert="/opt/symas/etc/openldap/example-net-cert.pem"
tls_key="/opt/symas//etc/openldap/example-net-key.pem"
binddn=uid=lloadd,ou=users,dc=example,dc=net credentials=geheim
tier roundrobin
backend-server uri=ldaps://ldap01.example.net starttls=critical retry=5000
max-pending-ops=50 conn-max-pending=10
numconns=10 bindconns=5
backend-server uri=ldaps://ldap02.example.net starttls=critical retry=5000
max-pending-ops=50 conn-max-pending=10
numconns=10 bindconns=5
database monitor
---------------------
The bind-user exists in the database of the backend-server. If i start
the loadbalancer I can see that the connection are established.
-------ldap01-----------
Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 fd=46 ACCEPT from
IP=192.168.56.40:38674 (IP=0.0.0.0:636)
Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 fd=46 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 op=0 BIND
dn="uid=lloadd,ou=users,dc=example,dc=net" method=128
Dez 14 21:07:12 ldap01 slapd[550]: conn=1380 op=0 BIND
dn="uid=lloadd,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
------------------------
I see the same massages on ldap02, so that's ok
The I do a search from a different machine:
-------------
root@ldap03:~# ldapsearch -x -D uid=repl-user,ou=users,dc=example,dc=net
-w geheim -H ldaps://loadbalancer.example.net:1636 -LLL
Proxied Authorization Denied (123)
Additional information: not authorized to assume identity
------------
The uid=repl-user has read permission to all objects and attributes.
On ldap01 I see:
---------ldap01-------------
Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 BIND
dn="uid=repl-user,ou=users,dc=example,dc=net" method=128
Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 BIND
dn="uid=repl-user,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
Dez 14 21:09:13 ldap01 slapd[550]: conn=1371 op=0 RESULT tag=97 err=0
qtime=0.000033 etime=0.015255 text=
-----------------------------
on ldap02
--------ldap02----------
Dez 14 21:09:13 ldap02 slapd[300]: conn=1306 op=1 SEARCH RESULT tag=101
err=123 qtime=0.000044 etime=0.000235 nentries=0 text=not authorized to
assume identity
Dez 14 21:09:13 ldap02 slapd[300]: conn=1306 op=1 do_search: get_ctrls
failed
------------------------
Why do I get different log-entries on the backend-server? And what did I
forgot?
When I do a ldapsearch with uid=lloadd I get:
-------------------
root@ldap03:~# ldapsearch -x -D uid=lloadd,ou=users,dc=example,dc=net -w
geheim -H ldaps://loadbalancer.example.net:1636 -LLL
dn: dc=example,dc=net
objectClass: domain
objectClass: dcObject
dc: example
-------------------
That's the only object the user has permissions to read.
log from ldap01
--------------------
Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 BIND
dn="uid=lloadd,ou=users,dc=example,dc=net" method=128
Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 BIND
dn="uid=lloadd,ou=users,dc=example,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
Dez 14 21:14:04 ldap01 slapd[550]: conn=1381 op=0 RESULT tag=97 err=0
qtime=0.000021 etime=0.008984 text=
--------------------
and log from ldap02
--------------------
Dez 14 21:14:04 ldap02 slapd[300]: conn=1308 op=1 SRCH
base="dc=example,dc=net" scope=2 deref=0 filter="(objectClass=*)"
Dez 14 21:14:04 ldap02 slapd[300]: conn=1308 op=1 SEARCH RESULT tag=101
err=0 qtime=0.000022 etime=0.002048 nentries=1 text=
--------------------
That's also ok, I think . The final version should be that the binduser
uid=lloadd will not see anything.
So what's the point I'm missing to get proxyauthz work correctly?
5 months, 3 weeks
lloadd standalone daemon
by Stefan Kania
Hi to all,
I want to test the "lloadd" as a standalone daemon. I'm using the symas
OpenLDAP 2.6 packages on a debian 11 system. I can only find the module
"lloadd.la" but not the standalone daemon. If I want to us it, do I have
to compile it myself?
What would be the better way using the standalone daemon or use it as a
module as part of slapd.
Stefan
5 months, 3 weeks
